The Headcount Myth and the Value of Overbooking

Fourth quarter, when a young information worker's thoughts turn lightly to thoughts of headcount. I've argued before that the idea that headcount (a.k.a HC in managerese) measures information worker bandwidth is a myth. The interplay of strengths and the ambiguity of definition of information work conspire to make it so. Headcount persists as a fixture in resourcing discussions because it signals relative priorities (and because we haven't found anything better). So far. Here I'll argue for a far better way to optimally use human bandwidth: true overbooking via continuous planning, coupled with strategic quitting. First, let's understand why headcount is a dumb measure of resource capacity and bandwidth, using one of my famous drawings. This one shows how 3 different workers (assume they are equally valuable) might react to 3 different loading conditions, and how much they can drive themselves before it becomes too much and their capacity "overflows." Think of capacity overflow as "brain muscle failure." [caption id="attachment_439" align="aligncenter" width="442" caption="The Headcount Myth"][/caption] The key to the diagram above is the actual overflow point under given project loading conditions for different individuals. From the picture above, "100%" (or 1 HC) clearly means radically different things in the 9 cases.  Let's remind ourselves why HC and traditional "project" definitions are mostly meaningless for the purposes of real (rather than ceremonial and budgetary) resource management and capacity optimization. Why Headcount is Dumb Quite simply, HC is silly because people like to work on different things, and have ridiculously different productivity levels on projects (or mixes thereof)  that apparently need the same skills. They also have different preferences about the amount of variety they like in their work. What is unacceptable fragmentation for you may be minimal variety and risk-hedging for me. The other big reason HC is dumb is that it inherits its logic from the logic of project factorization, which is itself dumb. Here's an example. One of the sillier claims I have heard (I think I saw it cited in Stephen Covey's execrable Eighth Habit) is that multi-tasking is bad and that going from 1 to 2 projects significantly drops your probability of succeeding at either. This is a dumb claim for one big reason: the idea of "project" is nearly impossible to define meaningfully in the context of modern information work. If you use a relatively clear measure of "projecthood" like David Allen's "Anything that takes more than 1 step and can be done within a year," then the typical individual is carrying something between 50-70 projects at any given time. Multitasking is a fact of life, not a choice. If you use standard waterfall organizational definitions ("things which are budget line items and have ambiguous and malleable expectations attached called 'deliverables' that will likely still need re-negotiation by Q3"), the typical individual is carrying between 1 and 4. These are purely nominal numbers, because of the typical level of incoherence in the nominal "projects" and the real/false synergies among "projects," in most organizations. In a truly Dilbertish world, this can create conditions where my 1 project is actually 4 and your 4 are coherent enough to actually count as 1. Finally, if you adopt a broad, new-agey approach, your whole life is one big project, all leading up to one giant deliverable to yourself on your deathbed. This is actually an operationally useful view, as I'll illustrate in a minute. I tend to ignore the middle level of coarseness, except for budgeting purposes, and work either by the Allen definition for actual resource/work estimation, and by the new-agey definition to keep it all together. So if we each typically, in a meaningful and measurable way, have 50-70 projects, clearly, thinking about HC at the level of 0.01 - 0.02 is beyond silly. We don't even know what 0.5 HC means. How on earth will we measure 0.02? Yup, the human mind is a rich and wonderful thing. It seems to admit a million sorts of bandwidth definitions. How many hours of email can you handle? Powerpoint talks? Writing? Reading? Coding? Relationships to manage? Errands? Paperwork? How much actual work is involved in committing to a weekly 1 hour attend-a-meeting level consulting role in a project? Is it really 1/40 HC (2.5%)? Assuming you are a lark with high morning energy, will it make a difference if the standing meeting is on Tuesday at 9:00 AM vs. Friday at 4:00 PM? How does opportunity cost work out? What about time spent on meeting-follow-up email threads? Overflow Detection, or Working to Brain-Muscle Failure You cannot measure work and bandwidth in meaningfully comparable ways. You can measure work by itself, as I argued before. So on the bandwidth side, what can you measure? Well, nothing with numbers, but you can detect an event: overflow. The human mind is an amazing null detector. It is bad at detecting 50 or 75% of its own capacity, but it can detect "full." Full is when there is a sharp drop in quality in non-trivial work (writing complex emails, tricky code) and/or a sharp increase in "falling through the cracks" for trivial work (missing appointments because you plain forgot, losing pieces of paper). The key is that it is sharp. You may see people talking about how they are "overbooked" (not calendar-wise; load-wise) but they are either just engaging in ritual moaning, or are taking HC seriously. Trust me, when you hit your limit, you will know. Your internal barometer of productivity will register a "oh crap, things are going to hell" condition. Worse (though even more detectable) you may freeze into stasis. It is the mental equivalent of muscle failure when you are lifting weights near your limit (work-life balance fits into this scheme by the way, since life/family stuff counts as work when it comes to measuring overflow: missing a kid's soccer game by accident is an overflow event). So why am I advocating true overbooking? For the same reason weight-training coaches advocate working your muscles to failure point. So your muscles grow. Let me explain non-metaphorically. True Overbooking Before you can understand why you should overbook your time, you should understand how to do so. You can't do it once a year, where your time gets parceled out in 5-25% increments for a year at a time. For weight training, you make decisions about how much to attempt to lift week-by-week. You need to be measuring your work at the same level of granularity using, say, the Allen-project. If you are measuring your work in units where "normal" is 50, and you add/drop/finish commitments 1 at a time, perhaps 1 a week, your internal water-level is varying around 2% at a time, with every change in your set of commitments. That's airplane-seat level or weight-training level of granularity. Between 72 and 73, your mental muscles may give out. So here's how you overbook yourself -- within the umbrella scope of your larger formal/nominal projects, take on commitments continuously, at this micro-level of granularity. When you hit overflow conditions, start optimizing by dropping commitments strategically and optimizing your workflows to get back under control, and then driving towards overload again. This means you need to view a lot of your commitments as contingent. But then, isn't your whole life contingent? Wouldn't you drop everything if you had a heart attack? Why overbook? Because that's the only way you'll pick a set of high-value opportunities to work on that match your strengths and present disproportionately high amounts of leverage, in terms of value to be won. Nobody knows their strengths at the level of detail where they can easily predict whether or not they'll like something without actually trying to do it. It is also the only way you'll work to capacity, since overflow is the only event you can detect using your mind's own feedback mechanisms. Dropping Commitments Strategically Overbooking to brain-muscle failure is all well and good, but that brings up the issue that most people hate: what to drop. Here are two heuristics that help:

