Why systems thinking matters and Engineering Managers should care about it
There is always a system
I’ve been discussing how to apply Systems Thinking in engineering leadership, and as part of that, it is worth talking about what systems thinking is and why it is essential in software development.
Starting from the beginning
Systems Thinking is a broad knowledge area approaching problem-solving by understanding how all the pieces connect and influence each other. If you are new to it, there is probably no better place to start than here.
This theory is not new, and different industries have applied it for decades. A great example is the Toyota Production System (TPS), which redefined how to manufacture products, focusing on the cycle from purchase to raw materials.
It is old news in software as well. Any team using a work methodology considered ‘agile’, like Scrum or Kanban, is influenced by the same ideas. At least in theory.
In summary, it’s pretty much everywhere. There is always a system, whether it is visible or not. Every group performing a regular activity will work under certain rules. Some will be formal and defined as processes, and some will be informal as habits acquired through time. And that includes your team.
Are we all cogs in a machine?
Even if these concepts already influence our work, it is relevant to talk about them because Systems Thinking has a lousy reputation in technology. And that is stopping managers from being more effective.
The usual concern of looking through a system lens is that it will dehumanize work. If everything is a system, are we all just pieces doing the same daily task? Are we killing innovation by focusing too much on the process?
In reality, the opposite usually happens. Managers inadvertently create ineffective teams by not making systems and processes a first-class concern within a team, constraining everyone’s work. Whether we want it or not, most team members’ individual performance is defined by their systems.
“The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance.” (Deming)
It’s unfortunately still too common for managers and teams to focus on improving individuals and their behavior without looking at the context producing that result. And that is often a waste of time.
The underperformance example
An example that has unfortunately become too familiar in my career is an excellent way to illustrate this: How to approach individual underperformance.
In many instances when I started to manage teams, I have been warned about individuals underperforming. In some cases, they would already be in a performance management process, meaning that the situation had already impacted their careers.
The natural behavior would be to focus on the person having challenges. Provide feedback and ask for behavior change. But unfortunately, while these attitudes might lead to a positive bump in results, they usually don’t last long.
I found it more beneficial to ask myself and the individual another question: ‘How did they get here in the first place?’ How is their team working, and how are they working within the team? If the team’s objective is to produce high-quality software, what is their system to create software from beginning to end?
The answers I found were usually interesting. While it’s not always the case, something else was broken in most instances. For example, the team didn’t have a good working process, and less tenured individuals found it hard to understand what to do. Or the team didn’t collaborate well, leaving less confident engineers behind since they didn’t know how to learn.
The situations vary. The exciting part is that I could improve individual performance by improving the team around underperforming individuals. That’s because they weren’t the dysfunctional part, but the system was. And the added benefit is that these changes also helped the broader team. A win-win situation, as they say.
Managers, focus on the system
In summary, pay attention to the systems in your team. As a leader, you have a perspective on how the work works that individual contributors don’t. And you have the capacity to influence it to help everyone achieve better results.
Understanding the systems doesn’t mean you will be able to change them all or that you can’t adapt them to the individuals in your team. But it does mean you will know the best levers to pull, giving you the best chance of success.
If you have found this content interesting, this post is part of a Leading Software Teams with Systems Thinking series. More broadly, I write about leading effective software engineering teams. Follow me if you are interested in the area.
