Systems Thinking Skills

6 engines. 168 cylinders. One aircraft. In this 1940's factory image (digitally enhanced) , the wing of the Convair B‑36 Peacemaker is being fitted with six Pratt & Whitney R‑4360 Wasp Major radial engines each producing 3,800 horsepower. That’s 28 cylinders per engine. 168 cylinders across the wing. Built by Pratt & Whitney, this was the most powerful piston aircraft engine ever mass-produced. But the real lesson isn’t horsepower. It’s systems engineering. Every one of those engines had to integrate with: • cooling airflow • fuel distribution • propeller dynamics • structural loads in the wing • vibration modes across a 70-meter wingspan • maintenance accessibility for ground crews One engine is a machine. Six engines become a system. And systems create problems you can’t see when you design components in isolation. That’s why early strategic aircraft like the B-36 forced engineers to think beyond parts , toward integration, redundancy, and failure tolerance. A single engine failure was expected. The aircraft had to keep flying anyway. The lesson still applies today , whether you're designing spacecraft, AI systems, or aircraft: Engineering breakthroughs rarely come from bigger components. They come from better integration of complex systems. The engineers at Convair building this aircraft understood something we often forget in modern engineering culture: Complexity isn’t solved by adding technology. It’s solved by designing systems that survive it. One aircraft designed to carry the weight of an entire strategic doctrine. Sometimes the most important engineering achievement… is making complexity fly. Pic Credit : Jets n Props

If you are trying to understand distributed systems, focus less on what and more on why, when, and how. Answering what a system does is usually the easy part. The harder one is why it behaves the way it does. This is actually learnable, and it comes from building intuition around trade-offs and from spending hours working through that one strange bug. And that intuition is what really matters when things break. In those moments, surface-level or theoretical knowledge is not enough. What matters is having that ability to reason from 'first principles' and apply deep practical understanding. For example, imagine a system where requests suddenly start timing out after a new deployment. Logs look normal, dashboards seem fine, and nothing obvious is broken. If you only know what the system does, you are stuck. But if you understand why it behaves the way it does, you start asking better questions - did latency increase due to a hidden network hop, did retries amplify load, did a small configuration change trigger cascading failures? That is where real debugging begins. So, when you are picking up distributed systems, spend more time asking why, when, and how. Hope this helps.

Understanding complex systems changed how I think about design, strategy and futures work. It’s also the fourth and final ellipse in my strategic design model. Complex systems have some unique qualities: - Cause and effect aren’t linear - Even observing the system changes its nature - You can only really make sense of what happened in hindsight Those properties matter more than most design models acknowledge. A lot of design and strategy work assumes that if we can define a future state clearly enough, we can plan our way towards it. That can work when a problem is complicated. It doesn’t hold in a complex environment. If you’ve ever worked in a situation where: - People disagree on what the problem actually is - Interventions create unexpected side effects - The same “solution” works in one place and fails in another - Progress feels real, but hard to explain or predict you’re probably dealing with complexity. This is the work of Dave Snowden and The Cynefin Company, particularly through the Cynefin framework and Snowden’s work on anthrocomplexity. Complex adaptive systems shaped by human sense-making, not just behaviour. In that context, the approach changes. Rather than defining an end state and working backwards, we: - Understand and start from where we are - Run multiple safe-to-fail experiments - Amplify what seems to work - Dampen what doesn’t - Watch for what else emerges Importantly, we run these experiments in parallel. This is where complexity challenges design habits. Design often pushes us toward convergence — finding the best answer as efficiently as possible. In complexity, diversity matters more than optimisation. We might deliberately run experiments we think might fail, as we can’t be certain of the results. And because cause and effect are only clear in the rear view mirror we should expect surprises. I’m barely touching on the depth and breadth of anthrocomplexity here. There’s a substantial body of work behind it. In my practice it doesn’t replace design, strategy or futures thinking. It reframes how and when they’re useful. It’s also a reminder to be careful with familiar models, especially when the system itself is adaptive, complex and uncertain. As Col. John Boyd put it: “If you don’t challenge assumptions, what is doctrine on day one becomes dogma forever after.” For me, complex adaptive systems thinking is one way of keeping that challenge alive. #StrategicDesign #FuturesThinking #Strategy #DesignThinking #ComplexAdaptiveSystems

