# Human bottlenecks *Spread what only one person knows* --- In *The Goal*, Eliyahu Goldratt argued that every factory has a bottleneck: one point that sets how much the whole factory can get through. Jobs arrive from several directions and queue in front of it. An hour saved anywhere else doesn't change how much gets through, because the jobs still have to [[Waiting|wait their turn]] there. An hour lost there is lost to the whole factory. In my experience, the bottleneck in a mid-sized business is often a person rather than a tool or a machine. As a business grows, the way a critical job gets done ends up with one person, because nobody ever needed to write it down. It tends to become obvious pretty quickly who that is. Every hour of their time that is lost is then an hour lost to the whole business. Ask them what would help and they'll say nothing will. It'll take too long to train someone, nobody else can do it, other people will get it wrong. In a week when the work has to be finished, that isn't unreasonable. Teaching someone else costs time now, and the payoff comes in some later quarter that never seems to arrive. Every hour they spend teaching is an hour taken from the work everyone else is waiting for. And they're the only one who knows the work well enough to teach it. ## What only they know Before deciding what to do, it helps to know what kind of knowledge the person has. Some of it is know-what: the facts and steps of the job, such as what happens in what order, where the files are and which customers are on which terms. Know-what can be written down, and once it is, anyone can use it. Passing it on costs little more than the time it takes to write it. Knowhow is different. It's the practical sense of how to get something done. Two people each send me a policy for sign-off. One attaches the document with a one-line note, can you approve if you're happy, and leaves me to orient myself, recall the context and work out what to say. The other messages first: remember we talked about X, this is coming, look out for it, I'll find a slot in a couple of days. The first request drags on. The second takes a call, an email and a meeting for one signature, and it gets done. There's no recipe for what the second person does. Ask a team which of them work like that and which don't, and they will mostly agree. Not one of them could write down what the second person knows. Knowhow lives in people, and the way to pick it up is to work alongside someone who has it. Most of a business's internal work, such as finance, reporting and admin, runs on knowhow. The monthly management accounts arrive as a spreadsheet. What produced them is knowing who to chase and when, which estimated costs are judgement calls rather than arithmetic, and what a plausible answer looks like before anyone checks it. The spreadsheet is the only part of that you can see. César Hidalgo's book *Why Information Grows* is about this kind of knowhow across whole national economies. One idea in it applies directly to a single business. One head can only hold so much. Any job that needs more knowhow than that can only exist across a group of people, each holding a part. The working relationships between them usually take years to build. > [!note]- The working > Hidalgo's unit for the limit is the personbyte: the most knowledge and knowhow one person can carry. Any job that needs more than one personbyte (which is nearly everything a mid-sized business does) can only exist across a network of people, built up "in chunks of less than one personbyte". [The book](https://en.wikipedia.org/wiki/Why_Information_Grows) is built on national export data rather than on firms, so applying it to a single business, as here, goes beyond what the book itself shows. So there are two questions to ask about any piece of work your business depends on. The first is whether it runs on know-what or knowhow. The second is how many people wide it is: how many people between them hold what it takes. The answers to the second question are uncomfortable in both directions: work is often wider than you thought, or narrower. The monthly management accounts usually depend on several people, and nobody has ever written down who they are. The rules for pricing renewals, with their exceptions, their old contracts and the reason one group of customers is invoiced in March, are often known in full by no one. Several people each know a part. And something you assumed the whole organisation knew turns out to sit inside one person's head. When the answer is several people, the reflex is to appoint an owner. That's right if you mean someone accountable for it working. It's wrong if you mean someone who holds all of it in their own head. That is one way a business makes a bottleneck, and people mix the two up all the time. The second kind of owner doesn't fail dramatically. They simplify the work until one person can carry it. The people who used to know parts of it stop being asked. A year later nobody can say what was lost. Put the two answers together and they tell you what you're dealing with. Know-what held by one person is the cheap case: it needs writing down, which mostly means finding them the time to do it. Knowhow held by one person is the fragile case. It's the one worth spending money on, because the only way to pass it on is for other people to work alongside them. Knowhow spread across several people is harder still, and it comes up again below. ## Taking the load off Whichever it is, the person needs time they don't have: time to write the know-what down, or time for other people to learn the knowhow by doing the work with them. When I've made progress with a person like this, it has come from changing three things around them: the requests that reach them, the route the work takes, and the team underneath them. Start with the requests. A person like this gets a steady drip of routine tasks and requests. The best thing I've found to do, practically, is to put myself between the people asking and the person being asked, so that the requests come to me, and triage them from there. The first thing that gives you is a view of what's actually coming through. Then some of it falls away. Sometimes the extra step of going through you is enough for people to drop a request, sometimes the work can be done by someone else, and sometimes it can wait. Being in the middle, you have some context about the business that neither side of the request may have, which lets you push back, delay and clarify. Seeing all the requests together, you can also group similar ones so they can be done in one go. You can give people a sense of when things will be delivered, so they can manage the expectations of their own senior leaders. For a while the requests wait on you instead, so this has to be temporary. The second change gives the work a route that doesn't go through them. Sometimes you can find a better way of doing the work and set it up to run alongside the old one. Someone was doing critical data preparation work for us, largely by hand, and we started building a more automated process separately from the existing one. Running the two side by side kept the business operating. Building the new process taught a wider team the work without the original person having to stop and teach them, and they grew more confident about switching over. The third change is to look at the team beneath. These critical people are often player-managers, particularly in systems, data and operations. They're doing the doing and running a team at the same time, and running the team is surprisingly time-consuming. You can take some of that load off them yourself, by picking up some of the check-ins and reviews for a while. Or you can split the team beneath them by creating a team-lead role, so fewer people report to them directly. That only helps if the new lead handles the day-to-day while the person above handles the longer-range work. Otherwise it creates [[The missing middle|a layer that can only add delay]]. ## When they leave The first cost of knowhow held in too few heads is the queue while they're there. The second comes when they leave. The knowhow leaves with them, and so does any work nobody had written down. Often nobody notices until something that depended on it breaks. I learned this in a restructuring, where it was a whole team rather than one person. There was one team whose work we couldn't understand. Their job titles didn't make sense, and their manager wasn't close enough to the work to explain it to us. So what the team did never made it into our design for the new organisation. Only after they'd left did we realise they had been doing work nobody had written down. That work kept other parts of the business running smoothly. They called customers after invoices went out to check they'd arrived, and answered the queries that came back. Problems started showing up elsewhere in the business, and it wasn't immediately obvious why. Knowhow spread across several people is harder still to hand over, because no one person holds it all. A handover document can capture the know-what, but it misses who checks with whom. A month of handover works for routine processes such as reconciliations. It doesn't work for the steps where one person relies on another, or passes work to them. When you buy a small business, pricing is a classic case of knowhow held by one person. Pricing there is usually done by the business owner, who handles the new contracts and the big renewals personally. They know how far each customer's price can go, and whether it's worth pricing low now to win a customer and earn more from them later. One company I knew bid for its work through public tenders with complicated pricing schedules. That's high-stakes work you can't fully hand to outsiders. You can hire experts to write the bid, but only the owner knows which numbers to put in it. So the handover has to be planned and paid for as a transfer of knowhow. Instead of a handover document at the end, the successor sits in on the real pricing conversations, many of them, before anything is handed over. Retention packages pay people to stay, but you can keep the people and still lose the working relationships around them, because after the deal the colleagues and reporting lines around them change. --- Finding out how many people each piece of work depends on costs nothing but attention. The cheapest test is absence: watch what queues up while someone is on leave, and ask who actually gets called when a particular report or process breaks. Building the same knowhow in a second person costs real money. Having them do the work alongside the first means paying two people for one person's output while it lasts, and no line in the budget shows the working relationship it builds. Unless someone senior protects that spending, it tends to be cut at the next budget round. ---