Speed Up Your Org: When to Require Approval

Published on February 22, 2023 (↻ September 7, 2023), filed under Engineering Management (RSS feed for all categories).

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 their being required means 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 Austin-Beermann, who reviewed this post, points out, the change of defaults may also make for a helpful burden on anyone taking initiative. Approvals may lead to complacency, in a sense that less care might be exercised once 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:

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 Austin-Beermann and Hans-Georg Bess for reviewing and sharing feedback on this post!

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you’d like to do me a favor, interpret charitably (I speak three languages, and they do collide), yet be critical and give feedback for me to fix issues, learn, and improve. Thank you!