Teams often implement solutions that do not fix the problem they were trying to address. That's because the issue wasn’t framed correctly in the first place. This is especially true in complex or unfamiliar situations, where quick conclusions feel comforting but are often wrong. When I work with teams on decision-making, I turn to a framework developed by Julia Binder and Michael Watkins. Their E5 approach helps leaders define the right problem before trying to solve it. Phase 1: EXPAND Suspend early judgments and deliberately broaden how the challenge is understood. By exploring multiple interpretations of the issue, teams uncover hidden assumptions, surface blind spots, and create the conditions for more original thinking before jumping to answers. Phase 2: EXAMINE Shift from scope to depth. Teams analyze the problem rigorously, moving beyond visible symptoms to identify behavioral patterns, structural drivers, and underlying beliefs that reveal what is truly at play. Phase 3: EMPATHIZE Center on the perspectives of those most affected by the issue. Through (real) listening and reflection, teams gain insight into stakeholders’ motivations, emotions, concerns, and behaviors, often uncovering needs that data alone cannot reveal. Phase 4: ELEVATE Step back to see how it fits within the broader organization. Viewing the challenge through lenses such as structure, people, power, and culture exposes interdependencies and systemic tensions that shape outcomes. Phase 5: ENVISION Articulate a clear future state and map a path to reach it. Working backward from a shared definition of success, teams prioritize initiatives, sequence efforts, and align resources to move from understanding to execution. I've found that when leaders take the time to frame problems well, they increase the likelihood that those solutions will actually matter. #decisionMaking #leadership #perspective #learning #problems Source: The model is described in more details in this Harvard Business Review article: https://lnkd.in/gAeBb5uT

A few years ago, a CEO I coached said, “Every week feels the same. The same fires, just in different departments.” Like many leaders, he was solving brilliantly but within the same loop. ✅ What he needed was a systems-thinking shift. It often comes down to this: • Leaders who think in steps solve problems repeatedly. • Leaders who think in systems solve them once. Most leadership energy is wasted in firefighting mode, reacting to outcomes instead of addressing the structures that create them. Systems-thinking leadership changes that. It’s preventive leadership. Instead of asking, “What went wrong?” Ask, “What pattern keeps creating this?” When you fix the pattern, the symptom often disappears permanently. That’s why organisations led by systems thinkers see up to a 60% reduction in recurring issues. You can start by: 1. Mapping the flow:  Where does the problem originate? 2. Identifying repetition: What keeps resurfacing? 3. Intervening at structure: What policy, rhythm, or decision loop fuels it? One systemic intervention can prevent dozens of future fires. That’s strategic leverage. Because when leaders build systems that self-correct, teams become self-managing, and leadership finally shifts from firefighting to fire prevention. What’s one recurring issue in your organization that might be a system problem in disguise? #LeadershipDevelopment #SystemsThinking 

