Engineering consulting was not what I thought it would be.
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.
Trying to complete projects without fixing org issues is like trying to run a 3-legged race.
Why Role Clarity Matters on Engineering Teams
Workplace teams are like sports teams.
Just as every athlete on a team has a specific role to fill, every team member in the workplace plays a specific role as well.
When every person understands and fulfills their role, the entire team wins.
But when there is a lack of role clarity, people step on each other’s toes, balls get dropped, and performance suffers.
A major source of engineering problems is a lack of role clarity among team members.
Lebron James understands the importance of role clarity when he tells his teammates to be a “star in their role.”
And furthermore 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
Engineering leaders must pay more attention to whether their team members are clear on their expectations and roles.
Providing role clarity will eliminate many of the mishaps that I’ve seen affect engineering orgs in my consulting practice.
1. Role Clarity on Cross-Functional Projects
Clear roles are particularly important for engineers working on cross-functional projects.
I’ve noticed that projects within a single engineering team tend to go smoothly because there is a clear line of command.
The engineering manager leads. The engineers execute.
The division of responsibilities between a manager and the engineers is clear.
But when it comes to cross-functional projects, the members of this project often aren’t in the same organization and they don’t report to each other.
This lack of ownership often leads to major problems down the line.
The Product Manager leads the cross-functional project, but the engineers technically report to someone else, creating a potential communication gap.
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.
Note how there is a manager for both individual engineers, but no manager owning the entire engineering stack across the cross-functional project.
So while the engineers made sure their individual piece was working, it was when all of the engineers’ work came together that bugs would surface.
The individual engineers’ pieces would work, but bugs would appear upon integration.
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.
You can see the new working model in the diagram below.
Note how now there is an explicit owner of the entire engineering aspect of this project now so that end-to-end gaps wouldn’t be missed.
Once we implemented explicit roles in cross-functional projects, the projects went more smoothly with fewer hiccups along the way.
So while many bugs look like pure engineering issues, the lack of role clarity around who owned the end-to-end technical architecture was the real reason for all the engineering issues.
Once those roles were defined, the engineering issues disappeared as well.
2. Lack of Ownership over Engineering Teams
Second, I’ve seen the issue of role clarity come up among upper-management in startups as well.
For example, 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.
Take a look at their org chart here.
Can you see what’s wrong with the org structure here?
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.
In fact, the CTO told me that the VP was more of a “right-hand man” and they practiced “tag-team management.”
So if there was an issue with a team one week, and the VP was busy, the CTO would manage the team. If the CTO was busy, then the VP would step in. So there was no clear ownership over who owned which teams.
The CTO and VP “tag-teamed” on issues, but there was no clear division of responsibility over their separate 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.
The proposed new org structure
A few months after, the CTO told me that their re-org was a success.
You can see the CTO’s message below:
3. 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.
This quote applies particularly to CTO’s.
Why CTO’s Shouldn’t Always Say Yes to the CEO
In another startup I consulted with, the CTO told me that they felt “overwhelmed” from trying to balance both the CEO’s priorities with their own.
They told me that the CEO had two main priorities:
Changing their business model to a flat subscription fee
Expanding to new markets
The CTO had one main priority:
- Finishing a tech debt cleanup.
The tech debt cleanup had already lasted for over a year, and balancing the cleanup with the need to innovate overwhelmed the CTO.
How would you manage this situation if you were in their shoes?
I discovered that there was actually a communication issue between the CEO and the CTO.
First, the CEO didn’t understand the challenge of implementing a new business model.
They didn’t know that the codebase had assumptions about how they charged their customers previously, making this change difficult.
Second, the CTO didn’t understand that they had the power to speak up and mention these challenges to the CEO.
So what happened was the CEO issued their priorities, and the CTO tried to execute on it, leading to their engineering teams getting overwhelmed.
But there was actually a solution here.
Had the CTO spoken up and mentioned the difficulty of implementing the business model change, they could’ve worked with the CEO to suggest that they prioritize their 2nd goal — moving to new markets instead.
This involves no work for engineering, because every new customer in the market is just another entry in the database. So while the rest of the company tries to expand to new markets, this would buy the CTO some time to finish their cleanup.
Adding customers from a new market is easy, because it’s just another entry in the database.
And by the time this expansion finishes, they would have already redesigned the code base to make the business model changes easier.
So the learning here was that this new CTO was acting more as an “executor” and doing what they were told. But the CTO didn’t realize that they are no longer just an engineer, but they had the power to change business priorities as well.
Had they communicated to the CEO the technical challenges of these business priorities, they could have worked together to switch the order of priorities to buy the engineering org more time, while still achieving both business objectives.
Final Thoughts
Engineering leaders should pay close attention to whether their team members know their roles and responsibilities.
Doing so will help you avoid these painful mistakes that plague startups.
💡 If You Liked This Article...
I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.
BONUS Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).
Top comments (0)