It's time to start writing

I recently became aware of Jeff Bezos’s dotcom-era policy of banning PowerPoint within Amazon. Instead, meeting organizers must write a multi-page “narrative” and distribute it to all attendees at the start of the meeting - denying any single person a head start - and only after everyone has finished reading do proceedings begin.

This policy is particularly notable as it finds itself embedded in a company staffed largely by software engineers, who often have neither experience nor interest in writing prose. We feel most at home when transmitting ideas as algorithms, unambiguously described by mathematics and sequences of instructions. And the further we stray from this the more discontent we feel as the ambiguities of natural language leak through, needlessly eroding clarity.

But on closer examination I believe this is neither about powerpoint nor about reading - it’s about thinking. To see why we need to look beyond the headline.

If we could peer into Jeff’s 2004-era outbox we would find his original email:

The point being made is clear from the language: “writing” is mentioned twice but “reading” not at all. It’s creation which is important, not consumption. Even if the memo was written and immediately shredded, the act of writing would not be undone and the improvement to thought and understanding would persist.

Still, for a company trying to be Earth’s most customer-centric company, it is hard to shake the feeling that time would be best spent interacting with, say, customers, rather than crafting narratives.

But Amazon is far from the first to recognise the value in the writing process. Some go even further:

Writing is thinking. To write well is to think clearly. That's why it's so hard.

And here I think it’s worth digging even further to ask - why is thinking clearly important? Obviously - in our context of software engineering - if you don’t think clearly then any solutions you craft as an individual will be suboptimal.

That is undoubtedly true. But more importantly, writing a coherent and logical narrative forces your thoughts into a shape which can be easily communicated to others and used to persuade. None of us work in isolation. There is little point in having the answer if you cannot convince others of its merit.

Let’s imagine a team of engineers. Having just been informed of the firm-wide mandate to migrate from in-house servers to the cloud, they must make the impactful and long-lasting decision about which technology to introduce. In an attempt to reach consensus they’ve gathered around a pizza and begin exchanging views.

The Kubernetes guy knows that only his solution leads to a future free from tedious discussions around the solved problems of authentication and service discovery. Batteries must be included. Three slices to the right another engineer brims with confidence and espouses the virtues of Nomad - single-purpose, orthogonal and composable components are the bedrock of well-engineered software systems. Principles must come first.

After an hour of discussion bouncing from feature to feature to pro to con to bug to feature, everyone has learned something new. But no one is persuaded and no consensus has emerged. Though useful for knowledge exchange, such unstructured discussions are not an efficient mechanism for reaching agreement.

What is needed to break the stalemate is for a single individual¹ to spin a narrative which captures the journey from business need through to practicalities of implementation, in a comprehensive, flowing and logical manner. This would be persuasive - it would instill in others the confidence that this is not just the best technology in an abstract sense, it’s the right choice for our problem, our business, and our people at this point in time.

It would be useful for others to read this. But even if they didn’t, the newfound clarity of mind of the creator would allow them to make an argument persuasive enough to break the stalemate of ideas.

For this particular situation - the choice of a technology - the writer will likely have thought about and touched on:

The beginning

• What were the underlying reasons for the decision to change technologies? Why is this worthwhile embarking on and what benefits will be seen?
• What reason do we have for investigating this particular tech as a solution? What other alternatives are worth investigating?
• How high are the stakes? Are we laying the foundations of the cathedral or painting the bike shed? Can we easily switch later if things aren’t working out?

The middle

• Does the tech being suggested have a mission statement or core guiding principles? How does that tie in with our problem and philosophy?
• If we roll with it, what’s the end goal? When implementation is complete, what does the world look like?
• How might we get from where we are to where we want to be with minimal disruption? What might the transition period look like? How long, roughly?
• Do we have any existing in-house expertise?
• Are there any risks? What steps might we take to reduce them? Any unknown unknowns?
• In what ways might this solution fare better than the alternative(s)?
• In what ways might the alternative(s) fare better than this?

The end

• Relate back to the underlying business needs and sum up with a recommendation, explaining why this the best option

In this case, the content of the narrative would overlap substantially with a technical design document. But whereas a TDD is an end in itself, the physical output of this writing is a pleasant side-effect. What matters are the organised thoughts left in the mind of the author.

Having competently translated these thoughts into natural language once before, the author will have no trouble doing so again when called upon, orally and in real-time. And having considered the problem at several levels of analysis - as must be done to write well - they will, at a moments notice, be able to adapt their narrative to suit any audience, regardless of their existing knowledge.

Finally, unlike specialised tools, narratives are general. They scale. From the narrowest of technical issues up to the most fundamental question of the mission and purpose of the company as a whole, there are no problems which resist clear-thinking.