Are You A Systems Thinker?
Why is Systems Thinking essential in the AI era, and what steps can you take to develop it?
Once, a city experienced rapid growth that its authorities failed to anticipate, resulting in traffic congestion.
They widened the major roads as an immediate mitigation measure. Although it temporarily eased the problem, the issue grew worse within a few months.
They felled trees, encroached on the pavements, and used every bit of space to widen the roads.
The situation worsened each day until road transport became gridlocked.
…
What do this city’s transportation and the software applications we build have in common?
System!
A city manages its Transportation System, while we develop Software Systems.
Both require Systems Thinking!
Part 1: Who made Aaron redundant?
Part 2: AI Boom or Career Doom?
Part 3: This article
The Golden Ages Of Software Engineering
“We live in a Golden Age of Systems!” echoed Grady Booch on an episode of The Pragmatic Engineer podcast, where he divided software engineering into three golden ages:
The age of Algorithmic abstractions (1940s to 1970s),
The age of Object-Oriented abstractions (1970s to 2000s), and
The age of Systems (2000s to today and beyond!)
Looking back at the evolution of the software engineering industry, a common thread — the thoughtline — throughout the eras is abstraction.
Algorithmic abstraction: 1940s to 1970s
During the first golden age, computers were rare and costly. As experts separated assembly language from hardware, high-level languages flourished, and developing algorithms for various tasks became easier.
The spread of structured programming and subroutines — i.e., procedures and functions — helped break down programs and create abstraction, leading to the concept of building blocks of software.
Object-oriented abstraction: 1970s to 2000s
With Peter Coad, Edward Yourdon, Ivor Jacobson, James Rumbaugh, Grady Booch, and others spearheading the shift from the Structured System Analysis and Design Methodology (SSADM) to an Object-Oriented modeling approach, the industry found a new method for analyzing, architecting, visualizing, developing, and documenting software systems.
Object-oriented system-behavior thinking and visual modeling tools enabled teams to collaborate effectively. As a result, a whole ecosystem of component-based, loosely coupled systems swept across the industry.
By applying modularity patterns and reusability principles, engineers learned to build even larger systems, leading to multiple streams of technological advancement — from Web Services to Service-Oriented Architectures (SOA) to microservices, which contributed to the development of the cloud itself.
Industry now had more abstractions than before!
The age of systems: 2000s to today and beyond!
Advances in technology now allow us to apply abstraction at cloud scale! Yes, think of the cloud as an abstraction. It simplifies infrastructure and software by providing a range of services. Serverless, for example, is another layer of abstraction within the cloud.
In a similar way, thanks to the cloud, AI now helps abstract away and automate mundane tasks. As an engineer, you’re getting used to being part of this fast-paced software development cycle.
Despite AI and Agents flooding the industry with new skills and capabilities, are the global problems that rely on software any simpler?
Absolutely not!
We build global systems capable of disrupting everyone, everything, and everywhere. Therefore, Systems Thinking becomes essential for every software engineer.
What is a [Software] System?
According to the renowned systems thinker, Russell L. Ackoff,
A system is a whole that consists of parts, each of which can affect its behavior and properties. The parts are interdependent.
In a city’s transportation system, for example, the roads are one part, not the whole.
Donella Meadows, the author of Thinking in Systems, provides a definition relatable to software.
A system is an interconnected set of elements that is coherently organized to achieve a goal.
A complete definition of a Software System is provided by Diana Montalion in her book Learning Systems Thinking (O’Reilly, 2024).
A system is a group of interrelated hardware, software, people, organization(s), and other elements that interact and/or interdepend to serve a shared purpose.
Software System = Technology + Others!
An important aspect of a system is the consideration and inclusion of the socio-technical elements.
In the transport system example, if you encroach on the pavements, it affects people’s mobility on foot, forcing them to drive or ride, adding more traffic to the roads — an example of how the different elements interdepend and affect each other in a system.
The socio-technical aspects, in my view, are a crucial difference in how software engineers must perceive the systems they help build.
Chip Huyen is one of the celebrated authors of the current AI/ML era, with the hugely popular books AI Engineering (O’Reilly, 2024) and Designing Machine Learning Systems (O’Reilly, 2022). In her ML book, she mentions her systems approach in writing it.
ML systems design takes a systems approach to MLOps, which means that it considers an ML system holistically to ensure that all the components and their stakeholders can work together to satisfy the specified objectives and requirements.
System as an Ecosystem
An ecosystem is a geographic area where plants, animals, and other organisms, as well as weather and landscape, work together to form a bubble of life. — NationalGeographic.org
In nature, an ecosystem contains both living and nonliving parts, also known as factors. Every factor in an ecosystem depends on every other factor, either directly or indirectly. The Earth’s surface consists of a series of connected ecosystems.
In Serverless Development on AWS (O’Reilly, 2024), I used the ecosystem analogy to explain the socio-technical aspects of serverless technology and why engineers should view it as a system rather than merely as an architecture or technology stack.
If it helps, you can think of a software system as an ecosystem. Just as Earth’s diverse ecosystems are interconnected, various global-scale software systems also interact and share information.
The key takeaway to remember is that a few factors or parts, such as platform, code, tests, pipelines, and data, alone won’t make a software system. It has behaviors, influencers, users, and many more.
As Ackoff said, a system is a whole that consists of parts. Therefore, a clear understanding of software systems is an essential trait for every software engineer.
The socio-technical aspects are crucial in how software engineers perceive the systems they help build.
The Indispensable Need For Systems Thinking
Technology evolves.
Industry evolves.
We evolve — so are our needs!
We observe rapid growth in methodologies, frameworks, tools, platforms, services, and related elements. Equally, our reliance on technology has steadily grown, pushing the industry to build increasingly complex systems at a faster pace.
Many of these systems are so complex — non-linear, chaotic, and unpredictable — that they are beyond our comprehension. Yet they function like clockwork (mostly!).
Complexity is a common theme across all systems. It is inherent. We embrace it and live with it. Our body is a prime example of a complex system.
In addition to complexity, there are other reasons why I think engineers require systems thinking, as discussed below.
Modern systems are easy to use but hard to comprehend.
A segmented view of a system by the engineers leaves them vulnerable.
A disruptive force, AI, is infiltrating and shaking the status quo!
1. Easy-to-use systems that are hard to comprehend!
Most modern apps are simple and easy to operate with the touch of a finger, but beneath and beyond the touchscreens lie globally distributed, highly intelligent, and interconnected complex systems.
Whether a glitch in one part of a system can cause the entire system to fail, whether it affects one hundred users or one hundred million users, will demonstrate how deeply systems thinking was incorporated into its design.
Take, for instance, your everyday food-ordering app. So simple and easy to use. But do you ever think about the numerous parts of this system and how tirelessly and collaboratively they work to fulfill your order?
Pause for a few minutes…
Think of-
An autonomous vehicle on a public road.
A highly advanced life-critical health care system.
An interconnected transport network of a metropolitan city.
A global food supply chain.
There are many more.
Just imagine the multitude of parts and intricacies in such systems. Not just building them, but also ensuring safety, compliance, availability, reliability…and their impact.
In March 2026, a media report revealed that for a brief period, some users of an international bank’s app could see other customers’ transactions!
2. A segmented view of a system by the engineers
There’s a well-known story about six people who each felt an elephant in a dark room. Each person’s view was based on the part of the elephant they touched.
The above resembles many software engineers’ partial views of the systems they work on.
Traditionally, we’ve been nurturing engineers to work that way, whether it’s team silos, the promotion of specialists, or constraints on responsibility boundaries.
A QA Engineer only knows how to write tests and run them as part of the CI/CD pipelines.
A Frontend Engineer mainly focuses on user interaction and the aesthetics of a system.
A Java Engineer deeply invested in programming the logic for their microservice.
An SRE (Site Reliability Engineer) only cares about the health of their site!
…and more segmentation exists in today’s organizations.
You are welcome to add to the above list based on your experience!
Disappointingly, many skilled engineers’ knowledge is limited to their codebase or the Git repository. Therefore, their view — and knowledge — of their system is segmented.
Ask them how their code is deployed and operated on the cloud; many have no idea!
Ask them what enables their program to support 10 or 10 million users concurrently. They will point at the SRE!
Ask them why they use a NoSQL database instead of an SQL one (or vice versa). They will tell you to ask the architect!
Ask them about how their API is protected against an army of malicious bots, and they point towards a bunch of folks in a dark corner!
Ask them about the end users of the services they develop, and they will only know about their product managers!
Ask them how the programming language they use or the code they write impacts the sustainability of this world, and they simply stare!
Such engineers are segmented in their views and knowledge; categorized as developers, programmers, or even resources (the term I hate the most).
3. AI is redrawing the responsibility boundaries
When the US government briefly imposed a ban on TikTok, a friend from the tech community commented,
“For the first time, a generation looked up (from their mobile screens)!”
As a software engineer, if you still haven’t caught up with reality, now is the time to look up!
Or, wake up!
The dangerous phrases such as
“We’ve been building systems this way for ages!”
and
“We’ve been doing it this way for decades!”
will no longer come to your defense.
Understandably, teams have specific roles and responsibilities. But what happens if a role changes and the responsibility becomes shared?
Let’s assume that you are a successful QA Engineer. For years, you were responsible for ensuring a zero-defect system. Today, you’ve been asked to share your responsibility with an AI agent specialized in writing and running tests.
What will happen tomorrow — or in the near future — when its AI model learns and improves its success rate? What will be your role then? Why would your company still keep you?
The same is true of numerous coding agents that vomit code (to borrow Dr. Venkat Subramaniam’s old humor) and outperform the best programmers.
As we progress in the industry, the main challenges of building software are no longer just coding but also conceptualizing, architecting, and managing large interconnected systems. In daily life, these are seen as ecosystems of systems — cloud platforms, pipelines, data, AI models, people, and organizations — creating complexity often unseen by coding-focused engineers.
AI adoption is alarmingly on the rise. Yet many engineers are in denial, even as the ground shifts beneath their feet. It’s like we spin every day and travel millions of miles a year with the Earth, yet we remain unobservant of it.
How To Become A Systems Thinker?
Albert Einstein said,
If I had an hour to solve a problem, I would spend 55 minutes thinking about the problem and 5 minutes thinking about the solution.
This is why human value remains relevant in the AI era. The book Intelligent Ignorance echoes this in the following words.
Machines bring speed and scale. Humans bring judgment and heart!
In the words of Gunnar Grosch, a fellow AWS Hero,
If code is cheap, engineering is priceless!
Think and grow as a diverse engineer
When discussing cloud and serverless adoption, I advise creating a growth environment that enables every developer to become a diverse engineer.
Why am I so vocal about it?
As a seasoned engineer with decades of experience building solutions and mentoring other engineers, I’ve observed many excel in or specialize in one area.
be it programming in a particular language as a developer,
writing and running tests as a QA engineer,
handling data storage, pipelines, and queries as a data engineer,
scripting the infrastructure and operating it as a platform engineer,
specializing in protecting the system as a security engineer,
focusing on the application’s well-being as a software reliability engineer,
and so on!
Modern teams that leverage emerging technologies don’t operate in skill silos. The fast pace of technological change doesn’t wait for engineers to be hired and trained in specific areas.
Engineers on an autonomous team share responsibilities. For example, you cannot employ a full-time AI prompter because you wouldn’t be interacting with AI coding tools alone, but also with other aspects, including designing architectural patterns, security principles, data queries, and so on.
This is similar to transitioning from a T-Shaped engineer to a Comb-Shaped engineer that I referred to in the previous article.
Five steps to develop your Systems Thinking
There is no one way to introduce systems thinking to a software engineer. For most, it is a thought process born of experience. Nevertheless, here are five steps to help you.
1. Understand the whole system, not just components or modules
Focus beyond the isolated modules or features you own.
Understand how different parts of the system interact — APIs, data pipelines, user flows, the platform, etc.
Importantly, learn how changes in one part affect the entire system.
2. Identify and map dependencies and feedback loops
Visualize the system with diagrams: data flows, service maps, architecture, sequences, etc.
Pay attention to circular dependencies and their effects.
Understand retry loops, caching strategies, sync and async flows, and how they affect performance.
3. Think of causes and effects over time
Be strategic and consider the long-term outcome.
Avoid quick fixes whenever feasible and think holistically to solve problems.
Develop a mindset to anticipate delayed effects and unintended consequences of an action.
4. Observe and learn from systems behavior
If you can’t measure it, you can’t improve it!
Know how to observe the system’s behavior in the real world through logs, metrics, and traces.
Correlate architectural and design decisions with outcomes such as latency, scaling constraints, error rate, downtime, and user experience.
5. Incorporate non-technical perspectives
Adopt an interdisciplinary perspective with a diverse engineering mindset.
Consider business goals, stakeholders, user behavior, developer experience, and operational constraints.
As a software engineer, collaborate with product managers, analysts, designers, and platform teams to understand how your application fits within a broader ecosystem.
I conclude with a phrase from the book Designing Machine Learning Systems (O’Reilly, 2022).
(ML) Systems aren’t just technical. They involve business decision makers, users, and, of course, developers of the systems.
In the next article, I will discuss Domain Thinking — the organizational pattern every software engineer must know to succeed.