CTO Kelly is overwhelmed and underwater. So when one of her engineers, Brad, shows interest in leadership, she jumps at the opportunity. Brad hasn’t managed other people before, but he’s a strong performer with great soft skills. Kelly assigns Brad a team and gives him full autonomy to lead.
It’s a common story that always ends badly. Here’s why:
Inexperienced managers don’t magically transform into experienced managers.
Inexperienced managers require dedicated time and effort to train.
Bringing onboard an inexperienced manager always adds net new workload. You can choose to either pay the cost upfront in training, or down the line in retroactively correcting rookie mistakes.
It’s logic that gets lost in a cloud of magical thinking. Kelly wants to alleviate her own workload. Brad wants a growth opportunity. They’re primed to see convenient, flattering solutions in one another.
Engineering leaders are uniquely susceptible to this fallacy because they often mislabel management and leadership as personality traits rather than hard, earned skills. Ex: Kelly would never staff a inexperienced engineer to “save time” on a major technical project.
There are three possible outcomes from here - all of them bad.
Micromanagement hell
A series of unfortunate discoveries
Perpetual, inescapable mediocrity
1. Micromanagement hell
If Kelly is paying close attention, she’ll notice issues off the bat. Brad’s missing things that should be obvious. This is on top of what feels like a million little things that aren’t quite right - ex: waiting too long to give feedback, meetings that run over, getting too hands-on.
The root cause of this is simple: management is an entirely new job that Brad has never done. He can’t see what’s obvious because he doesn’t know what success looks like yet - and a standard 1:1 cadence isn’t going to help.
Imagine trying to teach someone to do literally anything by meeting for an hour a week and asking them to give you updates.
But…Kelly’s magical thinking blinds her. She tries to “mentor” Brad by packing as much feedback as she can into their 1:1s. She gives constant ad-hoc corrections and starts overriding his decisions. The team pretty quickly realizes that Brad’s not really in charge. When they need final answers, they always go back to Kelly.
For Brad, it’s just plain demoralizing. It feels like he’s always doing something wrong. Over time, he begins to believe that he’s just not cut-out for leadership.
Often, Brad steps back into an IC role or leaves because he no longer feels good at work. If he ever does make another go of the leadership route, he’s picked up some really, really bad management practices. Kelly, despite her best intentions, was a pretty poor model.
2. A Series of Unfortunate Discoveries
This short term bad ending assumes that Kelly is paying close attention. More often, by virtue of being very busy, Kelly leaves Brad with the autonomy and trust she would typically give a direct report.
The problem: Brad is not a typical direct report.
This is his first time doing a categorically different job. He cannot and should not be expected to handle everything competently. Brad is also the worst person to surface issues with his own work; he isn’t senior enough to know what he doesn’t know.
But when he tells Kelly that things are fine, Kelly believes him because she wants to. Brad stepping up has made her feel much less busy and she doesn’t want this fantasy interrupted. This mutual delusion goes on for months, sometimes years.
Until…it grinds to a screeching halt. Maybe there was a very bad rollback, an inexcusable delay, or a key contributor suddenly quits in a rage. Regardless, Brad’s inexperience becomes clear all at once - and the bill is way overdue.
Kelly finds herself firefighting and course-correcting. Along the way, she makes unfortunate discovery after unfortunate discovery. As a leader, Brad had outsized impact. His inexperience has bled everywhere - in hiring, growth, morale, code quality, and delivery. Brad can’t even help them triage the extent of the bleed because he still can’t see the problem.
There’s usually no coming back for Brad at this point. His incremental rookie missteps have accumulated in a big way. Plus, Kelly feels misled. They met every week to go over progress. Why didn’t he just ask for help? How could he let this happen?
Brad is ousted, while the rest of the company is left to figure out the extent of the bill and the interest it’s accrued.
3. Perpetual, Inescapable Mediocrity
But maybe there’s no blow up or obvious missteps. Brad turns out to be a gifted leader who intuitively navigates most scenarios with competence. Kelly fills in the remaining gaps - ex: Brad is a very skilled project manager but struggles to give negative feedback, so Kelly coaches and enforces performance improvement plans.
This outcome is much more subtle and insidious because it ends up stunting the entire org in the long term.
Junior leaders who are never fully taught to lead - and have subconsciously absorbed the idea that leadership isn’t a skill requiring development - eventually calcify into inadequate leaders.
No matter how gifted they were to begin with, these inadequate leaders become talent ceilings. They’re not good enough to upskill their team. They struggle to attract and manage senior talent, who seek and expect strong leadership and mentorship.
It also makes leaders in other departments feel resentful. Your head of support ran a half-dozen teams before being promoted to a VP. Your director of marketing spent six-figures on an MBA to even qualify for management roles. Brad’s naiveté (and Kelly’s coddling/tolerance of his very clear gaps) may feel normal within the engineering team, but to an outsider, it’s painfully obvious…and deeply unequal.
This is arguably the most tragic outcome because it traps everyone involved. Once mediocrity becomes the norm, it’s very difficult to uproot. And Brad is the biggest victim of all. His incredible potential is undeveloped and misshapen. Instead, he’s stuck in a cosy, lulling rhythm that he can’t escape; without Kelly’s coddling and maladaptive behavior, he would fail.
What’s worse, he’s come to see Kelly’s behavior and their dynamic as normal - priming him to perpetuate the cycle.
How to teach leadership
None of this is a case against junior leaders. But it is a case to treat the transition into leadership for what it is - an entirely new job and skillset that must be taught.
And there’s only one solution to teaching someone a new job on the fly.
Mentor the shit out of them.
Here’s what this means:
Brad and Kelly both recognize Brad’s status as an apprentice who is learning a new skill. They’re on the same page that this is a new job - not just an extension of Brad’s existing responsibilities/personality.
Because it’s an apprenticeship, Brad begins as Kelly’s shadow. Kelly should be prepared to slow down, explain her reasoning, and painstakingly walk through each step she takes. Think: the management equivalent of pair-programming
As Brad gains independence, Kelly transitions into the shadows. She still knows the intimate details of his projects and they still pair, but Brad takes all of the credit and optically makes decisions.
Kelly steps further and further back over time, which could take 3 months to a year depending on Brad’s latent skill. They constantly check-in to make sure that this is what Brad wants and that he’s on the right track.
This sounds exhausting and expensive because it is. Developing leadership in others is its own set of skills, and there’s no shortcut. Once again:
Bringing onboard an inexperienced manager always adds net new workload.
It’s costly but essential work. You don’t need to do it perfectly, but you do need to try. As a leader, you owe it to your team to treat their careers with due care and attention. Those who routinely fail to provide growth opportunities soon find that their best people leave them behind.
And for good reason. After all, if you’re not forging the path forward, you’re not worth following.
Godfrey helps map and track the institutional skills that keep great engineering organizations running. Instead of shallow productivity gains, we use AI to (thoughtfully) visualize the real work of engineering - architecture, resourcing, and maintenance.
That includes the very hard, often thankless, but vital work of training the future generation of engineering talent.