Leading React with Clarity and Care

When I took on the Head of React role at Meta in 2021, the organization was around thirty-five engineers. React powered Meta's family of apps and millions of applications beyond it — a lot of surface area for a relatively small team.

The thing I kept coming back to was that leading a project like React isn't really about the technology. It's about the people. The ones building it. The ones depending on it. The ones who trust that the tools they've chosen will be there tomorrow, working a little better than yesterday.

That's the job. The rest is implementation detail.

The Human Infrastructure

There's a seductive trap in technical leadership — the belief that if you get the architecture right, the rest will follow. I've watched it claim some of the best engineering minds I've known. They optimize for systems when they should be optimizing for people. They treat organizational problems as technical problems. And eventually, they wonder why their brilliant solutions keep colliding with messy human reality.

When we began scaling the React organization — eventually doubling it to around seventy engineers — I made a choice that felt almost naive at the time. I decided that our primary investment wouldn't be in process or tooling or elaborate planning frameworks. It would be in understanding.

Every planning cycle started with one question: Who needs context to move faster?

Not "what needs to get done" — that's table stakes. The deeper question is about information flow, about the invisible barriers that slow talented people down. Where are people waiting for decisions that never come? Where are teams duplicating effort because they don't know what's happening next door? Where has institutional knowledge gotten stuck in someone's head instead of becoming shared infrastructure?

These aren't technical problems. They're trust problems. And they require a fundamentally different kind of solution.

Shipping as a Unified Crew

React Compiler was the hardest technical bet we made. The idea: automatically optimize React applications in ways that previously required careful manual work with useMemo, useCallback, and React.memo. If it worked, developers would get faster apps without changing their code. If it didn't, we'd have shipped complexity disguised as progress.

But here's what I learned: you can't ship something that ambitious without first building something harder. You have to build a team that moves as one.

We made an early decision that shaped everything that followed. Compiler wouldn't ship alone. It would ship alongside a refresh of React DevTools and a complete overhaul of our release engineering infrastructure. Three major initiatives, coordinated as a single story.

On paper, this looks like a project management challenge. In practice, it's a trust challenge. You're asking different teams with different priorities to synchronize their work in ways that create dependencies and vulnerabilities. You're asking people to move slower in the short term for a payoff that might not materialize.

The only way this works is if people believe in each other. If the Compiler team trusts that DevTools will be ready. If the release team trusts that what they're building infrastructure for is actually going to ship. If everyone trusts that the coordination cost is worth it — that the whole really will be greater than the sum of its parts.

We earned that trust through transparency. Roadmaps were public, not just within the org but to the broader community. Problems were shared early, before they became crises. Decisions were explained, including the trade-offs we considered and rejected.

It worked — though "worked" undersells the grind. We shipped React Compiler alongside updated DevTools and a revamped release pipeline. The technical outcome mattered. But what I'm prouder of is that the team held together through it — nobody burned out, nobody got steamrolled, and the pieces actually fit when we put them together.

The Rituals That Hold Us Together

Fast-moving organizations have a tendency to erode. Not through any single failure, but through the accumulated friction of speed. Communication becomes terse because everyone's busy. Context gets lost because there's no time to share it. People burn out not because the work is too hard, but because they've lost sight of why it matters.

This is where rituals become essential. Not the performative kind — not status meetings that exist because someone once decided there should be status meetings. I mean the rituals that actually hold a team together.

We instituted skip-level listening sessions. Not to circumvent managers, but to create space for the concerns that don't fit neatly into existing channels. Engineers two or three levels down would tell me things their direct managers didn't know — not because anyone was hiding anything, but because some things only surface when you create explicit space for them.

We protected writing time. Not documentation sprints or wiki cleanup, but actual writing. The kind where you slow down enough to think clearly about what you're building and why. Some of the most important strategic insights came from engineers who finally had time to articulate what they'd been noticing for months.

We made roadmaps genuinely public. Not sanitized versions designed for external consumption, but real plans with real uncertainties. This felt risky at first — what if competitors used the information against us? But the trust it built with the community was worth more than any tactical advantage secrecy might have provided.

These rituals aren't overhead. They're infrastructure. During this period we went from shipping major releases roughly once a year to quarterly, and the team was less stressed, not more. That's not because the rituals were magic — it's because people had enough context to make good decisions without waiting for permission.

What I Carry Forward

I'm no longer at Meta. The technical lessons from that period are already dating — that's the nature of the work. But the human lessons have stuck.

Clarity is underrated. Transparency is uncomfortable but worth it. And the best technical outcomes tend to come from teams where people feel safe enough to take real swings — not teams optimized for predictability.

The code will be rewritten. The architectures will evolve. React itself will eventually be superseded by whatever comes next. What lasts is whether people grew. Whether they did work they're proud of. Whether the environment helped or got in the way.

I got some of that right and some of it wrong. But I'd take the same approach again.