Hardly a week goes by without someone telling me that the critical skill for the AI era is "systems thinking". Software leaders say it. Recruiters say it. Coverage of the World Economic Forum's Future of Jobs Report 2025 places it among the skills growing in importance. Harvard Business Review has even run a piece by Tima Bansal and Julian Birkinshaw of Ivey Business School with the blunt title "Why You Need Systems Thinking Now".
Each time I hear it, I feel a strong sense of recognition. When I was studying for my PhD and then delivering enterprise software in the 1990s, "a systems approach" was not a slogan. It was the foundation for how we designed, built, and delivered large systems. So, is this a meaningful revival? Or is an old phrase being reused to cover something rather different?
What "a systems approach" meant at the end of the 20th century
Three ideas shaped how many of us approached systems design, development and delivery at the time.
The first was Peter Checkland's Soft Systems Methodology, developed at Lancaster University and set out in his 1981 book Systems Thinking, Systems Practice and, with Jim Scholes, in Soft Systems Methodology in Action in 1990. Checkland argued that organisational problems are messy, contested and human. A "system" was not a thing waiting to be built, but a way of learning about a problem situation. Rich pictures, root definitions and the repeated question "what is this system for, and for whom?" forced you to understand the purpose and the people before touching the technology.
The second was Michael Jackson's work on structured software design, from Jackson Structured Programming, described in his 1975 book Principles of Program Design, to Jackson System Development, set out in his 1983 book System Development. Its central insight has stayed with me for 30 years. The structure of a system should reflect the structure of the real-world problem it serves. Model the world first, then add function. Get that wrong and no amount of clever code will save you.
The third was the rise of enterprise architecture. John Zachman's framework first appeared in his 1987 IBM Systems Journal article, "A Framework for Information Systems Architecture". Steven Spewak's 1992 book Enterprise Architecture Planning turned the idea into a planning process, and The Open Group began developing its TOGAF standard in 1994. Their promise was a coherent view of how business processes, information, applications and infrastructure fit together across a whole organisation.
These traditions differed in many ways. Yet they shared one conviction: you start from the whole, not from the component. Technology was always one part of a sociotechnical system, and the hard problems lived in the connections.
Three conversations using the same words
Look closely at today's commentary, and you find three distinct conversations, each using "systems thinking" to mean something different.
1. The architect's view. The loudest voices come from software development. As AI tools generate more of the code, the argument goes, the valuable skill is understanding how components connect, where the dependencies lie, and how a change in one place ripples through the whole. Rockford Lhotka puts it starkly: developers must decide whether they are systems thinkers or typists, because AI already types faster than any of us. This is Michael Jackson and enterprise architecture by another name.
2. The orchestrator's view. A second group is concerned with directing AI agents. Here systems thinking means breaking a desired outcome into clear, logical steps and giving agents structured context to work from. Recruitment firm Aquent defines it in almost exactly those terms. This is valuable, but it is closer to the structured analysis and process modelling of the 1980s than to systems thinking as Checkland would have understood it. It is about sequence, not about feedback or purpose.
3. The organisational view. The third conversation is about leaders and transformation. Its focus is feedback loops, delayed consequences and second-order effects. When an organisation deploys AI in one function, roles, skills, incentives and customer relationships shift elsewhere, often months later. Axial Search uses exactly this lens to explain why so many AI pilots succeed in isolation and then fail to scale. This is the view that traces back through Peter Senge and Jay Forrester, and it sits closest to Checkland's concern with purpose and people.
The three views are not wrong. But they are not the same thing, and treating them as one skill hides more than it reveals.
Why the systems approach has come back
So, has the thinking returned? I believe it has, and for three reasons.
First, AI has made building cheap, so the bottleneck has moved. When code, content, and analysis can be generated in minutes, the scarce work is deciding what should be built, how the pieces fit together, and whether the result serves its purpose. We have seen this pattern before. Every wave of automation in software, from CASE tools to fourth-generation languages to low-code, pushed value upstream towards analysis and design. AI is the most powerful version of that shift yet.
Second, AI systems are increasingly composite. An agentic workflow is a set of semi-autonomous components passing work between themselves, legacy systems and people. The behaviour that matters emerges from the interactions, not from any single part. That is precisely the territory the systems tradition was built for.
Third, organisations are discovering that AI is not a tool you drop into an existing process. It reshapes roles, decision rights and relationships with customers. The leaders who struggle are those who built their business case on first-order effects (faster responses, lower cost per task) and then found themselves surprised by everything that followed.
The same, but different
However, it would be a mistake simply to dust off the old methods. Two things are different.
The 20th-century approaches largely assumed that a designer could specify the system and that it would then behave as specified. AI components do not work like that. They are probabilistic, they change as models are updated, and the people around them adapt their behaviour in response. A system containing AI is less like a machine to be engineered and more like an ecosystem to be steered. Harvard Business Impact's 2026 leadership research makes a similar point, urging leaders to practice complexity thinking alongside systems thinking. Some critics go further, arguing that the language of interconnection is now table stakes, and that what matters is the capacity to act when outcomes are emergent and unpredictable.
We should also remember why the systems approach faded the first time. In too many organisations, it hardened into heavyweight frameworks, large models and documents that few people read. If the revival repeats that pattern, it will fail again. The value lies in the habit of mind, not the paperwork.
Three questions to ask before you hire for "systems thinking"
The next time someone tells you systems thinking is the key skill for the AI era, agree with them. Then ask which kind they mean. For digital leaders, three questions follow.
When your teams talk about systems thinking, do they mean architecture, orchestration, or organisational dynamics, and which of those is your real gap?
For your current AI initiatives, who is responsible for anticipating the second- and third-order effects, and how will you know when they appear?
Are you building systems thinking as a habit of mind across your leadership, or delegating it to a framework and a few specialists?
Those of us who lived through the first wave of the systems approach have something to offer here. Not nostalgia, but hard-won lessons about what worked, what didn't, and why the connections always matter more than the components.
Right, I'm off to the loft to see if I can unpack some of my old textbooks. Somewhere between a dog-eared copy of Checkland and a box of floppy disks, there is surely a rich picture explaining how we managed to forget all this the first time around.
