Technical projects are often hard to explain. Scalability work, migrations—these can sound like expensive, low-reward investments to non-engineers.
There’s a simple trick that can make it easier: give the project a name.
When I was Head of Engineering, managing two teams building a real-time text editor, we hit a wall. Our conflict resolution algorithm wasn’t scaling. It was too slow and users were experiencing data loss.
Incremental fixes were exhausted. We needed a fundamental shift: a new algorithm and a more appropriate data structure.
Outside of engineering, this sounded like an enormous, risky investment with no immediate payoff. I knew we needed buy-in—not just approval, but real understanding.
As we discussed the work, what kept coming up was what this work enabled. More users writing in a document at once. More users in the product overall. A foundation for better commenting and versioning.
So we branded it: The Great Enabler.
Instead of selling complexity, we roadmapped the stream of outcomes this migration allowed.
We plotted milestones, showing which features and improvements would be unlocked at each stage.
When I presented it at an All Hands, people latched onto the name. They remembered it. They asked about it. They even got excited …about CRDTs and OTs.
In 2014, the Heartbleed bug became urgent industry news—not just because it was severe, but because it had a name and a logo.
As David Chartier, CEO of Codenomicon—the firm that discovered it—said: “Fixes went extremely quick… the fact that it had a name, had a catchy logo, really helped fuel the speed with which people became aware of this.”
Not every project needs branding. Overuse it, and you dilute its impact.
But if you’re struggling to get buy-in or if people keep misunderstanding the value of your long-running technical project—try giving it a name. It might just change the conversation.
—Dan
p.s. You're reading the archives. Want new posts? Subscribe for free today and join a growing community of builders, founders and engineers: