When managers fail developers (six years later)

Almost six years ago, I wrote a post about management failing developers. I was frustrated with micromanagement, rigid timelines, and process-heavy environments that treated software development like a factory. I argued that the best teams were developer-led, trust-driven, and focused on outcomes over checklists.

I still believe that. But I understand something now that I didn't back then: the absence of bad management is not the same thing as the presence of good management. And good management is harder than it looks.

What I was right about

Software is still not predictable work. You still cannot take a set of requirements, estimate every task upfront, and expect reality to cooperate. Discovery is part of the job. Forcing certainty too early still leads to bad products delivered on time.

Micromanagement still kills teams. Developers need space to think, solve problems, and build with intent. And "Done by Date" is still a dangerous goal if nobody is asking whether what is being built should exist in the first place. None of that has changed.

What I didn't understand

What I didn't understand is what it actually takes to make those principles work consistently. It turns out you don't get alignment, clarity, and momentum for free. Someone has to create them.

The best teams I've led had something in common: they knew exactly what they were trying to achieve, they understood why it mattered, and they had ownership over how to get there. That doesn't happen accidentally. It requires someone to continuously refine direction, remove ambiguity, and make decisions when things get fuzzy. Not by dictating tasks, but by ensuring everyone is pointed at the same outcome. Autonomy only works when it's aligned.

I've also seen what happens when ownership is unclear. One engineer went completely off track, working in isolation, not contributing to the team's core objective. It created friction, slowed everything down, and forced difficult conversations that eventually led to letting them go. Without accountability, autonomy just becomes drift. A team without clear ownership is a group of engineers working near each other.

Discipline is the difference

This is the part I used to undervalue. High-performing teams aren't just trusted. They're disciplined. They follow through, communicate early when something is off, hold a high bar for quality, and stay focused on the goal even when things get messy.

Looking back, the reason I had such high expectations around trust early in my career is that I was lucky. The managers I worked under early on were demanding and held me and my peers accountable with real discipline. I absorbed that without realizing it was unusual. I took it into my own management style and only later understood how rare it actually is in software. A lot of managers never had that example set for them, and it shows. When that discipline is missing, heavy process rushes in to fill the gap.

Someone has to own the overhead

This is the biggest shift in my thinking. I used to see process as something imposed on engineers. Now I see it as something that needs to be absorbed away from them.

Someone has to care about timelines, coordination, and delivery. But that doesn't mean pushing that burden onto the team. It means reading the tickets instead of asking for status updates. Identifying blockers before they escalate. Shielding engineers from unnecessary noise and pressure.

I've seen what passive management looks like up close. A project manager, ostensibly senior, asks the engineering team to define the requirements expectations. Not clarify them. Define them. From scratch. It's a small thing on the surface, but it's exactly how confusion calcifies into chaos. Observation with extra steps. Asking for updates instead of understanding the work. Sitting in standups and nodding along, then pinging someone on Slack an hour later to ask the same question.

The best management I've experienced, and what I try to practice, is to show up before things go sideways. Read the room early. Notice when someone goes quiet in standup, when a ticket sits untouched for too long, when a deadline conversation gets vague. And when things do go sideways anyway, be the one absorbing the pressure rather than redirecting it downward.

Why management exists

My Director of Engineering pushed for a more aggressive timeline that would have compromised quality and burned out the team. I pushed back and kept it from them entirely. They never knew there was a fight to have. They just built, held their standard, and delivered early anyway. That's when it clicked for me what management is actually for. You are there to make hard timelines achievable without grinding your team down to do it.

Late is just for a little while, suck is forever - Gabe Newell

What I still believe

I still believe in craftsmanship, high standards, psychological safety, trust, and autonomy. But I also believe it is the manager's job to build the environment where those things can actually survive. Not by adding more process, but by owning the complexity so the team doesn't have to.

I still don't believe most teams have a developer problem. I still believe many teams are over-managed. But I understand now why management exists. I just wish more managers did too.