Is a lack of role clarity hurting your engineering team?

https://michaellin.substack.com/p/is-a-lack-of-role-clarity-hurting

As a temporary CTO, I thought I’d spend most of my time helping startups solve engineering problems. Yet one year in, I’ve found that most engineering issues I deal with are actually organizational issues. And the most common organizational issue I’ve seen is a lack of role clarity on engineering teams. I’ve discovered that this lack of role clarity exists at all levels of engineering orgs. This includes:

• how engineers work cross-functionally
• how CTO’s work with their VP’s
• even with expectations on the CTO role itself

How Netflix Engineers Work Cross-Functionally

At Netflix, I saw this issue first-hand. Netflix often works cross-functionally on A/B tests. The working model before would involve a product manager leading the initiative, and managers “loaning” engineers to these projects.

However this model often lead to bugs and delayed deadlines. It turned out that while each individual engineer worked on their piece of the project, there was no clear owner for the end-to-end engineering design.

So the solution to fix this was to explicitly assign engineering “lead” roles for all cross-functional projects. In particularly, we created two new roles in cross-functional projects:

• Engineering Lead — the individual responsible for the technical architecture of a project.
• QA Lead — the individual responsible for ensuring adequate test coverage.

Lack of Ownership over Engineering Teams

I consulted with the CTO of a Series C startup on a migration that was taking too long. At first, I thought that this was due to poor project management. But I soon discovered that the real issue with their migration wasn’t a technical issue, but due to their poor org structure instead.

There are several issues with this org structure. Among them include:

• Product Managers in the wrong org — The product managers reported to the CTO when they should’ve been in a separate product org instead
• Too many direct reports — The company had 15 engineering teams, and a 70-person engineering org. Split between the CTO and the VP, they had on average 7.5 teams reporting to each, which means 35 direct reports for both the VP and CTO!
• No clarity of roles — There was no clear division of responsibility between the CTO and the VP over who owned which teams.

So what started as a migration issue turned into an organizational one instead. I discussed with the CTO what organizational structure made sense, and we agreed that:

• He needed more VP’s under him to cut down on the number of direct reports.
• He has to create a new product org for the PM’s and move them under a new Chief Product Officer.
• He had to clearly define roles among his VP’s, and call out who managed which of the 15 teams. The tag-teaming days were over.

Why Engineers Struggle as First-Time CTO’s

Lastly, I’ve discovered that CTO’s are often unclear on their role as well. Many first-time CTO’s were engineers in a previous role. And they report to the CEO the same way an engineer reports to an engineering manager. But this is the wrong way to look at the CTO role.

The CTO should view themselves not as a subordinate, but as equals to the CEO. They can’t just wait on the CEO to give them orders, because the CEO could be waiting on the CTO to tell them what to do instead!

CTO’s have more power than they realize, because without their buy-in the product can’t move forward.

Not understanding the level of autonomy expected in a CTO role can lead to disastrous results for a startup.