The Cost of Process Evolution

There’s a genre of “don’t I sound smart” type of personal improvement insight that draws from the same well as the old joke, “In Soviet Russia, television watches you!” which looks something like,

Control your schedule; don’t let your schedule control you.

I’m not even kidding.

The linguistic construct even has a name: the Russian Reversal. At the risk of over-explanation, the formula is simple: you originally started with well-intentioned systems—emails, personal and professional calendars, to-do lists, familiar lifestyle rituals—and after a while, these routines calcify from useful processes to tedious constraints. The advice is to break away from this repetitive rut by recognizing these limitations and overhauling your approach, for a fresh new start.

Put in these terms, this type of insight is yet another format of productivity porn. It triggers feelings of FOMO with promises of a happier, more efficient, and more productive version of yourself—if you only broke free of these constraints. Chasing the dragon of productivity, though, has no endgame; much of the self-improvement industry relies on the fact that it’s nigh impossible to measure success, and adopting new systems feels exciting and personal progress.

This isn’t just about churning between a dozen to-do list apps either. The Agile Manifesto has this as a core tenet:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is the principle behind team retrospectives; the idea is to consistently push for improvement, evolving the how along with the what of the software you’re building. I’m pointing this out not because it’s a bad practice, but because evolution is an ongoing cost, one that most teams are willing to pay for the promised improvement in effectiveness. Ideally, these iterations enable the team to work faster and with less waste, but as with the above observation on personal efficiencies, the difficulty of quantification can make this aspect of agile feel Sisyphean.

In the worst cases, the iteration is less evolutionary and more outright revolution. For instance—and I’m speaking from experience, unfortunately—a planning process that didn’t quite produce accurate timelines and timely deliverables gets completely overhauled the next quarter. When that newfangled process also falls short of the mark, another Product/Program Manager is tapped to run the planning exercise the quarter after…and this can go on for a while. I guess eventually you’d stumble across a system that gives off the right productivity vibes, but the cost of the iterations themselves quickly overwhelm any inefficiencies attributable to imperfect processes.

To be clear though, I’m not arguing for procedural stasis. To go back to the analogy of evolution, progress comes from changing a small subset of variables, and testing it against the unmodified original to see which works better: or, in CS terms, a genetic search algorithm. This may mean tweaking meetings by adding a new standing agenda item or redefining membership; trying out a new story point estimation system for grooming sprints; adjusting bedtime routine by adding 15 minutes of non-fiction reading1. And as a practical matter, changing and measuring one thing at a time follows my principle of singular variability, applicable to personal processes as much as, uh, science.

One step at a time.