Team and organisational processes have a tendency to run amok without explicit efforts to contain them. It happens in both highly structured teams and loose "flat" ones. Over time, processes become more complex while the context in which they were designed changes, reducing their benefit over cost. The result is a bunch of heavyweight, low value process bogging down your team.

Orgs that notice this process growth sometime react by raising the bar for new processes, requiring more thorough proposals, more discussion, and broader buy-in. This has the unfortunate result of making process experimentation harder. Processes that survive the process-process tend to be more complex, rigid, and deeply embedded. The people who designed the process put an awful lot of effort into it, and the sunk cost is socially very hard to ignore.

In my experience, the opposite reaction to this instinctive one produces much better results: lower the barriers to experimentation while making it harder for an unfit process to survive intact. One specific technique for doing this is the "keep or kill" test. It works like this:

  • Whenever a new process or change of process is proposed, a keep-or-kill decision is scheduled for the near future.

  • When the scheduled decision rolls around, stakeholders decide whether to keep the process or drop it. The default is to drop it unless it's clearly adding value in excess of cost.

This makes each new process or change only an experiment. The real decision about whether this is a good change for your team is postponed until you have some data about its impact and cost. Keep-or-kill makes changes easy to try by making them even easier to revert. It encourages repeated experimentation over complex, costly and failure-prone up-front design, debate, and consensus.

There's a hidden third option, of course. Rather than keeping or dropping the change as-is, you can tweak it or propose something else, and start the clock again. It's like a micro-retrospective. In this way, a complicated but high-value process can evolve from simple iterations and data.

With keep-or-kill, you only need a minimum of people to make a proposal, usually just two (a proposer and someone they've asked for advice). Any extension suggested by the team that isn't an obvious winner can be deferred with "let's try this first, and then add that idea later". A team that's honest about iterating on decisions with data will have a hard time refusing to experiment with a simple change.

Some practical tips:

  • Advertise the keep-or-kill decision and its date up front when proposing a change.

  • If someone proposes a new process without such a date, opt them in to keep-or-kill and request they nominate one.

  • Put an event in your team calendar or use a Slack reminder to notify everyone when the decision point rolls around.

  • Include both humans bearing the cost of the process and those enjoying the benefits in the keep-or-kill decision.

Keep-or-kill is a practise that you can adopt bottom-up. You don't need org-wide agreement or support, you just ask for the decision about a process change to be deferred until after a simple experiment has been run.

Bonus points: you can can adopt the same technique to simplify existing process. Propose a simplifying change and a scheduled keep-or-kill decision point. In this way, you can trim the fat from existing processes without offending their owners.

Many thanks to my colleague Mick Johnson for introducing me to keep-or-kill at Lexy.