How Good Engineers Become Bad Leaders
The way we promote and insulate software engineers often sets them up to fail dramatically as leaders. Here's how, and a better way forward.
Functional expertise and people management are two separate skill tracks. If you’re looking to advance your career, you need develop them in tandem.
In most fields, this happens naturally. You get promoted by:
Selling your vision
Delivering on your vision
Getting credit for what you did
Except: software engineering.
Engineers get promoted because they came up with a Very Good Answer to a technical problem. Simply having a Very Good Answer is enough.
They don’t need to sell their vision; their peers will buy their answer based on merit alone.
They automatically get credit for their work because those same peers inherently understand the impact of the work done.
This is the norm in engineering orgs by design. Most technical leaders consciously insulate their team from non-technical conversations and context.
Their motivation is usually to protect their team, but it comes at a steep cost:
While their peers are developing both their political and functional acumen, software engineers are only developing their technical skills.
This asymmetry quietly compounds for years. It’s not noticeable, until it is - often in a big way.
Maybe our tech lead joins a startup with non-technical founders. Or maybe they need to work with sales on an important client deliverable. Either way, our engineering leader - often 5+ years into their career - needs to sell and communicate their Very Good Answer to non-technical peers for the very first time.
It’s a jarring, rude awakening. Not only is their non-technical counterpart unable to recognize the merits of their vision, they don’t seem to have any idea how software engineering works at all.
They aren’t interested in conversations about updating dependencies or implementing types or microservices vs. monoliths.
They seem to think new features just magically appear.
The real work of engineering - managing dependencies, resourcing, and architecture - is an inconvenient afterthought.
What’s the ROI of updating this dependency?
What the hell’s a Kubernete?
It doesn’t help that we’ve come to accept low technical literacy as normal - most non-technical stakeholders don’t have a working mental model of enterprise software engineering. In it’s place, Big Agile tools like Jira actively misrepresent engineering as a feature factory and cost center.
It’s a blindness we would never accept in other functions - ex: a CEO who thinks that marketing is “running ads” is not very long for this world.
So our CTO faces two steep disadvantages:
They aren’t as practiced in politics as their tenure would suggest
Other leaders don’t understand the nature of their work
The latter is particularly dangerous. When your work is fundamentally not understood, it’s easy for bad (or simply ignorant) actors to co-opt the narrative.
A COO who fixates on a single bad release to undermine engineering’s credibility
A Head of Product who sets unattainable roadmap targets, and then blames engineering when they’re not met
A CFO who withholds funding on key projects - while demanding their delivery.
It’s no wonder that so many engineers come to see all politics as toxic. They internalize the idea that they’re not “cut out” for leadership and quit the managerial track altogether.
The ones who stick it out run the risk of learning all the wrong lessons.
To avoid pain, they “protect” their teams from non-technical conversations as much as they can, unwittingly perpetuating the cycle.
They promote the way they were promoted: for simply having Very Good Answers.
When you don’t value the collaborative act of coming up with answers together, you create sink-or-swim talent swamps: You either “get it”, or you’re not one of us.
These cultures kill some of the best possible characteristics in hires and in humans - conscientiousness, curiosity, and tolerance.
Ironically, it doesn’t even surface the most technically skilled. The ones left behind are usually those without external systems of mentorship.
Think: a junior IC who was the first person in their family to go to college.
That’s the sad truth: when you only focus on the technical - you end up as a leader in title only.
One simple trick
The way to get out of this rut and back on the right track is so simple that it feels trite: a perspective shift.
Not having your work recognized or being misunderstood can feel devastating.
But it’s also a part of Every. Single. Job.
You are not entitled to anyone’s time, empathy, or understanding.
It feels amazing to collaborate with like-minded people who immediately get your ideas. But, on the leadership track - and in life - it’s a luxury, not a given.
When you stop expecting understanding, you no longer take it personally when someone doesn’t see your vision: it’s just a part of the job you signed up for.
You can now help your juniors see that this is their job too:
You normalize working with non-technical stakeholders.
You offer patient explanations in the face of ignorance
You model ethical, practical politics
In other words: you make sure that they aren’t blindsided 5+ years into their careers.
Each time you do this, you’re honing your leadership. Eventually, you realize something.
The best leaders aren’t know-it-alls with a cheatsheet of Very Good Answers.
They take people, across various perspectives and walks of life, and bring them together.
They help everyone be at their very best. They make them feel valued. They impart a sense of belonging.
Together, they come up with Very Good Answers.
Together, they leave things better than how they found it.
Christine Miao is the creator of technical accounting–the practice of tracking engineering maintenance, resourcing, and architecture.
It visualizes the most complex technical problems - think: breaking up monoliths or cleaning up tech debt - in a way that anyone can understand. Whether its their CEO, CFO, or grandmother - technical accounting helps you build a practical, working mental model of software engineering.