‍

Recently, I was speaking to a leader at a very well-funded, fast-growing scale-up with a 50 person technical team. Roughly 9 months ago, they hired two co-CTOs at the head of their engineering team structure after finding two great candidates and not being able to choose between them. I’d come across co-CEOs before but never co-CTOs, so I was instantly intrigued to learn more.

‍

Of the two CTOs, one had gotten deep into the code, been very hands-on, and engaged directly with the engineers — pitching in to solve problems through direct contributions, mentorship and resource-rebalancing. The other CTO focused on strategy, long-term people-planning, and process. Both were doing well in their respective focus areas —  their skills complemented one another nicely, each was incomplete in what they delivered compared to a one-person CTO.

‍

‍

On the spectrum of engineering leaders we commonly see today, these two CTOs represent two opposite poles: the engineering leader as a technical expert or Tech Lead and the engineering leader as a people manager or Engineering Manager. How an organization balances these two concerns deeply reflects their approach towards software delivery and is also a strategic dilemma that all software-building companies must face when they exceed a certain size.

‍

How to structure engineering teams?

Inevitably, all tech teams face the decision of how they will structure their engineering leadership roles. On a team level, will they have Tech Leads or Engineering Managers, both Tech Leads and Engineering Managers, or one person who is both the Tech Lead and the Engineering Manager? Or will they have none of these roles at all?

‍

Beyond the team, how can they fit senior, cross-team individual contributors into the organization? What do they do with managers who thrive when they can make significant ‘horizontal,’ org-wide contributions rather than just concerning themselves with their teams? The decisions don't end there. When these roles do get identified and created, who will be the ones to fill them? Should someone from the team be asked to step up or are these roles so new and different that they merit an external hire to help define what success means in the role? 

‍

Ask 100 different CTOs and you’ll get 100 slightly different answers to these questions. But most will agree on one thing: focus on the outcomes you want to drive. 

‍

Why leaders should optimize engineering teams for consistent, efficient, sustainable delivery

‍

Team leadership requirements change as the company changes

At some stage, your tech team will grow out of being a small, highly-aligned unit that has context about everything going on — viscerally feeling every milestone, success, and failure. 

‍

As it evolves, it will become an organization of interdependent teams responsible for different product slices. As a result, optimal outcomes will change from prototyping and meeting deadlines at any reasonable cost to having a stable and predictable pace of delivery that the team can maintain over a long period of time without the risk of burnout or compromising on product quality. The changes you note in the outcome, therefore, serve as the signal you need to read to structure your engineering team’s leadership differently. 

‍

Structuring your team based on the changing leadership responsibilities

As the company changes, the leadership of the company must change as well. For example, the engineering leader who jumps into the code at the last minute to help their team meet their goals can be highly valuable when the team and company are living week-to-week. However, as the team scales, this leader becomes the problem by becoming the person who applies short-term patches to structural issues rather than solving the root cause. 

‍

The leader you need then as the team grows is the one who asks why the team can't make its commitments whilst working at a sustainable velocity. You need a leader who optimizes for process — even if it means failing, knowing that failure will bring an important lesson to help the team grow in the long-run.

‍

Fast-scaling teams’ leaders should be focused on processes

What’s also noteworthy here is that as the organization grows, the challenges faced by a leader evolve from being purely technical in nature to organisational. Some of these include:

‍

• Navigating the organization
• Advocating for the team to other leaders 
• Making sure everyone in the team is engaged and at minimal risk of leaving 

‍

These aren’t stimulating challenges for everyone at all times in their lives, nor is the strongest engineer necessarily the most effective at surmounting them. They can, however, have a huge impact on the velocity of delivery and take up so much time and emotional energy that only the very best professionals can balance them — while still being the technical leader the team needs. 

‍

Such leaders do exist —  I’ve worked with some of these people, but I’ve also seen situations where expecting one person to do all the things leads to all the things being half-done or done poorly. 

‍

The key org design principle: Never design for exceptional cases — design for the average team instead

It is unwise to design companies for the exceptional cases — those people will set an unachievable example and eventually move on. Instead, structure your org for the average teams. Tech companies succeed and fail based on the effectiveness, consistency, and predictability of their average teams as much as they do by the rapid velocity of their strongest team. In most company cultures, the average team tends to benefit from having separate people management and technical leadership roles. 

‍

Perhaps the decision for this company to have co-CTOs actually made sense in the beginning, especially if we look at one of them as the process, people and strategy leader and one other as the technical, execution leader. Seen through a different lens, one would be CTO or VP of Engineering while the other would be a Technical Fellow or Principal Engineer — both of whom fill needs the company has now and will have in twelve months time. 

‍

Without conscious planning, organization structures are mirrors of your company’s past. Make sure they are mirrors of where you are now and where you will be tomorrow, rather than where you began.