In 2012, I asked our engineering team to throw away a working codebase and start over.
Not because the code was bad. Not because of a technical debt crisis or a customer complaint. Because I believed the architecture was fundamentally wrong, and that fixing it incrementally was going to be slower and more expensive than rebuilding from first principles.
Getting the team to believe this with me — not just execute on it, but genuinely believe it — was the hardest leadership problem I had encountered to that point.
At Realm, our first storage engine was a wrapper around SQLite with clever caching. It worked. Developers were using it. We had shipped something real.
The problem was the data copying. Every read involved three copies of the same bytes moving from disk to memory to objects. We could optimize this path endlessly and never escape the fundamental inefficiency. The only way to solve it was to design a storage engine where the data format on disk and in memory were identical — a custom C++ engine built around direct memory mapping and zero deserialization.
80x performance gains, eventually. Developers who described it as feeling like magic.
But none of that happens if I can't convince a team of smart, skeptical, capable engineers — people who have been shipping working software — to take on a months-long rewrite of something that already works.
The mistake most founders make in this situation is framing it as a vision problem. "Here's what I think we should build. I need you to trust me."
That framing is wrong, and it produces bad outcomes. Not because the vision is wrong, but because engineers who are executing someone else's vision do different work than engineers who share the vision as their own.
When you're building something you genuinely believe in, you make a thousand micro-decisions correctly. You catch edge cases because you understand the whole system, not just your component. You push back on a design choice because you care about the outcome, not just the completion of a task.
When you're executing on someone else's vision, you make those same micro-decisions according to the spec. Which means every gap in the spec is a potential problem.
The zero-copy storage engine was technically complex enough that we couldn't spec it fully in advance. The team had to be making good judgments in the details. That required the team to understand not just what we were building but why — and to have enough ownership that they would defend the "why" even when it created friction.
I've come to think of this as the difference between communicating a vision and transferring it.
Communicating a vision means explaining it clearly enough that people can execute on it. Transferring a vision means creating the conditions where engineers arrive at the same understanding independently — where the reasoning makes enough sense to them that they would reach the same conclusions even if you hadn't been in the room.
The difference in outcomes is significant. Teams executing on a transferred vision catch problems you didn't anticipate. Teams executing on a communicated vision ship what you described, even if what you described turns out to be wrong.
There was one moment during the rewrite that has stayed with me. We were in the middle of implementing the MVCC design — the multi-version concurrency control that let us avoid traditional locking — when one of the engineers pushed back on a specific design choice in the version chain structure. His concern was about a garbage collection edge case: under a specific write pattern with long-lived read transactions, the version chain could grow unboundedly in a way that our collection logic wouldn't catch in time. He had found it because he had been thinking about the full lifecycle of a transaction in the new system, not just the happy path. If he had been executing rather than owning — waiting for the spec to cover this case — we would have shipped it, hit it in production at the worst possible time, and faced a degraded performance problem that would have been extremely difficult to debug remotely on a developer's device. Finding it in the design phase cost an afternoon. Finding it in production at 2 billion installs would have cost something much larger.
The practical difference is in how you spend your time as a technical leader.
Communicating vision requires you to be present, explaining, unblocking. Transferring vision requires you to invest more upfront — in the right context, the right framing, the right shared mental model — so you can be absent later, trusting the team to make good decisions without you.
At Nokia, working on software deployed across hundreds of millions of devices with hundreds of engineers contributing to the same codebase, the projects that failed were the ones where the vision lived in one person's head and everyone else was executing on their interpretation of it. The projects that worked were the ones with written architectural principles that teams had internalized — not because they were told to, but because the principles made sense to them.
The document doesn't transfer the vision. The work of making the document — the arguments, the debates, the refinements — does.
The zero-copy storage engine shipped. The 80x performance gains were real. What I'm most proud of isn't the architecture itself.
It's that by the end of the project, every engineer on the team could explain the architectural decisions as clearly as I could — and some of them could explain specific tradeoffs better than I could, because they had lived through implementing them.
That's what product vision and engineering execution actually look like, when they're working together. Not a gap to bridge. The same thing.