TL;DR.

"Writing is nature's way of telling you how sloppy your thinking is."

— Richard Guindon

• Intelligently crafted writing culture, though no silver bullet, is the only way to reliably leverage ourselves across space and time ¹. Far beyond our own heads, and far into the future ².
• The closer one looks, the more one will notice elite performers in one's peer group. The proverbial 2x, 5x, 10x teams. Maybe even better. Invariably, they rely on strong writing culture to perform at the high level they do.
• To successfully use writing for leverage; first, clean house. Then, start small. Think concurrency. Help one critical and busy person free up 10% of their work week.

The thesis

"Give me a fulcrum, and I shall move the world."

— Archimedes of Syracuse

All leverage is about finding or creating some source of asymmetric advantage. The greater the leverage, the greater the advantage, and the lower the energy expended to make things happen.

Writing is Lever.

Product is Fulcrum.

Team is Force.

Writing Product Team is A-Team.

Word.

A-teams write to kill complexity

Complexity is to software what mass is to a rocket; the hard limiting factor of net-positive growth in any dimension one chooses to measure (shipping velocity, headcount, revenue, cash flow, account expansion; anything).

David-sized product organisations succeed against Goliath-sized ones because they keep accidental complexity at bay ³. Such competitive advantage invariably flows from strong writing culture created by the Davids for their needs.

Yet, teams of A players routinely crash and burn like "F"-Teams.

They habitually accumulate unchecked masses of software debt, and fail to escape the terrible gravity well of accidental complexity.

"I must not complect.
Complexity is the mind-killer.
Complexity is the little-death that brings obliteration.
I will face complexity and I will permit it to pass over me and through me.
And when it has gone past, I will turn the inner eye to see its path.
Where the complexity has gone, there will be nothing.
Only I will remain.
— Litany Against Complexity

A-teams write to compound value

They use writing to generate overlapping compounding benefits:

• conserve personal and collective attention
• power creativity
• grow intellectual capital
• maintain clear situational awareness
• run high-trust workplaces, and
• make high-quality decisions.

Because they know that software is peoples' thoughts on repeat, and that complexity is the negative-compounding mind-killer.

Yet most product teams do not invest in writing culture.

The result?

Their people toil on hamster wheels of endless forgetting and rework. Value creation craters. Stock dilutes relentlessly. Their true burn rate measures not in cash, but in minds wasted and bodies spent.

Sad, but not fated.

A-teams get lucky more, by writing pervasively

Privately cultivated writing culture runs dark and deep, but emits plenty of heat and light visible to even the most casual of observers.

A strong culture of writing has the (good) habit of pervading all aspects of an organisation. Everything from their marketing copy, tweets, blogs, customer support interactions, documentation, mass mailers etc. reflects their deliberately curated writing culture.

As a proxy measure ⁴; a company blog that is both tasteful and routinely makes the HackerNews front page is no accident. Fortune favours a power law curve. Sure it randomly rewards the prolific brainrot TikTock because there is sometimes a quality to quantity ("Even a broken clock is right twice a day." etc. etc.), but the prolific with taste and quality, fortune rewards a lot more, a lot more reliably.

Individuals play the game, but teams beat the odds.

— The US Navy SEALs

A-teams master common-sense writing

The good news? Our kind of writing is NOT rocket science.

It is about:

• simple common sense writing (no literature major necessary),
• of, by, and for the product team, empowered by
• systematic use of information tools (be it grep, wikis, or LLMs),
• privately within the safety of one's team,
• such that the whole team is significantly better off,
• even if "team" is just you, to begin with.

Good writing is the single most undervalued talent a startup can have.

— "How we write", Griffin (a UK banking-as-service company).

That page is just… chef-kiss-emoji. ⁵

Examples of common-sense writing I use

nb. I have artificially separated out categories to illustrate many different contexts in which writing is useful. This does not mean "Vomit needless words." ⁶.

Quite the opposite… I write to systematically re-use a given unit of writing in multiple contexts, with little or no tweaking. For example:

• how/why I write high quality commit messages (below), and
• how/why I write teaching material such that I can use the same text to deliver live demos and publish as blog posts and as slides.

To make

