Every company I've worked with has done this at least once. Someone in HR or L&D buys a "Leadership Fundamentals" course. Good curriculum. Decent facilitator. Then they book every manager into the same room: the brand-new tech lead who's mentoring their first two engineers, and the VP running three departments and a budget line. Same slides. Same case studies. Same workbook.
Nobody in the room gets what they need.
The $366 billion mistake
McKinsey looked at why leadership development programs fail and found companies spend an average of $366 billion a year globally on this stuff, $166 billion of it in the US alone. Most of it doesn't stick.
The number one reason: one-size-fits-all training. McKinsey's own words are blunt about it. Too many programs assume the same group of skills, the same style of leadership, works regardless of strategy, culture, or the job the person is doing.
This isn't a training problem. It's a design problem. You built one program and pointed it at ten different jobs.
A tech lead and a CTO are not doing the same job
I remember the first time someone called me "CTO." I hadn't earned it. A startup needed the title for a funding deck, and I was the person building the MVP, so I got it. I kept doing the work. The title sat there, uncomfortable, in quotes.
Getting from "CTO" to CTO meant climbing through roles with almost nothing in common with each other.
As a tech lead, my job was making technical decisions and mentoring one or two engineers. As an engineering manager, my job became building a team of five to seven people, learning to stop writing the core code myself, and getting good at conflict I used to avoid. By the time you're running multiple teams as a director, you're managing managers, owning hiring and firing calls, and thinking in budgets and quarters instead of pull requests. Get to CTO and coding is off the table entirely. You're now a business leader who happens to have a technical background, aligning a technology roadmap with the rest of the company.
Four stages. Four different jobs. If your leadership program teaches the same "how to give feedback" module to all four, you've helped the tech lead a little and wasted the CTO's afternoon.
Engineering makes this worse, not better
Here's the part specific to tech. Gallup found only about 1 in 10 people have the natural talent to manage well, and companies get the hiring call wrong on 82% of their manager decisions. Layer this on top of how most engineering orgs build their management pipeline: promote the best individual contributor.
I've written before about why promoting your best engineer is corporate sabotage. Being excellent at writing code and being excellent at managing the people who write code are different skill sets. Sending a newly-promoted engineer to a generic leadership course doesn't fix the mismatch. It hands them a certificate for a job they haven't figured out yet.
Engineers who want to manage, and have some talent for it, need something different from the ones who took the promotion because it was the only path to a bigger paycheck. A single leadership track won't serve both.
What McKinsey found works
The same research pointed at a fix, and it isn't complicated. Tie the content to the person's context: their level, their team, the specific problems in front of them right now. Balance classroom time with real projects, not theory divorced from the work. Track whether behavior changed on the job, not whether people showed up and filled out a feedback form.
For engineering leadership specifically, this means separating the tracks properly:
A tech lead needs help with technical decision-making under pressure and giving feedback to peers, not org-wide change management.
A new engineering manager needs to learn how to stop being the best coder in the room and start being useful in a different way. This is an identity shift, not a slide deck.
A director needs help with budget conversations, cross-functional negotiation, and letting go of the last threads of hands-on technical work.
A CTO needs almost none of what the other three need. Business strategy, board communication, and the discipline to stay out of the code entirely.
The fix costs less than the mistake
None of this requires a bigger training budget. It requires admitting "leadership" isn't one skill you either have or don't. It's a different job at every level, and engineering packs more levels closer together than most functions, because the jump from writing code to managing the people who write it is one of the steepest transitions in any career.
If you're the one buying the training, stop asking "what leadership course should we run this year." Ask "what does a first-time tech lead need this quarter, and is it the same thing the director needs?" It almost never is.
If you're the one sitting through the generic course, you already know it isn't working. Ask for something built around your job, not the job title next to yours on the org chart.
What would you have needed at your first leadership step, and nobody gave you?