“Simplicity is prerequisite for reliability.” — Edsger W. Dijkstra
Several years back, I worked on a team full of extraordinary people—some of the best I’ve ever worked with. The company was making money, customers were happy, and yet… the best folks were quitting.
Why? It wasn’t that anyone was malicious or incompetent. It was that no one could tell what to do. Smart, principled leaders were pulling in different directions. Their ideas were all reasonable—but they didn’t cohere. There was no shared goal, just a complex tangle of overlapping needs, plans, and incentives. As an advisor told me at the time, a team of leaders works toward a common goal. We just had a collection of them.
The problem wasn’t people. It was complexity.
As leaders, we make decisions that impact our teams, customers, and businesses. We like to think we’re right. But the reality is, we’re only right a lot—not always. That’s Amazon’s leadership principle: leaders “are right, a lot.” Not always. A lot.
Mistakes happen, not just because we lack information, but because many decisions are harder than they need to be. The world is full of unnecessary complexity, and complexity breeds confusion, errors, and slow execution.
This is where Dijkstra’s insight applies: simplicity is a prerequisite for reliability. When we work hard to make simple easy, we reduce the likelihood of making bad decisions.
Why Simplicity Matters for Leaders
We tend to blame bad decisions on poor insight or intelligence. But often, the real culprit is complexity itself—too many interdependencies, unclear priorities, tangled incentives, opaque systems.
Consider Hanlon’s Razor: “Never attribute to malice that which is adequately explained by stupidity.” In an organizational setting, we can take this further: never attribute to individual failure that which is adequately explained by a complex, brittle system.
If we want better decisions across the board, we need to stop expecting people to navigate unnecessary complexity flawlessly. Instead, we should simplify the work itself.
Simple vs. Easy
In software engineering, Rich Hickey’s 2011 talk Simple Made Easy defines three useful distinctions:
Complex: Intertwined, braided together.
Simple: Unmixed, clear separations of responsibility.
Easy: Convenient, nearby, familiar.
We see this in engineering all the time. A well-designed API is simple: it defines responsibilities cleanly and avoids entanglement. A tangled monolith might be “easy” to change at first, but over time, changes become harder, risks grow, and reliability suffers.
The same is true in leadership. If we don’t work to make simple easy, then what’s easy will often be complex. Decisions will be burdened by silos, unclear ownership, and ever-growing dependencies.
How to Make Simple Easy
Here are a few ways I actively simplify.
Clear alignment between customer needs and company goals reduces decision friction.
Product plans that align internal and external incentives simplify trade-offs.
Transparent priorities reduce ambiguity about what matters most.
Financial transparency makes business decisions easier to reason about.
Work-in-progress (WIP) limits prevent tangled, competing efforts.
Vertical slices of work help teams ship focused value instead of sprawling, cross-cutting projects.
APIs (both internal and external) enforce clean separations of responsibility.
Autonomous teams with self-service deployment tools minimize reliance on others to make progress.
Organizing teams around value streams clarifies ownership and accountability.
Using Team Topologies patterns (and related principles) prevents teams from getting stuck in unnecessary dependencies.
Each of these reduces unnecessary complexity. None of them make hard problems disappear, but they help teams focus on the right complexity: the real innovation, the valuable risk, the work that moves the business forward.
Closing Thoughts
I’ve worked in environments with and without these simplifications. No system is perfect, and I’ve never implemented them all at once. But each one has helped make my job simpler—and my team’s decisions more reliable.
When we simplify, we don’t just make life easier. We make organizations smarter. The goal isn’t to remove all complexity, but to eliminate the unnecessary complexity so we can focus on the valuable complexity.
We’ll still trip and fall. But we’ll be “right, a lot” more. And that makes all the difference.
Where do you see complexity creeping in—either in code or collaboration? What’s one place where you’ve made simple easy? I’d love to learn from your examples.
This is my favorite article yet!