On the list of ways to generate a guaranteed negative knee-jerk reaction from an engineer, I offer a single word: process.

Folks, in order to make sure that we hit our ship date, we have a new bug triage… process.

You’ve heard the groans and you’ve seen the rolling eyeballs and made the fair assumption that engineers are genetically predisposed to hate process. It’s an incorrect assumption that doesn’t add up. Engineers are creatures who appreciate structure, order and predictability, and the goal of a healthy process is to define structure so order is  maintained and predictability is increased. The job of a software engineer is writing code, which is codified process.

So, what gives? Why the groaning?

Engineers don’t hate process. They hate process that can’t defend itself.

Don’t Answer the Question

At Apple, there is a creature called an Engineering Program Manager (“EPM”). Their job is process enforcement. They are the folks who sat in meetings like bug reviews and made sure that every part of the process was being followed. As a person who prefers to spend mental cycles on the people and product rather than the process, I appreciated the role of the EPM.

A good EPM’s job is to keep the trains on time by all reasonable means. However, my experience with program managers over the past two decades is that 70% of them are crap because while they are capable of keeping the trains running on time, they don’t know why they’re doing what they’re doing. When someone on the team asked them to explain the reasoning behind the process, they’d say something to the effect of, “Well, this is how we’ve always done it…”

If you want to piss me off, if you want me to hugely discount your value, do this: when I ask you a clarifying question that affects how I will spend my time, my most valuable asset, don’t answer the question. This non-answer is the root cause of an engineer’s hatred of process. A tool that should help bring order to the universe is a blunt instrument that incites rage in the hands of the ignorant.

Healthy Process is Awesome

It pains me to type that heading because of the 70% out there who are giving process a bad reputation with their blind enforcement. But if we explore where process might come from, you’ll understand three things: the circumstances that lead to the necessity of process, how it could be awesome, and most importantly, your role in maintaining the awesome.

With a small team, mostly you don’t need process because everyone knows everything and everyone. You don’t have to document how things occur because folks know how to get it done, and if they don’t they know exactly the right person to ask. If something looks broken, you don’t hesitate to stand up and say, “That’s broken. Let’s fix it.” You do this because, as a small team, you feel equally responsible for the company because everyone is doing everything.

Hidden among all this work are essential parts of your company that everyone knows, but no one sees: your values and your culture. If you’re a small team, you likely don’t have a mission statement, you have the daily impossible amount of work you must do to survive and the way you do that work is an embodiment of your culture and your values.

Now, if you stopped someone in the hallway of this hypothetical company and asked them to explain the values, they’d look at you like a crazy person and give you exactly the same damning answer as the program manager above: “Well, this is how we’ve always done it.” Double standard? No. The difference here is that if you could actually get the attention of the hallway person, if you pressed them, they’d be able to explain themselves. When you asked them, “Why must we debate every decision?” they’d say, “We encourage debate because we want to make the most informed possible decision.”

Then, at some magical Dunbar number, you pass two interrelated inflection points. First, the number of new hires arriving exceeds your population’s ability to organically infect culture and values. Second, because of the vast swath of preexisting people, the arriving individual erroneously believes that they as a single person can no longer influence the cultural course of the company. The team is fractured into two different groups that want exactly the same thing:

#1 The Old Guard. These are the folks who have been there for what seems like forever. They understand the culture and the values because they’ve been living and breathing them. They have a well-defined internal map of the different parts of the company that consist of the rest of the Old Guard. Whether they like it or not, they are the exemplars of what the company values.

#2 The New Guard. These folks have arrived in the last year and while they understand that there is culture and there are values out there, they spend a lot of time confused about these topics because no one has taken the time to sit them down and explain them and the folks who are qualified to do so are busy keeping the ship pointed in the right direction. This situation is exacerbated by the fact they don’t have an internal map of the company in their head and they don’t know who to ask what, so once their honeymoon period is over, they get angry because they don’t know why they’re doing what they’re doing.

Problem is, the Old Guard can’t conceive of a universe where everyone doesn’t know everything, and they have difficulty explaining what they find obvious. The Old Guard begins to hear the New Guard’s crankiness, but their suggestion is, “Duh, fix it. It’s your company. That’s what I did.” This useless platitude only enrages the New Guard because while they desperately want to fix it – they don’t know how – and having the Old Guard with their informed confidence and flippancy imply it’s simple is maddening.

