The change that takes you down is rarely the one you were worried about.
I've seen versions of this story more than once. It is the dependency upgrade that should have been boring. It passed code review, it passed the test suite, and it shipped on a quiet afternoon behind a routine change ticket. Then a connection pool that nobody had thought about in years exhausted itself under real traffic, a retry storm turned a small hiccup into a brownout, and a few lines of changed configuration took down checkout for the better part of an hour.
A postmortem like that can end where most of them do, with a note about the connection pool and a promise to be more careful. The better teams, or at least the teams trying to learn honestly, end it somewhere more useful. If a routine upgrade could do that, the system was telling them they didn't understand how it behaved under stress. So they start breaking it on purpose: injecting the failures they fear into safe environments, running chaos tests until the way the system behaves under pressure is something they have observed rather than something they assume. An organization reaches that fork every time it learns something expensive, and the answer it gives, over and over, is often what separates a company that compounds from one that just accumulates scar tissue.
Most enterprises say they want to move faster. Far fewer are honest about what's slowing them down.
The drag is the accumulated weight of modern engineering itself rather than one tool, one platform, one architecture decision, or one team you could point to and fix: cloud complexity, security requirements, cost pressure, legacy systems, regulatory expectations, AI upheaval, funding models, decision rights, handoffs, and the stubborn human reality of how work gets done. That last part is the one we like to understate.
A modern technology organization is a living system. It carries history and risk, along with old decisions that made sense at the time and new ones that haven't proved themselves yet. It also carries platforms, vendors, operating models, compliance obligations, budget cycles, and talent constraints, and none of it arrives in neat sequence. So when someone tells me, "We just need to simplify," I usually agree with the intent and push back on the framing.
That lesson took me a while to learn. Earlier in my career, I treated simplification like the destination: fewer tools, fewer paths, fewer exceptions. Those things can help, but they aren't enough by themselves. A simple system that ignores how the business works doesn't stay simple for long; it moves the complexity somewhere less visible, usually onto the people least able to absorb it. The goal is to make that complexity usable, and that's what I mean by turning complexity into leverage.
Complexity is inevitable
Some complexity exists because the business is genuinely complex. A large enterprise has real obligations. It needs resilience and security, auditability and cost discipline, and systems that can survive failure, scale under demand, and protect a kind of customer trust that takes years to earn and minutes to lose. That complexity is the price of operating at scale, and trying to wish it away is how you end up with systems that are simple and wrong.
Other complexity is self-inflicted. Too many bespoke solutions, too many one-off patterns, too many decisions trapped in meetings, too many teams quietly solving the same problem in slightly different ways. Too many temporary exceptions that live long enough to start collecting furniture.
That is where complexity stops being the cost of scale and turns into drag. Drag is what you get when teams have to rediscover the same lesson alone, when security shows up as a late-stage review instead of a default path, and when cloud cost becomes visible only after the bill arrives. It's what you get when delivery depends on a few heroic people who know where the bodies are buried, which scripts still work, and which Slack channel has the real answer. That is institutional archaeology where leverage should be, and while archaeology is fascinating, it is not a delivery model.
Drag is optional
Whether complexity slows an organization down comes down to one decision: what kind of complexity are you willing to live with? Because there is a real difference between complexity that creates capability and complexity that creates confusion. A well-designed cloud platform is complicated underneath and makes life simpler for the teams building on top of it. A strong CI/CD system has a lot of moving parts and turns release risk into repeatable flow, and a good operating model uses its structure to clarify decision rights instead of adding one more committee to the calendar. So the problem was never complexity itself, only the unmanaged, unowned kind that leaks upward and sideways and outward until too many teams are paying the tax.
And that tax compounds. A team waits for an environment, a release waits for an approval, and a security question waits for someone to interpret it. Meanwhile a cost spike waits for someone to notice, an architecture decision waits for the right forum, and a production incident waits for the one person who still remembers how the system really works. Each delay, on its own, looks perfectly explainable. Taken together, they quietly become the actual operating system of the company.
This is why the bottleneck is rarely the stack. The bottleneck is the system around the stack.
Leverage is designed
Leverage shows up only when a platform encodes hard-won lessons into defaults that other teams can reuse without paying for the lesson themselves. A platform is an opinionated system of defaults that helps people make better decisions without asking every person to rediscover the same lesson alone. It says: here is the path we trust, here are the guardrails, here is what we already learned so you don't have to learn it the expensive way. That's the shift. Good platforms turn recurring problems into reusable capability. Good operating models turn ambiguity into ownership, good automation turns toil into flow, and good governance turns risk management into a system instead of a scavenger hunt. Good leadership turns intent into something people can act on without needing a meeting every time the work gets real.
None of this makes the work magically easier, but it stops the organization from forcing every team to carry the full cognitive load of the enterprise. The platform carries some of that load, the defaults carry some, and the operating model, the culture, and the durable artifacts carry the rest. When those systems work together, a team can move quickly without having to pretend the risk isn't real.
The thesis
A platform is an opinionated system of defaults that helps people make better
decisions without asking every person to rediscover the same lesson alone.
Platforms are how organizations remember
One of the most valuable things a platform does is help an organization remember. Every incident teaches something, and so does every migration, every audit finding, every cost surprise, every deployment failure, and every production recovery at two in the morning. The only question is whether that lesson becomes institutional memory or just another war story told by the people who happened to live through it. Organizations under pressure often rely too much on the people who remember. Better ones try to encode what they learned into systems, so the memory outlasts any individual.
Chaos testing is the loud version of that. You turn a someday-failure into a rehearsal, so resilience stops depending on whether the person on call happens to remember. Most of the time the encoding is quieter. It's a default that makes the wrong move difficult, a check that runs before anyone has to remember to run it, a guardrail that holds whether or not anyone has seen this particular failure before.
That can sound mechanical, but it's deeply human. Encoded memory protects teams from having to be perfect and lowers the bill for heroics. It makes good decisions easier to repeat, and it hands a newer engineer the hard-won judgment of people they may never meet.
This is one reason I care so much about platform engineering. At its best, a platform is empathy, encoded. It says: we know this is hard, we know the enterprise has constraints, we know you're trying to ship, so we built a path that carries more of the complexity for you. Good internal platforms absorb complexity so product teams can spend their energy on customers and business outcomes instead. They make responsibility easier to exercise well, and they leave it with the team.
AI raises the stakes
AI raises the stakes on all of this. There is a tempting story going around that AI is about to strip enormous amounts of complexity out of software delivery. In places, it will. It already accelerates coding, summarization, analysis, testing, documentation, support, and migration work in ways that feel significant on a good day.
But AI introduces its own kind of complexity, and we should be honest about that too. More output does not automatically mean more progress, and more generated code does not mean better systems. More agents don't mean more accountability either, because accountability lives in the team or the platform that owns the work. A faster path to a pull request does nothing to fix unclear intent, unclear ownership, shaky architecture, or a missing feedback loop. If anything, AI makes those weaknesses louder, because the system around the work now has to keep up with a much faster source of change.
I've watched an agent hand me a clean, confident, well-tested pull request that solved the wrong problem. The code was not the issue. The frame was. When generation gets that cheap, the scarce thing is no longer typing the code. It is the judgment that decides whether the work should ship at all, and the only way that judgment scales is to make it explicit and verifiable: written specs the agent works against, evaluation gates that run before anything merges, and a versioned spec that travels with the work instead of living in a hallway conversation. That's the part the demos skip.
So AI raises the premium on engineering leadership. The organizations that get durable value from AI will pair it with clearer intent, stronger platforms, real verification, and an operating model that can absorb the new speed without losing the thread, rather than bolting it onto a messy delivery system and hoping. AI changes the economics of creation without repealing the need for trust.
The leadership work is making leverage repeatable
This is also why technology leadership is mostly about systems rather than tools. Tools matter, and so do architecture, vendors, and talent, but the job of leadership is turning all of it into a system that helps people make better decisions, over and over, without a meeting each time.
That means asking a different set of questions. What decisions does this platform take off teams' plates? Can we deploy fast with the controls, observability, and rollback paths that let us sleep? Where does AI improve flow, and where does it demand stronger verification? And is ownership clear enough that work can move without a meeting to interpret the org chart?
That last one matters more than it looks. Heroics are inspiring in the moment, and they're also a tell. When delivery depends too heavily on exceptional effort, tribal knowledge, or a few indispensable people, you're getting outcomes without getting leverage. Leverage is what you have when the system itself got better because someone did the hard work once and encoded what they learned, so the next team inherits the judgment instead of repeating the struggle. The human goal is to build systems that let talented people spend less energy navigating avoidable friction and more energy doing the work only they can do, without asking them to carry more to get there.
In practice, turning complexity into leverage is a set of specific, unglamorous moves:
- Build paved roads for the common patterns. Make the well-supported path the obvious one, so teams opt into your best thinking by default instead of reinventing it.
- Make the secure default easier than the custom exception. Security wins when the safe path is also the path of least resistance, not a gate bolted on at the end.
- Give teams cost visibility early enough to act on it. I've seen focused FinOps work materially change the shape of a cloud bill, and the bigger win was making the number show up while the decision was still being made. A surprise on the monthly bill is a postmortem. A number in the pull request is a decision.
- Make small, frequent changes the safe ones. Deployment systems should reward shipping in small increments, because that's what makes rollback boring and risk legible.
- Reduce handoffs by clarifying decision rights. Most delay is waiting for someone to be allowed to decide.
- Treat documentation, architecture records, specs, tests, runbooks, and dashboards as durable artifacts rather than administrative residue. They're how the judgment survives the people who created it.
- Measure platforms by adoption, friction removed, reliability gained, cost avoided, and confidence built. If the scorecard only counts what you launched, you'll keep launching things nobody adopts.
The throughline is leadership that understands the technical system and the human system at the same time. In a modern enterprise, those were never two separate systems, and they shape each other every single day.
The real goal
Notice that the goal here was never simplicity for its own sake. Simple can be good, and simple can also be naive, the kind of clean diagram that quietly ignores how the business works.
The real goal is clarity: clarity of intent, of ownership, of the path, of the tradeoffs, and of how the work turns into value. Clarity is what makes complexity navigable. That is how an organization moves faster without getting reckless, and how teams scale without drowning in coordination. It's also how engineering stops being a translation layer between strategy and systems and starts being the thing that accelerates the business.
Complexity is inevitable. Drag is optional. Leverage is designed.
Every serious technology organization is going to face complexity, and the only real question is what it does with it. Shaping complexity into leverage is harder and more useful than chasing simplicity as an aesthetic or wearing complexity as a badge of sophistication, and it's the work I keep coming back to. Because the engineering organizations I respect most do not win by pretending their systems are simple. They win by building systems that let people do genuinely complex work, well.
