The seven letter word that engineers hate!

Just FYI, writing clickbait titles is super fun, can’t promise not to do it again. Anyway, as tempting as it is to drag out the answer over 5 paragraphs a la Buzzfeed, I’m trying to retain a tiny bit of my humanity, so I’ll break the bad news to you now, this is a post about Process.

Why everyone hates the P-word

If you’ve worked anywhere for any period of time then I’m guessing that you have a… complicated relationship with Process. For me, the word immediately conjures up images of grey suited men, ashen faced in their monochromatic room systematically finding ways to rob companies of all their spontenaity and humanity. Questions like “why do we do it this way?” are met with the soul destroying response of “ermm, not sure, it’s just how we’ve always done it”, and before you know it you’re filling in forms that get routed through 3 levels of approval to spend $20 on paperclips.

Bad process is usually divorced from the reality in some significant way. It’s lowest common denominator, treats people like they’re children, usually in the service of control. The driving force behind that desire for control could be a few different things - it could be trying to create fairness, prevent some kind of undesirable behaviour (like the uncontrolled purchase of paperclips), or save the organisation for itself by preventing the recurrence of mistakes. Regardless of the motive, you tend to know crappy process when you see it by the gut feel it evokes.

Good process, on the other hand, can be something completely different. It captures a small part of the culture of an organisation, and helps spread that culture to people joining the team as it grows. It helps you scale. This is the best reason I can think of to write a process, that it helps people understand ‘the way we do things’, and why, without becoming so prescriptive that it becomes a time sink.

Having spent some time thinking on this more, I think that there are some key things to keep in mind when writing or inheriting a process from someone else:

1. Be clear what objective the process is trying to achieve, and how it aligns with your company values
2. Produce the most minimal version of the process that you can
3. Be explicit in the process who’s responsible for its content and changes to it
4. When changes are made, record why in the document itself

1 - Alignment with Culture

It’s a recurring theme in my thinking about management that your company values are important. I like to start processes with an Objective & Why section, despite the clumsy English, because it gives you an opportunity to explain upfront to the reader why the process exists and what it’s trying to achieve. Values come in to this because it’s really important that you demonstrate (either explicitly or implicitly) that the process is in alignment with them, and it helps you to notice early on whether you’re capturing culture or being dictatorial.

Admittedly, understanding your company or team values is potentially another post altogether. Even if yours is the kind of company that provides a neat list during new employee onboarding, it’s entirely possible (or even likely) that the list is aspirational rather than based in the reality of the company culture. As unscientific as it sounds, relying on the gut reaction of yourself and others to the Objectives & Why section is a pretty good way of judging whether you’re in alignment or not.

2 - Minimum Viable Process

As I mentioned above, the creation of a process often arises as a knee jerk reaction to disaster. The team is smarting from something that’s gone wrong, and is looking for a way to protect itself (aka exert control), so someone inevitably thinks ‘what we need is a process!’. It’s here that it’s important to resist the urge to preemptively ‘fix’ all the other problems that you can imagine arising in the same area with one Uber-process.

If you are in this category and you’re writing something in response to a bit of a disaster then I think it’s also worth stepping back slightly and asking some slightly broader questions. For instance, what was the actual cost of the disaster? If we don’t write a process, how often do we expect the disaster to recur? What’s the cost of having everyone follow a process instead? Does it offset the cost of the disaster?

If this sounds like a mini cost/benefit analysis then that’s because it is. Most of the time actually writing a formal one is going to be overkill, but these are important questions that hopefully keep you focused on just producing something that solves the problem at hand, and only that. If you’re still not sold, just keep in mind that no one reads long processes anyway and use that as motivation to be brief!

3- Be clear where feedback can be directed

My last couple of points are around the topic of changes and updates to the process. Your company is doubtless changing as you read this (unless it’s in a death spiral or drift towards irrelevance), and so your processes will need to evolve to keep up with the evolving culture of your company. Since a good process should be defensible, it’s important that there’s an actual named person on the hook to do that defending, or else make updates so that it aligns more closely with the values of the company or the reality of life on the ground.

Being that person is a responsibility that can’t be taken lightly, as it effectively makes you a custodian / guardian of a piece of company culture. If you ignore people or are dismissive when they come wanting to discuss its content you’re sending a very clear signal to that person as to what kind of company you really are. It’s occurred to me that this doesn’t scale well, which is possibly one of the reasons why larger companies end up with inhuman feeling processes. I don’t have a neat answer for how to address that, other than the hope that if the process really is an expression of organisational values that you end up with many people in your leadership or people teams who can have these kinds of conversations with people. Even at scale, it’s clear to me that these kinds of conversations are really important for a company to have a healthy culture.

4- Changes get recorded with the process

As the process lives and evolves, I think that it’s important to retain the context behind why certain decisions were made. The goal is to try and retain a sense of cultural alignment, of how this document still represents a small slice of the values of the company. However, no one reads change histories, so recording them in the document itself seems the only way to do it. If your process accrues so many changes that it gets unwieldy, well, perhas it’s time for a rewrite, addressing all the points that drove change in the Objectives & Why section.

What about external mandates?

I’ve spent a fair amount of the last month writing Infosec policies that align with external standards, and so I’ve been spending a bunch of time thinking about this. The key issue is this - if you have to include a whole bunch of externally mandated content in your policies or processes how do you make them align to your company values?

I think it’s helpful to look at it this way - that your company already has many of the values that these standards are seeking to formalise, such as valuing the confidentiality of your clients, protecting your information systems etc, so whilst the sheer volume of documentation might be culturally new, the things written there shouldn’t ‘feel’ wrong. A lot of the points I wrote about above still apply - really ensure that you’re addressing the core of the mandate and nothing else, be explicit about why each policy or process needs to exist and be clear who owns updates to the policy. Recording changes with the policy might be more difficult, since these documents often find their way into the hands of auditors and they need to be easy to understand, so I’m still making my mind up about that one.

Then there’s the Netflix way

Of course, you can do all of this and still have people telling you that you’re doing the wrong thing. One of the most interesting and inspiring business books that I’ve read in recent years is Reid Hastings and Erin Meyer’s No Rules Rules (not an affiliate link), which explains how Netflix have gone about creating a culture where they’ve systematically removed process. The virtuous cycle, they explain, is to max up talent density, increase the level of candour and direct feedback, then take an axe to process. You can do this since you’ve created the level of performance in your team that results in them making consistently good decisions, and having processes would just slow them down.

According to this way of thinking , the creation of most processes should stop at the cost-benefit analysis phase above. Unless the costs of a failure are apocalyptically bad (life endangering, or leading to some other kind of existential threat to the business) the answer is to not write a process in the first place, instead trusting in your team to usually do the right thing, with the the cost of the occasional wrong thing being offset by the increased productivity you get when people can do what they know is best.

The middle way

My feeling is that, for most companies, this minimal viable process model is more achievable than going full-Netflix, as nice as that would be. If that is where you want to go as a company leader then I think it takes real commitment and a number of years to get there due to the level of discipline it takes throughout your company. The Netflix book makes really clear, if you don’t have the discipline then removing process alone doesn’t work, it just leads to things breaking and bad decisions being made. I’ll stop there, however, as that makes me want to talk about the role of discipline in forming great companies, and this post is too long already. Thanks for reading, I’d be really interested in any thoughts you might have, you can contact me at paul@paulmerrison.io.