(Self review) I stand by this essay, and in particular I like having this essay to point to as an example of why some organizations are not holding the idiot ball quite as much as people might assume. This essay is somewhat self defense? I work like this most of the time these days.
Followup work on how to better juggle balls is useful, and basically leads into an existing field of management. If One Day Sooner is unusual startup mode, Never Drop A Ball is a very normal middle and end stage of many organizations, and for good reasons. It's also a genuinely superior way for many groups to work. (Consider a hospital emergency room. Dr. House going deep into one patient's medical minutia is not as good as making sure that zero people have unsterilized and unbandaged bleeding wounds.) Having a shorter pointer is useful, though probably this could be made shorter and serve as a somewhat better pointer.
Followup on when and how to set balls down would be useful. Someone else should write that, I'm rubbish at it =P
This seems like an excellent essay, that is so good, and about such an important but rarely named and optimized virtue, that people will probably either bounce off (because they don't understand) or simply nod and say "yes, this is true" without bothering to comment about any niggling details that were wrong.
Instead of offering critiques, I want to ask questions.
It occurs to me that a small for-profit might plan to have the CEO apply One Day Sooner and then the COO Never Drops A Ball, and this makes sense to me if the business is a startup, isn't profitable yet, needs to grow fast, recently took huge loans and wants high ROI, or similar contexts to this.
By contrast, once a giant source of profit has been found, and "not killing the golden goose" takes priority, I would guess that the CEO should be doing this Never Drop A Ball thing, while some other person (the CSO? the CTO? the CFO? all of them aimed at different projects the CEO thinks are important?) does One Day Sooner.
Does this make sense? Do you think the CEO should pick between these two modes? What about CEOs that aren't in either mode?
Another question: how do these two different approaches differ in their approach to delegation? My hunch is that Never Drop A Ball delegates by finding someone who can do "Never Drop A Ball" and then assign them to some "zone" and basically play "zone defense", with higher levels of management handling things that don't land in any named zone and/or handling huge exceptions inside of a zone that require extra resources. I have no clear idea how to delegate "One Day Sooner". Do you?
"Never Drop A Ball" reminds me a lot of work ticket systems and/or bug tracking systems. Is that similarity spurious in your opinion, or on the right track?
Work ticket systems are one of the main examples of this I've worked with, that's the right track! Early in my career I worked IT for a university, and the ticket system was core to how the IT department operated. Every user report should create a new ticket or be attached to an existing ticket. Every ticket should be touched ideally once a day unless it was scheduled for a future date, and if a ticket went untouched for a whole week then that indicated something had gone horribly wrong. That's because the failure we really wanted to avoid was something like "the projector in room 417 hasn't been working for two weeks, the professors can't show slides, and nobody in IT knows about this." It's pretty easy for that to happen.
Bug tracking can be a little different, as software is a bit more likely to say 'eh, we don't care about that bug, mark it as Won't Fix/leave it on the backlog indefinitely.' My guess is this is a matter of asymmetric payoffs/counting up vs counting down. Or a matter of department. Some departments are going to weigh new features equally against fixing bugs, while your Q&A team is going to have a different institutional view.
how do these two different approaches differ in their approach to delegation? My hunch is that Never Drop A Ball delegates by finding someone who can do "Never Drop A Ball" and then assign them to some "zone" and basically play "zone defense"...
Yeah, Never Drop A Ball delegation is often by category. To use the school field trip example, it's straightforward to say the first grade teacher is in charge of getting all the first graders back safe, the second grade teacher is in charge of getting all the second graders back safe, and so on. A convention might have a treasurer (in charge of never dropping a reimbursement request or payment that needs to be made) and a tech lead (in charge of never losing a projector or microphone) and a community safety contact (in charge of never dropping a harassment complaint.) And like you said about higher management, the principal or convention chair are the people who catch problems that don't cleanly fit a category and operates as the fallback for lower levels. The main fail case here is when a problem is doesn't have someone obviously on that zone. One way to try and fix that is to say all unhandled problems are the domain of the organization President/CEO/Director, though this comes with its own problems.
From what I've observed, delegating One Day Sooner works best with tasks.
Examples:
(I have way more experience with software engineering and convention running than military exercises, if someone shows up and says that's not at all how the military works then probably I'm just wrong.)
It occurs to me that a small for-profit might plan to have the CEO apply One Day Sooner and then the COO Never Drops A Ball...By contrast, once a giant source of profit has been found ... I would guess that the CEO should be doing this Never Drop A Ball thing, while some other person (the CSO? the CTO? the CFO? all of them aimed at different projects the CEO thinks are important?) does One Day Sooner.
If the small for-profit is sufficiently small, I expect everyone in the organization is in One Day Sooner mode almost all of the time. Someone should have their eye on some important paperwork that must get filed, but most of the energy should be on the mission goal. (It would not surprise me at all if there are otherwise successful startups that, sometime in year 3, had to ask "wait, who filed the taxes for this last year?" followed by a quiet expletive.) This is going to vary based on the purpose and scale though. Like, I think a community hospital is generally in Never Drop A Ball mode. There just isn't a way to sprint really fast, work super hard, and fix all the broken bones before taking a rest. Someone's going to walk in ten minutes after you sent the last patient home with a new broken bone.
I currently don't think there's a generic answer here, it's going to vary based on what you're trying to do and how big you're organization is. If I had to guess, I'd guess an ideal division is the CEO in One Day Sooner mode, and their executive assistant in Never Drop A Ball mode.
What about CEOs that aren't in either mode?
I mean, I'm cheerfully willing to call these two modes a false but useful dichotomy, and there's other ways to work. Off the top of my head, Maker vs Manager Schedules; and like Maker vs Manager, sometimes making the distinction clear to people helps them understand.
That got a bit long, but I hope it helps! Thank you for the commentary :)
You can fail to get rid of balls. All of your energy and effort can go into not allowing something to crash or fall, averting each disaster shortly before it would be too late. Speaking for ten minutes with each of fifty of sources every day can be a good way to keep any of them from being completely neglected, but it’s a terrible way to actually finish any of those projects. The terminal stage of this is a system so tied up in maintaining itself and stopping from falling behind that it has no slack to clear tasks or to improve its speed.
This is the salient danger of this approach. While valuable, it absolutely must be paired with a ruthless, exacting and periodic inventory of the balls that matter, otherwise your slack will be completely burned and you will die an exhausted and unaccomplished juggler.
Is there a point where the cost to pick balls up and add new items to the checklist converge, and if so, what would be best to remedy that situation? or does this only apply to balls that have values sufficiently greater than checks?
I'm not sure I understand the question.
Do you mean, what do I suggest doing when it's equally easy to add something new to the list vs fixing a ball that's been dropped?
I think this approach is best used when fixing a dropped ball is costly. Consider the example of taking fifteen children on a hike. Fixing the situation if you have fourteen children at the end of the hike is stressful.
I was just thinking about if you could extend the practice to scenarios where adding something to the list would equal the value of the ball, like if the time and value needed to complete the list approached that of finding a lost child. Perhaps you could handle more balls if you allowed some to fall?
Not all tasks/responsibilities count as "balls" in this metaphor. Continuing with the hike example; the teacher's task list might include
None of which count as a "ball" - you do as much of the "nice to have" stuff as the (time/energy) budget allows after ensuring that no student gets lost.
Previously I talked about the skill of doing things One Day Sooner. Today I’m going to talk about a different way of working which is in some ways its opposite. The Sazen for this approach is “Never Drop A Ball.” I was exposed to this approach in my teens, though I didn’t grasp it on an intuitive, fluid level until I was midway through university. It’s the method of work I’ve been in most often for the last year or so, and while it’s not the way to get things done that I most enjoy, it does have some benefits. Never Drop A Ball has some downsides in use, with the main issue being fairly predictable from the phrase “reliably doing the bare minimum.” For my own case, the part I like the least is that I don’t feel proud of most of the output.
It works something like this: make a list of the things that actually, really, no fooling needs to happen, and then take multiple routes to ensure that those things happen.
In grade school, I would sometimes get confused by how repetitive teachers got on field trips. “Is everyone here?” they would ask again and again. “Line up neatly as you go into the next room,” they’d call, and then count us as we walked by. When I was older and sometimes responsible for shepherding kids myself, I began to realize the wisdom of my elders on this point.
You have many goals when guiding a bunch of ten-year olds through a wilderness hike. First among these goals is not to lose any kids. If you counted fifteen when you started the hike, you really really want there to be fifteen kids when you get to the end of the hike. Perhaps in theory you might be willing to grant that filling the children with the joys and wonders of the natural world is worth a tiny bit more risk to them! That’s the reason for the hike after all. This argument will do little to help you in the event you can only count to fourteen kids at the end.
You will observe people attempting to never drop a ball constantly comparing against very specific rubrics. Convergent pressures create check lists and todo lists. No task is allowed to be added to the plate without a written (preferably digitalized and timestamped!) reminded of it. Never dropping a ball wants redundancy, and when it can get extra resources those resources are spent quadruple checking things or getting to the same list marginally faster. From the outside, this can look like spending more time and people and money being spent to change nothing except maybe complaints become a little less frequent.
I have worked adjacent to organizations that were constantly dropping the ball. I have talked to them, they’d say a task was very important, and then a month later I’d realize I hadn’t heard anything more about it and when I talked to them again they’d slap their forehead and go “oh, right, I forgot!” When I asked them how they forgot, they’d shrug and gesture to piles of paper on their desk. “So much to do. You know how it is.” When I asked if the task was in that stack of paper, I’d be told they weren’t really sure, maybe it was.
Surgical checklists reportedly save lives by reminding doctors to do things like wash their hands. Airplane pilots have checklists too, segmented by when to use each list, and the one for landing includes “Landing Gear - Down”. I used to use a checklist when pushing software to production, and it included (details changed slightly in case a former employer decides this would be a proprietary competitive advantage) “Tests were run. Tests passed. Test results are for this build, not a previous build that worked before you changed things.” Those checklists are the organizational scar tissue created from dropping the ball.
Above all, every single time a ball gets dropped, you write down what happened and you sit down and you come up with some way to stop it from happening again.
First, make a list of every ball you have in the air. Clearly describe what outcome you want or (more frequently) don’t want. I suggest that you should have an evocative one sentence or at most one paragraph core goal even if you write a more detailed specification to describe the details. Never allow a ball to be added without an accompanying addition to the list, and never let a ball be removed from the list before triple checking that the ball is safely on the ground.
Second, run through every ball in the air repeatedly and at a regular cadence. Touch each one regularly, such that you would know if it was starting to fall. If you have too many balls to check on each of them sufficiently frequently, you have too many balls. Put some down gently.
Third, take responsibility (possibly heroic) for adding guardrails and defanging hazards. Every extra layer of protection must cut off some path by which a ball might reach a hazard. If hazards can be removed entirely, do so. It may be more useful to ditch the entire idea of responsibility and just think about what needs done to keep the balls in control.
Fourth, keep alert for weird ways of solving the problem or signs that you’re off target. It may be worth Babbling and Pruning, or Actually Thinking For Five Minutes, or Actually Trying. It may also be worth thinking about what you’d do with vastly more resources. This is especially true if you can’t think of a single guardrail, or if you’re adding guardrails but balls just keep getting dropped. Your guardrails must actually be blocking ways balls get dropped, even if they’re attempts with expected value instead of uncertain value.
This list is not exhaustive, but it sure exhausted me. This list is largely compiled by observation of the guardrails of organizations I have been embedded in.
You can carefully train and teach your team this lovely system which does not allow balls to fall, but the source of the balls (your customers or users) will not and cannot be taught. This cannot completely be managed by adding guidelines and guard rails at the point of entry for a ball, since there will somehow always be a place for things to trip and fall right before it gets to where you’d be able to pay proper attention to it.
You can develop an antagonistic relationship with the source of the balls. Information Technology staff have jokes about how dumb their users are, wait staff have jokes about how obnoxious customers are, teachers have jokes about how lazy their students are, and sometimes the jokes slide into despair or anger. It’s easy to feel like if they would just stop making your job harder, you could actually go home at a reasonable hour, and they must be doing this on purpose. In some of the more extreme cases, someone succeeds in preventing certain genres of balls from reaching them, thereby meaning they don't have to deal with it and also making themselves less useful.
You can fail to get rid of balls. All of your energy and effort can go into not allowing something to crash or fall, averting each disaster shortly before it would be too late. Speaking for ten minutes with each of fifty of sources every day can be a good way to keep any of them from being completely neglected, but it’s a terrible way to actually finish any of those projects. The terminal stage of this is a system so tied up in maintaining itself and stopping from falling behind that it has no slack to clear tasks or to improve its speed.
You can finish things, but do so at the bare minimum. Every extra bit of effort polishing the quality above that floor trades off against being a little extra sure nothing will go wrong anywhere or, more often in my experience, against taking on just one more little project. This doesn’t mean that quality falls to an unacceptable level, but I have noticed the definition of “unacceptable” tends to have an uncomfortable tendency to slip ever downwards.
You can become unintentionally even more important a pillar. See, once you’re reliable, once you’re an institution that doesn’t drop things, other people can notice this and use you as an ad-hoc support beam for their projects. This can be worth it, on an organizational level, but it’s rarely what your system was designed for. In some orgs, this shifts budget in a way reminiscent of a Dilbert cartoon, but even without that particular failure mode there’s a kind of moral hazard in making sure other people’s balls don’t hit the ground.
I wrote this half to praise an often unsung kind of work, and half in apology for when I’m working like this. It’s harder than it looks, and the problem is that it often looks like it’s not hard at all. What’s actually happening isn’t that a particular ball is hard to keep from falling; you could hold one or even two in your hand with no trouble. What’s happening is that there’s six or seven balls, and so what the end user sees is often the best that could be done on five minutes of thought while standing ready to be interrupted at any moment.
I’m not convinced this is a good way to work. Certainly it frustrates me. I often feel like I’m dashing about between a dozen things, where I can’t properly concentrate on any of them. And yet, I think that every sufficiently functional organization has at least one person operating in this mode, all the time. They are the exception handler, the catch-all, a way for problems that aren’t anyone’s main job to get seen to. Whenever you have more problems to solve than you have people to solve them, someone is going to be dividing their attention. Many domains, by their nature, create setups where the number of balls in the air will outnumber the people supporting them.
I.T. departments. Operations personnel at an event. Wait staff at a restaurant. Scout leaders at a campground. It wouldn’t make any sense to have one person on staff for each customer you’re trying to serve. Therefore, you begin to juggle. If the conference organizer hyperfocused on solving exactly one problem for a large conference, then maybe the communication with attendees would be flawless and sparkling, but they’d be communicating about a hole in the ground with a raw toad for lunch and a schedule of events that just consisted of a flag saying “Do Stuff.” Except the flag would be misspelled.
I think that as a pair, one person in Never Drop A Ball mode and one person in One Day Sooner mode (or two departments, if you want to scale it up) can be a powerful team, but if they don’t recognize how the dynamic works it’s easy to wind up in a compromise with neither of the strengths.Naming the technique makes it easier to see it and do something which is not that. If you notice that you’re juggling balls trying mainly to avoid letting any of them fall, recognize that this is not an overall strategy which will let you create new things quickly or well.