Ripple Group

Insights

Engineering morale problems are usually system problems

A team that can't finish anything doesn't need better all-hands — it needs a roadmap where completion is possible. What killing nine initiatives did.

Philip Barber ·

A portfolio CEO told me her engineering team’s morale was through the floor. Then she showed me their roadmap. I understood why in three minutes.

Twenty-six initiatives across six pods. Two-thirds of them tagged “high priority.” Most carried over from previous quarters. No clear definition of done for any of them.

Her diagnosis was that the team needed a culture shift. More recognition, more 1:1s, better all-hands. It’s the natural read, and I think it’s almost always the wrong one. Recognition programs don’t fix a system where there’s nothing to recognize the completion of.

The question that reframed it

I asked her one thing: “How does an engineer on this team know when they’ve finished something?”

She didn’t have an answer, because the honest answer was that they can’t. Every initiative was open. Every backlog grew. Every retrospective produced more action items than it closed. The team wasn’t depressed because the culture was bad. They were depressed because the system they were operating inside made completion impossible, and humans don’t stay motivated inside systems where finishing isn’t a thing that happens.

A roadmap where everything is high priority and nothing ever closes isn’t really a plan. It’s a work of fiction, and the engineers are the ones who have to live inside the novel.

Killing nine initiatives in an afternoon

We sat in front of the roadmap together and killed nine initiatives by the end of the afternoon. Hard ones. Pet projects she’d championed. Things the board had asked about.

Each one got the same question: if this initiative is still open six months from now and unmoved, what does that mean? If the answer was “we’d be fine,” we killed it. Not paused, not backlogged, killed. A paused initiative is just an open one with worse morale attached, because it still sits on the list telling everyone they haven’t finished it.

That test works because it separates initiatives the business is actually waiting on from initiatives that exist to make a slide look ambitious. The first kind has a consequence attached to its absence. The second kind only has a sponsor.

What changed, and what didn’t

The morale didn’t fix itself overnight. Killing the initiatives is the fast part; rebuilding the team’s belief that “done” exists takes longer, because they’ve been burned by every previous reset that quietly refilled the list.

But within a month, engineers started talking about what they’d shipped instead of what was still on the list. Standups changed shape. The remaining initiatives got definitions of done, and a few actually reached them, which did more for the team than any all-hands could have.

The CEO’s instinct to treat this as a people problem wasn’t wrong about the symptom, just the cause. Morale problems often look like culture problems. They almost always trace back to a system that doesn’t let people finish. If your team seems burned out, look at the roadmap before you book the offsite. Count the open initiatives, count the ones tagged high priority, and ask who could say what “done” means for each.

If nobody can, you don’t have a morale problem. You have a roadmap problem wearing one. That’s a leadership fix, and the afternoon it takes is the cheapest engagement in this business.

This is what we do all day

Want a second opinion on your situation?

Thirty minutes, no pitch deck. You'll leave with a clearer read on your technology function — whether or not we ever work together.