# The constraint is a person *Get between the demand and the person* --- In my experience the constraint in a mid-sized business is often a person rather than a tool or a machine. Businesses grow naturally, and a critical process or a body of knowledge ends up embedded in one person because it's never [[Bottled knowhow|needed to be written down]]. It tends to become obvious pretty quickly who that is. Ask them what would help and the answer is nothing. It'll take too long to train someone, nobody else can do it, other people will get it wrong. From inside a week where the work has to go out, that isn't unreasonable: teaching someone else is a cost now and a benefit in some quarter that never seems to arrive. The key is to find a way to break out of that. When I've made progress with this, it has come from changing what surrounds the person: the requests coming in, the process running alongside, and the team underneath. ## The gatekeeper There tends to be a steady drip of routine activities and requests to a person like this. The best thing I've found to do, practically, is to insert myself physically 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 a bit of friction is enough on its own, sometimes the work can be done by someone else, and sometimes it can wait. Because you're in the middle, with some context about the business that neither side of the request may have, you can push back, delay and clarify, and some of the volume just disappears. From a slightly elevated view you can also merge requests into larger blocks, or give people a sense of when things will be delivered, so they can manage the expectations of their own senior leaders. You become the queue yourself for a while, which is fine as long as it's only a while. ## A parallel build Sometimes you can find a better way of doing the thing and wire it up in parallel. Someone was doing critical data preparation work for us, largely by hand, and we started building a more automated process entirely separately. Running the two in parallel kept the business operating, and building the new one spread the understanding to a broader team, who grew more confident about switching over. Building the replacement does the training, which means nobody has to agree to be trained. ## The span underneath The last thing is to look at the team beneath. These critical people are often in player-manager roles, particularly in systems, data and operations functions, 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 burden from the top, by picking up some of the check-ins and reviews yourself for a while, or you can break the span underneath them by creating a team-lead role. That only helps if the new lead owns work of a different length from the person above them, or it adds [[The missing middle|a layer that can only add delay]]. --- Goldratt's focusing steps still apply: find the constraint, get everything you can out of it, subordinate everything else to it, elevate it, and then look for the next one. What changes when the constraint is a person is that it can tell you it doesn't want elevating, and mean it, which is why all three of these moves work on the demand and the structure around the person rather than on the person.