Inspired by the insights of Donella Meadows: “Every system is perfectly designed to get the results it gets.”
Last time I wrote about the wake we hold for projects that never ship. This is part two: not another obituary, but an attempt to understand why the industry returns, again and again, to the same scenes of collapse.
If the problem were simply “not enough tools,” then this last decade of unprecedented abundance should have been our golden age. Instead, we have normalized the pivot, industrialized the rewrite, and quietly accepted a degree of chaos that would be unthinkable in any other field claiming to operate on reason. The deeper problem is not an absence of tools. It is an absence of systems. And the evidence has been in front of us all along.
I have spent enough years inside technology teams to recognize the pattern long before it fully unravels. At first, everything looks promising: a compelling idea, a motivated team, a founder confident that this time the process will be different. I entered as a product designer, but inevitably I became an unofficial custodian of systems: untangling workflows, clarifying responsibilities, mapping decision paths that no one had time to define. I have come to understand that most teams do not fail because they lack talent or ambition, but because they are quietly held hostage by the absence of structure.
One project in particular has stayed with me. It had all the elements of success, a visionary CEO, a talented CTO, and a team genuinely eager to build something meaningful. Early on, I warned that unless the delivery system, how features actually traveled from idea to implementation, was rebuilt, the final weeks would buckle under their own weight. Everyone nodded politely, but nothing changed. The CEO placed his faith in his management team. As the release date crept closer, optimism calcified into denial. Seven days before launch, the CEO and the investors finally saw what the system had been whispering for months: the product was nowhere near ready, and postponing was no longer an option. The project didn’t fail because the people failed. It failed because the system that should have supported them never existed.
This story is not unique. It repeats itself across industries, across funding rounds, across continents. And it is echoed in the data: the Standish Group’s CHAOS Report continues to show that only 31% of technology projects succeed, a number that has barely moved in two decades, despite the explosion of tools, frameworks, and methodologies. The 2025 DORA Report adds another layer: organizations that rush to adopt AI without addressing foundational process debt simply accelerate dysfunction. AI magnifies the system it is placed inside; it does not correct it.
Meanwhile, the market offers its own parables. Think of the companies forced into costly rewrites because their front-end architecture was tightly tied to a single framework. The shift from Vue 2 to Vue 3 left many teams facing months of re-engineering, not because their ideas were flawed, but because their systems were brittle. Tools had been treated as the foundation rather than what they truly are, secondary actors in a much larger design.
Across my career I have seen the same divide: the teams that struggle improvise their way through complexity, hoping a new tool or a clever AI workflow will save them; the teams that succeed build systems: clear processes, composable structures, and sustainable rhythms that protect them from chaos. They understand that clarity is not rigidity, and that structure, far from limiting creativity, is what allows it to flourish.
It was through observing this divide that I began to ask a question that eventually shaped both this article and the platform we are building: what if we could give teams the ability to build software for longevity? What if we could combine process design, systemic thinking, and a composable, framework-agnostic front-end foundation capable of surviving the next migration, the next rewrite, the next wave of technological hype?
This article is the beginning of that exploration. It is an argument for returning to systems thinking as the missing discipline in software. It is a reminder that our industry does not need more tools, it needs a way of working that makes tools relevant. And it is an invitation to imagine what might be possible if we built not just products, but the systems that allow them, and the people behind them, to endure.
"Every system is perfectly designed to get the results it gets"
Donella Meadows’ insight is unsettling precisely because it refuses to blame individuals. If a team repeatedly ships late, burns out, or produces brittle architecture, the problem is not effort or talent. The problem is the system doing exactly what it was built to do, often unintentionally.
Technology loves to worship speed. But most of what we call speed is simply an attempt to outrun the consequences of structural neglect. Innovation becomes a workaround for missing processes. The modern MVP becomes an apology for having had no time to think. And the industry, flush with tools, continues to confuse motion with progress.
The truth is simpler: Tools amplify patterns. Systems create them.
And when the system is noisy, unstructured, or reactive, the tools inherit that character. Developers feel this most acutely. PMs inherit it. Founders finance it. None of them choose it. What they inherit is the system, or the absence of one.
The loop that runs the industry
Anyone who has spent time inside a product team can spot the loop almost immediately. Discovery shrinks because everyone is racing to “show progress.” Documentation is deferred with the optimistic promise that “we’ll remember.” Testing is sacrificed to the altar of a fixed deadline. Something brittle ships, collapses under real conditions, and the next few months are spent repairing what haste has broken. Then the whole cycle begins again, unchanged, as if it were a ritual rather than a mistake. This isn’t incompetence. It’s choreography, an unwritten pattern the industry follows even when it knows the steps lead nowhere.
And scale offers no immunity. Startups sprint into the loop because they feel they have no choice. Scaleups inherit it as institutional muscle memory. Enterprises perform it with more dashboards, more meetings, and more expensive autopsies.
History is full of reminders. Healthcare.gov’s disastrous launch wasn’t a failure of engineering talent but of coordination, too many parts moving without a shared rhythm. Google Wave didn’t fold because the idea was weak, it folded because the system around it never established a purpose or a feedback loop. Even Apple, the patron saint of precision, stumbled with the first version of Apple Maps. The problem wasn’t aesthetics. It was the absence of the organizational scaffolding required to build a living, breathing map of the world.
And then there’s Silicon Valley, the satire that lands because it’s barely satire at all. Many teams operate exactly like that: panic performing as productivity, decisions made by proximity or volume, heroics standing in for structure. The comedy is funny only because it’s true.
The 2025 DORA Report finally states what many people have whispered for years: AI doesn’t fix a broken system. It accelerates it. Strong systems become stronger. Weak ones unravel faster. Attaching AI to a disorganized workflow is not strategy. It’s propulsion without navigation. A motor on a boat that has long since lost its compass.
The paradox of abundance
We live in an era of technological plenty. For every task, there is a platform, for every uncertainty, a dashboard, for every hesitation, an AI promising to think ahead for us. And yet this abundance has not made our work clearer. It has fractured it.
Teams jump between half a dozen tools just to understand the status of a single feature. Documentation is scattered across platforms like debris after a storm. Framework debates consume more collective energy than defining what “done” even means. The more tools we adopt, the thinner our attention becomes, until the workflow resembles a museum of overlapping interfaces, each confident it will bring order, none capable of it alone. Because tools were never meant to organize us. They were meant to assist us. Without a system beneath them, they simply move the chaos to prettier screens.
The work that actually holds teams together, steady discovery, thoughtful decisions, clear communication, testing that isn’t a fire drill, quietly dissolves. The result is a paradox familiar to anyone in tech: we have never had more tools, and yet the work has never felt more scattered.
What systems actually are and why they matter
Strip away the corporate language and systems turn out to be simple, almost domestic things. They are the rhythms a team returns to, the boundaries that protect focus, the pathways through which an idea becomes real. They are habits, not software.
In well-run teams, these habits accumulate into an environment where excellence feels natural. Decisions flow in a straight line. Ownership is clear. Work moves without fanfare. No one needs to become a hero to keep the lights on.
In struggling teams, the opposite happens. Confusion becomes the background noise. MVPs are built like emergency shelters. Knowledge lives in private chats and half-remembered conversations. A small group of overworked engineers carries the entire operation on their backs. The system isn’t broken, it simply doesn’t exist.
Both teams may use the same stack, the same frameworks, the same collaboration tools. What separates them isn’t talent. It is the world around the work. And this is the quiet truth the industry rarely states plainly: when you build software, you are also building the conditions under which you will work. If those conditions are chaotic, your product will inherit the chaos. If they are coherent, the work gains a kind of calm momentum.
Toward a systemic way of working
Systems thinking sounds abstract until you realize it is simply the discipline of noticing what keeps happening, and asking why.
Developers see it in the bugs that return every sprint, in the handoffs that create more questions than answers. Product managers see it in shifting priorities that collapse their timelines. Founders see it in the surprise delays that arrive like clockwork. These patterns persist not because people are careless, but because the structure permits, sometimes even reward, them.
The shift begins with small, almost unglamorous acts: deciding what “ready” truly means, giving every decision a home, agreeing on a cadence that isn’t ceremonial but genuinely stabilizing. A system is born not from grand frameworks but from modest agreements honored consistently.
This is why companies known for shipping well, Netflix, Shopify, even Apple at its best, invest so heavily in the invisible scaffolding: conventions, shared languages, internal tooling with guardrails, design systems that prevent entropy, platform teams that think in decades, not quarters. Stability is not a constraint, it is an accelerant.
And it is why Steve Jobs’s famous line, “Design is how it works”, is so often misunderstood. He was not talking about aesthetics. He was talking about systems: the hidden logic that allows thousands of small decisions to cohere.
The beginning of a shift
This is not an argument against tools. It is an argument for something older and more durable than tools: the structure that makes tools meaningful.
Teams that endure, through market shocks, leadership changes, rewrites, migrations, are the ones that treat systems as infrastructure, not afterthought. They understand that clarity is not bureaucracy, that rhythm is not rigidity, and that freedom is not the absence of structure but the result of it.
Good teams build products. Great teams build the systems that allow those products, and the people behind them, to thrive.
References:
“Thinking in Systems” Donella H. Meadows
“Team Topologies” Matthew Skelton & Manuel Pais
CHAOS Report 2020, Standish Group
DORA 2025: State of DevOps, Google Cloud.
GitLab Global DevSecOps Report 2024, GitLab
Stack Overflow Developer Survey 2024, Stack Overflow
“The Hidden Costs of Technical Debt” 2024, Harvard Business Review
