I'm taking over a team that's just had a bad manager.

What to do when you take over a team that's had a bad manager

Detroit, mid-January two thousand and fourteen. Mary Barra has been Chief Executive Officer of General Motors for two weeks when the company's faulty-ignition-switch scandal breaks open in public. The defect — a switch that could slip out of the run position and shut off airbags during a crash — has been quietly known inside the company for over a decade. Linked to more than a hundred deaths. Systematically buried.

Barra has not inherited a team. She has inherited a workforce that has been taught, by the previous culture, that raising problems is career-ending.

Her first move is not a memo. It is to stop production on the affected vehicles, commission an independent external investigation, publish the findings without editing, and name the internal cultural failure in public rather than blaming individuals. The phrase she uses repeatedly across those first months is I don't want you to forget this. Not a performance of humility. A structural commitment to not letting the company paper over what has happened.

What follows in the year after is something most leadership coaching wouldn't predict. The workforce that has been trained to hide problems starts reporting them. GM's recall rate goes up. Not because the cars get worse. Because the information stops being suppressed.

That is what recovery from a bad regime actually looks like. Uglier numbers for a while. Because the truth is finally being counted.

Expect uglier numbers as the truth starts being counted

So let's go to the office and work through it.

"I'm taking over a team that's just had a bad manager."

The feeling is untrusted.

The team is being polite to you. They are also waiting to see whether you are a continuation of the previous problem, a different kind of problem, or — and this is the option they have stopped expecting — the actual change.

Two choices. Both teams look quiet. Both have learned not to speak. The first move is different.

When they need their autonomy restored

Choice one: the team needs their sense of autonomy restored. The previous manager micromanaged. The team has learned that asking for permission is safer than using initiative. Every decision the team would normally make has been routed upward, and the team has stopped trying.

If that's the read, flip every approval workflow from opt-in to opt-out. Decisions are auto-approved unless someone flags them for review. The default has reversed.

Richard Thaler, working with Cass Sunstein on the design of choice architecture, found that defaults are the most powerful lever in the entire choice-architecture toolkit. People disproportionately go with the default — not because they're unable to deviate, but because deviating costs effort, and the cost is usually higher than the benefit. The architecture of distrust the previous manager built was the problem. The architecture has to change before the culture can. A memo about trust is read with suspicion. A structural change the team will feel the next day, when they notice that a thing they used to have to clear is just happening, is read as the thing the memo claims to be.

When the environment itself reminds them

Choice two: the team isn't micromanaged. The team is traumatised. Every familiar meeting room and ritual reminds them of the person who left. The Tuesday standup happens at the same time the previous manager used to chair it. The Slack channel still has the artefacts of the regime. The brain associates the old bad experience with the old surroundings, and a clean break in the surroundings lets the brain stop flinching.

If that's the read, change the environment immediately. New meeting cadence, different room, different Slack channels, different recurring rituals. The point isn't that any single change is individually meaningful. The point is the aggregate is unmistakable.

Kurt Lewin, working in the nineteen-forties on what he called unfreezing, observed that group behaviour is held in place by the surroundings as much as by the people. Change the surroundings and the behaviour can change. Leave the surroundings and behaviour change is a permanent uphill struggle.

Autonomy, or environment. Same quiet team. Two different first moves.

How to repair the team on purpose

Three tools. The discipline is to heal the team deliberately, not by pretending the problem isn't there.

The first is

Acknowledge what happened before you move on

Change Management.

Change Management as a corporate discipline traces back to John Kotter's nineteen ninety-six book Leading Change, which formalised an eight-step approach to organisational transformation. The deeper lineage runs through Lewin's three-stage model — unfreeze, change, refreeze — formalised in nineteen forty-seven, and earlier through the post-war organisational-development tradition that emerged from Tavistock Institute work in London. The contemporary practice is multi-source.

The reason Change Management matters when you've inherited a damaged team is that the inherited damage is itself the change you are managing. Most Change Management literature assumes you are introducing a new programme. The inherited-team version is closer to unfreeze than to change — what has to happen first is acknowledgement that the team has been through something difficult, and that you know it.

The unique insight is that the manager who pretends everything is fine is read as a continuation of the problem. Teams in recovery need to hear that what happened was real before they can start to move past it. The pretence — let's draw a line and move forward — is the precise signal that confirms to the team that the new manager hasn't actually understood what they're inheriting.

What you get when you acknowledge first is a team that becomes able to move on. What you get when you pretend is a team that learns the new regime is the same as the old one in different language.

So. How to run it.

Acknowledge. Out loud, to the whole team, in the first or second week. I know what happened here. It was real. We are not pretending it didn't. Specifics matter. Vague acknowledgements read as performance.

Name. Be concrete. The Tuesday standup is moving to Wednesday in a different room. The approval workflow on expenses under five hundred pounds is being removed. The retro is being run differently — let me explain how. Each change is a small piece of unfreezing.

Decentre. The acknowledgement is for the team. It is not the new manager's psychological-safety speech, and it is not the moment for the new manager to position themselves as the good replacement. The story is about what the team has been through, not about who is in charge now.

Refreeze. New rituals, new cadences, new physical or digital environments — and then leave them in place long enough to harden. Constantly changing things signals continued instability. The fixed new shape is what tells the team the change is real.

The second is

Point the team back outward at the user

Voice of Customer.

Voice of Customer comes out of total-quality-management practice in the nineteen-nineties, specifically Abbie Griffin and John R. Hauser's nineteen ninety-three paper at MIT formalising the framework as a structured way to capture customer needs in product-development decisions. The lineage runs through the Japanese kansei engineering tradition of the nineteen-seventies and Toyota's customer-focused production discipline.

