Leadership and Systems Thinking: Clear Sight for Complex Decisions

Leadership and Systems Thinking: Clear Sight for Complex Decisions - Interview with Patrick Kua (Leadership Coach)

Leadership comes with carrying the heavy load of making countless extremely complex decisions. Everything is connected with everything else, and you can’t simply break it all down to numbers. It can get really annoying.

If you too feel that pain, here’s a tip: mastering systems thinking and applying it to management will help you do it better.

What is systems thinking exactly, and how does it work in management?

Great question.

We’ll walk you through the answer from defining systems thinking by applying it to organizations with Pat Kua. He’s a former engineering leader and a well-established leadership coach running his own business. Interviewed by Karolina Toth on episode 48 of the Level-up Engineering podcast.

This interview covers:

• The definition of systems thinking
  • Emergent behavior
• Applying systems thinking to leadership
  • Teams are systems
  • Define your purpose
• Key concepts and potential traps of systems thinking
  • Clear limits
  • Feedback loops
• The steps of applying systems thinking
  1. Define the purpose
  2. Explore the system
  3. Consider your options
• The importance of exploration in systems thinking
• Tools for systems thinking
  • Offline tools
  • Online tools
• Bonus advice to apply systems thinking in leadership
• About Pat Kua

How do you define systems thinking?

From an early age we’re taught to think in general based on a reductionist view - much like scientists. You run an experiment in a controlled environment, test your hypothesis and look for repeatable results. The point is to find clear cause-and-effect relations.

There are two key elements to systems thinking that differ from this:

Look for emergent behavior

Systems thinking focuses on emergent behavior. It’s about qualities that the individual parts alone don’t possess.

Human life is a good example for this. We’re made up of parts, such as skin, brain, etc., but none of these parts can be alive on their own. Life only happens when you combine them.

The reductionist view is still important and valuable. Systems thinking is a complement to the classic scientific view. It can help you take a holistic approach to understand complex systems.

Define your system clearly

One challenge in systems thinking that may lead to different views is drawing the boundaries of a system. Looking at the same system with different boundaries will lead to different definitions of the same thing.

When using systems thinking, take your own purpose into consideration while analyzing your system. A different purpose is likely to lead to a different perception of the same system.

How can systems thinking be applied to leadership?

Teams are systems

You can think about a team as a system, and apply systems thinking to gain a different perspective.

Systems thinking can help you understand that high team performance is emergent behavior. The interactions among the team members are essential. Engineering leaders are accountable for engineering productivity, so systems thinking provides a valuable perspective.

Sticking to a reductionist view may lead you to think that you can swap out people and keep getting the same performance out of the team. Or you may think that if you move people from one team to another, they will keep behaving the same way.

You can’t just look at the individuals. Putting a great engineer, a great designer, and a great product manager together may not result in a great team. You have to work on building trust, relationships, and communication channels, and you have to clarify roles and responsibilities, and you have to set expectations.

Define your purpose to define your system

You need a clear purpose to be able to include all the elements you need to take into consideration. If you have that, you can start breaking the system down into components and think about what you may want to shift.

You can’t control everything

Some elements are beyond your control. Treat these as a constraint, rather than a piece you can change to transform your team.

There are always other components in your control. For example, you may use different knowledge sharing methods or communication channels.

Engineering culture constrains team dynamics by adding another element that is outside the team's control and that may differ significantly between organizations. I’ve worked in teams using strict Scrum bi-weekly planning, and I’ve also worked in startups doing continuous deployment and iterations. Even in a similar role, it was a different experience.

Going from one company to another is often a huge change. You may be in the same position, but working with different people in different environments under different constraints changes everything.

What are the most important concepts and potential drawbacks in systems thinking?

Draw clear limits to your system

Use visual models

Drawing visual models is a good practice in systems thinking. The team is holistic by itself, but so is the organization, the product, and so on.

One of the dangers in systems thinking is extending your scope to encompass everything. A visual model will naturally give a boundary to your system. It’s fascinating to consider all the effects on every level, but it’s often counterproductive to your purpose.

Feedback loops

Feedback loops are always present, so we have to acknowledge them.

Slow vs quick feedback loops

Speed is an essential quality to consider about feedback loops, and whether it fits your needs in each case.

In some cases, short feedback loops are good. For instance, developers need a short feedback loop about whether their code works; otherwise, they may end up building on the wrong foundation. That can lead to a lot of wasted time and effort.

Slow feedback loops can be advantageous as well. You can slow down the feedback with buffers. For instance, COVID-19 has a short feedback loop, and the quick spread of the virus is a bad thing, so we try to slow it down with vaccines, masks and social distancing.

You need to consider the feedback loops you have and what may best serve your needs. If you need to slow down a feedback loop, you can use buffers.

This is why a circuit breaker is a common architectural pattern. If there’s an error on the external service, a fast feedback loop could bring down your entire service. You may start with a retry, but if that doesn’t work, you want to slow down the subsequent retries, and try an alternative way, so the rest of your system won’t crash.

Common issues with feedback loops

A trap of systems thinking is reacting too quickly because the feedback loops don’t line up well.

For example, giving feedback to employees only in annual performance reviews is too slow. Managers should have one-on-one meetings with their team members to give them feedback regularly. This provides a quick feedback loop to employees in between performance review cycles.

You still need to get the cadence right.

Some managers check in with their reports once in a quarter, which tends to be too long as a feedback loop. On the other hand, weekly one-on-ones might be unnecessarily short as a feedback loop when it comes to deciding whether to take action. A team member may go on a random rant one week, and acting on it before making sure there’s indeed a bad pattern can be a mistake.

What are the steps of applying systems thinking to a specific leadership issue?

1. Define the purpose