“𝐓𝐡𝐞 𝐠𝐫𝐞𝐚𝐭𝐞𝐬𝐭 𝐝𝐚𝐧𝐠𝐞𝐫 𝐢𝐧 𝐭𝐢𝐦𝐞𝐬 𝐨𝐟 𝐭𝐮𝐫𝐛𝐮𝐥𝐞𝐧𝐜𝐞 𝐢𝐬 𝐧𝐨𝐭 𝐭𝐡𝐞 𝐭𝐮𝐫𝐛𝐮𝐥𝐞𝐧𝐜𝐞; 𝐢𝐭 𝐢𝐬 𝐭𝐨 𝐚𝐜𝐭 𝐰𝐢𝐭𝐡 𝐲𝐞𝐬𝐭𝐞𝐫𝐝𝐚𝐲’𝐬 𝐥𝐨𝐠𝐢𝐜.” 𝐏𝐞𝐭𝐞𝐫 𝐃𝐫𝐮𝐜𝐤𝐞𝐫 I found the global Delphi position paper, "Leadership for the agentic age", very insightful as it argues the role of leadership in the agentic era, and I wanted to share these key insights with my network. As AI is moving from tools to teammates, leaders need to have a different mindset and skills. The central disruption of the Agentic Age isn't about technology; it is a profound disruption of leadership itself. Now, with autonomous AI agents, leaders must shift from controlling human labor to orchestrating distributed intelligence. The Mindset Shift: From Process to Purpose: Leaders can no longer rely on programmatic thinking. In an environment defined by the Agentic Fidelity Paradox, forcing autonomous systems to strictly follow step-by-step procedures creates fatal "brittleness". Instead, leaders must transition from being "process managers" to "objective architects". To navigate this transformation, leadership must be structurally redesigned using core frameworks: ✔️ The Objective Hierarchy: requires defining the Purpose (why the system exists), the Performance metrics (how multidimensional success is measured), and the Constraints (the ethical and legal lines that must never be crossed). ✔️ Organizational Readiness Hierarchy: moving an organization from isolated AI experimentation (Level 2) to full ecosystem integration (Level 5), where AI is woven into the core cognitive fabric of the business. Leadership must focus on an inner discipline built on qualities algorithms cannot replicate: Empathy, Curiosity, Innovation, ethical seriousness, and Moral Presence. Translating these qualities into action requires mastering 11 new leadership skills, including: ✔️ Systemic Empathy: Guiding human teams through the emotional impact of losing tasks they formerly took pride in. ✔️ Machine Clarity: Communicating directives with absolute precision to avoid unintended consequences from literal interpretations by AI. ✔️ Judgment Sovereignty: Having the conviction to uphold human intuition and experience over algorithmic confidence when necessary, and 8 other important skills. The next decade belongs to "Alignment Leaders" who act as gardeners of coherence between human and machine intelligence. To prepare for this age, leaders must adopt the five leadership mandates: 1- Keep human judgment as the final, moral authority. 2- Grant autonomy explicitly, never by default. 3- Rigorously simulate scenarios before deploying AI at scale. 4- Codify your values, or you will surrender them to your training data. Own the outcome. Accountability can never be delegated to a machine. The Intelligent Age will be defined by leaders who know how to share agency intelligently. #AgenticAge #AIagents #Leadearship

Why doesn't adding more engineers speed up a late project? This is a classic systems problem. If you're a knowledge worker dealing with complex problems, understanding systems thinking isn't just helpful. It's essential! According to the Cynefin framework, in a complex domain, the link between cause and effect is only obvious in retrospect. There are no "right answers". This is why some of our common "solutions" in tech often fail: 🚫 More testers don't guarantee higher software quality. 🚫 More process doesn't guarantee a safer release. 🚫 More money doesn't guarantee a project will finish on time. We're so often focused on the individual parts of the problem, but we forget to think about the relationships between them. In my conversation with Diana Montalion, she shared an incredibly insightful way to understand systems thinking: "Relationships produce effects. We think because we understand 'one', we understand 'two'—because one and one make two. But we forget that we have to understand 'and'." This simple idea that we must understand the "and" is a powerful insight! If you're curious to learn more about systems thinking, tune in to my full conversation with Diana on the latest Tech Lead Journal episode.

How often do we really step back and see the full picture of a problem? Take sustainability initiatives, for example. They’re not just a collection of isolated projects or actions; they’re deeply woven into an organization’s core operations. And it’s this systems thinking approach, rooted in Lean Six Sigma, that gives us a way to look at the big picture. Rather than focusing only on immediate tasks, we consider every step in the lifecycle, connecting dots between people, resources, and processes. Studies show that sustainability initiatives grounded in systems thinking yield more resilient outcomes. I n fact, a 2023 McKinsey study found that organizations with an integrated approach to sustainability had a 20% greater rate of project success than those using isolated, short-term fixes. If you’re considering a systems approach, think about these key elements: -Define your end goal clearly: Where do you want this initiative to lead? -Engage all stakeholders: Every voice, from leadership to frontline workers, plays a part. -Break down big problems into manageable tasks: This makes complex challenges easier to tackle. -Continuously evaluate the structure: Keep refining how each part connects within the system. -Justify each major step: Having a solid rationale builds trust and clarity. The global challenges we face—like climate change, resource scarcity, and social equity—require this type of thinking. By applying a systems view to sustainability, we’re not only working to solve the immediate issue but also creating a resilient foundation for the future. Where do you see systems thinking fitting into your projects?

