Here’s a story you’ve heard before, probably because you’re living it.
Your company grew. Fast. You went from twenty engineers to eighty in about eighteen months. You promoted your best individual contributors into management because they were the obvious choices. They knew the codebase, they had credibility with the team, and they were willing to do it. Or at least they didn’t say no.
Now those people are managing six to ten direct reports, sitting in meetings four hours a day, context-switching between architecture decisions and performance reviews, and slowly drowning. They’re not shipping code anymore, which was the thing they were good at. They’re doing a different job entirely, one they were never trained for, and they’re judging themselves by the only metric they know (technical output) which is now zero.
Meanwhile, the decisions that actually matter, like system design, technical direction, build-versus-buy, how to structure teams around the next phase of the product, those decisions are being made by default. Not by anyone in particular. By inertia. By whoever happens to be in the room. By the last person who had a strong opinion.
You don’t have a talent problem. You have a leadership vacuum that you filled with job title changes and hoped for the best.
The IC-to-manager trap
Promoting strong ICs into management is the oldest mistake in engineering leadership, and we keep doing it because the alternative feels worse. If you don’t promote the senior engineer who’s been carrying the team, they’ll leave. If you bring in an outside manager, the team will resent them. So you split the difference: you give the IC a new title, a few direct reports, and a vague mandate to “keep doing what you’re doing but also manage the team.”
This works for about three months. During that time, the new manager is still close enough to the code to have opinions, still has enough context to make good technical decisions, and hasn’t yet accumulated enough management overhead to feel the squeeze. It feels like you made the right call.
Then reality sets in. The one-on-ones eat two hours a week. Sprint planning takes a morning. There’s a performance issue on the team that requires documentation and HR conversations the new manager has never had. The quarterly roadmap planning meeting requires a level of cross-functional communication that makes their eyes glaze over. They start canceling one-on-ones to make time for technical work. The team notices.
The brutal truth is this: management is a career change, not a promotion. It requires a completely different set of skills: communication, prioritization, conflict resolution, organizational awareness, the ability to achieve outcomes through other people instead of through your own hands. Some engineers are naturally good at these things. Many are not. And there’s no shame in that, unless you’re the one who put them in the role without acknowledging the gap.
The architecture by committee problem
When there’s no clear technical leadership (not management, leadership) what you get is architecture by committee. Every significant technical decision becomes a negotiation between whoever feels strongly about it. The team with the most political capital wins, regardless of whether their approach is right.
You can spot this pattern from the outside. The system has three different approaches to the same problem because three different teams built their solutions independently. There’s an internal wiki page titled something like “API Design Standards” that was written eighteen months ago, has twelve comments disagreeing with it, and is followed by nobody. The words “tech debt” come up in every sprint retrospective and nothing changes.
Architecture by committee isn’t a technical failure. It’s the predictable result of not having someone whose job it is to hold the technical vision, make the hard calls, and be accountable when those calls turn out to be wrong. That’s what a CTO does. Or a VP of Engineering, or a principal architect, or whatever you want to call the role. The title doesn’t matter. The authority and accountability do.
If nobody in your organization can answer the question “why is our system designed this way?” with something more substantive than “well, it evolved,” you have a leadership vacuum.
The middle management gap
There’s another version of this problem that shows up in larger engineering orgs, and it’s subtler. You have a CTO. You have senior engineers. What you don’t have is the layer in between: the engineering managers and directors who translate strategy into execution, who notice when teams are misaligned before it becomes a crisis, who develop junior engineers into senior ones.
This middle layer is the hardest to build and the easiest to neglect. Senior leadership thinks the teams are autonomous enough to self-direct. The teams think senior leadership is setting the direction. Nobody is doing the connective work. The result is an engineering org that looks healthy on an org chart and feels chaotic to work in.
The symptoms are specific: engineers in their second year who’ve never had a meaningful career conversation with their manager. Teams that duplicate effort because nobody noticed they were solving the same problem. Production incidents that keep recurring because the post-mortem action items get deprioritized every sprint. Senior engineers who are frustrated because they can see the organizational problems but don’t have the authority to fix them.
If any of this sounds familiar, you’re not alone. And the fix isn’t hiring a bunch of managers. The fix is being intentional about what your leadership structure needs to look like at your current scale, not the scale you were six months ago.
What scaling leadership actually looks like
We’ve helped engineering organizations work through this, and the pattern that works is less glamorous than you’d hope:
Separate the technical and people tracks. For real. Not the version where you have a “Staff Engineer” title that everyone knows is the consolation prize for not getting the manager role. A real technical track with real authority, real compensation parity, and a real scope of influence. Staff and principal engineers who own architectural decisions and are accountable for technical outcomes the way managers are accountable for team outcomes. If your best engineers see the management track as the only path to influence, your technical track is broken.
Invest in management as a skill, not a side effect. Your engineering managers need training. Not a two-day offsite with a leadership consultant, but ongoing, practical investment in the skills they use every day. How to give feedback that changes behavior. How to run a team meeting that isn’t a waste of everyone’s time. How to identify when someone is struggling before they quit. This isn’t soft stuff. This is operational capability. You wouldn’t put someone in charge of a production system without training. Don’t put them in charge of people without it either.
Define the decisions that need to be made and who makes them. This sounds obvious. It almost never happens. Most engineering orgs have an implicit decision-making structure that nobody has articulated. When you ask “who decides which database we use for new services?” the answer is usually an uncomfortable silence followed by “well, it depends.” Map the decisions. Assign them. Make the assignments public. You’ll be amazed at how much organizational friction this eliminates.
Accept that leadership takes time away from building. The reason your promoted-IC managers are struggling is that they’re trying to do two full-time jobs. Leadership is the job. The code will get written by the team. The leader’s job is to make sure the team can write the right code, in the right order, with the right support. That’s not a lesser contribution. It’s a different one. And it needs to be valued as such.
The question to ask yourself
Walk through your engineering org in your head. For every team, ask: who is responsible for the technical direction? Who is responsible for the people? Are those responsibilities clearly defined, or are they floating somewhere in the space between job descriptions?
If you can’t answer confidently, the good news is you’ve identified the problem. The bad news is it’s been compounding while you weren’t looking.
Steadfast Digital helps engineering organizations build the leadership structure they need at the scale they’re actually at. If your org has outgrown its leadership model, let’s figure out what’s next.