At Nokia, where I spent over a decade before founding Realm, the way you got anything done was to write it down.
Not in a bureaucratic sense — though Nokia had plenty of that too. In the practical sense that Nokia was a large, global organization where the person who controlled the budget for your project was several organizational layers away, spoke in a different technical dialect, and had a different set of priorities. If you couldn't explain your idea in writing in a way that survived that translation, your idea didn't happen.
I resisted this for years. Writing felt like the overhead you did before the real work. Then I realized: the writing was the work.
The hidden benefit of writing down an argument before you build something is not that it persuades other people. It's that the act of writing forces you to understand your own reasoning in a way that talking about it never does.
When you can explain your idea conversationally, you can hide the gaps behind your energy and your certainty. You skip over the uncomfortable assumptions. You lean on context that only you have. The gaps don't show up until you're already six weeks into building.
When you write it down, the gaps show up immediately. Sentences that sound convincing in conversation become obviously incomplete on paper. "Users will find this valuable" turns into: wait, which users? What's the problem they have right now? Why is this the solution to that specific problem and not some other solution?
I started requiring written arguments for significant technical decisions at Realm not because I was trying to create process. I was trying to create a forcing function for the thinking that needed to happen before the building started.
The format that worked best was not a formal document. It was closer to an argument: here's the problem we have evidence of, here's the option we're considering, here's why I think it's right, here are the assumptions that could make me wrong.
The quality of the argument mattered less than the discipline of making one. Engineers who wrote thorough, well-structured arguments didn't always get their proposals approved. But they almost always had a clearer understanding of the decision than engineers who didn't write. And that understanding showed up in the quality of the implementation.
The one that comes to mind most clearly is the sync architecture proposal. An engineer had been working through the design for how Realm's synchronization protocol would handle conflict resolution between devices that had been offline. He had a clear idea in his head and could describe it fluently in conversation. When he wrote it down — walking through the conflict resolution logic for a specific sequence of operations — he got about halfway through the document and flagged a section as "needs clarification." The scenario he was trying to articulate was one where two devices had made conflicting edits to the same object, both had gone back online, and the server needed to produce a deterministic outcome that wouldn't look wrong to either client. He couldn't actually articulate the rule clearly in prose. Which meant the rule didn't exist yet — he had been assuming there was an obvious answer without having actually worked out what it was. Two engineers spent three days resolving that question correctly before any code was written. If we had started coding from the conversational version of the design, we would have built to an ambiguous spec and discovered the conflict resolution problem after the sync engine was already partially built. The document didn't solve the problem. It found it.
The parallel to what I'd observed at Nokia was not the content of the writing — Nokia's documents were a different genre entirely, shaped by the compliance requirements of a global corporation. The parallel was the discipline of externalizing your thinking as a prerequisite to acting on it.
At Nokia, the forcing function was organizational: you had to write because the organization required it. At Realm, the forcing function was the team's expectation: if you're proposing something significant, you write it down first. Not as a gate, but as a shared norm.
The practical difference between these contexts is that at a startup, you can choose whether to build this discipline before you need it. Nokia had writing because a large organization can't function without it. A startup can get away without writing for a long time — and most do.
The problem is that the point where you need the discipline most is the point where it's hardest to introduce. Once you're moving fast, under pressure, with a growing team, introducing a writing practice feels like slowing down. It is slowing down, at first. But it accelerates everything that comes after.
The teams I've watched waste the most time are the ones that build things thoroughly and then discover they built the wrong thing. The teams that move fastest are the ones that have learned how to invest time in understanding the problem before investing time in solving it.
Writing is the most effective tool I've found for doing that.
The investment is real: it takes longer to write an argument than to describe it in a meeting. What you get back is a team where the people building something understand why they're building it — which means they make good decisions in all the gaps your argument didn't anticipate.
That's worth more than the time the writing takes.