𝑻𝒉𝒆 𝒎𝒆𝒆𝒕𝒊𝒏𝒈 𝒕𝒐𝒐𝒌 𝟗𝟎 𝒎𝒊𝒏𝒖𝒕𝒆𝒔. 𝑻𝒉𝒆 𝒑𝒓𝒐𝒃𝒍𝒆𝒎? 𝑺𝒕𝒊𝒍𝒍 𝒖𝒏𝒔𝒐𝒍𝒗𝒆𝒅. Customer delivery was failing. Promises missed. Revenue bleeding. The entire meeting: "Whose fault is this?" Sales blamed Operations. Operations blamed Product. Product blamed Sales for unrealistic timelines. Sales blamed Leadership. Round and round. Finally, the COO stopped it: "I don't care whose fault it is. What's broken?" They mapped the process. Found the real issue in 15 minutes: a system handoff no one owned. 𝘛𝘩𝘦𝘺 𝘴𝘱𝘦𝘯𝘵 90 𝘮𝘪𝘯𝘶𝘵𝘦𝘴 𝘰𝘯 "𝘸𝘩𝘰." 𝘛𝘩𝘦 𝘢𝘯𝘴𝘸𝘦𝘳 𝘸𝘢𝘴 𝘪𝘯 "𝘸𝘩𝘢𝘵." 𝑾𝒉𝒆𝒏 𝒑𝒓𝒐𝒃𝒍𝒆𝒎𝒔 𝒈𝒆𝒕 𝒉𝒂𝒓𝒅, 𝒍𝒆𝒂𝒅𝒆𝒓𝒔 𝒎𝒂𝒌𝒆 𝒕𝒘𝒐 𝒇𝒂𝒕𝒂𝒍 𝒎𝒊𝒔𝒕𝒂𝒌𝒆𝒔: Mistake 1: They hunt for WHO instead of WHAT Blame dissipates energy. It feels productive—someone’s accountable!—but it solves nothing. Quality thinker W. Edwards Deming estimated that most failures come from systems and processes, not individual employees. Yet we spend most problem-solving time on people. Mistake 2: They add resources to broken systems "We’re overwhelmed. Hire more people." But if the process takes 47 steps when it should take 12, more people just means more people struggling. 𝘈𝘥𝘥𝘪𝘯𝘨 𝘱𝘦𝘰𝘱𝘭𝘦 𝘵𝘰 𝘢 𝘣𝘳𝘰𝘬𝘦𝘯 𝘴𝘺𝘴𝘵𝘦𝘮 𝘫𝘶𝘴𝘵 𝘴𝘤𝘢𝘭𝘦𝘴 𝘵𝘩𝘦 𝘥𝘺𝘴𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯. 𝑴𝒚 𝑹𝒐𝒐𝒕 𝑪𝒂𝒖𝒔𝒆 𝑷𝒓𝒐𝒃𝒍𝒆𝒎-𝑺𝒐𝒍𝒗𝒊𝒏𝒈 𝑭𝒓𝒂𝒎𝒆𝒘𝒐𝒓𝒌 When a problem hits: 𝟏. 𝐁𝐚𝐧 "𝐖𝐇𝐎" 𝐟𝐨𝐫 𝟑𝟎 𝐌𝐢𝐧𝐮𝐭𝐞𝐬 ❌ "Whose fault is this?" ✅ "What's happening? What's the actual symptom?" Focus on facts first. Blame later (or never). 𝟐. 𝐓𝐫𝐚𝐜𝐞 𝐁𝐚𝐜𝐤𝐰𝐚𝐫𝐝 𝐭𝐨 𝐭𝐡𝐞 𝐎𝐫𝐢𝐠𝐢𝐧 Don’t solve symptoms. Use the 5 Whys: → Delivery late. Why? → Backlog. Why? → Orders spiked. Why? → Sales overpromised. Why? → Comp plan rewards speed, not feasibility. 𝟑. 𝐀𝐬𝐤: "𝐏𝐄𝐎𝐏𝐋𝐄 𝐨𝐫 𝐒𝐘𝐒𝐓𝐄𝐌?" If 3+ people struggle with the same thing, it’s not them. It’s the process. Fix the system first. Then see if you need more capacity. 𝟒. 𝐑𝐞𝐟𝐥𝐞𝐜𝐭: 𝐖𝐡𝐨 𝐀𝐫𝐞 𝐘𝐨𝐮 𝐁𝐞𝐜𝐨𝐦𝐢𝐧𝐠? Problem-solving reveals character. Are you blaming or building? Reactive or strategic? Covering or learning? 𝘉𝘭𝘢𝘮𝘦 𝘣𝘶𝘳𝘯𝘴 𝘵𝘳𝘶𝘴𝘵. 𝘈𝘤𝘤𝘰𝘶𝘯𝘵𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘧𝘪𝘹𝘦𝘴 𝘴𝘺𝘴𝘵𝘦𝘮𝘴. 𝑹𝒆𝒇𝒍𝒆𝒄𝒕: → What problem are you "solving" by hiring more people instead of fixing the process? → When did you last spend more energy on WHO than WHAT—and what did it cost? (Next time a problem hits, ban blame for 30 minutes. Watch what shifts.) Next week: 𝑭𝒐𝒓𝒆𝒔𝒊𝒈𝒉𝒕 — anticipating problems before they become crises. 𝘗.𝘚. 𝘞𝘰𝘳𝘬𝘪𝘯𝘨 𝘰𝘯 𝘺𝘰𝘶𝘳 𝘴𝘵𝘳𝘢𝘵𝘦𝘨𝘪𝘤 𝘦𝘥𝘨𝘦? → 𝑻𝒉𝒆 𝑰𝒏𝒏𝒆𝒓 𝑬𝒅𝒈𝒆 https://lnkd.in/gi-u8ndJ 𝘗.𝘗.𝘚. 𝘙𝘦𝘢𝘥𝘺 𝘵𝘰 𝘣𝘶𝘪𝘭𝘥 𝘳𝘰𝘰𝘵-𝘤𝘢𝘶𝘴𝘦 𝘱𝘳𝘰𝘣𝘭𝘦𝘮-𝘴𝘰𝘭𝘷𝘪𝘯𝘨 𝘤𝘢𝘱𝘢𝘣𝘪𝘭𝘪𝘵𝘺? 𝘋𝘔 𝘮𝘦 𝘵𝘰 𝘦𝘹𝘱𝘭𝘰𝘳𝘦 𝘦𝘹𝘦𝘤𝘶𝘵𝘪𝘷𝘦 𝘤𝘰𝘢𝘤𝘩𝘪𝘯𝘨. #TheInnerEdge #ProblemSolving #RootCauseAnalysis #StrategicLeadership

