Differentiate “Process” from “Deliverable” Work

I once asked a coworker to “get on top of our errors, bring them under control, and keep them that way”. I did give a fair bit more detail as to what I want, but for many weeks, my coworker was failing to do what I asked. He worked on it, iterated, but at no point did I get the comfortable feeling of “the errors are under control, I know that if a new error starts happening frequently, it will be on our radar, and we’ll fix it quickly”.

It took a while for me to realize why my request was not serviced successfully. This same coworker was doing good work when asked things like “implement a new signup flow”. I eventually realized what the problem was — “deliverable” work, where the end result is a finished product or feature or module, is very different from “process” work, where there is no end result as such. There’s a stable state — “systems are running smoothly” or “our services achieve desired SLAs” or “the error situation is under control”, but the work of keeping the stable state is ongoing.

Until that point, my coworker was only doing “deliverable” work, and the transition to “process” work, which was never explicitly called out, was too much of a paradigm shift to successfully make without conscious awareness of what is happening.

So, when given a task, make sure you understand whether it’s a “deliverable” or a “process” task. Sometimes a task can have both components.

For “process” tasks, strive to set everything up in a “push” rather than “pull” way. Having to remember “how things are going” on a daily basis is a time-consuming, diligence-requiring annoyance. Automatically receiving a notification when “things are not going well” saves cycles, and also lets you respond in a more timely manner. You do, however, run the risk of having things break on you and not noticing. When no automatic notification about “things not going well” are coming in, how do you know if things are really well, or if the notification system is broken? It is important to carefully set up a “canary in a coal mine” sort of system along with any "push" notification system.

Next: Organize Your Execution ⇒