How 80,000 Engineers Actually Work

The org measured satisfaction tool by tool — good at tracking the problems it already knew about, blind to the ones that lived in between. And the frictions themselves weren't secret; teams knew their own tools had rough edges. What no one had was the whole picture: how those rough edges compounded across a developer's day into a real drag on the efficiency the org existed to deliver.

The friction compounded across the whole day

These weren't isolated bugs. They were systemic — woven across the whole journey, belonging to no single step or team.

I built this detailed workflow map to synthesize the 18 interviews — a way to make sense of everything we were hearing and see the whole developer loop at once. Every step is annotated with the pain points we heard. The density is the message: this is what builders navigate every day.

Code review alone had a dozen breakpoints

Once it existed, the map became a way to talk with teams. Because we'd mapped the whole workflow, I could pull out any team's slice and show them exactly where their product sat in a builder's day.

Zooming in on code review — one of the most complex parts of the loop: two parallel paths (submitting vs. reviewing), decision points around analyzer rules and approval, context-switches while waiting for feedback, and error-diagnosis branches that could send builders back through the entire loop.

“The review itself takes 20 minutes. Getting someone to do it takes three days.”

— SDE, from research interviews

With the Code Review team, that started a deeper collaboration — I did design work with them to address several of the issues the research surfaced. It also seeded a number of other projects across the org. See the Code Review redesign →

The worst problems crossed the most teams

We prioritized what we found by how much each problem hurt and how many teams a fix would require. The most critical problems were consistently the ones that crossed the most teams — the ones no single team could solve alone.

30+ notifications, all landing on one developer

Some of the most systemic problems were invisible precisely because they were spread across teams — so I ran workshops to surface them collectively. Teams from across the platform contributed to shared boards, cataloguing the friction they lived with and mapping their own corner of the system. Problems no single team could see came into focus once everyone's piece was in one place.

Notifications were the clearest example. Every tool sent its own alerts, and every team was sure theirs mattered — but no one could see the aggregate. I had teams map their own notification sources onto one board, and the picture was undeniable: over 30 notification types, from more than a dozen tools, all landing on the same developer — most with the same complaint (too many, no way to tell signal from noise), and many requiring no action at all.

That was the pattern beneath all of it: the worst problems weren't anyone's fault, and weren't anyone's to fix. They only became visible when someone looked across the whole system — and that was the work.

“I'd love to see us identify a couple of key deep dives with the right brains around a first set of these findings.”

— Head of Product

These are problems that take years and many teams to work through, and the hardest ones are still hard. But the research is what got the org to start treating the developer experience as one thing worth solving — and to fund the first steps toward it.