Systems Thinking Chapter 11: Systems Leadership
Chapter 11 is about leadership. But not the kind you see on LinkedIn where someone posts a sunset photo and writes “leaders eat last.” Diana is talking about something very different. Systems leadership is about improving how knowledge flows through your organization. Not about your title, not about your authority, not about how many people report to you.
The World Was Not Designed for Us
Diana opens with a pretty bold statement. We are systems thinkers in a world that was not designed for systems thinkers. Most organizations still run on mental models from the industrial age. Roles are linear. Hierarchies are about control. Success is measured by output, not by understanding.
She traces this back to Frederick Winslow Taylor. If you never heard of him, he was an engineer in the late 1800s who basically invented modern management. His big idea? Workers are lazy. They will do as little as possible unless you watch them and measure them and control their every move. He called it “systematic soldiering.” People avoiding work to whatever extent they can get away with.
Taylor had an apprentice named Henry Gant, whose family depended on slave labor until the Civil War. Together they defined management as “knowing exactly what you want men to do, and then seeing that they do it in the best and cheapest way.” If Taylor was alive today, he would pay developers by lines of code. Think about that for a second.
This thinking is still everywhere. The return-to-office debates? Pure Taylorism. Elon Musk saying remote workers “pretend to work”? Taylor would have loved that. Microsoft found that 85% of leaders don’t trust that hybrid employees are productive, even though multiple studies show the opposite. We believe in control even when control doesn’t work.
What Systems Leadership Is Not
Diana spends time explaining what she does NOT mean by systems leadership. This was useful for me.
It is not management. You can be a systems leader without managing anyone. And plenty of managers actively work against systems thinking. Being a CTO does not make you a systems thinker. Sometimes it helps, sometimes it just gives you more power to do the wrong things faster.
It is not unique to technology. Diana tells a story about her hairdresser Kelly. Kelly is a natural systems thinker. When a client sits in her chair, Kelly considers psychology, chemistry, cost, personality, lifestyle, all in about five minutes. She integrates multiple dimensions to produce a result. That is systems thinking. Being in tech does not give you a monopoly on it.
It is not just being really good at coding. This one hit close to home. Subject matter expertise alone is not leadership. Knowing React or Kubernetes inside out does not prepare you for systems leadership. Systems leadership is about building relationships with other experts, integrating their knowledge with yours, seeing the bigger picture.
So What IS Systems Leadership?
Diana describes several characteristics. I will group them the way she does.
Architecting communication structures. Conway’s Law says your system will mirror your communication structure. So if you want better systems, design better communication. This means actual communication skills, systemic reasoning, proactive listening, empathy. Yes, empathy is a technical skill. We write code with people and for people.
Integrative leadership. This is the big one. In systems, leadership is shared. Hierarchy exists, but it is a communication structure, not a command structure. Higher-level functions serve the needs of lower-level activities, not the other way around. Your job as a systems architect is not to tell people what to do. Your job is to make sure everyone knows what they need to know to have a positive impact.
Diana says the most successful systems operate with little need for executive control. The goal is to make yourself obsolete. You never actually become obsolete, because systems always need some coordination. But your mindset should be: how do I create conditions where people think well together without me hovering over them?
Systems design. This is about integration, relationship design, pattern design, information structure, and orchestration. Instead of tweaking individual APIs, systems leaders look deeper. They look for root causes. They look for leverage points, places to intervene that will change the whole system, not just patch one symptom.
Debugging the Cat
My favorite part of this chapter is the cat story. Diana’s cat Mauritia was struggling to breathe. She took her to the vet. Three different vets gave three different diagnoses. Each was confident. Each was wrong. They sent the cat home saying she was fine. The next morning, the cat was near death again.
Then the chief medical officer took over. He sat down with Diana and explained what he knew and what he did not know. He shared his theories, his reasoning, how he would test them. Diana said, “We are debugging the cat.” The CMO blinked.
For five days, nobody knew if the cat would survive. The CMO never found the exact cause, just that it was a virus he had not seen before. But he understood enough of the patterns to act effectively. He knew where to intervene. The cat lived another nine years.
The first three vets did what most of us do. They diagnosed the problem linearly and applied a concrete solution. The CMO did systems thinking. He held the full equation in his mind, kept learning, drew on experience, and used intuition. He did not randomly stab problems with needles full of guesses.
We are all, always, debugging a cat. I really liked that line.
Seven Learning Heuristics
Diana ends with seven heuristics for systems leaders. Not rules. Heuristics. Mental shortcuts that guide you when things get confusing.
- What you know is probably your blocker. The call is coming from inside the house. Sometimes the solution you are so sure about is actually causing the problem.
- Knowledge is more valuable than information. Information tells you to eat less red meat. Knowledge is understanding that your cholesterol is a systemic challenge affected by lifestyle, genetics, and factors nobody fully understands yet.
- Devalue your opinion. Your opinion is not knowledge. Share your reasoning, your experience, the context. Not just “I think X.”
- One perspective is always insufficient. If you only have one point of view, you do not have knowledge. You have a photo through one window.
- There is always another right way. If you have not found more than one valid answer, you probably have not learned enough yet.
- Be Missouri. Show, don’t tell. Use visuals, models, stories. Do not just dump text on people and expect them to get it.
- Is the word in the glossary? People use the same words to mean different things. Create a glossary. Keep it visible. Diana admits she has always failed at doing this consistently. Which is exactly how she knows it matters.
Build Your Support System
The chapter closes with practical advice. People always ask Diana, “How do I get my organization to think this way?” Her answer: you cannot control what other people think. But you can influence by demonstrating. Find one person who thinks in systems. Set up a monthly discussion. Build a small group of people who care about this stuff. Support each other.
This is not glamorous advice. There is no framework to buy, no certification to earn. Just find your people and keep practicing.
My Take
This chapter connected a lot of dots from earlier in the book. After reading about self-awareness, perspective shifting, feedback loops, and pattern thinking, you finally see what it looks like when someone puts it all together in a leadership context.
The Taylor history was eye-opening. I knew about Taylorism from university, but seeing it connected to modern management debates made it feel very current. We are still fighting the same fight, 120 years later.
The cat story is the kind of thing that sticks with you. Simple, relatable, and it makes the abstract concrete. That is exactly what a good systems leader does. Shows, not tells.
Previous: Chapter 10: Modeling, Together - Part 2