Most teams don’t fail because the people are bad.
They fail because the system they’re in makes doing the right thing harder than it should be.
You’ve seen it before. Talented engineers grinding away, frustrated by endless blockers. Architecture that’s more cage than canvas. Leadership that says “go fast” but needs a meeting for every change.
That’s not a team problem. That’s an org design problem.
The API Memo That Changed the Internet
In the early 2000s, Jeff Bezos sent a now-famous internal memo to every team at Amazon:
From now on, you’ll communicate via APIs. No direct calls. No backdoors. No exceptions. And if you don’t do it, you’ll lose your job.
Extreme? Yep. But it worked.
That memo didn’t just reorganise teams — it reshaped Amazon’s sociology. Every team had to act like a service. They had to care about interfaces. Reliability. Ownership. Not because someone told them to — but because the constraint made it the natural path.
That’s an enabling constraint. The kind that opens up options instead of shutting them down.
The Real Job of Tech Leadership
This is what good technical leadership does: it designs the conditions where high performance is not heroic — it’s inevitable.
That’s a sociological shift.
Most organisations, even the well-meaning ones, design for control. They assume that without strong oversight, things will fall apart. So they add gates. Then review boards. Then Jira workflows that need a 12-step approval to change a config value.
Meanwhile, the humans adapt. They stop asking questions. They follow the process, not the problem. They stop believing what they do makes a difference.
And leadership responds not with trust — but with more process.
What Are You Designing For?
Every system has values baked into it — whether you admit it or not.
- A tightly coupled architecture says: “we don’t trust teams to own things end-to-end.”
- A centralised platform says: “it’s faster if we just do it for you.”
- A bloated SDLC says: “something bad happened once, so now no one can move.”
Here’s how that shows up on the ground:
| What the System Says | What the Team Hears |
|---|---|
| 12-step approval for config change | We don’t trust your judgment |
| Centralised deployment gate | You’re not allowed to own delivery |
| Ticket required for every decision | Thinking is not your job |
| Architecture Review Board | Innovation needs permission |
Architecture is anthropology in disguise. It reflects our trust, our fears, our defaults — often more than our intentions.
Enabling vs Constraining
Here’s the real question: are you enabling your teams, or just managing them?
To enable means you:
- Give clear boundaries, then let people run
- Create feedback loops that help teams improve
- Remove friction so doing the right thing is the easiest thing
To constrain (in the bad sense) means you:
- Assume people will fail unless watched
- Add process to compensate for low trust
- Centralise decisions to feel in control
And here’s the part most teams miss: _you’re always designing for something — even when you think you’re not.
Even silence — even inaction — is a design choice.
Two systems. Same goal. One adds friction, the other adds flow.
Why This Matters More Than Ever
We don’t build software the way we did 10 years ago. We work across time zones. We deploy daily. We don’t know what users will want until they tell us. And we deal with complexity you can’t solve through top-down thinking.
That means we have to think differently — not just about code, but about how we work.
Psychologically, people do their best work when they feel trusted, safe, and stretched. Sociologically, teams get better when information flows freely and teams make decisions close to the work. Technically, systems stay healthy when you design for loose coupling, fast feedback, and shared context.
You can’t get any of that if you’re still managing like it’s 1998.
This Series
This post is the first in a series about those invisible forces: the culture, systems, and philosophies that make or break tech teams.
We’ll look at:
- What “enabling” looks like from the trenches — not just exec slides
- How architecture can become a leash or a launchpad
- Why Agile so often gets turned into control theatre
- How systems theory and complexity thinking offer a better playbook
- And how to strike the right balance between freedom and alignment
The goal isn’t to preach. It’s to notice the water we’re swimming in — and give you tools to change it.
Next up: What principal engineers and tech leads actually do when they’re enabling, not just managing.