Writing as part of the source of the artifact (code or design file).

• Naming things (functions, APIs, domain entities)
• Documentation strings
• In-line comments
• Metadata etc…

Example: outline an API as working code, with mock implementations so that we can peer-review and evolve the meaning of our code, without getting lost in implementation details. The purpose of that commit was to help me think about, and get feedback on, the shape of an HTTP API. (Told ya. It ain't rocket science.)

To ship

Writing that is adjacent to the artifact being produced. High quality commit messages, written code reviews, development-time notes etc…

Example: Habitually writing model git commit messages is table stakes as far as I'm concerned, because I profit from the effort multiple times.

• While making, writing the commit text forces my brain to switch from "execution" mode to "reflective" mode, to debug my thinking about what I just did. Subtle design errors and subtler bugs surface in this process often enough to keep me humble!
• In code review, colleagues are rarely blocked on me to understand work-in-progress.
• At feature shipping, they yield release notes, feature documentation, executive summaries… stuff that helps other people perform better and look good to their stakeholders, whether executive talking to board, customer success helping a new feature roll out succeed, sales to build factually accurate non-B.S. pitches etc…

To share

Context captured smartly on-the-fly folds into an assortment of trustworthy (with provenance) facts and explanations:

Material for peers and colleagues that helps them reliably communicate with each other, the board / investors / customers / other outside stakeholders.

• Executive briefings
• Release notes etc.

Product know-how that is essential to future decision-making about implementation details.

• Feature documentation (you are allowed to have fun)
• Architecture Decision Records (check out simpledotorg/simple-server)
• System Diagrams (but please label and explain all the arrows)

Instruction material

• Setup and usage guides (e.g. in READMEs)
• Demos and/or instructions for demos,
• Tutorials, onboarding programs, blog posts
• e.g. The tutorial content and the README of clojure-by-example.

Raw "research notes" and stream-of-conscious-y brain-dumps.

• Create psychological safety by having a a place where everybody is allowed to be wrong, drop half-assed ideas, add secondary context / things they explored and learned about while working on features.
• Commit this context straight into the source to keep all new context visible through code review, or dump it in a wiki (but please cross-link the page to the project's README and mention changes in code review.)

To evolve

All shareable content as well as original sources further inform product requirement documents, project plans, and product strategy.

• Improve and plan better via. context-rich bug reports, post-mortems, and critiques.
• Encourage critical thinking through rationales, concept notes, architecture diagrams, specifications
• Help individuals grow by instutionalising knowledge in checklists and runbooks that help seniors rapidly onboard, mentor, coach juniors into independent skilled staff members.

To de-risk

Teams with a strong writing culture automatically de-risk themselves. They can go as far as to become a collection of buddy teams and individual contributors, cooperating with each other as needed. A lot more like specialty surgical teams than generic marching bands.

Strategically: by cultivating a strong design culture.

• Design in Practice (video)
• Design in Practice in Practice (video)

Tactically: by cultivating deep observability.

• My favourite example again; model commit messages. Because I habitually make atomic commits and write model commit messages, colleagues have granular enough information about feature history to independently audit, debug, fact-find… for the whole life of the software. Such a history is very useful while making, but is rarely needed post-shipping. However it is needed inevitably, and when the need arises, the stakes are invariably high. Being able to inspect manually as well as trivially automate scripts using git-bisect run becomes a superpower.

To show up

Please, let's make visible the impact of the invisible work we do. Besides, why give up even small chances to look great to outside observers, by being able to magically produce good answers fast. Not infrequently, by literally dumping a feature's git log (or ones' running notes) into a document and cleaning it up.

Please read Julia Evans's post Get your work recognized: write a brag document. Guess what. You can't do this unless you have a writing habit — scribble down "TIL"s and "A-ha"s and tiny wins. All these roll up into big impact. But we ourselves remain unaware because we often don't have a tangible feedback loop that we are having an impact.

To LLM harder

For the LLM enjoyers out there, need I even suggest the compounding value of having a (consistently high-quality) input context to (re)feed into your LLM-assisted product development?

What might be two hours of mostly manual collation and rewording of a raw dump could become a twenty-ish minute job of mostly intelligent review and copy-editing of LLM-produced content.

The key is to make writing systematically useful

Utility is contextual ⁷. Use the examples as a box of tools and craft something suited to the orientation, mandate, and goals of the workplace / team / self.

Collaboration oriented writing is the name of the game I am convinced that has directly made me a better colleague, made "us" better together, and bettered professional lives of others. Some of my best days have been people telling me, years after the fact, how much they benefited from stuff my like-minded colleagues and I wrote down and made useful "back then". My colleagues report similar experiences.

There are no silver bullets

Writing is unnatural, especially for teams. Heard of Bezos? Well, even someone with his smarts, charisma, and sweeping authority over his company had to work to make it work, because…

It is a conscious choice

We have to culture ourselves into pervasive, thoughtful, effective product development writing. As individuals. As teams. As whole org charts. LLMs may make writing life easier, but only we can do the work to make it work.

It is not a one off activity

Our kind of writing remains useful only through repeat use and progressive revision throughout the life of a software product. It needs leadership and community contribution to update, curate, improve, teach, use. Because bureaucratic ossification is always around the corner.

It requires widespread buy-in

One can't force it. Doing so will reliably cause more damage than good, by violently convincing people that it sucks, because the experience of it will in fact suck for everyone involved. If you find yourself in a leadership position in a writing-averse culture, boy do you have your work cut out. How will you save your people from the septic floodwaters of Meeting Overflow?

It is not a mechanical template

For example, if you try to copy Bezos and some imagined "Amazon Way", you will at best create a poor facsimile, which will only degrade over time. Just like those who tried and failed and still do, to recreate the Toyota Way. Many are seduced by the allure of their Zen-like philosophy, lofty principles, and relentless success. Few notice how deep their writing practice goes, and how central it is to the ongoing success of their Way. So draw inspiration by all means, but work intelligently with your own context.

It will reveal -your- nature and values

If you fear that you might create a nightmare bureaucracy of soul-sucking process documentation and inter-personnel file redirection, you may need to stop right now and do some heavy soul-searching.

Maybe some more great points that elude my mind. But you catch the drift, yes? Ain't no silver bullet.

How to begin?

Before beginning, ensure the kitchen and the toilets are clean

10x of zero is zero. 10x of "we suck" is "we dead".

Writing practice creates leverage only if one's house is in order; viz. the team knows how to prioritise and how to reliably ship working software. The point of 10x-ing is to radically leverage competence, without diluting radically. As any seasoned businessperson will attest, dilution is relentless, and is a steep price to pay for a stitch in time.

"Dilution is relentless."

— Startup founder wisdom after their first Series B.

Decide whether it's for you and your team

IMO, teams and leaders fitting the following profile are well-positioned to evaluate and adopt "writing as a 10-xing strategy" ⁸:

• The team is small and lean, whether independent, or lurking somewhere in the shadows of a world-spanning mega-corp. And you all aspire to do more with less, without burning out.
• Your team builds and sells software products. Software service teams who trade time for money cannot hope to 10x in equity terms. They can, however, greatly improve overall profitability.
• Your house is in order. You are so busy shipping, you just can't spare anyone to intelligently culture writing systems that will unlock the next level of elite performance.
• You are willing to recruit a partner in crime. You, and at least one person you all trust, know that writing practices deployed strategically are key to punching way above collective body weight, without ballooning in size.
• You have a discretionary budget to start small today. You must hire an out-of-band coach, or someone from another team, or your own mentor to drive this change. If you want to DIY, spend money to clear your brain and calendar… hire an executive assistant, or get a competent person on loan from another team, whom you can delegate time-consuming busy work to. Your brain can't be swamped and strategic (creative / observant) at the same time.

Make no mistake, learning to create/deploy/adapt writing culture is a process of progressive team transformation. It is a long game that needs belief and buy-in. Nobody can change your beliefs about the value of good writing culture. Only you can do that. ⁹

Reason like we do for concurrency problems

Marginally reducing pressure off a contended main thread can remarkably improve throughput of a whole system.

Individuals are single-process doers. Teams are concurrent systems. Achieving lock-free coordination is a winning play. Good writing culture delivers that capability.

Choose a small goal…

A reasonable person may choose a reasonable success criterion, such as "Achieve a 10% notional 'gain of leverage' of one critical person in a team of ten, such that all ten win.".

"Gain of leverage" shows up as less polling/waiting, more proactive unblocking, less rework, higher value work product, higher quality thinking, more autonomy and improved collaboration, and uplifting experiences of real productivity.

Pick one in-demand person in one in-demand team.

Re-organize to inhabit "The Zone"

Make it so that getting into the The Zone, and staying there becomes standard, especially for you as a leader.

Learn from the best

I am sure my list is not comprehensive. There are more tools and ideas and techniques out there. Search, adopt, and adapt! No need to re-invent the wheel.

Here are some resources, in no particular order, to get the brain-juices flowing:

• A Note About Git Commit Messages
• Diátaxis: A systematic approach to technical documentation authoring.
• Inverted Pyramid: Writing for Comprehension
• The Checklist Manifesto
• Get your work recognized: write a brag document
• Debugging with the Scientific Method (video)
• Design in Practice (video)
• Design in Practice in Practice (video)

What does it feel like?

External peer recognition may be one of the most validating measures of all. You know your team is winning when even the skeptics and the rivals soften up and ask "How can we do what you're doing?!".

Yet, several internal measures are perhaps more personally valuable, and worth prioritising over outside admiration.

Your leadership potential is fully realised

Because good writing culture ended denial of mind attacks. The more senior you are, the more risk you bear of producing outcomes. Once upon a time your mind could barely keep up with endless interruptions and streams of consciousness arriving at you from chat channels, door knocks, and shoulder taps. Seniority rarely brought satisfaction commensurate with the weight of leadership.

Now you spend most of your time coaching, mentoring, and writing exemplary code. Now you rarely have to ask anyone for a status update, you can query a system for it. You routinely have well informed senior-level conversations with the right people, all literally on the same page.

The sense of progress is real

Because good writing culture ended rework. Forgetting used to be endemic. The same problems repeated with more joining the fray. Every day was groundhog day.

Now, you are still busy, but with real work, not busy work. You still wake up at 3AM worried about something, but that is the highest value thing. Your mind and body are sweating almost exclusively because of the difficult job of making, operating, selling, scaling your product.

Confidence of business continuity is high

Because good writing culture ended anxiety. Once upon a time, nobody really remembered why anything was done. Bus factors were high and rising. Velocity suffered when different people kept asking the same kind of questions again and again, pulling attention away from critical path tasks. Go to market failures seemed always around the corner. Stakeholder confidence in development was low, because it was an incomprehensible magical black box to them.

Now decision making is no longer psychologically fraught. Now, you and your team have a shared, sufficiently coherent, organisation-wide picture, from daily priorities to long term objectives. Everybody has confidence that when the unexpected happens, as it will, they have the strategic context, tactical information, and systematic situational awareness to rise to the challenge and thrive through it.

Everyone's default work mode becomes "Deep Work"

Because good writing culture ended meeting culture. No more nebulous "all talk, no do" meetings, no more frequent sync-ups that could be async wiki page updates, no more constant barrage of chat DMs and at-mentions.

Now when you see two or more people in a huddle or a live chat, it is them producing tangible value; pair programming, brainstorming, teaching and learning, reviewing and reflecting, deciding significant things, fixing outages, solving real emergencies.

Job satisfaction is high

Because with good writing culture people help people become Better, including their own future selves, and future colleagues they will never meet.

Once upon a time onboarding new staff was chaotic and slow. Mentoring anyone was impractical because everything was synchronous conversation. Developer outreach and marketing were distant dreams because there was nothing to begin with… you couldn't even hope to make an internal Engineering blog.

Now staff have better tools and skills to make their work and their impact visible and legible to colleagues, decision makers, and outsiders. They derive more satisfaction from teaching each other. They are better supported in their day to day lives as knowledge workers. They have more ownership over their means of production. They tend to have higher autonomy as well as a high degree of collaboration.

Remote work works

Because good writing culture made asynchronous work work. See: WordPress, GitLab, 37Signals, and pretty much any well-oiled remote-first workplace.

And guess what? With good writing culture, in-person work works even better!