# Bottled knowhow *Ask how many people wide the work is* --- Two people send me the same 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 one drags for weeks. The second is a call and an email and a meeting for one signature, and it's done. No recipe produces that. Ask a team who has it and who doesn't and they will mostly agree, and not one of them could write down what the second person knows. Information moves for almost nothing. Knowledge moves with effort. Knowhow barely moves at all, because it lives in people and transfers by working alongside them. You can't bottle it and hand it over. Most of what a business produces internally is made of the stuff. The monthly management accounts arrive as a spreadsheet, and what produced them is who to chase and when, which accrual is judgement rather than arithmetic, which number is always wrong in the first week and right by the second, what a plausible answer looks like before anyone checks it, and which of last year's oddities is a real trend rather than a coding error. The file is the part you can see. César Hidalgo's *Why Information Grows* is about that gap at the scale of national economies, and one idea in it comes straight down to a business. One head can only hold so much. Past that limit a capability exists only as a network, held in pieces across people whose links took years to form. > [!note]- The working > Hidalgo's unit for the limit is the personbyte: the most knowledge and knowhow one person can carry. Anything that exceeds one personbyte - which is nearly everything a mid-sized business does - exists only as a network, accumulated "in chunks of less than one personbyte" across people. His term for a product is a crystal of imagination: the practical uses of knowledge, held in nervous systems the buyer will never meet, given a form they can use without understanding any of it. A car is imagination in metal. [The book](https://en.wikipedia.org/wiki/Why_Information_Grows) is built on national export data rather than on firms, so the reading here is an extension of it. --- Which gives you a question to ask about anything your business produces. Not who owns it: how many people wide is it? Run it across the things that matter and the answers are uncomfortable in both directions. The monthly pack is usually several people wide and nobody has ever drawn that. The renewal-pricing logic - the exceptions, the legacy contracts, why one cohort invoices in March - is often nobody's, in the sense that no single person could reconstruct it; the business as a whole knows it and each person holds a corner. Meanwhile something you assumed was institutional turns out to sit inside one head, which is the genuinely fragile case and the one worth spending money on. The reflex when a thing comes back wide is to appoint an owner. That's right if you mean somebody accountable for it working, and wrong if you mean somebody who holds it, and the two get conflated constantly. The second version doesn't fail dramatically. The appointee standardises the thing down to what one person can carry, the others stop being consulted, and a year later nobody can point at what was lost. Some width really is disorganisation, and narrowing it on purpose is a solved problem: automate the close, consolidate the systems, move it to a shared service. The rest is what the thing costs to produce. The two look identical on an org chart, which is most of the difficulty. --- I learned that from the other end. In a restructuring, there was one team we could not explain. The titles didn't describe the work, the manager wasn't close enough to it to tell us either, and so what the team did never made it into the design of the target organisation. People lost their jobs because of what we couldn't see. A whole layer of us looked directly at a piece of the business and could not see the work, because the work only existed in the doing, spread across several people, and nothing about it had ever needed writing down. What they'd been doing, it turned out, was chasing invoices. The chasing wasn't the part that mattered. It was which customers to ring rather than email, which query was a real dispute and which was a stall, and who to go to before it became one, and that sat across four people and wouldn't have survived being written down. Problems appeared downstream afterwards and it took a while to connect them back. It isn't the leavers problem, which is smaller and easier. Someone leaves holding a login, or a routine nobody had ever assigned, and you have a gap in your handover packs. It's uncomfortable and cheap to fix, mostly by writing things down. The harder case is the thing that was never one person's to hand over, where a handover document catches the knowledge and misses the paths: who checks with whom, and whose judgement each of them calibrates against. A month of handover works for documented processes and reconciliations, and not for the junctions. In an SME the narrow version is usually pricing, and it's the one I'd check first. Pricing there is the owner-manager, doing the new contracts and the major renewals themselves, bringing to bear how much this customer will tolerate and whether it's worth underpricing now to sell the benefit later. One company I knew bid through public tenders with complicated schedules, which is high-stakes work you can't outsource your way out of: you can hire experts to write the bid, and nobody can tell you which numbers go in it. That's a one-head product, and a transition has to be bought as one - the successor in the room for the live pricing conversations for a good while before anyone hands anything over, rather than a document at the end. Retention packages try to hold the people and can still lose the network, because the links run to colleagues who took other jobs and to reporting lines that no longer exist. The wiki is genuinely good at what it holds - runbooks, onboarding, the deploy checklist - and disappoints only when it's sold as capturing the person. What the models changed is the boundary. Writing something down used to cost more than it returned; now anything written feeds the tools, so plenty that was never worth typing is worth typing. The residue still doesn't move. --- Seeing the width costs nothing but attention, and absence is the cheapest test: watch what [[Waiting|queues]] while someone is on leave, and ask who actually gets called when a certain kind of thing breaks. Rebuilding it costs real money. A second person walking the same work halves the pair's output while it runs, and no budget line shows the link it builds, which is why this is the spend that never survives a planning round unless someone senior is holding it. ---