Eventually, meetings are convened, whiteboards are filled with suggestions, and while different companies give the end result different names, it’s the same outcome: someone volunteers to document the means by which we get stuff done. They document the process.

When you think of process, I want you to think of this moment because it could be a noble moment. Process is being created not as means of control; it’s being built as documentation of culture and values. It’s likely you can’t imagine this moment because you’ve been clubbed into submission understanding process as the dry documentation of how rather than the essential explanation of why.

The Dry Documentation of How

Here’s some really boring process for you. It’s an internal transfer process. Leads refer to it when someone wants to move from one group to the next. Chances are, you may even be aware this thing exists. Lucky bastard. Here’s the breakdown:

• Employees must have been in their current job for one year before applying for a new job.
• Employees must have a performance rating of solid or higher in order to apply for a transfer.
• An employee may have one conversation with a new job’s hiring manager before discussing the internal transfer with their current hiring manager.
• And it goes on, but you get the idea.

Who wrote this? HR prescriptive bullshit, right?  Yeah, it probably was someone in HR that wrote this years before you arrived, but they were trying to help. When it was 42 of us, how did this internal transfer happen? Well, Frank wanted to try out design, so he talked with the design lead, Luke, who then talked with Frank’s lead, Alex, over a beer and it was done in a week.

This informal conversational process doesn’t work at 420 people for a lot of reasons: Frank doesn’t know if there are opportunities in design because he doesn’t know Luke. If he does figure out that there is a gig and has a chat, Larry doesn’t even think to talk with Alex because they don’t know each other. This leads to all sorts of misunderstandings and crankiness about who knows what, which leads to trust issues, crap communication, and politics that could have been all avoided if we simply agreed to document how our company felt about internal transfers.

I want you to look at this boring process from the perspective of someone who cares about preserving culture. What values are they attempting to capture? Look again.

• Employees must be in their current job for one year before applying for a new job. We meet our commitments to our teams.
• Employees must have a performance rating of solid or higher in order to apply for a transfer. If someone is failing at their job, we work to improve them rather than shuffling the problem elsewhere in the company. We fix problems, we don’t ignore them.
• An employee may have one conversation with a new job’s hiring manager before discussing the internal transfer with their current hiring manager. We understand that situations change. We want people to grow, but we are adamantly transparent in our communications because we know that poor communications results in painful misunderstandings.

The unfortunate fact is that when an internal transfer policy does need to be defined, it often falls to an HR person who is good at defining process, but is shitty at explaining the culture. This means that as they diligently and capably do their job, they’re also merrily eroding your communicated culture and values. Process should be written by those who are not only intimately experiencing the pain of a lack of process, but who are also experts in the culture.

Imagine all process as a means of capturing and documenting culture and values. Unfortunately, in a larger company, it doesn’t work that way. Even if qualified cultural bellwethers took the time to document their pain and to write a process, these folks eventually leave. When they leave so does their cultural context, and the root pain that defined the process leaves with them. The company forgets the stories of how we ended up with all these bulleted lists, and when someone asks why, no one knows the story.

Defend Itself

An engineer instinctively asks why. When someone or something doesn’t make sense to them, they raise their hand and say, “This feels inefficient. Explain this to me.” Now, they don’t usually ask that way. They usually ask in a snarky or rude fashion that gives the process enforcers rage, but snarkiness aside, the engineer is attempting to discover the truth behind the bulleted list.

Anyone who interacts with process has a choice. You can either blindly follow the bulleted lists or you can ask why. They’re going to ignore you the first time you ask, the second time, too. The seventh time you will be labeled a troublemaker and you will run the risk of being uninvited to meetings, but I say keep asking why. Ask in a way that illuminates and doesn’t accuse. Listen hard when they attempt to explain and bumble it a bit because maybe they only know a bit of the origin story.

It’s a myth, but healthy process is awesome if it not only documents what we care about, but is willing to defend itself. It is required to stand up to scrutiny and when a process fails to do so, it must change.

Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.