# Developing Systems Thinking
**Kevin:** [00:00:00] Hello and welcome once again to the It Depends podcast. I, as always am your host. My name's Kevin Goldsmith, and in every episode I try and bring you lessons in technology leadership based on my 34 years now, working in technology, the last 10 of that as a CTO and before that, VPE director, engineering manager, and engineer.
This week we're gonna talk about systems thinking. Now, I've talked about systems thinking multiple times in this podcast.
I've talked about its importance. I've talked about different aspects of it, but I realized I've actually not done a great job giving people the tools to develop systems thinking. And part of that is. Certainly at this point, a lot of my utilization of systems thinking is intuitive. I've been doing it long enough that I don't really think about how I do it.
I've [00:01:00] been telling people to learn systems thinking for years without. Giving them a way to actually do it. And that's on me. So that's what this episode is about. It's an attempt to make the implicit explicit to lay out what systems thinking looks like in practice and how to build the skill over time.
The surface question is, how do I think more strategically? But the real tension is between two different modes of operating. There's the transactional mode, so where you're defining rules, you're assigning tasks, you're creating incentives. You're fixing problems as they surface, and then there's the systems mode.
That's where you're understanding the underlying structures that produce the problems. And the results, and then you work on those structures. So when you hear leaders talking about being a gardener, I love that metaphor. I use that metaphor all the time. Leaders as gardeners, planting seeds, nurturing them, helping them grow to get the [00:02:00] outcome you're hoping for, or an approximation of that outcome, that's systems thinking. So there's a tie in here between systems thinking and strategy and you can see that because you're setting up conditions for the right outcome, that's systems and that strategy.
And that's why these two things actually go hand in hand. Because if you understand the system, you can anticipate how a change you make in one place can affect another. And that's a critical part of strategy.
And strategy is another skill that I talked about the last episode being an incredibly important skill as you move up into more senior leadership.
Transactional management that defining rules and assigning tasks, that works fine for small teams or short time horizons, but it hits a ceiling. As scope grows, the problems multiply faster than any leader can individually address them. Leaders who [00:03:00] stay transactional end up playing whack-a-mole. With symptoms instead of addressing root causes.
And if you've been part of a small startup that grows into a larger company, you feel that tension. You feel that kind of growing pains because in that early stage, you can get away with a lot and you can really get focused on transactional thinking because you're just trying to survive. But when the company starts to get bigger, when the time horizons start stretching out, when you're not just trying to make it day to day.
That's when you start to realize, like that kind of thinking is now holding you back and you gotta think broader. You gotta think about the system you're in and how to improve that system. And that's where you're moving into the longer term thinking. The longer term strategy.
If every problem you solve creates two new problems, you're not solving problems, you're rearranging them. That's that transactional thinking. The added tension there is systems thinking takes longer to show [00:04:00] results. You're growing that garden and organizations can be impatient.
And I've lived that. I talk a little bit about this in my book. It's also in an earlier episode of the podcast.
I was CTO at this company and when I came I got to understand some of the challenges the company was having and I wanted to address 'em and I started putting better things in place. The reason that they brought me in is because the company was struggling to grow in a way that was consistent with how it got to where it was, but at the same time, it had to evolve, because it was now a bigger company and a more successful company.
So we had a bunch of practices in engineering specifically that weren't working anymore. And so as the new CTO I'm working on setting things in place. I've identified the issues, I've talked to the leadership. I'm getting things going the right way.
The improvements were [00:05:00] happening, but, I wasn't doing a good enough job communicating, explaining what I was doing. And some of my executive peers were getting impatient. They're like, we want these changes now. We want this now. And I was explaining to 'em that I could get it to them now.
Transactionally. I could force that stuff, but that wasn't gonna get them what they needed next. That wasn't gonna work. You can't just do that over and over and over again. That's transactional leadership. So I didn't do a good enough job explaining the system. Improving was obvious, but it wasn't proving fast enough, and so people kept looking at where we were.
And wanting us to be much further along. And that created a lot of friction between me and some of my peers, because they were coming from, things like sales where it is a lot more transactional and. They were expecting us to operate in tandem with them and work in the same way.
And we just weren't. [00:06:00] And I knew it wasn't the right way, but I wasn't communicating things well. And that's part of the challenge of really building a system as in a larger kind of context, in the context of a company. Because if you're not good at communicating that out, if you're not making the system clear, and especially the system you're trying to build.
It's hard to see from the outside and that was a failure of mine. I didn't do a good job explaining, I didn't make it visible the way I should have, and that just created a lot of tension and a lot of friction in that leadership of that company. The lesson was, building a better system is not enough.
If the people around you don't understand that you are building one the system I forgot to work on. Was the one that was between me and my peers there.
So let's talk a little bit about a more successful thing.
When I join a new company , the first thing I do I talk to everyone in my organization, but also all the other organizations around mine because what I'm [00:07:00] trying to understand is what is working and what isn't working both from within the organization and outside the organization to other people's perceptions.
What that helps me do is not only make a list of what's working well and what's not working well, but I start to understand the interconnections between teams Now. You can have lots of different ways of organizing teams and even two companies adopting the same team model may actually end up with completely different dependency maps.
So that's a critical thing I do because I need to visualize the system that I'm now responsible for, because that helps me figure out how to improve it. Because if I can't see the interconnection, I can start poking on things or trying to improve one thing and dramatically damage something else, because the linkage between them isn't necessarily obvious.
I build a list of challenges in the organization. I look [00:08:00] at specific teams and how many dependencies. Other teams have on them how many dependencies they have. If people talk about the work going too slowly, I try and understand how the different functions, even within a team work, how product is working.
It's sometimes it looks like product is the problem, but it's actually something like test and it isn't obvious from the outside or even from the inside, but when you actually start to visualize the system, you start to see how these things become bottlenecks within that. So having that map also gave me a way to talk about the problems concretely with my team and my peers.
Not as hunches, but as visible structures. It's a really valuable exercise.
Another thing when you have a map or when you have an understanding of how to map the systems within which you are working the speed problem's a great one.
At a company, we [00:09:00] had this challenge around velocity. Things weren't shipping. As fast as we knew they should be. The teams were good. They had good processes. There wasn't a good reason. We couldn't tell things weren't going as fast as they should be, but we couldn't understand why. And I was talking to one of the leaders in my organization about this problem and I asked him to do an exercise and that was to take a single piece of work and map it.
Follow it as it moved through the organization. So we wanna build this feature, okay? So that comes from someplace, product team goes to a team, goes through the team, does it touch other teams and just do that exercise, follow the path through and figure out where it goes. And what we found was work was getting caught in multiple small friction points that individually seemed insignificant.
It waited a day here, two days here, but those little [00:10:00] pieces of friction, because it was going between teams or it was waiting on somebody within the team that was busy working on other stuff, and there were just lots and lots of 'em. And what it ended up being was there wasn't like one major slowdown.
There wasn't like a function or a process or a team that was creating the slowdown. What it was was a ton of little things. Each individually addressable and people were aware, but nobody was aware that the accumulation of these little things made it a really big thing.
So we streamlined those areas. And improve velocity without having to tax individuals harder. Everybody was working hard. Just the system was working against them. And because we weren't regularly doing these kind of exercises, it wasn't obvious. We knew it was slower than it should be, but if we looked at any place, everything looked fine.
It was only when we mapped out the whole system and [00:11:00] we mapped how work moved through the system, that that became visible. So that's another benefit. That's another application. This by the way, is an exercise that I often recommend to people in other companies or people I'm mentoring, but this is something we do if we're trying to figure out what's going on, why something's not working the way it should be, or working the speed it should be.
You just take a piece of work and you map it through the whole system. You can do some of it in Jira, but you can't get all of it. You actually have to go to the standup or go to the retros to actually figure this out. Jira will help, but you can't do it a hundred percent automatically.
I know I've tried multiple times.
Let me give you a framework that you can use to help you develop your systems thinking as a skill. It's the systems thinking progression. It's four stages from observation to intervention.
So [00:12:00] stage one. Is to see the system. I've talked multiple times already about mapping the system and visualizing the system within which you're working.
See that system, that's stage one, recognize that a system exists beneath the visible activity. Most people see individual actions or decisions or outcomes. The first step is recognizing that these are connected by structures, by incentives and dependencies that aren't always visible. This is a shift from why is this person not delivering to what's making it hard for this person to deliver?
That's subtle, but it's important because if you just assume, and I hear this all the time, even from within my own teams, this team is really slow or this function in the team is way too slow. what's wrong with them? Why aren't they working harder? But no one's actually talking to them.
And to understand [00:13:00] that that team is having to deal with lots of stuff or possibly a poor set of tools or waiting on another team. And that's not necessarily visible. So it looks from the outside like it's a problem with this team. But if you go the next step deeper, you ask the next why In the five whys, you actually can figure out that it's not that.
And so thinking about changing that mode of thinking into not assuming that it. This team's problem or it's a product problem, or it's this developer instead thinking, what are the conditions that are making it hard for the product team or this other team or this developer to get their work done? So once you've seen the system, by trying to understand the ocean that we're all swimming in. Now you wanna map it. I've talked about mapping [00:14:00] as a concept. Let's talk about how mapping works. I said, you're making the invisible structures visible. Draw the relationships, draw 'em on a whiteboard, draw 'em in a drawing tool, draw 'em in a mermaid chart.
Whatever works. Draw the relationships between the teams. Trace how that work flows. Identify where the decisions get made and where they get stuck. This is where concrete practices live.
And I mentioned using Jira to do this, you can use Jira to do this as a start. We do this all the time. We've tracked the dependencies between teams. We draw that as a map and that helps us understand is there a lot of in arrows going to a single team, guess what? That team's now gonna be a bottleneck for the whole organization, which gives us a reason to think about how do we decouple. And how do we make it so teams don't have this dependencies?
What do we need to change to make this system work better? But a [00:15:00] big part of that is that we have these tools that let us visualize this.
The next stage is understand how the system constraints and enables. Once you can see that map. I analyze where the system is helping and where it's hurting. I just mentioned the example of a bunch of arrows tracking work through Jira, where the ticket goes from team to team, and if there's a bunch of arrows all going into one team, guess what?
So that's A constraint. Where are the bottlenecks? Where are the feedback loops? Where are the incentives that are driving behavior? And are they producing the behavior you actually want? This is the analytical layer where pattern recognition across situations starts to develop.
If you go and read Donella Meadow's book on systems thinking. She talks about it in the context of just any kind of system and systems have sources, system have sinks, and systems have bottlenecks, and she talks about how you understand those [00:16:00] and how you map those.
And you have that in your organization and you need to understand where your sources. Where are your sinks? Where are your bottlenecks? Your sources are usually gonna be, this is where features come from. Are they coming from the sales team? Are they coming from the marketing team? Are they coming from the product team? Are they coming from developers on the team? Those are generally when we're talking about product development, those are your sources where your sinks usually shipping code to a hundred percent of your customers. That's usually the sink.
What is the path that takes and what are the things that slow it down, that work, and what are the things that speed it up?
Now, once you have that mapping and that understanding, now you can intervene. With awareness of cascading effects and that's stage four. Make changes to the system, but with full understanding that changing one thing will affect other things that are currently working.
This is the [00:17:00] hardest stage because it requires predicting second order effects and being willing to manage the disruption that improvement creates. Improving one part of the system can break another part that was working fine if you didn't anticipate that you'll create problems faster than you solve 'em.
this is an example of how I'm thinking about this exact problem right now, this understanding of cascading effects. So if your engineering teams are adopting new AI practices and it's working for you, right, your teams are getting faster, code generation is happening, you're able to produce a lot faster than you used to.
Well, the system within which we work, the one we've been working in for decades now, is a system where software development is very time consuming and very. Expensive. And so the software development practices that we have adopted in the industry [00:18:00] are all built around that. We have things feeding the engineering team, and we're trying to maximize the engineer's time and the utility of those folks because we are expensive.
We are the bottleneck in the system. We now are becoming less of the bottleneck. So that's a good thing, right? That means that everything should go faster. Well, if everything's been organized around engineering being a bottleneck, and now engineering is the faster part of the path or becomes.
A very, very fast part of the path. What happens? Well, if the product team is the one that's feeding the engineering team, like the backlog or the next feature to work on, and the product team is used to having a lot of time to research and understand and prepare a feature for an engineering team to pick up, and all of a sudden the engineering team can actually [00:19:00] execute on that much faster than it used to. Now, you put back pressure on the product team, 'cause the product team has to continue to build a backlog and continue to research and continue to decide what new features to create. But the engineering team is now consuming them faster than the product team can generate them.
This is a great problem to have, but still a problem. Similarly, if you have a test team that takes the features and does a QA pass or a QE pass on them as part of the software process, usually the test team is smaller than the engineering team because the test team is getting things slowly from the engineering team.
'cause the engineering team produces things. More slowly. Now the engineering team is producing things much faster. What happens? The QA team gets backed up. By making the slowest node in the system [00:20:00] faster, the biggest bottleneck, you've now created a problem.
In other places. And so if you can solve the product problem, then there's something upstream of the product team. And if you can solve the test problem, maybe now you're putting pressure on the sales team or you're putting more pressure on the infrastructure team.
It's this second order effects that you need to understand, but you can understand if you are understanding the system. So that gives you that intervening with awareness of cascading effects, that's important. And for this exact reason.
I mentioned, Donella Meadow's Book Thinking in Systems. I recommend that book very wholeheartedly. It's great introduction to Thinking in Systems. It's got a lot of the great foundational concepts. You've also heard me recommend Jurgen Appelo's Management 3.0 book.
I thought that was a great book. And it uses [00:21:00] systems thinking a lot without really calling attention to it. Sometimes it does reference it as a concept, but it's well integrated into a lot of the things that he talks about.
How do you build the skill of system thinking? Let's stay practical here.
When you join a new organization or take on a new scope, draw a map of how teams relate to each other. That's the first thing I do.
And to be clear, that's not the org chart. It's the actual working relationships who depends on whom, where handoffs happen, where shared resources create contention. You can't see that from the outside. You can only understand that from talking to people and from asking them the question of what's working right now and what's not working, and they'll tell you, "I'm always getting a ton of work from this one team. They just are dropping tons of work on our team all the time." Okay, well that's gonna tell you [00:22:00] something. Or "we're constantly waiting on this other team and it's creating lots of problems for us. People will tell you this stuff, especially if you are new to the organization. 'cause it's not your fault.
It's not from a decision you made and they're hoping you're going to improve this situation, make their jobs better. As you learn, start building that map immediately. Talk to people. Start to understand. Start to put teams on a virtual or real board and start to understand, the red thread across the different connections, then update this map as you learn.
Show it to people and ask them to correct it. The conversations, the map generates. Are often gonna be more valuable than the map itself. This is an artifact that isn't a secret. This is an artifact you can share with people and get their opinion on, and they'll tell you, this is wrong. Yeah, this doesn't really work that way, or whatever.
Super valuable, and it's a great conversation to have. The org chart tells you who reports to whom. A systems map tells you how [00:23:00] work actually gets done.
Now that you have the map I talked about following that piece of work from end-to-end, pick a piece of work a feature, a bug, fix a customer request, and trace it from origin to delivery. And by the way, if that isn't clear, this map extends past your organization past the technology organization to the other teams as well.
You can fix your part of something. But that Awareness of cascading effects means your team is not the full system.
So document every handoff, every queue, every approval step, and every place that sits waiting. And you'll, I'm certain, find new things that you didn't map out because you didn't realize that there were these other kind of way stations for work. Look for the accumulation of small delays, not just the obvious bottlenecks.
This particularly powerful for teams that it feels slow, like I was talking about, but can't explain [00:24:00] why.
How do decisions get made? Pick a recent decision that was communicated and trace it backward. Who made the final call? What information did they have? Who influenced it? How long did it take and where did it stall? This surfaces hidden power structures, information, bottlenecks, and approval layers that slow the organization down. It also reveals whether the people closest to the problems are the ones making the decision or whether decisions are being escalated unnecessarily.
That exercise probably easier to do if you are a senior leader where you can see that whole thing. It's hard to trace decision making if you're not in a position where you've seen all the different steps or can find them easily. Another good practice. If you're trying to develop your systems thinking and you're trying to understand the different ways you can apply it.
Mapping incentive structures. So for a team or a group of [00:25:00] teams that aren't producing the outcomes you expect, ask what are they actually incentivized to do? Look at how performance is measured. What gets rewarded, what gets punished, and what gets ignored? Misaligned incentives are one of the most common system level causes of dysfunction, and they're almost always invisible until you look for them deliberately.
If you don't like the behavior a system is producing, look at the incentives before you look at the people. And if you remember, we talked about this very explicitly in the discussion around building career pathing and actually several other places. When I see bad behavior or misaligned priorities. What I see is perverse incentives. Oftentimes, a lot of sources of friction between teams is teams are incentivized for different outcomes instead of the same outcome. This is a part of systems thinking that we've talked about [00:26:00] multiple times in this podcast, this problem of misaligned incentives creating a lot of friction within the system. The way you can see that is by understanding those incentives and by mapping them on your system.
So I talked about my biggest failure around system thinking, which was not communicating effectively enough to my peers about the system I was building, about how long it was gonna take, about the pieces I was gonna put in place, which meant from their perspective, they were seeing the change. They knew change was happening, but they weren't satisfied with it because they couldn't see it being effected.
That lesson applies broadly, if your peers and your leadership don't understand your work on a system level improvements. They'll evaluate you on surface level metrics. Communication about system level work needs to be ongoing, not a one-time explanation. And those were the mistakes I made before that I try not to make again.
I mentioned AI before [00:27:00] because we're all thinking about it a lot these days. There's a real value in applying systems thinking to how we do AI stuff. AI and agentic systems are at their core systems design problems. When you design an AI workflow or an agentic system, you're building a system: components that interact, handoffs between steps, feedback loops, failure modes, and emergent behaviors. Leaders who can think in systems will design better AI implementations because they already understand how components interact and where things break down.
AI also introduces new system dynamics into existing organizations Adopting AI tools changes how work flows through teams, where bottlenecks form, and what skills matter. Without systems thinking leaders will treat AI adoption as a tool problem. rather than a system problem.
How does adding this tool change how we work? Adding AI to a broken process is just gonna give you a faster broken [00:28:00] process. So you also have to understand how your existing system works. And then think about those cascading effects, like with developers getting faster, putting back pressure on product, and forward pressure on test. System thinking has always been critical, but AI is making the cost of not having it more visible and more immediate.
As you get better at thinking in systems, at visualizing systems, as you get better at explaining systems and trying to talk to people about the system you're building or the system that you're working within, sometimes you will get resistance.
Some people see systems thinking as cold or mechanical as an attempt to turn people into COGS in a machine. When you try and map out what is essentially human relationships and team dynamics, very organic, very people things. And now you're trying to map them and turn it into a system some people are going to resist that.
[00:29:00] It's worth addressing it directly. System sinking is not about treating people as interchangeable parts, it's about making the environment around them better so they can do their best work. One of the reasons I've always really appreciated the gardening metaphor is that you can perfectly plan a garden. There's going to be a rose here. It's going to be this tall, it's gonna have this many leaves on it. There's gonna be another plant right next to it, and it'll be two inches from it and it'll be this tall and it'll have this many leaves.
You can visualize that. You can plant it on paper, but when you plant the seeds and they grow, you're gonna get what you're gonna get. And your goal is not to have it be exactly as your plan. Your goal is to have it be nice. And so you can guide and help shape it, but the end result is always going to be something that has to happen because of the living things that create it.
These are living things. These are not [00:30:00] wood or metal, these are not legos or whatever. All the planning in the world, you're trying to get a positive outcome, not an exact outcome, because often you're gonna get a better outcome than you could have planned because of the people who are involved with it.
I talked about working with transactional leaders and how that creates a problem when you're trying to be a systems thinking leader. I mentioned sales specifically. 'cause sales teams tend to be exceptionally transaction driven.
That's just the nature of the way that we generally do like enterprise or B2B sales inside sales. A lot of the friction I or the people I mentor has often come from engineering leaders who are trying to be long term and trying to be very systems oriented and transactional leaders in other parts of the company who really need, other people to work the same way they are.
that doing stuff approach that looks productive in that short term. [00:31:00] Reorganizing. This is where you get, " action. We need more action. You're not doing enough things. You need to reorg or you need to reassign people, or you need to add more process." It looks productive in the short term.
When you're building systems, it can look like you're not doing much because those changes are structural, not visible activities you're preparing the ground for plants to grow. This is where that communication becomes critical and getting buy-in for it. And early wins are good there to just show you're making progress, but that also showing the evolution that you're getting.
So you will be making improvements. Things are improving. They may not be happening at the speed that some of your peers may want them at, but they're gonna happen in a better way. You're gonna end up with a much better result than if you just force things through. You have to make that visible to people.
Systems level, [00:32:00] change takes time, and organizations are full of people who want faster answers. If you can get things to a self-perpetuating state. People will see the results and become supporters. If the leadership team is impatient, doesn't understand what you're doing, they'll lean into quick fixes that can undermine the system that you're building.
Your job is to hold the line long enough for the system to start producing results, and that is harder than it sounds. Building a system and thinking for that long term is also much easier in companies that are doing well.
If your company is struggling and you're trying to put in a system that's gonna take years to get really good outcomes you're probably misaligned there, you need to be more transactional. Just like I talked about, early stage startups are very transactional, and that works okay because they're just trying to survive. If your company's in that position, that's not a great time to be putting in a system that's gonna take a while to achieve results. Usually you need to achieve results [00:33:00] faster.
Let's be realistic. That is a good time to be doing more transactional level leadership.
I developed my system thinking organically. I did that a lot through experience and reading without formally naming it for a long time.
The most senior leaders I know have this understanding, but many of them also developed it organically. And have a hard time like I do teaching it explicitly, that's a bit of a problem because it means systems thinking is treated as something you either have or you don't, rather than a skill you build. It is absolutely a skill I built.
I mentioned I made the mistake of understanding how much communication mattered when doing systems level work. The tendency was to focus on building the right system and assume that the results would speak for themselves. I absolutely made that mistake.
They don't. You have to narrate what you're doing and why, especially to the people who think differently about management and also to your team. It's important they are bought [00:34:00] in and understand where you're trying to lead them. I used to think that the hard part was understanding the system. It isn't, the hard part is getting the people to see it.
The progression model that I gave you, that four stage progression is an attempt to make explicit what I and other leaders do implicitly, and to give someone an actual path to follow.
System thinking is not an advanced leadership concept reserved for CTOs. It's a skill that can be developed at any level, starting with a simple act of looking beyond individuals and asking how the structure around them is shaping their work.
The challenge for you, pick one of the exercises from this episode and try it this week. Map the dependencies between teams you work with. File one piece of work from start to finish and write down every place it pauses. Pick a recent decision and trace how it actually got made, or look at a team that's [00:35:00] underperforming and ask what they're incentivized to do versus what you want them to do.
Every organization is a system. The question is whether you're designing it or just living in it.
Thank you. This was my attempt to try and actually teach how to be a better systems thinker. I would love your feedback to hear how useful was it? Did I do a good job? I'm trying to figure out how to explain it and explain how to do it better. I hope it helped you.
I will see you next week in the newsletter. I will see you back here on the podcast in two weeks. Have a great week.
**Kevin:** [00:00:00] Hello and welcome once again to the It Depends podcast. I, as always am your host. My name's Kevin Goldsmith, and in every episode I try and bring you lessons in technology leadership based on my 34 years now, working in technology, the last 10 of that as a CTO and before that, VPE director, engineering manager, and engineer.
This week we're gonna talk about systems thinking. Now, I've talked about systems thinking multiple times in this podcast.
I've talked about its importance. I've talked about different aspects of it, but I realized I've actually not done a great job giving people the tools to develop systems thinking. And part of that is. Certainly at this point, a lot of my utilization of systems thinking is intuitive. I've been doing it long enough that I don't really think about how I do it.
I've [00:01:00] been telling people to learn systems thinking for years without. Giving them a way to actually do it. And that's on me. So that's what this episode is about. It's an attempt to make the implicit explicit to lay out what systems thinking looks like in practice and how to build the skill over time.
The surface question is, how do I think more strategically? But the real tension is between two different modes of operating. There's the transactional mode, so where you're defining rules, you're assigning tasks, you're creating incentives. You're fixing problems as they surface, and then there's the systems mode.
That's where you're understanding the underlying structures that produce the problems. And the results, and then you work on those structures. So when you hear leaders talking about being a gardener, I love that metaphor. I use that metaphor all the time. Leaders as gardeners, planting seeds, nurturing them, helping them grow to get the [00:02:00] outcome you're hoping for, or an approximation of that outcome, that's systems thinking. So there's a tie in here between systems thinking and strategy and you can see that because you're setting up conditions for the right outcome, that's systems and that strategy.
And that's why these two things actually go hand in hand. Because if you understand the system, you can anticipate how a change you make in one place can affect another. And that's a critical part of strategy.
And strategy is another skill that I talked about the last episode being an incredibly important skill as you move up into more senior leadership.
Transactional management that defining rules and assigning tasks, that works fine for small teams or short time horizons, but it hits a ceiling. As scope grows, the problems multiply faster than any leader can individually address them. Leaders who [00:03:00] stay transactional end up playing whack-a-mole. With symptoms instead of addressing root causes.
And if you've been part of a small startup that grows into a larger company, you feel that tension. You feel that kind of growing pains because in that early stage, you can get away with a lot and you can really get focused on transactional thinking because you're just trying to survive. But when the company starts to get bigger, when the time horizons start stretching out, when you're not just trying to make it day to day.
That's when you start to realize, like that kind of thinking is now holding you back and you gotta think broader. You gotta think about the system you're in and how to improve that system. And that's where you're moving into the longer term thinking. The longer term strategy.
If every problem you solve creates two new problems, you're not solving problems, you're rearranging them. That's that transactional thinking. The added tension there is systems thinking takes longer to show [00:04:00] results. You're growing that garden and organizations can be impatient.
And I've lived that. I talk a little bit about this in my book. It's also in an earlier episode of the podcast.
I was CTO at this company and when I came I got to understand some of the challenges the company was having and I wanted to address 'em and I started putting better things in place. The reason that they brought me in is because the company was struggling to grow in a way that was consistent with how it got to where it was, but at the same time, it had to evolve, because it was now a bigger company and a more successful company.
So we had a bunch of practices in engineering specifically that weren't working anymore. And so as the new CTO I'm working on setting things in place. I've identified the issues, I've talked to the leadership. I'm getting things going the right way.
The improvements were [00:05:00] happening, but, I wasn't doing a good enough job communicating, explaining what I was doing. And some of my executive peers were getting impatient. They're like, we want these changes now. We want this now. And I was explaining to 'em that I could get it to them now.
Transactionally. I could force that stuff, but that wasn't gonna get them what they needed next. That wasn't gonna work. You can't just do that over and over and over again. That's transactional leadership. So I didn't do a good enough job explaining the system. Improving was obvious, but it wasn't proving fast enough, and so people kept looking at where we were.
And wanting us to be much further along. And that created a lot of friction between me and some of my peers, because they were coming from, things like sales where it is a lot more transactional and. They were expecting us to operate in tandem with them and work in the same way.
And we just weren't. [00:06:00] And I knew it wasn't the right way, but I wasn't communicating things well. And that's part of the challenge of really building a system as in a larger kind of context, in the context of a company. Because if you're not good at communicating that out, if you're not making the system clear, and especially the system you're trying to build.
It's hard to see from the outside and that was a failure of mine. I didn't do a good job explaining, I didn't make it visible the way I should have, and that just created a lot of tension and a lot of friction in that leadership of that company. The lesson was, building a better system is not enough.
If the people around you don't understand that you are building one the system I forgot to work on. Was the one that was between me and my peers there.
So let's talk a little bit about a more successful thing.
When I join a new company , the first thing I do I talk to everyone in my organization, but also all the other organizations around mine because what I'm [00:07:00] trying to understand is what is working and what isn't working both from within the organization and outside the organization to other people's perceptions.
What that helps me do is not only make a list of what's working well and what's not working well, but I start to understand the interconnections between teams Now. You can have lots of different ways of organizing teams and even two companies adopting the same team model may actually end up with completely different dependency maps.
So that's a critical thing I do because I need to visualize the system that I'm now responsible for, because that helps me figure out how to improve it. Because if I can't see the interconnection, I can start poking on things or trying to improve one thing and dramatically damage something else, because the linkage between them isn't necessarily obvious.
I build a list of challenges in the organization. I look [00:08:00] at specific teams and how many dependencies. Other teams have on them how many dependencies they have. If people talk about the work going too slowly, I try and understand how the different functions, even within a team work, how product is working.
It's sometimes it looks like product is the problem, but it's actually something like test and it isn't obvious from the outside or even from the inside, but when you actually start to visualize the system, you start to see how these things become bottlenecks within that. So having that map also gave me a way to talk about the problems concretely with my team and my peers.
Not as hunches, but as visible structures. It's a really valuable exercise.
Another thing when you have a map or when you have an understanding of how to map the systems within which you are working the speed problem's a great one.
At a company, we [00:09:00] had this challenge around velocity. Things weren't shipping. As fast as we knew they should be. The teams were good. They had good processes. There wasn't a good reason. We couldn't tell things weren't going as fast as they should be, but we couldn't understand why. And I was talking to one of the leaders in my organization about this problem and I asked him to do an exercise and that was to take a single piece of work and map it.
Follow it as it moved through the organization. So we wanna build this feature, okay? So that comes from someplace, product team goes to a team, goes through the team, does it touch other teams and just do that exercise, follow the path through and figure out where it goes. And what we found was work was getting caught in multiple small friction points that individually seemed insignificant.
It waited a day here, two days here, but those little [00:10:00] pieces of friction, because it was going between teams or it was waiting on somebody within the team that was busy working on other stuff, and there were just lots and lots of 'em. And what it ended up being was there wasn't like one major slowdown.
There wasn't like a function or a process or a team that was creating the slowdown. What it was was a ton of little things. Each individually addressable and people were aware, but nobody was aware that the accumulation of these little things made it a really big thing.
So we streamlined those areas. And improve velocity without having to tax individuals harder. Everybody was working hard. Just the system was working against them. And because we weren't regularly doing these kind of exercises, it wasn't obvious. We knew it was slower than it should be, but if we looked at any place, everything looked fine.
It was only when we mapped out the whole system and [00:11:00] we mapped how work moved through the system, that that became visible. So that's another benefit. That's another application. This by the way, is an exercise that I often recommend to people in other companies or people I'm mentoring, but this is something we do if we're trying to figure out what's going on, why something's not working the way it should be, or working the speed it should be.
You just take a piece of work and you map it through the whole system. You can do some of it in Jira, but you can't get all of it. You actually have to go to the standup or go to the retros to actually figure this out. Jira will help, but you can't do it a hundred percent automatically.
I know I've tried multiple times.
Let me give you a framework that you can use to help you develop your systems thinking as a skill. It's the systems thinking progression. It's four stages from observation to intervention.
So [00:12:00] stage one. Is to see the system. I've talked multiple times already about mapping the system and visualizing the system within which you're working.
See that system, that's stage one, recognize that a system exists beneath the visible activity. Most people see individual actions or decisions or outcomes. The first step is recognizing that these are connected by structures, by incentives and dependencies that aren't always visible. This is a shift from why is this person not delivering to what's making it hard for this person to deliver?
That's subtle, but it's important because if you just assume, and I hear this all the time, even from within my own teams, this team is really slow or this function in the team is way too slow. what's wrong with them? Why aren't they working harder? But no one's actually talking to them.
And to understand [00:13:00] that that team is having to deal with lots of stuff or possibly a poor set of tools or waiting on another team. And that's not necessarily visible. So it looks from the outside like it's a problem with this team. But if you go the next step deeper, you ask the next why In the five whys, you actually can figure out that it's not that.
And so thinking about changing that mode of thinking into not assuming that it. This team's problem or it's a product problem, or it's this developer instead thinking, what are the conditions that are making it hard for the product team or this other team or this developer to get their work done? So once you've seen the system, by trying to understand the ocean that we're all swimming in. Now you wanna map it. I've talked about mapping [00:14:00] as a concept. Let's talk about how mapping works. I said, you're making the invisible structures visible. Draw the relationships, draw 'em on a whiteboard, draw 'em in a drawing tool, draw 'em in a mermaid chart.
Whatever works. Draw the relationships between the teams. Trace how that work flows. Identify where the decisions get made and where they get stuck. This is where concrete practices live.
And I mentioned using Jira to do this, you can use Jira to do this as a start. We do this all the time. We've tracked the dependencies between teams. We draw that as a map and that helps us understand is there a lot of in arrows going to a single team, guess what? That team's now gonna be a bottleneck for the whole organization, which gives us a reason to think about how do we decouple. And how do we make it so teams don't have this dependencies?
What do we need to change to make this system work better? But a [00:15:00] big part of that is that we have these tools that let us visualize this.
The next stage is understand how the system constraints and enables. Once you can see that map. I analyze where the system is helping and where it's hurting. I just mentioned the example of a bunch of arrows tracking work through Jira, where the ticket goes from team to team, and if there's a bunch of arrows all going into one team, guess what?
So that's A constraint. Where are the bottlenecks? Where are the feedback loops? Where are the incentives that are driving behavior? And are they producing the behavior you actually want? This is the analytical layer where pattern recognition across situations starts to develop.
If you go and read Donella Meadow's book on systems thinking. She talks about it in the context of just any kind of system and systems have sources, system have sinks, and systems have bottlenecks, and she talks about how you understand those [00:16:00] and how you map those.
And you have that in your organization and you need to understand where your sources. Where are your sinks? Where are your bottlenecks? Your sources are usually gonna be, this is where features come from. Are they coming from the sales team? Are they coming from the marketing team? Are they coming from the product team? Are they coming from developers on the team? Those are generally when we're talking about product development, those are your sources where your sinks usually shipping code to a hundred percent of your customers. That's usually the sink.
What is the path that takes and what are the things that slow it down, that work, and what are the things that speed it up?
Now, once you have that mapping and that understanding, now you can intervene. With awareness of cascading effects and that's stage four. Make changes to the system, but with full understanding that changing one thing will affect other things that are currently working.
This is the [00:17:00] hardest stage because it requires predicting second order effects and being willing to manage the disruption that improvement creates. Improving one part of the system can break another part that was working fine if you didn't anticipate that you'll create problems faster than you solve 'em.
this is an example of how I'm thinking about this exact problem right now, this understanding of cascading effects. So if your engineering teams are adopting new AI practices and it's working for you, right, your teams are getting faster, code generation is happening, you're able to produce a lot faster than you used to.
Well, the system within which we work, the one we've been working in for decades now, is a system where software development is very time consuming and very. Expensive. And so the software development practices that we have adopted in the industry [00:18:00] are all built around that. We have things feeding the engineering team, and we're trying to maximize the engineer's time and the utility of those folks because we are expensive.
We are the bottleneck in the system. We now are becoming less of the bottleneck. So that's a good thing, right? That means that everything should go faster. Well, if everything's been organized around engineering being a bottleneck, and now engineering is the faster part of the path or becomes.
A very, very fast part of the path. What happens? Well, if the product team is the one that's feeding the engineering team, like the backlog or the next feature to work on, and the product team is used to having a lot of time to research and understand and prepare a feature for an engineering team to pick up, and all of a sudden the engineering team can actually [00:19:00] execute on that much faster than it used to. Now, you put back pressure on the product team, 'cause the product team has to continue to build a backlog and continue to research and continue to decide what new features to create. But the engineering team is now consuming them faster than the product team can generate them.
This is a great problem to have, but still a problem. Similarly, if you have a test team that takes the features and does a QA pass or a QE pass on them as part of the software process, usually the test team is smaller than the engineering team because the test team is getting things slowly from the engineering team.
'cause the engineering team produces things. More slowly. Now the engineering team is producing things much faster. What happens? The QA team gets backed up. By making the slowest node in the system [00:20:00] faster, the biggest bottleneck, you've now created a problem.
In other places. And so if you can solve the product problem, then there's something upstream of the product team. And if you can solve the test problem, maybe now you're putting pressure on the sales team or you're putting more pressure on the infrastructure team.
It's this second order effects that you need to understand, but you can understand if you are understanding the system. So that gives you that intervening with awareness of cascading effects, that's important. And for this exact reason.
I mentioned, Donella Meadow's Book Thinking in Systems. I recommend that book very wholeheartedly. It's great introduction to Thinking in Systems. It's got a lot of the great foundational concepts. You've also heard me recommend Jurgen Appelo's Management 3.0 book.
I thought that was a great book. And it uses [00:21:00] systems thinking a lot without really calling attention to it. Sometimes it does reference it as a concept, but it's well integrated into a lot of the things that he talks about.
How do you build the skill of system thinking? Let's stay practical here.
When you join a new organization or take on a new scope, draw a map of how teams relate to each other. That's the first thing I do.
And to be clear, that's not the org chart. It's the actual working relationships who depends on whom, where handoffs happen, where shared resources create contention. You can't see that from the outside. You can only understand that from talking to people and from asking them the question of what's working right now and what's not working, and they'll tell you, "I'm always getting a ton of work from this one team. They just are dropping tons of work on our team all the time." Okay, well that's gonna tell you [00:22:00] something. Or "we're constantly waiting on this other team and it's creating lots of problems for us. People will tell you this stuff, especially if you are new to the organization. 'cause it's not your fault.
It's not from a decision you made and they're hoping you're going to improve this situation, make their jobs better. As you learn, start building that map immediately. Talk to people. Start to understand. Start to put teams on a virtual or real board and start to understand, the red thread across the different connections, then update this map as you learn.
Show it to people and ask them to correct it. The conversations, the map generates. Are often gonna be more valuable than the map itself. This is an artifact that isn't a secret. This is an artifact you can share with people and get their opinion on, and they'll tell you, this is wrong. Yeah, this doesn't really work that way, or whatever.
Super valuable, and it's a great conversation to have. The org chart tells you who reports to whom. A systems map tells you how [00:23:00] work actually gets done.
Now that you have the map I talked about following that piece of work from end-to-end, pick a piece of work a feature, a bug, fix a customer request, and trace it from origin to delivery. And by the way, if that isn't clear, this map extends past your organization past the technology organization to the other teams as well.
You can fix your part of something. But that Awareness of cascading effects means your team is not the full system.
So document every handoff, every queue, every approval step, and every place that sits waiting. And you'll, I'm certain, find new things that you didn't map out because you didn't realize that there were these other kind of way stations for work. Look for the accumulation of small delays, not just the obvious bottlenecks.
This particularly powerful for teams that it feels slow, like I was talking about, but can't explain [00:24:00] why.
How do decisions get made? Pick a recent decision that was communicated and trace it backward. Who made the final call? What information did they have? Who influenced it? How long did it take and where did it stall? This surfaces hidden power structures, information, bottlenecks, and approval layers that slow the organization down. It also reveals whether the people closest to the problems are the ones making the decision or whether decisions are being escalated unnecessarily.
That exercise probably easier to do if you are a senior leader where you can see that whole thing. It's hard to trace decision making if you're not in a position where you've seen all the different steps or can find them easily. Another good practice. If you're trying to develop your systems thinking and you're trying to understand the different ways you can apply it.
Mapping incentive structures. So for a team or a group of [00:25:00] teams that aren't producing the outcomes you expect, ask what are they actually incentivized to do? Look at how performance is measured. What gets rewarded, what gets punished, and what gets ignored? Misaligned incentives are one of the most common system level causes of dysfunction, and they're almost always invisible until you look for them deliberately.
If you don't like the behavior a system is producing, look at the incentives before you look at the people. And if you remember, we talked about this very explicitly in the discussion around building career pathing and actually several other places. When I see bad behavior or misaligned priorities. What I see is perverse incentives. Oftentimes, a lot of sources of friction between teams is teams are incentivized for different outcomes instead of the same outcome. This is a part of systems thinking that we've talked about [00:26:00] multiple times in this podcast, this problem of misaligned incentives creating a lot of friction within the system. The way you can see that is by understanding those incentives and by mapping them on your system.
So I talked about my biggest failure around system thinking, which was not communicating effectively enough to my peers about the system I was building, about how long it was gonna take, about the pieces I was gonna put in place, which meant from their perspective, they were seeing the change. They knew change was happening, but they weren't satisfied with it because they couldn't see it being effected.
That lesson applies broadly, if your peers and your leadership don't understand your work on a system level improvements. They'll evaluate you on surface level metrics. Communication about system level work needs to be ongoing, not a one-time explanation. And those were the mistakes I made before that I try not to make again.
I mentioned AI before [00:27:00] because we're all thinking about it a lot these days. There's a real value in applying systems thinking to how we do AI stuff. AI and agentic systems are at their core systems design problems. When you design an AI workflow or an agentic system, you're building a system: components that interact, handoffs between steps, feedback loops, failure modes, and emergent behaviors. Leaders who can think in systems will design better AI implementations because they already understand how components interact and where things break down.
AI also introduces new system dynamics into existing organizations Adopting AI tools changes how work flows through teams, where bottlenecks form, and what skills matter. Without systems thinking leaders will treat AI adoption as a tool problem. rather than a system problem.
How does adding this tool change how we work? Adding AI to a broken process is just gonna give you a faster broken [00:28:00] process. So you also have to understand how your existing system works. And then think about those cascading effects, like with developers getting faster, putting back pressure on product, and forward pressure on test. System thinking has always been critical, but AI is making the cost of not having it more visible and more immediate.
As you get better at thinking in systems, at visualizing systems, as you get better at explaining systems and trying to talk to people about the system you're building or the system that you're working within, sometimes you will get resistance.
Some people see systems thinking as cold or mechanical as an attempt to turn people into COGS in a machine. When you try and map out what is essentially human relationships and team dynamics, very organic, very people things. And now you're trying to map them and turn it into a system some people are going to resist that.
[00:29:00] It's worth addressing it directly. System sinking is not about treating people as interchangeable parts, it's about making the environment around them better so they can do their best work. One of the reasons I've always really appreciated the gardening metaphor is that you can perfectly plan a garden. There's going to be a rose here. It's going to be this tall, it's gonna have this many leaves on it. There's gonna be another plant right next to it, and it'll be two inches from it and it'll be this tall and it'll have this many leaves.
You can visualize that. You can plant it on paper, but when you plant the seeds and they grow, you're gonna get what you're gonna get. And your goal is not to have it be exactly as your plan. Your goal is to have it be nice. And so you can guide and help shape it, but the end result is always going to be something that has to happen because of the living things that create it.
These are living things. These are not [00:30:00] wood or metal, these are not legos or whatever. All the planning in the world, you're trying to get a positive outcome, not an exact outcome, because often you're gonna get a better outcome than you could have planned because of the people who are involved with it.
I talked about working with transactional leaders and how that creates a problem when you're trying to be a systems thinking leader. I mentioned sales specifically. 'cause sales teams tend to be exceptionally transaction driven.
That's just the nature of the way that we generally do like enterprise or B2B sales inside sales. A lot of the friction I or the people I mentor has often come from engineering leaders who are trying to be long term and trying to be very systems oriented and transactional leaders in other parts of the company who really need, other people to work the same way they are.
that doing stuff approach that looks productive in that short term. [00:31:00] Reorganizing. This is where you get, " action. We need more action. You're not doing enough things. You need to reorg or you need to reassign people, or you need to add more process." It looks productive in the short term.
When you're building systems, it can look like you're not doing much because those changes are structural, not visible activities you're preparing the ground for plants to grow. This is where that communication becomes critical and getting buy-in for it. And early wins are good there to just show you're making progress, but that also showing the evolution that you're getting.
So you will be making improvements. Things are improving. They may not be happening at the speed that some of your peers may want them at, but they're gonna happen in a better way. You're gonna end up with a much better result than if you just force things through. You have to make that visible to people.
Systems level, [00:32:00] change takes time, and organizations are full of people who want faster answers. If you can get things to a self-perpetuating state. People will see the results and become supporters. If the leadership team is impatient, doesn't understand what you're doing, they'll lean into quick fixes that can undermine the system that you're building.
Your job is to hold the line long enough for the system to start producing results, and that is harder than it sounds. Building a system and thinking for that long term is also much easier in companies that are doing well.
If your company is struggling and you're trying to put in a system that's gonna take years to get really good outcomes you're probably misaligned there, you need to be more transactional. Just like I talked about, early stage startups are very transactional, and that works okay because they're just trying to survive. If your company's in that position, that's not a great time to be putting in a system that's gonna take a while to achieve results. Usually you need to achieve results [00:33:00] faster.
Let's be realistic. That is a good time to be doing more transactional level leadership.
I developed my system thinking organically. I did that a lot through experience and reading without formally naming it for a long time.
The most senior leaders I know have this understanding, but many of them also developed it organically. And have a hard time like I do teaching it explicitly, that's a bit of a problem because it means systems thinking is treated as something you either have or you don't, rather than a skill you build. It is absolutely a skill I built.
I mentioned I made the mistake of understanding how much communication mattered when doing systems level work. The tendency was to focus on building the right system and assume that the results would speak for themselves. I absolutely made that mistake.
They don't. You have to narrate what you're doing and why, especially to the people who think differently about management and also to your team. It's important they are bought [00:34:00] in and understand where you're trying to lead them. I used to think that the hard part was understanding the system. It isn't, the hard part is getting the people to see it.
The progression model that I gave you, that four stage progression is an attempt to make explicit what I and other leaders do implicitly, and to give someone an actual path to follow.
System thinking is not an advanced leadership concept reserved for CTOs. It's a skill that can be developed at any level, starting with a simple act of looking beyond individuals and asking how the structure around them is shaping their work.
The challenge for you, pick one of the exercises from this episode and try it this week. Map the dependencies between teams you work with. File one piece of work from start to finish and write down every place it pauses. Pick a recent decision and trace how it actually got made, or look at a team that's [00:35:00] underperforming and ask what they're incentivized to do versus what you want them to do.
Every organization is a system. The question is whether you're designing it or just living in it.
Thank you. This was my attempt to try and actually teach how to be a better systems thinker. I would love your feedback to hear how useful was it? Did I do a good job? I'm trying to figure out how to explain it and explain how to do it better. I hope it helped you.
I will see you next week in the newsletter. I will see you back here on the podcast in two weeks. Have a great week.
