Here’s a better way to discuss process and friction

Takeaway: When talking about processes and how they can be improved, it pays to use a precise vocabulary. Ceej Silverio’s definition of formality, ceremony, toil, and friction is a great starting point.

image of a train station seen from above

I stumbled across an insightful post by former npm CTO CJ “Ceej” Silverio, Reduce Friction. It makes a case for why reducing friction is valuable, explains why it’s so often neglected, and gives various suggestions on how to get started.

As someone who preaches learning to use your tools properly to be as efficient as possible and who has been adjusting his shell aliases for the past 8 years to shave off keystrokes from repeated commands, the post resonated at a visceral level.

But what I think really stands out from the post is the introduction of a vocabulary for describing processes and how to improve them.

Language is a powerful tool. Having a rich set of linguistic abstractions to deploy when discussing with other people can unlock higher levels of reasoning and performance. There’s a reason why Eskimo have 50 words for snow. Details matter and we need names to identify them precisely.

The terms Ceej introduces are “process” and its properties, “formality,” “ceremony,” “toil,” and, of course, “friction.”


According to Ceej, process is “the way you habitually do things.” He adds that “you always have process,” but you might not have a “thoughtfully-designed, intentional process.”

Process is an algorithm of sorts that describes how to get stuff done. Sometimes the algorithm is clearly defined, either by being written down somewhere or because it has become ingrained through repetition. Other times, it is haphazard, and everyone makes it up as they go.

Moving through the steps of a process requires time and energy, and this is where friction might get in the way.


When physicists talk about friction, they refer to different kinds of forces that resist the relative motion of two bodies sliding against each other.

The physics definition of friction transfers neatly to the abstract domain of getting stuff done in knowledge work. Picture process as a railway. There are various stations, and work “carriages” move from one station to the next. Work can move smoothly down the track or struggle like a tired old locomotive.

Any factor, requirement, step, or external pressure that increases the energy it takes to move forward in the process is a source of friction.

Friction is not necessarily an external factor alone; it can come from the process definition itself in terms of too much formality or ceremony.


Formality refers to “how prescribed and enforced a process is.” Compiling a checklist with the various process steps, for example, adds formality to it.

Formalizing a process can help make it more intentional. When every step is clearly defined, it’s easier to identify those parts that might be wasteful or counterproductive. A formalized process also removes guessing, helping the people implementing it always know what to do next.

However, beware that too much prescription can render the process overly rigid. A rigid process might break when something doesn’t go according to expectations.


Ceremony is “a thing you do every time, ritualistically, usually involving other people.” Examples are morning stand-up meetings, requiring PRs to go through code review, and backlog “grooming” sessions.


Toil is draining, time-consuming work that “doesn’t seem to be related to the core of what we need to get done.” Usually, toil comes in the form of work that has to be done manually because it hasn’t been automated yet.

Resolving Dependabot PRs is a prime example of toil. As Ceej puts it, “it feels like work but accomplishes nothing worthwhile.”

What to do with the vocabulary?

This new vocabulary allows us to have a more rigorous discussion about how work works.

For example:

  • “It’s not clear to me how the release process works and who is in charge of starting the roll-out. Can we make it more formal?”
  • “Announcing I started to work on a ticket on Slack seems like an unnecessary ceremony when everyone can already see that from the task board state.”
  • “Adding a ‘Needs Review’ label to every new PR feels like toil. Do we need it? Can we automate it?”

Writing the code is the easiest part of building a software product. Designing and implementing the processes that get the right code written in time is much harder.

Execution is what separates successful people, teams, and companies from those doomed to fail*. A productive software developer thinks carefully about the processes they’re involved in and strives to make them efficient and effective.

Ceej’s vocabulary introduces new dimensions on which to measure our processes and will improve the way we design them. But, as valuable as it is, I suspect it merely scratches the surface. We have only just begun to understand how to leverage our creativity and collaborate with one another.

A richer vocabulary is intriguing, but it’s the possibility of using it to describe new kinds of processes that is really exciting.

I’d love to hear about your processes, how formal and intentional they are, and what you are doing to reduce friction. Leave a comment, hit reply, or get in touch on Twitter @mokagio.


* – Of course, luck plays a role as well. But luck is outside of our control. On the other hand, how intentional we are in our execution is entirely up to us. Being strategic, methodic, and intentional is the best way to reduce the contribution of the luck factor in the success equation. Back.

Image credits Jakub Nawrot on Unsplash.