# Turnarounds *What it actually takes* --- When you're given the hotseat in a business that has to improve to survive, the pull is to fix everything at once, and that spreads you too thin for anything to move. A few things matter more than the rest. ## Know your change window This is often set by cash, but not always. Some businesses die slowly, staying profitable for years while they decline (some B2B software, for example). So the clock gets set by other things: how patient the board is with management, what the investors' fund allows, when the big customers come up for renewal. How long you have informs how drastic you may need to be. ## Beginner's mind Your first three months are the most important. You have no stake in the previous decisions, so you can re-run them without it reading as criticism. That licence expires: within a few months you'll have positions and allies of your own, and you'll be part of the machine. Use early meetings to collect artefacts - reports, spreadsheets, plans, customer materials - that have been committed to paper, for as far back as you can. Looking through will help you reconstruct the history, and contextualise the present. And what's not available in writing is just as illuminating as what is. Ask each person in the senior team, separately, what they'd fix if the business were theirs. The answers won't all match, but you will get a sound list of hypotheses to test, and where they do match, you can move swiftly. Some issues are visible to everyone; they just don't feel empowered to take on the fix. They weren't in the room when the original decision was made, the person who owned it has gone, or raising it now would read as second-guessing a colleague. So the status quo carries on, until you ask. Spend hands-on time with the product (or products). Teams can get "snow blind" - trust their opinions, but verify for yourself. I once treated a shrinking business as a sales and marketing problem for well over a year, partly because that's what the senior management believed, and partly because I could see the obvious gaps in that area. A new tech leader forced me to look more closely at the product - and in one afternoon it was clear that I had it wrong. A better commercial engine wouldn't fix years of bloat and roadmap drift - a full stack rebuild became the priority. ## Structure > People When results disappoint, human instinct is to blame the people; they produced a bad plan, they didn't escalate the issues, they're not capable, or they're just not trying hard enough. It's better to start by looking at the structure they're working in. Functional boundaries, reporting lines and team sizes typically reflect evolution and business history rather than today's needs. In one situation I found a management team that had been stretched across three product lines with almost nothing in common in terms of end market, account size or technology stack. We split the leadership group within the first two weeks, and the people who took what looked like narrower jobs were relieved. One product line, seen on its own for the first time, was clearly short of senior expertise; which must have been true pre-shuffle too, it was just hidden. Filling that gap became the next problem. ## Two or three big decisions, early Most of what moved these businesses came from two or three decisions, and half the job was refusing to spend energy anywhere else. In practice that meant picking one competitor to take on rather than the whole market, so the story and the reference case only had to work once before we could carry them elsewhere. We stopped the marketing, events and retention spend in a declining business, on the bet that nothing would move: sales didn't move, churn didn't either. We simplified six products into two with clear price points. And a team pointed at one business, with its own plan, gets more done than the same people spread across three. The other half of focus is the stuff already in flight. A struggling business is rarely short of initiatives; it's carrying too many, and most of them are stuck behind decisions nobody has made. Before you start anything, count what's already started. Ask each team to list every active commitment and the number that comes back will be a multiple of what anyone guessed, which on its own explains why everything feels late: a queue that long means everything in it waits, however hard people work. Most of what you park, nobody misses - and the few things with a loud sponsor come back quickly enough to prove they mattered. Making the work visible doesn't need a system. In one business we weren't getting paid quickly enough, and part of the reason was that the paperwork the customer needed to pay us against simply wasn't getting finished: it felt like an end-of-the-day job, and nobody had connected it to the cash cycle. We put a row of physical boxes in the office and moved each job's paperwork through them, one box per stage - not started, being worked on, ready for checking, ready to submit. Nothing about the work itself changed; it just became visible, in boxes everyone walked past instead of piles on people's desks. ## Put the plan in the budget A plan only becomes real when it's in numbers people are held to, and the budget is where that happens. Expect to send the first cut back: it will arrive with everything still going backwards, and the work is in the assumptions - when development lands, when a deployment becomes something you can sell, what a missed window costs. When we modelled a cross-sell wedge into an adjacent customer base, we shaped it as a five-year adoption curve rather than the straight ramp the first draft had, segment by segment, with some segments assumed to adopt at a fraction of the rate of others. In a business that sells on an annual cycle, a missed implementation window doesn't cost a month, [[Waiting|it costs a year]], and you can't sequence a plan without knowing it. What you send back is the assumptions - the totals follow from those. Where a business's future is in doubt, build the case, don't assert it. For one that was being written off, we costed the technology rebuild to know how long the customer base needed to hold, put renewal probabilities against the customers and looked at the range of outcomes rather than the average, and separated the spend that protects existing customers from the spend that has to earn its case. It had been keeping customers on one-year contracts because nobody would commit to its future; when we committed, they did too. ## Set the rhythm, then hold your nerve Keep the machinery simple: short weekly sessions that actually decide things, a written update at the end of the week, the numbers and the product plan reviewed separately so each gets proper time, and a plan on a page for each business - the long-term goal, this year's milestones, the projects that get there, the metrics that prove it. Holding your nerve is harder, because the right moves routinely make the reported numbers worse before they make them better, and the pressure to reverse them is strongest exactly then. Exit unprofitable contracts and revenue falls; move engineers onto root causes and the roadmap slows; tell your biggest customers the truth about timelines and you'll watch the satisfaction scores dip for a quarter. Every one of those is the right call, and every one looks identical to a new leader making things worse. To get through it honestly, you need to know the difference between a system correcting and a plan failing, because in the board pack they look the same. The headline numbers are lagging: they're still reporting the consequences of decisions taken months ago. The signals that answer the question sit upstream, closer to the work - the defect rate, retention in the customers you kept, how long support tickets take to resolve. When the plan is working, those turn first while the headlines keep falling, and the gap between the two turns is where you earn your money. When they all fall together, the plan isn't working, and you look again rather than hold harder. Name those signals when you build the case, while you've still got nothing riding on the answer.