The Performance Problem That Code Can’t Fix
After reading a recent piece by Jeremy Keith on people problems in performance work, I was reminded of my own frustrating experience at a company not long ago. Keith frames it as a continuum: at one end are technical issues, solvable with technical solutions; at the other are human issues, which require discussions, agreement, and empathy. Developers naturally gravitate toward the technical end—it’s the comfortable, familiar ground.
I think that, as developers, we tend to gravitate towards the technical issues. That’s our safe space. But I suspect that bigger gains can be reaped by tackling the uncomfortable human issues.
When I joined that company, I walked into a mountain of performance work that I couldn’t possibly handle alone. I tried teaching, held office hours, and offered help wherever projects needed it. Despite that effort, the site I was working on in my spare time was getting slower. The root cause wasn’t a lack of technical skill—it was a lack of incentive. If performance improved tenfold overnight, nobody in the company would have noticed, except me, because I’m the kind of nerd who tracks such things.
Same Battle, Different Field
Ethan Marcotte describes an identical dynamic in his talk on design systems:
Creating modular components isn’t the primary goal or even the primary benefit of creating a design system. And what’s more, a focus on process and people always leads to more sustainable systems.
Whether you’re building a component library or optimizing pages, the blocker is never just the front-end. If the people inside the organization have no reason to use the design system’s components or to consult the team behind them, the codebase splinters. The same holds for performance work: without buy-in, best-effort fixes won’t stick.
It’s a simple axiom that’s hard to accept: the code is easy to change, but the incentives that decide what code gets written—and who fixes it—are not. Those incentives dictate what’s acceptable, what gets prioritized, and how teams collaborate. Effectively, you cannot fix the code without fixing the organization around it.
What Actually Moves the Needle
The most direct incentives are money and performance ratings, or simply staffing a team that is explicitly dedicated to the work. But there are softer levers too: improving visibility into performance problems and celebrating notable wins can help shift what people deem important. All of these, though, need to come from the top down rather than emerge from the ground floor. At least that has been true in my experience.
There’s no single answer for correcting misaligned incentives inside large organizations. What makes a site fast is only ever part of the battle—the bigger hurdle is making sure enough people care about the outcome. Yelling and screaming about it won’t help. Trust me, I know from experience.