1. Seth Godin's heuristic: applies the principle of The Dip: every project/commitment goes through easy early wins, a long valley of darkness, and then true returns. The valley is The Dip. If you're going to quit, quit before the dip. Quitting during is bad waste of sunk costs.
2. Drop the Drag: Productivity feels like movement. Movement has a feel of momentum at the "overall life" level, quite apart from movement towards specific goals. Even if you don't know what your life goal is, you can tell what is slowing you down and what is accelerating you towards it. Ask yourself, is this commitment slowing me down overall? If yes, that's a candidate for being dropped.

A metaphor I personally like: psychic acceleration/deceleration are absolutely detectable in the Einstein General Relativity sense, independent of where you are in a spatial frame where a "goal" is defined. I especially love the drop-the-drag heuristic. It is only movement that creates drag, and it is only drag that can send you clear signals on what to prioritize. If you ever meet someone who says they don't know what they can drop, it means they are pretending to work on too many things. If they were actually moving, they'd know by the drag. I'll write a piece just about drop-the-drag soon. A philosophical point: Overbooking is especially important for those who are looking for a purpose in life. This is because it is way easier to find a purpose for your life by overbooking to failure and systematically shedding things that are not your purpose. Negative definition works. At least if you are good-humored enough to only look for your life's purpose a couple of years at a time. I still don't know what I want to be when I grow up, but I am good till 2011. Optimizing via the Trash Compactor Principle Many people don't seem to get a basic fact about productivity "systems." Even when they work (like Allen's GTD), they come with an implementation and maintenance cost. If the content of your life and work isn't valuable enough to carry the overhead of a productivity system, you won't pay it. If you aren't moving or are going nowhere, it doesn't matter how efficiently you do it. This gives you the other way to recover from overflow conditions, after you've pushed yourself there. Overflow conditions (brain-muscle failure) show that you are actually in motion, and indicate that investing in productivity will now be a smart investment. Your hopper is full enough that any fat-cutting will pay dividends by effectively increasing your bandwidth by moving your overflow point higher. I call this the trash compactor principle. Unstructured work is like trash. It overflows relatively quickly. Optimizing and structuring your work is like trash compaction: it creates more room at the top. Applying productivity systems without work content already flowing through your pipeline in inefficient ways is like attempting to compact an empty trash can. Optimizing before you need to is pointless work. Overflow first. There was a time in my life when things were simple enough that I wouldn't have know what to put on a to-do list. Ah, nostalgia!