When applying systems thinking, the first step is to understand the issue better. You define the purpose of your system and why you’re examining it. You may just be looking for a better understanding, or you may be looking to introduce a change to your system.

2. Explore your system

The second step is getting a picture of your system. This is the phase where you’re trying to understand the elements, the relationship between them, and the feedback loops across them.

It’s useful to get other people involved because they have different perspectives. This may give you insight that no one else has.

Examples

When you mediate a conflict between two teams, get a representative from both teams to discuss their ideas. The point is to try to build a shared perspective, as the teams may not realize that the other team is optimizing for a different problem. Getting them on the same page is about expanding their perspective and awareness.

In another scenario, If you’re butting heads with project management about a process, it often helps to talk to somebody from that side to expand your own perspective. You tend to learn a lot in the process.

3. Decide whether you need change

The third step is deciding whether you want to make changes.

Building a picture of the system helps you understand why it works the way it does. By the time you’re done, you may realize that your reason to change the system isn’t strong enough.

I can’t give you generalized advice for this; you have to make these decisions on a case-by-case basis.

For example, I worked on a project as a consultant and I didn’t understand that we were getting an IT audit every quarter. Instead, I only noticed a person always asked me to write reports of open source licenses and security vulnerabilities, which looked like extra arbitrary work to me. Once I understood its purpose, it made sense.

If you choose to change a process, deciding how and when to take action becomes an issue. Your best bet is to work in an iterative process, and review regularly whether the changes you implement bring the results you want. This requires setting up a review cycle when you rebuild your picture of the system.

Story

When I started working in software, a developer’s job was done when their project was given to a testing team. If production problems came up, an operations team or a support team had to deal with them and find workarounds. The engineers who built the product never knew that they created a problem.

An interesting feedback loop has come in since then.

When there are production problems, the original feature developer gets all the information about them. This is the idea behind Amazon’s “you build it, you run it” philosophy.

Adding in an extra feedback loop is a possible way to change a system.

Why is a deep exploration of your system important to systems thinking?

Explore organizational structure

When you look at organizational structure, you need to consider what relationships may be necessary between teams but also what may be unnecessary.

Defining a team

A group of people may call themselves a team because they are co-located, or for a number of different reasons. During exploration, I’ve often found that you can make the organizational structure simpler by putting two to three seemingly separate teams together, because they’re working on the same product.

Different teams in the same company that have no need to coordinate with each other can work more effectively.

Dependencies lead to conflicts

In companies that work with relatively stable teams, there’s a lot of conflict between teams. It’s mostly about dependencies. An important holistic property may be whether your team is dependent on other teams or working on a relatively independent product.

For example, I saw a team working on a supposedly independent product, but they had a dependency on another team. These dependencies indicated that they in fact weren’t working as an independent product team.

Untangling this can give you a different perspective on a team.

Stick to exploration first

Software engineers are problem solvers, and they may feel the urge to jump straight to the solutions when applying the systems thinking process. It’s difficult to break this habit.

I tend to frame building a deep understanding of a system by reminding everyone that we’ll get to addressing the problem in its own time. The exploration phase is about gathering information.

Help them create a visual timeline of your process. Explain to them that this phase is about exploring agents, actors, and their different needs before they can move on.

What are the best tools to support systems thinking?

Offline tools

The simplest tool you can use in person are sticky notes and a whiteboard. They’re great because you can move them around quickly and easily, and discussions about systems thinking require adaptive and dynamic tools.

When software engineers are trying to build an architecture model, they tend to play around with what a tool can do, rather than focus on making the model. This is one of the reasons why a lot of people gravitate to the whiteboard.

I’m not a fan of using complex tools for systems thinking. The focus should be the discussion, and the tools are only there to capture the discussion. Keep your tools as simple as possible.

Online tools

In a distributed environment, you may use software like Mural or Miro, which allow you to brainstorm with a lot of items and to represent connections between them.

There are specialized tools for systems thinking. They’re most useful when you’re trying to do calculations. They help you measure the relationship between elements, inputs, and outputs.

I recommend everyone avoid software tools when they start out. Focus on the discussion first, and think about digitizing it later.

Bonus advice for using systems thinking in management

Systems thinking is not the only way

You can be a great leader without using systems thinking.

It adds another tool to your leadership arsenal that can help you under different circumstances. Engineering managers and leaders tend to come across complex problems that keep recurring. This is where systems thinking works best.

Sometimes you sense an issue, like a process just smells, but you can’t put your finger on it. Systems thinking can give you a different perspective in these cases.

Practice makes perfect

I learned about systems thinking by coming across the book The Fifth Discipline early in my career, and I’ve implemented it into my work process over decades.

Think of systems thinking as a habit—something to practice and build into the way you work.

I encourage everyone who wants to try systems thinking to pick a small problem, draw up the system and practice what I described above. Talk to people, involve them, and think about what you might change.

Don’t try to build the picture perfect system because that doesn’t exist. Don’t try to draw a huge system because it’ll likely be too complex to understand and to influence. Start small, practice, iterate and get good at it.

If you’re interested in learning more about Systems Thinking, Patrick offers a self-paced course, “The Fundamentals of Systems Thinking”. You can also find him on Twitter.

About Pat Kua

Pat has been working in technology for about 20 years. He started as a software developer working at companies like Oracle and Flight Center in Australia.

Eventually, he became a consultant at Thoughtworks. He’s worked with different companies at different scales and stages of maturity including enterprise companies that have been around for decades. He worked for a while as CTO at N26, a bank in Berlin.

Currently, he’s working independently as a leadership coach. He supports CTOs and VPs of Engineering and helps engineers transition to management.

He’s also written the books The Retrospective Handbook, Talking with Tech Leads and co-authored Building Evolutionary Architectures.