Don’t be a slave of the process, be aware of the process
When working, people generally have an ambiguous relationship with processes, structure or rules. They either just want to get things done efficiently without being bothered by protocol or bureaucracy, or they hide behind protocol instead of taking responsibility.
In our company we certainly don’t want an overkill of process, but we also want to be efficient with a culture of getting things done and continuous improvement. In a previous post I wrote about how we try to minimise protocol and policies, so how do we not end up in chaos?
By cultivating an environment where a culture and structure can emerge ‘naturally’.
Such an environment needs three things:
- Clear goals (company, team and personal), so everybody moves in the same direction
- Clear roles, so everybody knows their responsibilities
- A minimal set of simple processes and rules
The set of rules is necessary to continuously test the fitness of the system. We started with these:
- Don’t Make Me Think (DMMT)
- Be SMART
- Single Point Of Failure (SPOF)
Don’t Make Me Think
DMMT is the title of a book by Steve Krug about usability of websites. I read it one thousand years ago and the principle always stuck with me: the moment people start thinking, you have flawed UX/UI. You can apply the same rule to organisations. If a salesperson has to start thinking which quote template to use, how to send an invoice or how much to charge for a service, something is wrong in your process.
SMART
This must be simultaneously the most celebrated and most abused acronym I encountered during my career. Every meeting starts with ‘let’s do things SMART this time’ with people nodding in agreement. Every meeting ends with people leaving the room mentally exhausted with only one thought ‘I need a coffee’.
The next worst thing is SMART is only partly applied. Usually people are aware that a person should be assigned (A) and there should be a deadline (T) but keep the goal vague like ‘improve efficiency of sales’ or ‘make memory management more efficient’. Those kind of assignments are not specific (S) nor measurable (M) making it impossible even to judge if it’s realistic (R).
Single Point Of Failure
Single Point of Failure (SPOF) is a concept from (software) engineering system architecture where redundancy is built into a system to improve it’s resilience. This is especially needed for High Availability (HA) systems where downtime costs are high (human lives, economic). A system with one or more SPOFs is more fragile than a redundant system. We apply the rule to roles and people.
This is the rule people become aware of in the week before they go on holidays (simultaneously the period when people are most efficient). ‘What would happen if I would not be here?’, if production halts, code cannot be committed, prospects do not get contacted, support desk is offline, that is an indication that you are a SPOF in the system.
Computer says yes
The nice thing about above rules is that they are simple and that they can be applied to everything, at any scale. That means the rules can also be applied to the environment itself. Questions like:
- Where is the latest version of the project proposal?
- What is our prospected revenue for Q3?
- Will I get a raise?
Should all be clear to everybody who needs to know that information. If you can get to that kind of utopian state, you don’t have to think about non-productive chores and issues anymore, you can use all available time being creative and productive.
Computer says no
There are however dangers with focusing on structure and process:
1. Be wary of managing proxies: the process becomes the goal;
2. Not being aware of the process might result in unexpected outcomes.
Don’t mistake the process for the thing: be wary of proxies. What is important is being a company that makes great products for happy customers that is fun to work at. To achieve that, you need a set of tools and principles. A common mistake is that people exchange the proxy (eg an automated quality control for code) for the thing (we need great products). A common mistake from immature managers is that they hide behind the process (“I didn’t do anything wrong, I followed the process”). Mature managers are aware of the thing behind the proxy and see flaws as a chance to improve the process.
The second pitfall is overstressing the importance of the end while disregarding the means. With freedom comes responsibility. There cannot be an exception without a principle or premise. If you take the freedom to sway from the rule, you also have to take the responsibility to inform those that might not expect the outcome. Adding to the example above: if you find a flaw in the automated code control system, don’t forget to inform your team of the fix as it may lead to very unexpected results and unnecessary irritation.
The process is not important, …
…, being a great company is.
I strongly believe that if you want an open organisation where people feel free to take initiative and one that fosters creative thinking, this is what you need: simple but strong principles and rules, evolving processes, clear goals and well defined roles. If you want an organisation where structure emerges rather than designed, define goals, roles and process. Then continuously test their fitness with a simple set of rules.
Don’t be a slave of the process, be aware of the process.