This post is based on a talk I gave with Elena Tanasoiu at Brighton RubyConf in June 2026.

Last week my team shipped a small thing: a dropdown in the repository header that lets you jump straight to another repo, instead of trailing back to your dashboard and starting again. It is a good small thing, done well, and people noticed (they almost never do). One called it the best thing GitHub had shipped in three years. Another wrote, simply, “you legend we love you so much”. A third could not believe he was praising GitHub, and did it anyway, on the grounds that good design is usually just the obvious thing finally done. I am proud of it, and the love is deserved.

It also shipped in roughly the time it takes to read this paragraph, with no argument from anyone, because the moment you saw it you could see the point of it. Performance work is much harder to justify, which is what I am on a stage about this week, next to Elena, who can open a flamegraph of the pull request page (a dense picture of where every millisecond goes) and find the slow one before you have finished sitting down. It would take me all afternoon. That is a real and difficult skill, and it is the part of performance work the field has mastered. What the graph cannot tell her, or me, is which of those milliseconds anyone would have paid to keep. It answers the question it can answer. The rest is on you.

Everything that decides whether a slow thing gets fixed sits outside the graph, in the part with a person in it, and it is all the same job: making a value nobody can see legible to someone who needs to see it.

First, knowing what is worth fixing. The graph hands you the hundred slowest things on the page; it cannot tell you that ninety-nine are slow where nobody stands, and the hundredth is the one a real person hits so often they end up saying so in public. For us that was David: a developer well-known enough that when he said our navigation was slow, the people who heard him were exactly the ones we cared about, and it cost us something no renewal number would have caught. He was right, which was the part that stung. The evidence that speed matters is, for the record, enormous. Vodafone ran two versions of a page identical but for a third faster load, and the faster one sold eight per cent more. Google once slowed its own search by four hundred milliseconds, below the floor of conscious perception, and the world searched less, and kept searching less after the delay was gone, as though four hundred milliseconds had quietly lowered its opinion of the place. And does any of it move anyone? Not in my experience. People are staggeringly and inexplicably unconvinced by what happened at another company, so it does not count until it is one of your own users, on one of your own pages. Which is why you find David the slow way, in the forum thread and the tweet he never meant for you to read, and you let what the wait cost him pick the target, rather than whatever was most satisfying to fix.

Second, being allowed to do it. The work most worth doing tends to be the work whose payoff is hardest to draw, so the foundations rot while the visible wins ship on time. Everyone agrees with this in principle, right up until the planning meeting. The scale is not in doubt. McKinsey reckons the average company’s technical debt is worth twenty to forty per cent of its whole technology estate, a third of what you own held together by work no one can see. And a number that big still loses to a feature demo every time, because you do not win this on the numbers. You win it by carrying the customer into the room in the decider’s language: “still slow for the account you mentioned, and we are close” buys you another week; “ruled out three hypotheses” buys you nothing.

Third, the part after you ship, which I am worst at. You go back to the thread where David complained and say, slightly cringing, here is what was broken and here is what we did, because work nobody hears about is the first thing struck off the next list. When it goes well, he says so in the same place he complained, and the fix stops being something only you could see, which is the closest this kind of work ever comes to applause. There is a name for it now, glue work, the invisible kind that holds a company upright and gets nobody promoted. Closing the loop is the rare piece of it that pays you back, because it is how the work becomes visible enough to survive being cut next time.

None of the three is a skill you can put on a CV, which is exactly why the industry has quietly agreed they are someone else’s job. So here is the whole thing as one instruction: before you take on a piece of performance work, find the person who is going to applaud you when it is done. Ideally out loud, where other people can hear.

Find them before you start, not after. They are the reason the work is worth doing, the name that gets you the room, and the proof, when it is over, that it mattered. David was ours. The work goes better when you already know whose day you are trying to make.