There’s a sign I remember from a small shop somewhere in Italy. It says: pick two between quality, speed, and cost. Good and fast? Expensive. Good and cheap? Takes time. Fast and cheap? It’ll be shit.
It’s kind of a joke, but it’s not wrong. The shopkeeper wants you to know that if you insist on getting something right now and pay pennies for it, you should go get it on Temu or something, and accept the quality you can get there.
There’s a theorem in distributed systems called CAP. It says a distributed system can only guarantee two of three properties: Consistency (all nodes see the same data), Availability (every request gets a response), and Partition Tolerance (the system keeps working when network links fail).
This isn’t a limitation of current technology. It’s been mathematically proven. You can’t engineer around it.
And at some point I realised that teams work exactly the same way.
Teams are distributed systems
If you think about it, a team is a distributed system: It’s a bunch of nodes (people) exchanging information. Each node person, makes local decisions based on whatever they knows. Sometimes the network fails: different time zones, someone’s on holiday, two groups don’t talk to each other, or there’s just too much happening for everyone to stay synced.
Same mechanics, same constraints.
Consistency in teams is alignment. Everyone has the same information, the same mental model. Ask two people the same question, get the same answer.
Availability is responsiveness. Decisions happen without waiting. No blocking on approvals or syncs. Anyone can be on holiday and work continues.
Partition Tolerance means functioning when people can’t communicate in real-time. Remote work, different time zones, different floors, different shifts.
The CAP theorem says you can only have two at the same time.
Pick your poison
Here’s what I keep seeing. Someone says: “We want to be distributed AND fast AND aligned.” And I get it, it sounds great. But I think it’s denial.
I think you should explicitly name the property you decide to sacrifice, and optimise for it. That way, you can adapt your flow, culture, and systems to compensate for the gap.
We need better alignment.
No, you designed a distributed team that delivers fast. Alignment is the cost. This is Amazon, or was Amazon a while back maybe. Amazon is a huge company distributed across 6 continents. They deliver super quickly.
They do that by giving each team full ownership of a specific thing, and letting them figure it out completely independently.
One of Amazon’s quips is “two is greater than zero, one is greater than two.” That means that you could have two (or more) teams building a solution to the same problem, completely misaligned, and that’s ok. You then have a natural selection process that selects the best one solution.
Why is everything so slow?"
Because you’ve chosen alignment and distribution. Responsiveness is the cost. You have a split team across multiple geographies, and for whatever reason, you need everyone to be on the same page. This requires oversight, approvals, bureaucracy. This is how large corporations work, or governments.
Why does everything fall apart when I’m away?
Because you’ve chosen speed and alignment by keeping everyone tightly connected. This works because we’re all around the same table. Partition tolerance is the cost.
Startups typically fall into this category. When you start a company, it’s a few very focused people changing the world. You’re super aligned. You are responsive as fuck. But you need to be in the same room.
As your startup grows, you hire more people, and the risk of partitioning the team increases. At some point, it won’t work anymore, and you will split the team somehow.
Either accept that and stay small, or change your other choices.
The tradeoff is physics. The problem is pretending it doesn’t exist.
Spotting which lie you’re telling
“Let’s schedule a meeting to discuss.” “Who needs to sign off on this?” “We can’t decide until Sarah’s back.”
If this is your team, you’ve sacrificed Availability. Decisions queue up. There’s always one more person who needs to weigh in. That’s fine, you’re aligned and can handle distribution. But call it what it is.
“Wait, they built that too?” “That’s not how we do things” (but it is, somewhere). Three teams solving the same problem three different ways.
You’ve sacrificed Consistency. You’re fast and can handle partitions, but you’re drifting. That’s a valid choice, just know that’s what you’re doing.
“I didn’t know that was happening.” “Why did no one tell me?” Everything falls apart when key people are unavailable.
You’ve sacrificed Partition Tolerance. You’re fast and aligned, but only when everyone’s in the room. Works great at ten people. Breaks at fifty.
When the physics changes
The risky part is when something shifts and you don’t update your model.
A startup that was ten people in a room, fast and aligned and always talking, goes remote or scales past twenty. Partitions become real whether you like it or not. You have to choose: slow down and add process, or accept that teams will drift. Most companies try to keep all three. Chaos.
An acquisition that merges a slow, aligned company with a fast, fragmented one. They’re trying to combine systems with incompatible consistency models. Someone has to pick.
A “return to office” mandate that’s really a desperate attempt to get back to when everyone was in the same room. It might work if you’ve shrunk to that scale. It won’t work if you’re still trying to coordinate hundreds of people. You can’t solve a CAP problem by pretending partitions don’t exist.
So what do you do
You pick. Deliberately.
What does your team actually need right now? If you’re building something new and moving fast, maybe alignment can wait. Ship first, consolidate later. If you’re coordinating across teams or time zones, maybe you accept that things will be slower. If you’re small and tight and it’s working, maybe just don’t distribute. Stay in the room. Grow slower.
None of these are wrong. They’re just different tradeoffs.
The problem is when you want all three and pretend you can have them. You can’t. That’s not a management failure, it’s just how distributed systems work. Teams included.
So name the thing you’re sacrificing. Say it out loud. Then design your processes and culture around that choice, instead of being confused when it keeps biting you.