Building the team behind a high-scale platform
It’s easy to talk about a platform as if it were the architecture diagram — services, queues, databases, the shape of the thing. But the diagram doesn’t operate itself. Every reliable system is downstream of a team and a set of habits, and when a platform holds up under real load, it’s usually because the people behind it built the right ones long before the load arrived.
You can’t buy that with tooling. You build it, the same way you build the system — deliberately, and mostly in the unglamorous parts.
The platform is downstream of the team
Architecture sets the ceiling for how good a system can be. The team decides how much of that ceiling you actually reach. The same design, in the hands of a team with clear ownership and good instincts, becomes something dependable; in the hands of a team where no one quite owns anything, it slowly rots regardless of how clean the original diagram was.
So when I think about reliability, I spend at least as much time on the team as on the technology. They’re the same problem viewed from two angles.
Ownership over hand-offs
The single biggest difference I’ve seen is whether people own outcomes or just hand off tasks. When a team owns a part of the system end to end — builds it, runs it, gets paged for it — quality follows almost automatically, because the people making decisions are the ones who live with the consequences.
When work is thrown over a wall instead — built by one group, operated by another — the incentives split. Nobody feels the full cost of a shortcut, so shortcuts accumulate. I wrote separately about how expensive unclear ownership gets; on a platform that has to stay up, it’s the difference between a system that improves and one that quietly degrades.
Hiring for the judgment the bad day requires
Most of engineering at scale isn’t the steady state — it’s the exception, the incident, the call made with incomplete information while something is on fire. That’s why I hire for judgment more than for raw output. You want people who, under pressure, reason clearly about trade-offs instead of either freezing or thrashing. Throughput is easy to measure and easy to overvalue; judgment is what you actually need when the happy path breaks.
Process that survives the bad day
Good teams design their process for the bad day, not the good one. Runbooks, blameless post-mortems, clear escalation, a real on-call rotation — none of it matters when things are calm, and all of it matters when they aren’t. The point isn’t bureaucracy; it’s that a good process you can rely on every day beats an occasional act of heroism. Heroics don’t scale, and a platform that depends on them is one tired person away from an outage.
Culture shows up in the incident
You learn what a team’s culture really is during an incident. Do people reach for the facts or for someone to blame? Is it safe to say “I caused this”? Does the fix make the next incident less likely, or just close the ticket? The answers aren’t set by a values statement on a wall — they’re set by what the team tolerates, day after day, long before the pressure hits.
Build that part well and the architecture has a chance. Neglect it, and no diagram will save you.