# Systems first *The problem is rarely the person* --- When results disappoint, the instinct is to go looking for who is responsible. Nearly always the better question is what the setup around them was quietly encouraging, because the same people in a different structure behave differently. The clearest case I've seen was a team written off as an execution failure and then fixed without a single person changing, by cutting the queue they were working inside and writing down the decisions that kept stalling. Once you look at the structure rather than the culprit, the fixes change. The rep discounting too hard is being rational about his comp plan; the team that keeps missing deadlines is carrying work nobody has counted; sacking either leaves the thing that produced them fully intact. More often than not the cheapest fix is in the terms, not in anyone's behaviour - a contract that pays from signature makes a customer roll out sites that no amount of chasing ever would. Finding the structure is harder than deciding to look for it, because pain is felt by people rather than by businesses. A problem arrives already framed as one person's pain, described through the part of it they can see, so the first account you get is true and partial at the same time. Everyone has a torch, the problem sits somewhere out in the dark, and each torch lights one part of it: the blind men and the elephant. The work is to take that first account seriously and then go and find more torches, until you can separate what you have confidence in from what you still don't know, and build a hypothesis about where to act from that rather than from the loudest description of the pain. What makes this hard is the delay. A system answers back slowly, and sometimes in the wrong direction first: the right structural fix routinely makes the reported numbers worse before they get better, which is exactly when the pressure to reverse it is strongest. And a change everyone signed up to still dies quietly if nobody ever builds the way to carry it out ([[Two halves of trust]]). Before you redesign the people or the product or the strategy, it is worth asking what the current setup is actually rewarding, because it is usually doing exactly what it was built to do. The best decentralised acquirers make a point of not interfering, keeping their centre too small to override the businesses they own. The clearest version I've run myself was a cluster of software products under one management team and one monthly review - one selling at five hundred pounds a year, another at fifty thousand, run as though they were the same thing. We split the teams and the reviews so each got its own agenda and its own time, and a product that had been shrinking for years started growing again. ---