… or how software companies get weird
“Can I ask you a question?” my new HR professional friend asked.
“Sure.”
“Does a CTO typically manage people?” they asked.
I smirked as she told me of a client that had a CTO with no direct reports, with all the engineers reporting into the VP, Engineering instead.
Near the end of the story, I asked a pair of questions:
“Were they the first engineer?”
“And they’re still writing a lot of code, right?”
This story illustrates some of the warning signs of Founding Engineer Syndrome, or what happens when an early engineer has a role they haven’t grown into, and their company gets weird as they learn to grow around them.
Most software startups start life as a dyad – a non-technical CEO who sells the product and a technical CTO who builds the product. Eventually, more engineers are hired and the overall company grows.
Even at large businesses, their technical portion can end up in similar situations, where their best engineers get promoted into loftier and loftier titles without growing into a people management skill set.
Companies calcify and route around these engineers with management titles as they grow.
This manifests not only with the story I led with, but with multi-million dollar SaaS startups which still have critical components of the company running off of a founder’s laptop, or VP of Engineering title holders who refuse to do 1:1s with the direct reports but soak up all the work – leaving their team filled with mediocre producers who adore them.
As the technical leader, I get it – hell, I’ve been it. Far too often in earlier stints, I would fire off pull requests that would have been better handled by my team or gone through the regular channels.
One of the biggest mindset shifts from individual contributor engineer to management is realizing that the company will go further and faster if you enable your team to do great work.
And that means you can’t do the work for them because then you limit their growth at the expense of your dopamine and any short-term gain the company gets from you cranking out the fix or feature.
It also feels good. Getting the high five from the CEO, or the sales leader hitting a gong somewhere. You get a rush of dopamine, and it feels like a win – a quick one that fits in your comfort level and skill set.
And managing people? That don’t always feel so good.
People are messy, unpredictable and demanding. And wonderful.
Managing – helping – people doesn’t have quick wins and doesn’t generate dopamine in any real sense.
It’s only rewarding in longer timescales than sprints and pull requests and bug fixes.
It’s rewarding when the team accomplishes something great, when an engineer you manage becomes a successful manager themselves, when the folx you’ve managed go on to careers that far surpass your own.
It’s a deeper satisfaction than the quick win, the high five and the round of applause at the All Hands.
But not everybody is at a point in their life to grow into that role.
So, you can have a CTO or other high technical management title that is still deep in code long after the business needed them to grow into the title.
And the business’ growth will ultimately be stunted by this lack of growth – because, no matter how productive any individual can be, a team that’s built and managed well will outpace them by leaps and bounds.
A single person can only do so much – even 10X engineers get beaten by 11 mediocre engineers!
And good managers can turn 11 mediocre engineers into 11 great ones.
Businesses figure this out eventually. And that means they either have an uncomfortable conversation with their inflated title engineer … or they build around them.
Like a tree growing around a bicycle.
