A Familiar scenario: An engineering leader is trying to implement processes to structure their team's work. The goal is to increase focus and value delivery while reducing wasted efforts.

The challenge they often face: Many within and outside their team argue that such processes are just bureaucracy and obstacles. They feel they get in the way of doing their jobs more efficiently, as they need to go through all the extra motions.

Both parties, the leader trying to implement the process and its opponent, are usually right in their arguments, often leading to frustration on both sides.

How can they both be right?

If they're both right, which way should the organization go?

In today's article, I argue that this dichotomy originates from a fundamental misalignment of principles. Our responsibility as engineering leaders is to learn how to frame and explain this misalignment in ways that every organization member can understand. That understanding will be be the cornerstone of our ability to influence the organization in the direction we desire.

The Convenience Principle

The main reason why people tend to resist adhering to processes is that it's more convenient in the moment not to do so. I'm sure you all have plenty of examples where you faced someone arguing that it's just faster if I do it this way instead. We can find examples everywhere, but some are more evident than others.

A familiar category is the software engineer trying to take shortcuts from the established process to move faster. Some obvious examples include merging a PR without waiting for a review, skipping the documentation for a new feature, or not adding unit testing to the newly developed feature. Less obvious examples include using private DM chats instead of public channels to discuss topics that are relevant for the entire organization or not duly tracking their work on the issue tracking system.

In all such cases, the software engineer is acting in alignment with what has been called the Convenience Principle¹. They focus on working in ways that are convenient to them in the moment. They optimize their short-term efficiency.

And no matter what you argue with them, there is no disproving that - assuming the goal is to focus on short-term individual efficiency - their choice of action would align with the goal.

In other words, they'll be correct to say that this is the most efficient and convenient way to complete the task in isolation.

Examples of the Convenience Principle are also abundant outside of engineering organizations, though we might initially struggle to recognize them as such.

That peer of yours who comes tapping on your shoulder asking if you have 5 minutes because they urgently need your attention and can't wait for your next 1to1 in 2 days. In their worldview, it would be inconvenient to have to wait.

Or the CEO who reaches out to individual software engineers asking them to do something simple or urgent they request, bypassing whatever process the team has in place for prioritization and planning. In the CEO's view of the organization, it would be inconvenient and inefficient for them to understand the process and follow it. It's way more convenient to grab someone they can dump the issue on and move on with the rest of their day.

While all these people are correct in arguing that following whatever process you're advocating for would be less efficient for them, you are left witnessing the disruption and chaos caused by that and often struggle to come to terms with it.

Should you give up your efforts and embrace the narrative that every process is inefficient bureaucracy? Should you adopt this seemingly chaotic approach that feels more natural to its participants? Isn't this being agile, after all?

I would advise against giving up. While it's crucial to ensure that the process we create does not contain an unnecessary number of inefficient and ineffective steps, these tend to exist for a very valid reason.

To help you solidify your convictions, it's helpful to remind yourself what your role is and take a page or two from the discipline of system thinking.

Organizational Tragedy of the Commons

Since I read Donatella H. Meadow's seminal book on system thinking last summer², my ability to think formally about such problems and challenges has become more sophisticated and practically applicable.

As I'd like to frame the case of convenience vs. sustainable productivity here, it's helpful to refer to the tragedy of the commons.

The tragedy of the commons describes a situation in which individuals, acting independently and in their own self-interest, overuse a shared resource, leading to its depletion or degradation, which ultimately harms everyone. Initially applied to shared physical resources like grazing land or fish populations, this concept has a compelling parallel in the context of engineering teams and their shared resources.

A similar dynamic can unfold in knowledge work environments—including software engineering—when convenience for a few is prioritized over the systemic productivity of many. The main resource at risk of being depleted here is the organization's ability to sustain the creation of value over time.

As we want to optimize this characteristic of the system, we should not naively optimize for every single actor participating in it individually.

Instead, we should first focus on understanding and then acting on the feedback loops that cause the system to behave the way it does.

That, it turns out, should be an essential part of our role as leaders.

Our role as leaders

An essential part of our role as leaders is making decisions. Every decision is essentially a tradeoff between various alternatives. Those tradeoffs could be thought of as ways in which we're trying to balance the different feedback loops at play in the system we aim to influence.

Unfortunately, there isn't a playbook or an inventory of the optimal tradeoffs for all the situations you'll face in your career. Each situation is different, and the nuances are critical. Yet, the mental models and general approaches from system thinking can be applied to almost any problem you're facing at work.

Remember that your role is to optimize the functioning of the overall system, which means the engineering organization. Any leader's role is to maximize the functioning of their entire system. Yet, too often, they fall into the mistake of believing that's achieved by focusing first and foremost on individual efficiency. Especially the leader's efficiency and convenience.

If you apply system thinking to the software development process, trying to identify the relative impacts of chasing short-term wins versus working on building maintainable code, you might end up with a chart that looks like the following.

Here is the code for the diagram, in case you want to play with it at home:

flowchart TD
%% Nodes
    A("<b>Disciplined Processes & Coding Principles</b>")
    B("Code Quality")
    C("Bug Rate")
    D("Long Term Development Speed")
    D_short("Short Term Development Speed")
    E("<b>Long Term Business Value</b>")
    E_short("<b>Short Term Business Value</b>")
    F("<b>Shortcuts</b>")
    G("Technical Debt")
    H("<b>Value-Driven Features</b>")
    I("Investment in Development")

