2025-04-18 “Process” is not a dirty word ======================================== I run into a lot of folks who have a very negative reaction to the term “process”. I think that’s a very legitimate response to experience of Bad Process, and there’s a lot of Bad Process out there. But I think there’s also a lot of Good Process and that’s under-represented and Good Process can be hugely valuable. `If by “Process” you mean `__ long rigid documents that are tedious to read, tedious to follow, often just aren’t read or followed at all, bear little resemblance to reality, or are used as a stick to punish folks? Yeah that’s Bad Process and it can get in the sea. `If by “Process” you mean `__ agreed-upon conventions that help folks be clear and consistent in their approaches, increase alignment, make things smoother and faster with shared understanding, help newcomers get up to speed faster, save folks from reinventing the wheel or working things out from first principles repeatedly, and help surface disagreements and gaps and misunderstandings? Gimme gimme gimme. And a lot of the time Bad Process is what gets called “process” while Good Process ends up as “agreements” or “ways of working” or a tonne of other names that obfuscate it slightly. I firmly believe that **Good Process will make things faster and smoother and easier and clearer** and shying away from anything “process” because you only think of Bad Process means giving up a lot of value. Avoiding Bad Process -------------------- I think there’s so much Bad Process because it’s really easy to create. Some ways to avoid going wrong: Don’t try to cover every possibility """""""""""""""""""""""""""""""""""" It’s really tempting to want to get stuck in and try to define every scenario, every possibility, every exception. Don’t - start with what you’re clearest about, iterate from there. Fundamentally this increases the likelihood you’ll actually ship something - perfect is the enemy of good after all. But also by definition exceptions are exceptional - give people space and tools to work things out in the field as they need to. If something turns out to be a more common occurrence, sure, incorporate it later. Don’t go too deep """"""""""""""""" If it’s important someone cuts the wires in colour order with number three cutters, say so. If someone just needs to cut the wires, just say that. There are places where it’s valuable to be consistent (often at interaction points), but there are places where it’s valuable to give folks space to act as they see fit. The deeper you go, the more possibilities you encounter - see “Don’t try to cover every possibility”. Involve stakeholders """""""""""""""""""" An all-too-common scenario is someone (usually with a title like “Manager”) goes away and Writes A Process but it’s for Other People to follow and so they hand it off and then the folks actually on the receiving end find it’s irrelevant or stifling or otherwise unhelpful. As with so many things, feedback loops are important, handoffs can be harmful. `The IKEA effect `__ is real - people have more attachment to things they have a hand in - they’re more inclined to follow a process they helped create. Treat it as an ongoing living thing """"""""""""""""""""""""""""""""""" You will not get things right the first time, and even if you do, things change and evolve. If your policies aren’t updated to reflect changing realities, they’ll become stale and irrelevant, and people will begin to distrust and ignore them. Per the IKEA effect, this is another opportunity for folks to become attached and invested as they contribute to updates and changes. Understand that reality is messy """""""""""""""""""""""""""""""" Sometimes people won’t follow the process. There’s a whole host of reasons why, and it can be tempting to write this off as “laziness” or “human error”. But sometimes there’s an ongoing emergency, sometimes things didn’t go to plan, sometimes there’s circumstances the process didn’t envision, and sure sometimes people just simply forget stuff or get it wrong. Be clear about why the process says what it does. This is of the most important parts of documentation in general - context and understanding - see https://blog.doismellburning.co.uk/document-all-the-things/. If people miss something, enable them to understand the consequences. Maybe part of a process is safety critical, or has implications you might miss - the clearer this is, the better. If people need to adapt something, they can do so better the more they understand it. Creating Good Process --------------------- There’s a lot to be said for just writing down the briefest version of what already happens / what you want to happen, and iterating on that - incremental improvement etc. Documenting Minimal Viable Process """""""""""""""""""""""""""""""""" Several years ago, I was working with an organisation and wanted to bring in another contractor to help with some specific challenges they had. I had management approval, I knew someone good, they were well within the org’s budget, I thought this would be straightforward. The exact circumstances are a bit of a blur but roughly speaking I approached Legal first to get a head start on any potential contract issues - they told me I needed approval from HR first because this was a people topic, HR told me I needed to talk to Purchasing first because this was a purchasing engagement, and Purchasing told me I needed to get Legal’s signoff on the contract first. This was somewhat frustrating. And along the way, I got pointed at assorted process and policy documentation that generally seemed either outdated, irrelevant, or both. Ultimately it turned out there was a combination of some changed processes, misunderstandings about what I wanted, and general confusion, and I figured out the way forward. So then **I wrote down what I did** in a document called something like “My Process For Engaging A Contractor”. It was about five bullet points of “this is what I eventually did that worked for me”, with an introduction that was much longer and provided context and disclaimers, but **it helped the next person with the problem**. And they were able to improve it and help the next person after them. They had work to do to fill in the gaps, to figure out the answers to questions etc., but the process document gave them a framework and guidance and direction that got them to a solution much faster than if they’d had to figure it out from scratch. So -- I think it’s valuable to differentiate between Good Process and Bad Process, and I think Good Process is super valuable. I want folks to know that “process” can mean good things, and there’s value in investing in the right kind. See Also -------- - `Jonathan Lange on process `__