Empowering your team 

What changes for a technical founder once their team starts growing? The focus shifts from individual execution to empowering the team to deliver quality software efficiently. Let's explore how to navigate this important transition successfully.

Technical founders are pivotal in rapidly building features and launching products when founding a startup.

One of the initial objectives is to release a Minimum Viable Product (MVP) as quickly as possible to begin serving paying customers. This approach aims to gather customer feedback and validate product-market fit. As new customers join, the demand for additional features grows. The technical founder is continuously adding new features based on customer feedback. With the influx of customers, the responsibilities of the technical co-founder multiply. They must analyze new feature requests, handle customer support, and maintain the infrastructure. As revenue increases and the founder can no longer manage all tasks alone, the company decides to expand the engineering team by hiring new members.

From building a product to building a team

Hiring new team members is pivotal for the company and the technical founder. Previously, the founder single-handedly built features, knowing exactly what needed to be done. However, with the addition of new team members, the role of the technical co-founder evolves. Where they once handled all operational tasks, they now need to delegate and involve the team in the development process. 

For many first-time technical co-founders, this transition can be uncomfortable. They often wrongly believe they can build features more quickly independently rather than collaborating with the team. This is a misguided perception of productivity where technical debt is accumulated in exchange for quicker delivery. 

While taking on technical debt can sometimes be a strategic choice, it eventually must be addressed and resolved. For example, while skipping unit tests might save time in the short term, it’s proven that tests save time in the long run. 

A founder focused solely on shipping might cut corners by omitting tests, delivering solutions faster than an engineer who ensures comprehensive testing. This can lead to frustration when the founder prioritizes speed over quality, whereas the engineer understands the long-term benefits of thorough testing.

Main takeaways when transitioning from sole developer to team leader

How to manage knowledge workers and giving power to your team

Free Range Management is a book for all leaders that want to create space and give autonomy to their team

Get your copy

Involving your team is crucial

Additionally, founders usually have a deep understanding of the product. When a new feature idea emerges, they might be eager to build it themselves. However, transitioning from builder to enabler is crucial when managing a team. By building a feature solo, the founder misses the opportunity to involve the team, share context, and leverage their diverse insights, often leading to better solutions. 

Moreover, a quickly developed feature by the founder may be flawed, focusing on the happy path and failing in edge cases. When urgent support requests arise, and the founder is occupied with meetings, the team is left to address the issue without sufficient context. The founder becomes frustrated, feeling that the team is not trying to fix urgent issues, but this situation is self-created. They alienate the team by not including them in feature ideation and development and rushing to build and pass on features. 

Engineers see unfamiliar code and are hesitant to address support issues for features they had no part in creating. Instead of actively resolving problems, they may avoid them, leading to further inefficiencies and frustrations. This situation underscores the importance of involving the team early, sharing context, having proper documentation, and ensuring collaborative development to achieve sustainable growth and product quality.

Main lessons when transitioning from builder to enabler

Why would I delegate? 

As your team expands, it’s essential to transition from building features yourself to enabling your team to deliver them. As a founder, your focus should shift from developing core features to empowering your engineering team. While occasional contributions are fine, leave the primary feature development to your team.

Some may argue that involving engineers in feature ideation wastes time, believing that meetings take away time from coding. However, including your team in these discussions is vital for building a successful product. Engineers need comprehensive context about the problems they are solving.

Encourage all team members, even introverted ones, to participate in grooming sessions. Assure them that their opinions are valued and emphasize the importance of understanding the team’s goals and the reasons behind their work. 

Over time, you will notice a positive shift as the team begins to take ownership. They will start providing input on features, suggesting improvements, and proactively addressing issues. This is because they have a deeper understanding of the problems they are solving and feel more connected to the codebase and the product’s overall vision.

Main ideas on why delegating is important

  • Involve engineers in feature ideation
  • Encourage team participation and ownership
  • Positive shift in team dynamics and proactive problem-solving
  • Reading tip: explore the topic of Staff Engineers

But what if I like building things?

As a founder, letting go of programming can be challenging. However, consider shifting your perspective. Instead of focusing solely on coding, view your role as exploring the problem space and ensuring your team understands what to build and why. This is crucial in the building process. Writing the actual code is only a part of it.

As a technical founder and leader, your goal should be to empower your team. Ensure they are confident in the product, understand it thoroughly, and can effectively support users. Challenge their proposed solutions, but don't dictate. Organize grooming sessions to thoroughly discuss features and reach a consensus on the best approach. When a stalemate occurs, listen to everyone’s input and make the final decision.

Struggles transitioning from being the sole programmer to leading your engineering team?

Competent technical leaders often have problems to balance responsibilities in growing software teams. To help them, we now offer coaching for CTOs and tech-founders.

Discover CTO sounding board service

If you want to continue programming, focus on building proof-of-concepts. Once they have served their purpose, step back and let the team take over. Alternatively, tackle support tickets, which also benefits your team. If you find this insufficient, reflect on whether leading an engineering team is truly your passion. You might be better suited as an individual contributor, allowing someone else to take on the engineering lead role. That’s perfectly acceptable. 

In a startup, everyone should play to their strengths. Keeping someone in a role they do not want can negatively impact the product, team, and company.

Key lessons for technical leaders in a growing team

  • Shift perspective from coding to problem exploration
  • Empower your team through full support
  • Balance coding with leadership
  • Focus on proof-of-concepts and support tickets
  • Reflect on personal passion and suitability for leadership roles

Do you need help transitioning from being the sole programmer to leading and empowering an engineering team? Competent technical leaders often struggle to balance responsibilities in growing software teams. To help them, we now offer coaching and mentoring for SaaS CTOs with our CTO sounding board service. Feel free to reach out; we are happy to hear about your struggles!