%% Connections
    A --> |"fa:fa-plus Reinforces"| B
    B --> |"fa:fa-minus Balances"| C
    B --> |"fa:fa-plus Reinforces"| D
    C --> |"fa:fa-minus Balances"| E
    D --> |"fa:fa-plus Reinforces"| E
    F --> |"fa:fa-plus Reinforces"| E_short
    F --> |"fa:fa-plus Reinforces"| D_short
    F --> |"fa:fa-plus Reinforces"| G
    G --> |"fa:fa-minus Balances"| D
    G --> |"fa:fa-minus Balances"| E
    G --> |"fa:fa-plus Reinforces"| C
    H --> |"fa:fa-plus Reinforces"| E
    E --> |"fa:fa-plus Reinforces"| I
    I --> |"fa:fa-plus Reinforces"| A
    E_short --> |"⌛ Delays&nbsp;"| E
    D_short --> |"⌛ Delays&nbsp;"| D

%% Node Styling
    classDef process fill:#3c17d7,stroke:#3c17d7,color:#FFFFFF
    classDef shortcut fill:#f9f,stroke:#f9f,color:#FFFFFF
    classDef longValue fill:#00C853,stroke:#00C853,color:#FFFFFF
    classDef valueDriven fill:#FF3A2F,stroke:#FF3A2F,color:#FFFFFF
    classDef shortValue fill:#EF8C00,stroke:#EF8C00,color:#FFFFFF
    
    class A process
    class F shortcut
    class E longValue
    %%class E_short shortValue
    class H valueDriven
    
%% Link Styling
    linkStyle 0,2,4,5,6,7,10,11,12,13 stroke:green,stroke-width:2px
    linkStyle 1,3,8,9 stroke:red,stroke-width:2px
    linkStyle 14,15 stroke:orange,stroke-width:2px

We could spend hours refining that diagram, as some of the current actors could be entire systems in themselves, but that's beyond the scope of the article. I recommend doing that exercise at home, as it will help you refine your understanding of the different forces at play.

If you apply this to the more generic case of balancing individual convenience and good processes, you can start with a more straightforward yet very eloquent diagram.

Here is the Mermaid code:

flowchart TD
    %% Nodes
    A("Individual Convenience")
    B("Good Processes")
    C("Individual Efficiency")
    D("Team Productivity")
    E("Organizational Impact")
    F("Individual Impact")
    G("Waste")

    %% Connections
    A -->|fa:fa-plus Reinforces| C;
    B -->|fa:fa-plus Reinforces| D;
    B -->|fa:fa-minus Balances| C;
    C -->|fa:fa-minus Balances| D;
    D -->|fa:fa-plus Reinforces| E;
    C -->|fa:fa-plus Reinforces| F;
    F -->|fa:fa-plus Reinforces| G;
    G -->|fa:fa-minus Balances| E;

 classDef process fill:#3c17d7,stroke:#3c17d7,color:#FFFFFF
    classDef shortcut fill:#f9f,stroke:#f9f,color:#FFFFFF
    classDef longValue fill:#00C853,stroke:#00C853,color:#FFFFFF
    classDef valueDriven fill:#FF3A2F,stroke:#FF3A2F,color:#FFFFFF
    classDef shortValue fill:#EF8C00,stroke:#EF8C00,color:#FFFFFF
    
    class B process
    class A shortcut
    class E longValue
    %%class E_short shortValue
    class H valueDriven
    
%% Link Styling
    linkStyle 0,1,4,5,6 stroke:green,stroke-width:2px
    linkStyle 2,3,7 stroke:red,stroke-width:2px

Once again, I recommend you take the diagram and start enriching it based on your own situation and the terminology used in your organization. This could be a great exercise to do with some of your peers to test their understanding and buy-in of the process while giving you feedback on how relatable it is to how they perceive the situation.

When you start looking at the systems you're responsible for this way, you begin to see more and better ways to communicate their tradeoffs to people around you. You become more aware of the different feedback loops operating on them.

If you do this long enough, you'll start identifying areas where you can experiment with ways to influence one of the feedback loops and observe both the direct and indirect results. Those observations will, in turn, challenge some of your or someone else's assumptions, which will feed back into a better understanding of the system, informing new experiments. And so long and so forth.

The system thinking approach will also equip you with better and stronger arguments when you need to confront individuals who might naively imply that their convenience directly leads to team and organizational productivity.

If you enjoyed this

This newsletter is free, and I intend to keep it free forever.

Sharing it with others helps immensely in growing it.

Engaging with my professional services is a great way to ensure I can continue dedicating many hours each week to producing what I hope to be high-quality content.

Those services articulate around three legs:

1. Fractional CTO or Advisory roles for B2B companies. Find out more on this page.

2. Individual Mentoring and Coaching for Engineering Leaders. Find out more on this page.

3. A paid membership/community for engineering leaders. Find out more on this page.

If your needs fall into a different category, such as newsletter collaborations or sponsoring, please reply to this email or schedule a free call via this link.

🗣️ Feedback required

As you might have read in a prior article, I'm currently doing some early user testing on a SaaS product I'm building to help Engineering Leaders in their daily job.

Please join the waitlist if you'd like to test it for free and contribute to shaping the tool.

You can find more details in this article, including the link to sign up for the waitlist.

Will CTOBox help you become a better leader?

Sergio Visinoni · Feb 26

The primary reason I decided to leave stable employment at the beginning of 2024 and embark on my solopreneurship journey was the desire for greater autonomy.

Read full story

I'm looking forward to receiving your feedback in the upcoming weeks!