You can memorize patterns and still build systems that fall apart. Because real system design comes in levels. ⬆️level 0 Fundamentals: • Clients send requests • Servers handle logic • Databases store data You learn HTTP methods, status codes, and what a REST API is. You pick between SQL and NoSQL without really knowing why. You're not a backend dev until you've panic-fixed a 500 error in production caused by a missing null check. ⬆️level 1 Master the building blocks: • Load balancers for traffic distribution • Caches (Redis, Memcached) to reduce DB pressure • Background workers for async jobs • Queues (RabbitMQ, SQS, Kafka) for decoupling • Relational vs Document DBs; use cases, not just syntax differences You realize reads and writes scale differently. You learn that consistency, availability, and partition tolerance don't always play nice. You stop asking "SQL or NoSQL?" and start asking “What are the access patterns?” ⬆️level 2 Architect for complexity: • Separate read and write paths • Use circuit breakers, retries, and timeouts • Add rate limiting and backpressure to avoid overload • Design idempotent endpoints You start drawing sequence diagrams before writing code. You stop thinking in services and start thinking in boundaries. ⬆️level 3 Design for reliability and observability: • Add structured logging, metrics, and traces • Implement health checks, dashboards, and alerts • Use SLOs to define what “good enough” means • Write chaos tests to simulate failure • Add correlation IDs to trace issues across services At this level, you care more about mean time to recovery than mean time between failures. You understand that invisible systems are the most dangerous ones. ⬆️level 4 Design for scale and evolution: • Break monoliths into services only when needed • Use event-driven patterns to reduce coupling • Support versioning in APIs and messages • Separate compute from storage • Think in terms of contracts, not code • Handle partial failures in distributed systems You design for change, not perfection. You embrace trade-offs. You know when to keep it simple and when to go all in. What’s one system design lesson you learned the hard way?