Software Lead Weekly

Prioritization Is a Political Problem as Much as an Analytical Problem
8 minutes read.

Richard Mironov's post reminds me of "Maker schedule vs. Manager schedule." Understanding the different mindsets builders versus sales/marketing use can help find the right strategies to create positive momentum. Don't fight it. We all have our roles to play. Find a way to build proper communications and set expectations to deal with this healthy tension, rather than trying to avoid it.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

People Who Join Startups After Working at Large Companies
1 minutes read.

My humble effort to help you start the weekend with a smile on your face.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Staying Positive
3 minutes read.

"The great thing about working in tech is that there are always new problems to solve, new markets to create, new products to ship. The macro events don’t change that. So focus yourself and your team on building and shipping those things, get some wins, and move forward with optimism and positive energy. It will be infectious." -- Fred Wilson is spot on. Keep pushing.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Three Myths of Headcount. Headcount Is a Topic of Huge Debate in Any Startup. It's Your Largest Expense, and Many People See It as a Silver Bullet. It Isn’t. Here’s Three Myths of Headcount. (Thread)
4 minutes read.

So many great observations by Pedro Franceschi worth understanding. One of my favorites: "When a project isn’t going according to plan, we flirt with the idea of adding more headcount to make it go faster. There’s been zero times where headcount saved a project on a bad trajectory. The difference between great and bad projects is not headcount – it’s leadership. It’s easy to mix the two, because great projects tend to have more headcount. But that's only true because these projects were going well, and the company decided to double down on them."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

GitLab CEO: ‘Remote Work Is Just Work’
5 minutes read.

Undoubtedly, companies that started as "remote ronly" will always find it easier to attract a particular type of talent and claim it works well. It works well for them, as the DNA and an initial group of people who created the company do so effectively. Companies that will force people to come to work every day will suffer as they will push away the majority of the workforce looking for some (I repeat - some!) degree of flexibility. We need to look at how we work and deliver a clear message on the type of work we want people to do at the office and the type of work we believe should work best remotely (home or elsewhere). Adopt Sid Sijbrandij's mindset: "if you’re a leader who is scared of the changes that remote work will bring, I challenge you to make the necessary cultural shifts, adjust your organization’s workflows, and overcome the biggest remote workplace barrier: yourself."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Trade-Offs in Decision Making
4 minutes read.

Leading with the why is critical but also explaining the tradeoffs considered as Tom Sommer covers. It gives the other side the feeling that the team considered multiple directions to make the best decision possible given the context they had. To take it a step further, it's worth documenting the options and the decision in an ADR and sharing that as well.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

4 Tips for Choosing Job Levels When Headcount Planning
4 minutes read.

"My tip is to use a 1-to-2 ratio of senior to junior engineers. That way, senior (or above) engineers can have enough capacity to mentor others and still code." and "I’ve found that adding new people doesn’t pay off for six to 12 months. That first year is about understanding how your team works and building relationships. Account for this onboarding time in your hiring plans." these are important observations you should consider when planning your headcount. Take a look at the projects and products you'd need to execute on, understand their complexity, and from that, the type of technical leadership you need.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

The 7 Roles of a CTO
5 minutes read.

What I appreciate about Oded Blayer's writing here is not only the answers he shares and how he grasps his role, but also the journey he took to seek answers proactively. One thing I saw working well for me is - The CTO connects the business needs to envision the desired technology capabilities. The CTO is often more outbound (customers, investors, partners, etc.), whereas the VP of Engineering focuses more on the inbound (lead the team).

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

@rkoutnik: When I was a kid I wanted to be a science fiction author. Now I'm a software engineer who writes project roadmaps, so mission accomplished?

@marktsimelzon: I think of prototyping with new technologies as a dangerous tool, as it gives engineers false confidence to base their products on completely unproven technologies.