Balance the Process: How to Avoid Nightmares

We often create overly complex processes to address simple (or even non-existent) issues, instead of creating simple processes to address complex problems. This approach is far from optimal as it leads to over-engineered and inefficient workflows.

To avoid these common pitfalls, I recommend adopting a more pragmatic approach. My method draws parallels with physical systems, which naturally evolve toward equilibrium, the most favorable state. Here’s how this perspective can guide better process design.

Why do we define a process?

A process primarily exists to simplify or resolve a problem. These problems can be diverse and arise depending on the context—business needs, team dynamics, customer demands, company growth, and so on.

A well-defined process should address questions such as:

• How do we coordinate work within the team?
• How do we delegate tasks or responsibilities?
• How do we prioritize unexpected tasks or requests?
• How do we ensure the work is completed effectively?
• …and many more.

Numerous frameworks already provide answers to these questions. Rather than proposing a new framework, I want to share my experience in designing and implementing processes that address these challenges effectively.

What is an Equilibrium?

As a former physicist, I’ve spent years studying how physical systems reach equilibrium. Theoretically, equilibrium is the state where all constraints perfectly balance each other.

For example, imagine yourself floating on the sea: your weight, pulling you downward, is balanced by the Archimedes force, pushing you upward. When these opposing forces compensate, your body reaches the equilibrium, you are floating.

Thus, I postulate that introducing a process adds a new constraint to the system. This constraint should counteract the problem it’s designed to address (disorganization, bottlenecks, inefficiencies, …), by no means amplifying it. Otherwise, instead of floating, you might find yourself sinking into the abyss.

Finding the Equilibrium

Let me introduce a process: the plane-takeoff checklist¹. It intends to improve the safety of the flight at a critical moment. When the plane is close to the ground, close to potential obstacles and, at a low speed.

I represented on the graph below the safety added by the takeoff checklist with respect to its length, e.i., the number of items to verify.

We can see three zones under the plain line:

• Safety improves with the number of items. Adding items to the checklist addresses frequent and critical issues during takeoff, e.g., engine stop, fuel levels, runway clearance…
• Safety reaches the maximum. The checklist now covers the most frequent critical and mild issues at takeoff, and the pilot verifies all of those items.
• Safety decreases with the number of items. Adding more verifications for minor or non-existent incidents can distract the pilot from the critical items, leading to a higher likelihood of overlooking them.

Naively, we should expect another behavior, the one in dashed lines. It sounds logical: the more verifications, the safer. But we made the process too complex, by adding too many verifications, now everybody ignore the process.

Real-Life Application

Previously, I deliberately used a non-tech example to illustrate the philosophy without focusing on details. Now, let’s dive into a practical, day-to-day scenario with the example of the task-delegation process. The goal is to address the following challenges in a timely and effective manner (not exhaustive):

• How do we clearly define the task and its goals?
• How do we estimate the effort required for the task?
• How do we track the progress of the task?
• Who is responsible for owning the task?

We propose mapping each task to a single post-it. The content on the post-it can vary, ranging from a simple title to more detailed information, including:

• Title
• Owner
• Status
• Description
• Implementation details
• User story
• Acceptance test
• Dependencies
• Estimate
• …and any other Jira field!

We could require every task to have all fields filled out, but this approach would be counterproductive. The level of detail needed on post-its depends heavily on the size of the team and its context. For solo workers or small pairs, minimal details, such as a title and brief description, are enough. Because the task creator and executor are usually the same person.

However, in larger teams, tasks often involve multiple stakeholders, including managers, developers, and reviewers, which creates dependencies. As team size N grows, the number of interactions increases quadratically (N(N-1), e.g., 4 people = 12 potential interactions per task).

With many stakeholders, communication can quickly become overwhelming, resulting in endless Slack threads and back-and-forth conversations. To address this, filling post-it fields saves time by streamlining communication.

Therefore, we need to balance the level of detail required based on team size and autonomy. As shown in the graph, the optimal amount of detail increases with team size. However, if too many fields are made mandatory, similar to the takeoff checklist example, we risk wasting more time executing the process than actually completing the tasks.

In a nutshell, don’t get stuck on Agile, Scrum, or other dogmas. Take the best elements from each, adapt them, and create an optimal process tailored to your needs.

Equilibria and Transitions

We’ve focused on equilibrium as a single state, but there’s also a distinction between local and global equilibria, as illustrated below.

On the left, the local equilibrium is represented by the small cavity where the ball rests. It’s considered local because it’s not the most stable state. On the right, the global equilibrium, represented by the deeper cavity, is stabler.

Local equilibrium persists because of a barrier (what physicists call potential barriers) separating it from the global equilibrium. This barrier acts as a “tree hiding the forest,” creating the illusion of being in the most favorable state, while a better one exists just beyond your view.

These barriers are shaped by the context or environment. In a workplace, barriers could stem from processes, organizational structures, habits, or even egos. To overcome them, take a step back and question established assumptions.

Moving from a local equilibrium to a global one requires energy to overcome the barrier. During the transition, the system enters a non-equilibrium state where new opposing forces, like the fear of change, may arise. Theses force are resisting progress toward the global optimum. If the effort stops prematurely, the ball will roll back to the local equilibrium.

To successfully overcome the barrier, it’s essential to align efforts from team members and allies, focusing on the shared goal and working together.

Conclusion

A process is a tool designed to support you, your team, and your company by making work and collaboration easier. Always remember that its purpose is to simplify, not complicate. Avoid rigid adherence to dogmas, adapt processes to the context and regularly question their relevance. Additionally, implementing or proposing new processes requires energy and alignment. Don’t tackle it alone; collaborate with peers, iterate together, and incorporate their feedback to ensure success.

Thank you ewjoachim for the review and the recommendations.