Systems at Work: Seeing the Levers Behind the Chaos
I'm starting a series that will change how you see the world forever. Learn how systems thinking reveals the hidden forces behind burnout, misalignment, layoffs, and recurring team dysfunction.
I'm starting a series that will change how you see the world forever.
Not in a motivational quote kind of way. In a 'you’ll start noticing invisible machinery everywhere' kind of way.
This won’t be a list of tactics to manage your time better. It won’t be a pep talk about mindset. It’s about systems—the structures, incentives, and defaults that quietly shape your behavior, your team’s behavior, and your organization’s outcomes.
We’ll talk about why problems repeat. Why some people burn out while others seem to navigate the same chaos with clarity. Why change feels hard, and why it often fails. And most importantly, we’ll talk about where the actual leverage is.
Once you start seeing the hidden architecture behind day-to-day chaos, you stop taking things at face value. You stop blaming people for outcomes they never had the power to change. You stop playing whack-a-mole with symptoms—and start redesigning the system itself.
That’s what this series is about.
Your Career Is a System—Start Seeing It That Way
You think you're making decisions. But most of the time, the system has already made them for you.
Let’s take an example:
An engineer, let’s call him Eli, switches teams every 12 months. He joins with energy, ramps up fast, delivers solid work. But by month eight, something shifts—burnout creeps in, politics feel heavier, priorities blur. He starts scanning internal job boards. The cycle repeats.
Is Eli lazy? Misaligned? Lacking grit?
Or is he stuck in a system that produces this pattern?
Systems thinking starts here: behavior is the output of structure.
Not just the organizational system—though that’s part of it. He might also be operating inside a personal system: emotional habits, beliefs about work, fear of conflict, or a need for novelty that quietly nudges him toward restarting every year. These inner systems reinforce the outer ones. Unless both change, the pattern stays. That said, this post will focus primarily on the organizational system—because while personal patterns matter, it’s often the structural design of teams, incentives, and information flow that engineers underestimate the most. Over time in this series, we’ll also explore how systems show up in personal decisions, habits, and relationships—and how redesigning those systems can be just as powerful.
If you don’t change the underlying system, the pattern won’t change—no matter how many books you read, how many habits you build, or how many 1:1s you have.
A Quick Primer on Systems Thinking
Systems thinking is a discipline that originated in fields like ecology, biology, and industrial engineering. One of its most powerful insights is this: we are easily deceived by events. We fixate on what just happened—a missed deadline, a reorg, a surprise outage—without asking what patterns of behavior produced it. And even when we notice patterns, we rarely trace them back to their structural root.
This is where systems thinking—and especially systems dynamics—comes in. It teaches us to stop reacting to symptoms and start investigating the machinery behind them: the incentives, flows, and feedback loops that quietly generate behavior over time.
The field gained traction in the mid-20th century through the work of Jay Forrester at MIT, who developed it to model complex systems like urban growth, supply chains, and economies. Donella Meadows, one of Forrester's students, helped popularize these ideas in a more accessible form—especially through her seminal book Thinking in Systems.
Let’s take a modern example. Imagine a company where every quarter ends in a frantic push to hit targets. Projects are rushed, bugs pile up, and trust erodes. Most leaders respond with tighter deadlines or more reviews. But the underlying structure might be a quarterly goal-setting cycle that creates artificial urgency and rewards last-minute heroics. Until that structure changes, the pattern will persist.
Systems thinking gives you two superpowers: it shows you where to look when things go wrong, and it reveals the highest leverage points for meaningful change.
It’s a lens that applies everywhere: in ecosystems, in global trade, in healthcare—and yes, in your engineering career. Even in personal life and relationships, systems thinking helps you understand repeated conflicts, emotional patterns, or communication breakdowns. Instead of blaming moments or personalities, you start asking: what structures are reinforcing this behavior? Who has access to what information? What norms or defaults are shaping these interactions? The same principles—flows, buffers, feedback loops—apply. The same leverage points exist.
Now let’s look at the foundational elements that shape every system:
Systems: The Lens Most People Never Learn to See
A system is a set of interconnected parts that produce a pattern of behavior over time. That might sound abstract, but you’re living in one right now: your org chart, your product roadmap, your sprint cycles, your performance review process—these aren’t just tools or workflows. They are feedback loops with built-in incentives, constraints, and defaults.
Still abstract? Let’s zoom out.
Take traffic congestion. You’re sitting in gridlock on a freeway, frustrated. Most people blame the other drivers, or construction, or poor signaling. But the deeper cause is systemic: a mismatch between road capacity, zoning laws that separate jobs from housing, incentives that subsidize car ownership, and a lack of investment in public transit. Until those structural forces change, traffic will behave exactly as designed: clogged.
Or look at obesity in modern societies. It’s tempting to blame individual choices. But the system behind it includes food subsidies that make processed calories cheaper than vegetables, city designs that discourage walking, marketing campaigns pushing sugar, and work cultures that reward sedentary habits. Again, structure produces behavior.
These systems are shaped by three key dynamics that Donella Meadows often emphasized:
Flows
The movement of resources, information, or energy through a system is called flow. In traffic systems, the flow is cars; in tech systems, it’s information or decision-making. Think of flows like water in pipes that feed into or drain from a container—that container is your buffer (e.g., a backlog).
Inflows are what enter the system: bug reports, feature requests, customer feedback, new ideas. They fill the buffer, just like water fills a pool.
Outflows are what leave the system: completed features, resolved bugs, shipped updates. These are the items that have made it through the team and exit the buffer.
If the inflow is too strong—say, too many bugs due to weak QA—then the buffer (your backlog) overfills. That’s like turning the valve wide open. Conversely, stronger QA tightens the valve, reducing the number of issues flowing into the backlog.
But it doesn’t end there. Tuning inflows (e.g., by improving QA or filtering what enters the system) often affects outflows too. If upstream teams slow down to ensure quality, the system might deliver fewer items per sprint. On the flip side, speeding up inflow without increasing outflow capacity leads to bottlenecks and stress.
This is the heart of systems thinking: every flow—whether information, decisions, or tasks—has consequences. You can't tighten one valve without pressure building elsewhere. Unclear routing, ambiguous ownership, or blocked communication act like clogs in the pipes, choking flow and damaging the entire system.
But when you improve the flow—by making it smoother (less friction), clearer (less ambiguity), and better controlled (right pacing and direction)—you can dramatically increase team output without hiring new people, restructuring teams, or working longer hours.
Why? Because in many systems, the problem isn't the people—it's the system of movement. Engineers waste time waiting on unclear decisions, reworking due to vague specs, chasing down information, or switching context because priorities shift too often. These are flow inefficiencies, not skill gaps.
When you fix the flow:
Decisions reach the right people faster
Tasks move smoothly from design to dev to QA to prod
Context is preserved, reducing misunderstandings and rework
Backlogs stay healthy and actionable instead of bloated and stale
Work becomes more predictable and less frustrating
In short, flow improvements unlock latent potential. It’s like fixing the plumbing in a house—suddenly everything works better, not because you bought new appliances, but because the water actually gets where it’s needed.
This is the hidden power of systems thinking: you can amplify results not by pushing harder, but by unblocking what’s already trying to move.
Buffers
Buffers are shock absorbers that stabilize systems—like extra food in your pantry, or a backlog of user stories. Buffers make systems more resilient by absorbing volatility. For instance, when there's a sudden spike in the number of incoming tickets, they don’t immediately hit the engineers. Instead, they land in the backlog where they can be triaged and prioritized. This prevents the team from being overwhelmed and keeps them focused on high-leverage work. In this way, the buffer absorbs the shock of unpredictability.
But buffers come with a tradeoff. Too much buffering—like an ever-growing bug backlog or feature queue—can make a system sluggish and unresponsive. A healthy buffer gives you time to react. An overloaded one hides the signal until it’s too late.
Feedback Loops
Feedback is often what people observe when they look at a buffer. For example, if someone looks at the backlog and sees more bugs than feature requests, that observation becomes a form of feedback. The observer might act on that signal—perhaps by introducing more thorough QA processes—which, in turn, alters the flow of bug tickets into the system. This is how feedback closes the loop and changes system behavior over time.
These loops come in two primary types.
This kind of feedback loop can take two primary forms: reinforcing or balancing.
Let’s revisit the backlog example. When someone notices that the number of bugs in the backlog exceeds feature requests, they might respond by tightening QA processes. That action reduces the number of bugs entering the system—a balancing loop, since the system is nudging itself back toward stability. But if that signal is ignored, or the response is poorly implemented, it could do the opposite—let bugs continue piling up, team morale dips, and pressure increases to rush deliveries, causing even more bugs. That’s a reinforcing loop: the system feeds on its own output, amplifying the original issue.
Reinforcing loops (positive feedback) create growth or escalation—like virality in a social network, or compounding interest in finance. These loops amplify change, often leading to runaway effects unless something counteracts them. For instance, a team known for fast execution may get more urgent work assigned to it, which leads to burnout, which then affects execution quality, prompting more scrutiny and more pressure—fueling the loop further.
Balancing loops (negative feedback), by contrast, create stability. They act like brakes to maintain equilibrium—like a thermostat keeping room temperature steady, or a code review process that prevents poor-quality code from reaching production. These loops dampen deviation and help a system self-correct.
These three elements explain why systems behave the way they do. Most systems that feel chaotic aren’t broken—they’re just playing out the logic of their flows, buffers, and loops.
In each case, the outcomes we experience are not random. They are engineered—intentionally or not—by the system’s design.
Events vs. Structures
Here’s what makes systems thinking so powerful—and so neglected: most people focus on events, not structures.
Someone quits → we do an exit interview.
A team misses a deadline → we add more process.
A service goes down → we file a postmortem.
We try to patch the visible symptom without ever seeing the deeper structure creating it. But behavior doesn’t emerge from nowhere. It’s the visible trace of an invisible architecture: the flows of information, the incentives baked into reviews, the way teams are siloed or resourced.
Take the service outage. The root behavior might be engineers skipping key monitoring steps. Why? Because the review process rewards speed over thoroughness. Because monitoring ownership is fragmented. Because the incident never reached leadership’s radar last time. The behavior isn’t the problem. It’s the output.
That’s why problems repeat. Not because people don’t care—but because the system doesn’t.
Systems thinking teaches you to ask:
What’s driving this behavior?
What loop is being reinforced here?
What part of the structure is invisible—but crucial?
In other words: stop playing whack-a-mole. Start mapping the machine.
Let’s take a simpler, more personal example: your kitchen pantry. Suppose it’s designed in a way that makes it hard to put items back where they belong—deep shelves, no clear labeling, containers that don’t fit together. If you're rushing out the door in the morning, you're more likely to shove things wherever there's space. Over time, the pantry gets messy. But the mess isn’t about your habits—it’s the output of a system designed for disorder under time pressure.
Now imagine redesigning the pantry: shallow shelves, clear labels, and dedicated bins. Suddenly, even rushed mornings produce less chaos. That’s the power of structure. The behavior didn’t change because you suddenly became more disciplined—it changed because the system made the desired behavior easier.
The same is true in engineering teams, product orgs, or leadership culture. You can’t coach your way out of a badly designed pantry. You redesign the pantry.
Layoffs: A Familiar Event, A Deeper Pattern
Let’s take a more recent issue we’ve all grown far too familiar with: layoffs.
They feel sudden. Personal. Unfair. And the way they’re often communicated—“realignment,” “macroeconomic conditions,” “reprioritization”—makes them sound like isolated responses to bad luck.
But layoffs aren’t new. They’re a well-established behavior of a particular system structure.
In financialized capitalism, companies are rewarded not for long-term resilience, but for short-term stock performance. Hiring booms are driven by growth-at-all-costs goals, and when the market shifts, the same system demands aggressive cost-cutting to restore margin and investor confidence. Layoffs become a signal—not just a necessity.
This behavior is reinforced by:
Quarterly earnings pressures
Competitive benchmarking (“Company X cut 10%, we should too”)
Managerial incentives tied to profitability metrics
Even profitable companies do it. Because the structure makes it make sense.
You can swap the CEO. You can run town halls about “culture.” But until the upstream drivers change, the pattern won’t.
Layoffs are not random events. They’re the output of a system’s logic—predictable, repeatable, and invisible to those who only look at the surface.
And this isn’t a modern invention. Here are some numbers to show how structural this pattern has always been, and they are a few from many:
In the 1980s, roughly 20 million full-time workers reported losing jobs because their employers either went out of business or laid them off and had not recalled them over a year later (https://www.cbo.gov/sites/default/files/103rd-congress-1993-1994/reports/93doc09.pdf)
In the early 1990s, IBM laid off over 60,000 employees (source: https://www.forbes.com/sites/maryroeloffs/2025/02/07/at-least-65000-workers-accept-trumps-buyout-now-the-biggest-job-cut-in-us-history/) after decades of offering “lifetime employment.”
Ford laid off 35,000 people in 2002 (and announced another 30,000 job cuts in 2006). Source: https://www.forbes.com/sites/maryroeloffs/2025/02/07/at-least-65000-workers-accept-trumps-buyout-now-the-biggest-job-cut-in-us-history/
In the 1996, AT&T laid off 40,000 employees (source: https://www.nytimes.com/1996/01/03/business/job-cuts-at-at-t-will-total-40000-13-of-its-staff.html)
In the 1990s, HP cut more than 2500 jobs (source: https://www.nytimes.com/1998/10/03/business/company-news-hewlett-packard-to-cut-about-2500-jobs.html)
After the 2000 dot-com crash, over 2 million tech jobs vanished (source: https://sfist.com/2022/11/10/throwback-thursday-the-last-big-tech-layoff-bloodbath-the-dot-com-bust-of-2000-2001/) as companies like Cisco, Intel, and Oracle implemented sweeping reductions.
In 2022–2023, more than 300,000 tech workers were laid off (source: https://layoffs.fyi/), including mass cuts at Amazon, Meta, Microsoft, and Google.
And more https://archive.nytimes.com/www.nytimes.com/specials/downsize/large-graphic.html
These were not the anomalies. They were the pattern. So when we romanticize the "good old days" as if layoffs were rare or avoidable, we overlook the fact that this behavior has been structurally baked into the system for decades. If you've never personally seen layoffs, or believe things used to be better, think again. The structure didn’t just emerge recently—it’s been quietly shaping outcomes for over forty years.
Why Systems Thinking Matters in Your Career
Most engineers try to fix problems at the wrong layer.
They:
Burn out, then try meditation apps.
Feel lost, then switch teams.
Struggle with alignment, then ask for clearer OKRs.
These are tweaks to parameters—not interventions in the system.
In 1999, systems theorist Donella Meadows outlined 12 leverage points—places you can intervene in a system to create real change. Most people fiddle with the bottom of the list: effort, metrics, tools. But the top of the list? That’s where the power is.
Things like:
The goals of the system
The rules of the game
The flows of information
The mindset from which the system arises
These are invisible. But they explain everything.
A New Lens for Engineers
You're not just writing code.
You're operating within a set of constraints, incentives, defaults, and feedback loops that shape what you do and how you think.
Start asking:
Who defines success here?
What behaviors are rewarded? What gets ignored?
Who has visibility into what?
What can be changed—and what feels untouchable?
Once you ask those questions, you start seeing where the real levers are.
The Point of This Series
This isn’t another post about productivity hacks or mindset shifts.
This is about leverage.
In the next few posts, we’ll walk through some of Meadows’ highest-impact leverage points and show how they play out in engineering teams:
Misaligned goals that burn people out
Information asymmetries that erode trust
Rules and roles that entrench dysfunction
Paradigms that silently shape your org’s reality
Each post will show you:
How these dynamics play out in real engineering settings
Why conventional advice fails
Where the actual leverage is
What if the most powerful lever wasn’t your skills, but the goals of the system you’re inside?
Flows, buffers, and feedback loops help us see the system’s engine. But if you want to change where it’s going, you need to look at the goals it's chasing—and who set them.
See you in Part 2: The Invisible Goal: Why Your Work Feels Misaligned.
