Have you ever had a colleague complain about there being too much process? Or pointed out, powerlessly, that an existing process is pointless? I would posit that you have. In fact, it may have been you doing the complaining.



I’ve certainly been there.



I’ve been there in times where my jaw has dropped when opening up the description of the deployment process for an older part of the system, and in times where I’ve torn my hair out as a simple approval for a flight has gone round and round in endless repeating circles.



“Surely it must be easier than this,” I hear you cry and hear myself cry.



Yes, processes can be extremely annoying. But they don’t have to all be annoying. And, in fact, they should do more help than harm.



What is a process anyway?



Process is a very abstract term: in the dictionary, which I have just opened, it is defined as a series of actions or steps taken in order to achieve a particular end. In business in general, this could be the process in order to get some budget signed off or to hire a new person.



If you’re an engineer reading this post, then the word process may make you think about the steps that your JIRA tickets take from being created to being complete, or the way that deployments of your live application are done, or even the forms you need to fill in for your annual review.



Regardless of whatever the end is that the process is there for, the definition of that process is meant to make that end result more replicable, predictable and consistent regardless of the individual(s) that execute it.



Process as code



You could think of a process as the code that the company has written about how to do a particular thing. Everyone else following that process is executing it to achieve the same desired, consistent result.



But, as all programmers know, code evolves over time. Old code gets stale and misses out on the latest updates and features. The original authors of that code have also since learned more and become better programmers since they wrote it.



Have you ever gone back to code you wrote years ago and wondered what on earth you were doing at the time? The same is true of processes. Companies can grow, shrink, mature or completely reform: you can’t expect the processes to stay the same as a result.



Processes, like code, shouldn’t be set in stone. They should be revisited, tweaked, refactored, rewritten and deleted.



Arguing against processes



If processes don’t change despite being inefficient, then you’ll need to work on getting them changed. But why do processes get left alone and not continually updated?



Sometimes a business won’t want to change processes because those in charge are lazy: they’d rather not have to invest any effort into something that works well enough, regardless of how inefficient it is in practice. Tut.



Additionally, a process can often become orphaned because the creation of that process is to ensure that knowledge can be handed over (e.g. the process of deploying the live application) or to ensure the consistency expected by a particular individual (e.g. the annual review process as defined by the head of HR). As time passes, the relevance of those processes fades and need updating. But those who defined them may no longer care as deeply about them, since their attention is now elsewhere.



Still, in the same way that the management of a business would expect their employees to be efficient and diligent with their work, that same management should also expect to continually update the collective ways of working that they have codified in order to demonstrate that they are being efficient and diligent also.



A process should fundamentally serve those that are continually applying it. If those closest to the ground want to make it better, then they should absolutely be allowed to change that process for themselves. It’s likely they know more than the original authors about the latest and greatest way to get that work done.



Let chaos reign, rein in chaos



Still, even the best processes don’t have their place. There is also a good argument for process to not exist.



When a team is embarking on innovative or unknown work, process seems only get in the way, constraining ways of working and thinking. Chaos often breeds innovation, so why should we stifle it? But, on the other hand, if there’s no process, aren’t we all going to hurtle into the sea in a fiery ball?



There’s a neat quote that suggests a way of dealing with these situations:



Let chaos reign, then rein in chaos.

Andy Grove

Often during innovative or chaotic periods, it is best to let go of wanting to control things and let them unfold in a natural way, even if it seems like bedlam.



Chaos often gives birth to a new way of working; an emergent practice which can be the new best way of tackling a problem. After people converge on this new way naturally, then the emergent practice can be codified into the new process. Chaos is transitory, but necessary. Things will stabilize eventually.



A practical example is running R&D projects. Often truly innovative developments need space and lack of constraints for those that are working on them to explore all aspects of the problem. Too many meetings, checkpoints, reporting upwards and real-world engineering constraints can kill creativity.



Although it can be deeply uncomfortable, especially for directive-driven managers, to think that an investment into R&D is “not being managed”, letting go of the situation and trusting staff to do things the way that they want to can, paradoxically, get better results.



As the R&D project begins to move into a prototype and requires more input from designers and engineers, then chaos can be reined in.



But not before.



So, in summary



Process is good when it creates predictable results. However, like code, processes must be continually updated and revised to stay relevant, and the updating should be done by those closest to the process: the staff actually executing it.



Creative and innovative projects can benefit from having no process to let chaos become an emergent behavior which will eventually become the new way of doing things. Let chaos reign, then rein in chaos.



Now, according to my own process, this is where I hit “publish”.