Team Leads as a Mini-CTOs

Problem

At one moment in time, I noticed that I was becoming a bottleneck that was slowing down the team. In the past, when I ran a team of ten people I had enough time to have one-on-ones with everyone, do the hiring, take care of what the team needed, etc. But as the team grew I was too often a stumbling rock.

We didn’t have anyone with extensive managerial experience, but we had numerous engineers with solid technical expertise. If they would be empowered to expand on their responsibilities, much of the bottlenecks I was causing could be removed.

Actions taken

To preserve a startup mentality and keep the agility of small teams we split the team into multiple smaller teams. Granting each of these smaller teams autonomy looked like a model that would allow us to execute fast.

The key challenge I faced was how to define what would be the extent to which the teams would be given this autonomy. We decided to empower the team leads to act as mini-CTOs. Practically, any of these smaller teams would be a startup of its own and would have its own mini-CTO. Mini-CTO should be able to manage the budget and people on their team, make sound decisions, etc. In a nutshell, everything a CTO should do, a mini-CTO should also be able to do but within the scope of their team.

We gave mini-CTOs freedom to run their teams as they preferred. They could choose to run it remotely or apply different Agile approaches, for example. That freedom, of course, had its boundaries because there were some things that should be aligned company-wide. For example, the deployment or QA process were already established on a broader level and any team should comply with that.

The reason we decided to go with this model was to instill CTO-like thinking in our team leads. Team leads would often be constrained by having to ask for permission all the time, while CTOs are more proactive -- what “I” can do to make my team more effective, what ”I” can do to ensure that would launch high-quality products, etc. Mini-CTO would take ownership over the delivery and the people who would be responsible for execution. It was a simple mental switch -- from reactively receiving requirements a mini-CTO would be proactively defining requirements. Their responsibilities and rights would expand too. Our team leads would have access to information about salaries which is something EMs and above could only have. That would help them with making more sound decisions about promotions or who they could hire.

However, the title would stay the same -- a team lead or senior engineer. Only recently we started to introduce EMs because now we have more teams and we need someone to groom team leads.

Lessons learned

• Mini-CTOs helped improve the motivation of the people on the team. Ownership and autonomy made people on the team more productive and happier and much of the frustration caused by seeking permission and waiting for external dependencies to untangle was removed.
• Team members became more involved in product development. Rather than just executing on the requirements they are now more involved with proposing the solutions.
• We failed to immediately establish adequate communication channels between team leads and as a result, a lot of misunderstandings occur. Now every two weeks we have team leads sessions at which team leads would share their problems and facilitate discussion with their peers.
• The team leads sessions managed to solve the alignment between different teams. Different teams would approach things differently and sometimes even conflicts would emerge out of it. We had to develop guidelines that would safeguard the boundaries of each team’s autonomy. Before engaging in collaboration with other teams, people should agree on the common principles.
• As a side-effect, we established a process that helps less experienced engineers develop their leadership skills.