Breaking the Spiral: Rebuilding a Team From 54% Attrition
I got involved with a team of twenty-five people with a 54% attrition rate and an employee Net Promoter Score of -37. Those numbers told one story, but the daily reality told another. Some people were vocal about their frustrations, some were clearly disengaged, and others just kept their heads down in what we'd now call quiet quitting, though the phrase didn't exist yet. Sprints were running, standups were happening, but tickets sat in blocked status and nothing was getting finished.
The metrics were terrible, but they weren't the problem. They were symptoms of something deeper, something that had spiralled the team into a state where people either didn't care or had given up believing things could change.
The Downward Spiral
I started with one-to-ones. Not structured interviews with a list of questions, but open conversations. Where are you at? What are you unhappy with? What are you happy with? How can I help? What are you passionate about? What are you learning? These weren't interrogations, they were genuine attempts to understand what was happening beneath the surface.
The pattern emerged quickly. Pay reviews hadn't been conducted in over a year, which I sorted in the first month. But as people opened up, it became clear that wasn't the real issue. It was a hygiene factor, something that needed to be right but wouldn't fix what was broken.
The real problem was disconnection. The development team and the business had divorced. Developers didn't have a clear understanding of what the business wanted and felt unable to deliver on either business or technical priorities. Product managers were sort of acting as product owners but weren't close enough to bridge the gap. When a ticket landed with ambiguous requirements, developers lacked the business knowledge or the relationships with users to clarify what was needed. So tickets sat blocked.
Around this time, I'd been listening to Three Signs of a Miserable Job[^1] on Audible, part of the regular reading I do to understand people and teams. The framework resonated immediately: anonymity, irrelevance, and immeasurement. I didn't actively map it like a consultant doing an assessment, but those organic conversations kept revealing the same three things.
People felt anonymous, that their work wasn't visible. They'd build something and have no idea if it mattered or if anyone even noticed.
They felt irrelevant. They couldn't see how their work connected to business goals, and without that connection it was just tickets in JIRA, features no one asked for or understood.
Also, they couldn't measure their impact, because nothing was getting finished. How could they know if they were doing well? We tried measuring individual velocity and rework from QA, thinking it would help, but it created tension. People felt judged rather than supported.
The team was in a negative spiral. Low morale led to poor delivery, which led to disconnection from the business, which led to blocked tickets, which led to lower morale. People were leaving, meaning we lost knowledge, which made delivery harder, so more people left.
I needed to find the inflection point.
Reversing Direction
In the second month, I started a weekly tech ops meeting. An hour, strictly time-boxed, with product managers and tech leads. The agenda was simple: what are our focus areas, what specific items need attention, and how do we improve.
At first, there was real aversion to it. Just another meeting. People would say everything was fine when it clearly wasn't, or they'd skip bringing up problems and updates entirely. They didn't engage because they didn't believe talking about problems would actually change anything—the business wouldn't listen anyway, so why bother?
It took four to six weeks to build trust with the group, and it happened differently for everyone. There wasn't a single breakthrough moment. It was the accumulation of small wins—solving problems when we could—and being honest about the things I couldn't change. There was a lot of "the board thinks this" or "the senior team thinks that" floating around as reasons nothing could improve. Part of building trust was me saying, "I'm part of the senior team, we don't think that, and it hasn't even come up." Just being transparent about what was real and what was assumption started shifting things.
Around the three-month mark, after the first quarter, the business was already using OKRs but the development team wasn't really engaged in the process. I'd been thinking about Measure What Matters[^2] and how objectives and key results could connect technical work to business outcomes, but the framework is only effective if people feel ownership, not just compliance.
So I changed how we ran "All Hands on Tech" sessions. We got everyone together—about twenty people—for a couple of hours in Marquee, outside the building. This wasn't your typical planning meeting, and the physical space mattered. It gave us room for whiteboards and post-its, but more importantly, it got the team out of the usual meeting rooms into somewhere different.
We started by getting people to write what they wanted to work on, then we ranked ideas as a group. After the initial brainstorming, we set up stations around the room, each representing a potential objective. We split into groups and rotated through stations, each group drafting key results for that objective. Then we'd roast each other's proposals and try again at the next station.
By the end, we reviewed everything as a group and set the actual key results we'd measure. The energy in these sessions was completely different from the usual quarterly planning. People were engaged with both technical and business problems with the same energy, understanding the why behind the work. They were connected to what they'd be building and felt ownership over it.
This started addressing two of Lencioni's three signs. Irrelevance disappeared when technical goals connected directly to business goals. The OKRs made that link explicit, and anonymity started dissolving as people presented their work or had it called out in demos.
One moment stands out. We were working on a customer service system, and a developer demoed what they'd built. It was really good work but missed a couple of small pieces in the UI. Really simple stuff that took half a day to add. The result was a screen that users relied on daily, and a developer who was genuinely happy to see their code in production doing something valuable for the team.
That's when I knew we were turning the corner.
The Upward Spiral
It wasn't a smooth trajectory. People still left in those first three months. Some on bad terms, which was hard. Later departures were on good terms, and we took a strange pride in people leaving the 'right' way, keeping the door open to return. Still, when you're investing time and care in relationships with individuals and they leave, it's difficult not to take it personally.
What kept me going through that period wasn't confidence that we'd succeed. It was fear that we weren't solving issues fast enough, that we were losing knowledge from the team faster than we could stabilise it. I didn't doubt what we were doing; I was scared we'd run out of time.
The tickets stopped sitting in blocked status. That was the first tangible sign things were changing. The blockages had been about lack of connection; developers didn't have the business knowledge or the necessary relationships to clarify requirements, and PMs weren't close enough to help. The weekly tech ops meetings, the demos, and the shared OKRs started rebuilding those connections.
In tech ops, PMs and tech leads began genuinely engaging. They brought problems up for discussion rather than just reporting status. The distrust of meetings faded as people saw real issues getting solved rather than just talked about.
We'd been working on a re-platforming project the whole time, moving from a monolith to a microservice architecture. That project was already in flight when I got involved, but it became important context rather than just a feature list. Explaining the long-term plan, showing how the work fit into something bigger, helped people not feel like a feature factory. They were building something that would matter, that would last.
The measurement piece—Lencioni's third sign—remained the toughest. Individual velocity created tension, so we shifted to measuring team velocity. That worked better, but I'm still not convinced we cracked it. What mattered more was that things were actually getting finished. People could see their work going live, being used, making a difference.
After six months, we hit 0% attrition. Over the full year, the eNPS climbed from -37% to +17%. We measured it monthly, and it wasn't a sudden jump, it was a gradual building of momentum. The negative spiral had reversed into a positive one. Trust building in tech ops, delivering work that mattered, seeing the impact of what we built, feeling connected to business goals—it all fed on itself.
What Actually Mattered
Looking back, the thing that had the biggest impact was communication through multiple channels. One-to-ones every two weeks, weekly tech ops, quarterly All Hands on Tech sessions. But it wasn't just the frequency or the formats. It was caring personally about the team and making sure I understood and communicated the why behind decisions that impacted either the team or the work.
The frameworks—Three Signs of a Miserable Job[^1], Measure What Matters[^2]—helped me understand what was happening, and gave me language to think about solutions. But they weren't a Bible I followed step by step. They were theories that explained patterns I was seeing in real conversations with real people.
What didn't work as expected? Pay scales and bonuses. They needed to be right—we fixed the pay reviews immediately—but they weren't the solution. They were table stakes, not the transformation.
What surprised me? How participatory the OKR sessions needed to be. I'd initially thought about setting goals and cascading them down. That would have been faster, more efficient. But it wouldn't have worked. People needed to write on the post-its, rank the ideas, draft the key results, roast each other's proposals. That's where ownership came from. That's where the connection to business problems happened.
If I were talking to another leader facing this situation, I'd say: get to know your team. Understand their frustrations. Be clear and honest in communicating, particularly when it's not good news. Don't let things fester. But mostly, I'd say I was thinking on the fly, trying things, looking for what worked. The spiral metaphor fits because that's genuinely how it felt—not a series of discrete interventions but a gradual shift in momentum, each small thing building on the last until the direction changed.
The team wasn't broken because people were bad at their jobs, or because the previous manager failed. Circumstances had created a negative spiral, and it took intention and consistent effort to reverse it. That's what people leadership often is—not grand strategies or perfect frameworks- but showing up, caring personally, solving problems, and helping people see that their work matters.
The numbers tell part of the story. 54% to 0% attrition. -37% to +17% eNPS. But the real story is in the tech ops meetings where people started bringing up real problems, in the All Hands on Tech sessions where twenty people covered whiteboards with post-its, in the demo where a developer saw their work go live and felt proud of what they'd built. That's where the spiral reversed. That's where the team came back.
[^1]: Patrick Lencioni's framework identifying anonymity, irrelevance, and immeasurement as the core causes of job dissatisfaction.
[^2]: John Doerr's guide to implementing OKRs (Objectives and Key Results) for organisational goal setting and execution.