Speed Up Your Org: When to Require Approval

Post from February 22, 2023, filed under (feed).

Organizations can be slow. One thing that makes them slow is process. One part of process consists of approvals. But approvals aren’t always needed.

Mind the Default

The interesting thing about approvals is that they essentially mean a default answer of “no.” “Can I do x?” “No, unless you get approval.”

This can be legitimate, and approvals can be a critical requirement.

But more often than we like to think, we can switch the default without this meaning a free-for-all.

This works by asking to be informed instead.

By asking to be informed, the default answer is changed to “yes.”

“FYI, I’ll take care of y.” “Yes,” unless someone explicitly says “no” (asking to be informed doesn’t mean not to be able to put in a veto), or asks for clarification.

Shift of Burden

Switching the default puts the burden on what previously was the approver, to make sure their expectations are clear and they monitor communications. Without making requirements clear, including whom to inform, as well as without monitoring communication, they’d be charging the organization a high price when they would instead start stopping projects mid-flight.

This burden, however, is a good thing. There should be a downside to being unclear and inattentive, and therefore slowing others down. (Speaking of being slow, there’s a difference between taking a long time to process something and communicating something is taking a long time to process. Setting expectations helps.)

That is, by asking to be informed rather than requiring to approve, not only are processes sped up (faster default), there’s also incentive to communicate better.

As David, who reviewed this post, points out, the change of defaults also makes for a helpful burden on anyone taking initiative. Approvals may lead to complacency, in a sense that most care needs to be exercised until approval was given. Asking to be informed, however, empowers and trusts to approach the work more holistically, to exercise more care, and to assume more responsibility. This burden is likewise a good thing—a growth opportunity.

When to Require Approval

While at one end of the spectrum, it may not even be necessary to be informed, at the other end of it, approvals may still be needed.

Here’s one way to decide:

A flowchart asking about potential severity of failure and the probability of failure; only if failure could be severe and seems likely would approval be required—otherwise, asking to be informed or no process are to be preferred.

Figure: Connecting approvals with severity and probability of failure.

If the consequences of something going wrong are negligible, there’s merit to stepping out of the way to allow things to get done. Bias for action.

If the consequences are severe, but the probability of something going wrong is small, asking to be informed keeps the process fast but puts a safety in place.

Only if the consequences of something going wrong are severe, and the probability of this happening is sizable, then it appears useful, even advisable, to introduce an approval process.

❧ This is a sketch, and there’s some gray here. And yet monitor your organization, and your processes, on when you’re slow—on when you require approval. Review these requirements. Maybe you can’t do without process. But maybe you can change some default answers, and speed up your org.

Many thanks to David Beermann and Hans-Georg Bess for reviewing and sharing feedback on this post!

Toot or tweet about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!