Enabling Process vs Bureaucratic Process

The Process, today, is king. There're a lot of people focusing just on process, and a lot of them hold it as The True Solution to all the world's problems.

Then, there're those who don't believe in process. They say, we mostly focus on people! Process is a failed attempt at commoditizing individuals; a lot of large organizations survive despite their processes, not because of them!

But then... you start noticing something. When you speak with agile folks, they talk about guidelines. You talk about Google, which is the poster child of the New Enterprise, where people are happy and aren't burdened by strange processes, and you discover that, when designing Site Reliability Engineering practices, checklists are considered an excellent tool.

So?

So, I think that process is useful. Sometimes, it's overly so. Yet, it must be the right kind of process.

Let's see a couple examples for an example process to request some days off.

Example A

In order to request one or more days off, you should send an email stating which days you'd like not to work to both your direct supervisor and the HR department. The request should be sent at least 10 business days before the first day off you'd like to take. Your direct supervisor has got five business days to either confirm or reject your request; if he doesn't answer, your request is automatically approved.

Another process clearly defines who's your supervisor and who takes its place should he be on vacation or ill.

Example B

In order to request one or more days off, you should download the proper *Ask For Some Days Off Form*, fill it in completely, sign it, and send it to your supervisor via email.

Enter the bureaucracy

I'm confident that most corporate environments follow Example B rather than Example A. Example B is the perfect bureaucratic process: while it is short and it doesn't seem overly complicated at a first glance, it is nebulous, and it may enable nothing.

Where should you download the right form? Most probably it won't be linked from the policy page. You'll need to find it somewhere. And, if you finally ask the template to your colleagues, make sure it's the latest, approved version. Then you fill it in. How? Maybe it's a PDF, and you need to print it, fill the required days in a box, sign it, scan it back and send it via email.

And then, what happens? Maybe, nothing. Maybe your supervisor is ill, and won't read emails. Maybe he isn't, but he won't check immediately whether there's somebody who can do your job while you're away, and will forget ever after. There's nothing in such process which guarantees an outcome. There's no explicit responsibility transfer - your supervisor won't risk anything if he doesn't answer your request; you're the only one who's impacted; maybe you won't know anything until the day before you'd like to leave!

A good, enabling process

A good process will make it clear why it exists; we should not create processes for their own sake. A good process establishes a clear guideline to reach a target. And we should not create processes before we need them! A special request which is made once every couple of years by a single employee can be handled manually.

A good process is easy to follow and is not unnecessarily complicated; it won't use forms, software or other specialized tools when simple ones will fit perfectly.

You always know who's in charge at a certain phase of a good process; it's impossible (or rare and highly unlikely) for the process to get stuck without somebody taking care. Inaction is prevented by a default action which allows the process to go on without somebody's consent, if he's unwilling to enter the loop.

A good process either produces the desired outcome, or fails as fast as possible.

An even better process

An even better process is the one which makes it clear which business rules are applied at each approval step; using again the example above, this could be:

For each team, it is required that at least two members to be in the office at all time, in order to handle the basic support levels needed by customers; to achieve such requirement and cope with illness or other emergencies, no days off will be allowed if that would reduce the number of working team members to a number lower than three.

In order to request one or more days off, you should send an email stating which days you'd like not to work to both your direct supervisor and the HR department. The request should be sent at least 10 business days before the first day you'd like off. Your direct supervisor has got five business days to either confirm or reject your request; if he doesn't answer, your request is automatically approved.

Another process clearly defines who's your supervisor and who takes its place should he be on vacation or ill.

This process is probably close to great; people in the team will probably auto-organize with their days off, and won't request things that will inevitably be denied, reducing HR and supervisor's work.

Let's make sure the Template Zombies stay dead, this time!