The reason Voice of Customer matters when you've inherited a damaged team is that toxic management creates an inward spiral. The team has been spending its energy on internal politics, on watching the manager, on protecting itself from the regime. The work, as far as the people who actually use the product are concerned, has receded. Pointing the team outward — back at the real users — breaks the spiral.

The unique insight is that real users don't care about the team's internal drama. The users care about whether the product helps them do the thing they're trying to do. A team that has been stuck in internal politics finds it liberating to spend a week on the user — because the user is the part of the world the previous regime had nothing to do with.

What you get is a team that remembers what it's for. The work has a pole again. The internal drama loses its centre of gravity, because there's something outside the room that matters more.

So. How to run it.

Listen. Customer interviews, support-ticket analysis, NPS or Voice-of-Customer surveys, in-product feedback channels. Whichever is closest to live customer voice.

Gather. Engineers in customer interviews. Designers reading support tickets. Product managers running the synthesis. Not the new manager filtering the customer voice and reporting back. The team itself listening directly.

Change. Within the first month, ship something that came directly out of customer voice. Not a big initiative. A small thing. The visible link between we listened to a user and we changed the product is what makes the listening feel useful rather than performative.

Repeat. Voice of Customer is a cadence, not a one-off. The first round restores the outward orientation. The cadence keeps it pointed there.

Reconnect the work to the job it does

The third is

Jobs To Be Done.

Jobs To Be Done as a framework was formalised by Clayton Christensen in The Innovator's Solution, two thousand and three, and developed further in Competing Against Luck, two thousand and sixteen, drawing on earlier work by Anthony Ulwick and the outcome-driven innovation tradition that traces back to the nineteen-nineties. Christensen's framing — people don't want a quarter-inch drill, they want a quarter-inch hole — is the canonical surface form.

The reason Jobs To Be Done matters when you've inherited a damaged team is that the team may have completely lost sight of why the work matters. Toxic management drives a wedge between what the team does and what the team is for. The features ship. The roadmap fills. Nobody can articulate what the user is trying to do, because nobody has talked about the user as a person with goals for months.

The unique insight is that the framework reframes the work as a job the user is hiring the product for. The user isn't a demographic. The user has a job. They hired this product to do that job. Are we doing it well? The reframe pulls the team back to a question they can actually answer.

What you get is a team that can articulate the work in user-centric terms again. The work has to feel meaningful before the team can feel like a team again, and Jobs To Be Done is the fastest path back to articulating meaning.

So. How to run it as a workshop.

Pick. Real ones, ideally interviewed within the last quarter. If the team can't name three, the Voice-of-Customer step needs to happen first.

Surface. For each user, what is the job they hired the product to do? Job, not feature. I hired your product so I could send my team's weekly status update without spending an hour writing it. The job is structured: the situation, the motivation, the desired outcome.

Map. Against each job, where is the product helping and where is it failing? Be honest. Most damaged teams discover the product has drifted away from one or more of the core jobs while nobody was looking.

Decide. With the jobs visible and the gaps named, the team picks where to invest. The jobs do the prioritising. Not the new manager, not the previous regime's leftover roadmap — the user's actual work.

The team's reconnection to the work is the half of the work the framework is doing. The other half is producing better product decisions. Both halves run on the same engine.

That's the toolkit. One more story before we close.

A precedent: when the bad manager you took over from was you

The Barra story we opened with is what taking over a team after someone else's bad regime looks like. The story we close with is the inversion — what happens when the bad manager you're taking over from is yourself.

San Francisco, June two thousand and ten. Paul Biggar returns from honeymoon to find NewsTilt — the Y Combinator-backed platform for independent journalists he co-founded with Nathan Chong — almost two months into a crisis nobody outside the founding team has been managing.

NewsTilt launched in April. Biggar defended his PhD thesis the week of launch, married the next month, and left on honeymoon for most of May. Through the launch window — the period when the founding promises needed to be kept — the founder who had signed up the journalists, written the press, and committed the platform to specific features had been physically absent.

Chong has been holding the product together alone. The journalists who had been writing for the site, on the strength of the launch promises about branded pages, audience tools, and an eighty-twenty revenue split, have started not posting. The reader numbers are small. The promised features have not been built.

When Biggar returns, what he is taking over is not a team someone else mismanaged. It is a team he himself mismanaged, by being absent during the period when the founding promises needed to be kept.

He tries, briefly, to re-engage. It does not work. The trust gap between what the journalists were promised and what they received has widened across the absence beyond what subsequent attention can close.

His decision, after a short period of trying to salvage the company, is not to salvage it. Chong sends the email to the journalists on the twenty-sixth of June, two thousand and ten. They return twenty thousand dollars of the remaining Y Combinator seed to investors. In September, Biggar publishes a seven-thousand-word post-mortem naming the founder-communication failure, the absence of passion for the journalism problem, and his own distraction through the launch window as the core causes.

So.

The deeper point: deciding whether trust can be rebuilt in time

Barra at GM took over a team after someone else's bad regime, and the work was acknowledgement, structural change, and the patience to let uglier numbers surface as the truth started being counted. Biggar at NewsTilt took over a team after his own bad regime — the bad manager he was inheriting from was himself — and the work was a different kind of honesty.

When you take over a team after a bad manager, the first decision is not how to lead the team. It is whether the trust that's been lost can be rebuilt inside the time and budget you have. Sometimes it can. Sometimes the honest answer is no — that the distance between what the team was promised and what they received is too wide to close, and the least cruel move is to end the arrangement rather than extend it.

The inheritor's question — can this be saved? — answers itself faithfully only when you've stopped asking whether it should be.

So. Your Next Move from this playbook.

Which unspoken expectation is currently producing friction on your team that nobody's ever actually agreed to — and what would happen if you put it on the table this week?