Processes are a prerequisite for high-performance in software engineering teams due to their ability to amplify the skill of the team. I believe there exists no team, given that there is little to no process to begin with, whose performance could not be improved by adding appropriate process.


The performance of software engineering teams, and individual software engineers, is affected by process: the procedures or steps followed by team members in their day-to-day workflows. This should not be contentious.

Neither should it be contentious to assert that process has the ability to destroy productivity. This should be painfully obvious to any software engineer with a few years of experience — particularly those who have worked in larger companies, or who have reported to non-technical managers.

The potentially contentious claim I want to make here is that process also has the ability to amplify team productivity. The way I’m going to argue this is by appealing to common sense while exploring the counterfactual: that process can not improve performance.

If it were true that process does not have the ability to improve the performance of a team, then we could infer that:

  • process can, at best, have no impact on performance
  • therefore process can only be a hindrance — it either negatively impacts performance or it’s a waste of time
  • therefore the removal of process can only be positive for team performance
  • therefore team performance is optimised by the complete removal of process — a.k.a. anarchy

Based on your experience and common sense, does it stand to reason that anarchy is the pinnacle of software engineering team performance? Does it sound correct to you that there exists no process that could be of benefit to a team with absolutely zero processes?

In my personal experience, anarchy is a predictor of poor performance. It seems quite obvious to me that anarchy can not possibly be optimal. Even when I’m working alone on a personal project, I still follow some processes, because they help me do better than I could do otherwise.

If you reject the position that anarchy is optimal, then you accept the position that optimal performance can only be achieved with process.

A Simple Model: Process As A Coefficient

Think of process as a coefficient — that is, a number that multiplies another number — and think of team performance as the product of process and skill.

A process which requires all engineers to stop working is a coefficient of zero. Zero multiplied by any skill level produces zero performance.

A bad process is a coefficient less than one. It reduces the skill of the team, resulting in worse performance. For example, adding a 0.5 coefficient process would cut the team’s performance in half, and removing it would double performance.

A neutral process is a coefficient of one. It doesn’t hurt, but it doesn’t help either, so it’s basically just unnecessary complexity.

A good process has a coefficient greater than one. It amplifies the skill of the team, resulting in better performance than would be possible otherwise. The point of this article is that good processes do indeed exist.

Who Cares?

To some software engineers, I’m sure it’s plainly obvious that a good team requires good process. If you’re one of those people, then reading this was probably a waste of time. Soz, lol. You can stop now.

Some people may truly believe that anarchy is indeed optimal for performance in software engineering teams. How you could arrive at this stance is completely baffling to me, so I would love to hear your reasoning. If this is you, you can also stop reading at this point.

This article is for everyone else. It’s for the people who shoot down the mere suggestion that their team might benefit from some kind of new process, without even attempting to evaluate the pros and cons. If this is you, then I’d argue that you’re making two mistakes.

The first mistake is being irrational. You’re incorrectly treating your emotions as a source of truth. I understand where this emotional reaction comes from, but the reality is that some processes are bad and some are good. Knee-jerk rejection of all process is unproductive and unprofessional. The analytical part of your mind can be used for more than just code, you know.

The second mistake is worse: selfishness. Maybe you’ve correctly identified that adopting a particular process would be an inconvenience for you personally. That’s definitely a factor to consider, but it’s not the most important one. Assuming that the process doesn’t violate ethical boundaries, the law, or your employment agreement, the most important factor is the overall benefit to the team. Kneecapping the entire team just to suit your own preferences is kind of the definition of selfishness. This behaviour is toxic, and I would hope that it would be considered unacceptable by any decent engineering manager, and dealt with accordingly.

So if you find yourself in this camp sometimes, please reconsider blindly acting on your gut. Think about the effect on the team as a whole, and criticise the process from that perspective. Or just give it a go and evaluate the results. Ask that the process be reviewed after a couple of weeks before deciding to adopt it permanently. There are plenty of avenues for productive disagreement — take those avenues instead.