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.

What does it look like?

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. 

How do you do it?

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.

How can it go wrong?

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.

Conclusion

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.