I help small B2B SaaS development teams deploy writing culture as a 10x-ing strategy.


"10x-ing" is about creating remarkable leverage relative to where you stand, not some arbitrary absolute degree of it (there is no such thing). The closer you look, the more you will notice elite performers in your peer group. The proverbial 2x, 5x, 10x teams. Maybe even better. I happen to think writing maketh the 10x Developer. More so, the 10x development team.

Good 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 1.

What team is a good fit?

Your "two-pizza" B2B SaaS product team that gets all of this, but is stuck at a local maximum.

This only works if you reliably ship working software. We aim to scale that capability without needless dilution. As any seasoned businessperson will attest, dilution is relentless, and is a steep price to pay for a stitch in time.

I'm also not here to change your beliefs about the value of good writing culture. Only you can do that. I'm here to help you beat the averages 2 by actualising your conviction.

So if…

  • You run a small, lean B2B SaaS product engineering team.
  • That aspires to do more with less, without burning out.
  • That knows writing deployed strategically is key to punching way above their body weight, without ballooning in size.
  • Yet are so busy shipping, they just can't spare anyone to intelligently culture writing systems that will generate that leverage.
  • And has a discretionary budget to start small today.

… then let's talk.

Working together

Tailored consulting engagements.

If you match this description, or you know someone who does, I would love to hear from you / them at [email protected].

We can trade email about building good writing culture. We can get on a call if things get really interesting. And I can tailor a consulting engagement if we find reason to act now.

How to begin?

Think concurrency. Start small. Help one key busy person free up 10% of their work week.

It helps to 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.

Small goals are great beginnings. 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.

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

What does 10x-ing feel like?

You know you're winning when they ask you "How are you doing this?!".

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!

What sort of writing?

Types of collaboration-oriented writing in my developer toolbox.

Collaboration-oriented writing has been core to my process as a business and tech professional for nearly two decades now.

I know it has reliably made me a better colleague, made us excellent together, and enriched the work lives of others. Some of my best days have been people telling me, years after the fact, how much they benefited from stuff I or my like-minded colleagues wrote down and made useful back then. My colleagues report the same experiences.

I use the following types of writing in my development work, listed in no particular order.

  • In code: naming things (functions, APIs, domain entities), doc-strings, in-line comments
  • To ship: commit messages, code reviews, development-time notes, checklists and runbooks
  • To know: release notes, architecture decision records
  • To plan: proposals, project plans, research notes
  • To improve: bug reports, post-mortems, critiques
  • To use: READMEs, usage guides
  • To teach: tutorials, onboarding programs, blog posts
  • To design: rationales, concept notes, architecture
  • etc…

This is not a list of prescriptions. One must choose well and make writing systematically useful, tailored to a team's orientation, mandate, and goals.

How do I think about software in general?

Things I hold dear.

I love building software. I enjoy writing for it and about it. I delight in helping others do the same. B2B SaaS happens to be my wheelhouse 3. And I sorely want the world to have many more such high-functioning teams, where people like me can thrive.

To that end, I hold these things dear.

Why do I care about any of this?

Selfishly, I want the world to have more places where people like me can thrive.

Over the last nearly two decades of professional life, I have experienced working in obscure pint-sized teams that punched way above their headcount, and in obscure little teams that fell far below their potential.

Personal experience, 20/20 hindsight, and grapevine conversations have convinced me that their unreasonable effectiveness stems from solid cores of writing culture they built deliberately, for their needs. That is how they got very good at building and shipping together, succeeding through high growth and sharp downturns, all with low headcount and low attrition.

Whether on staff or as consultant, I thrived and grew working with the good ones, and narrowly avoided burning out with the also-rans. So have many friends and colleagues.

I've had the opportunity and privilege to help build, sustain, and exemplify collaborative writing culture at those places. I had the base and conviction to do so because, luckily, writing became core to my process early in my work life.

Will it surprise you to know that I dearly want the world to have many more such high-functioning teams, where people like me can thrive?

Slow is smooth and smooth is fast.

— the SEALs


  1. Consider the widespread influence of the late great Paul Erdős (1913—1996), Mathematical collaborator extraordinaire. Guess how his influence persists across space and time? He deliberately co-wrote Math papers with over five hundred other people. And it's not just the incredibly brainy people with finite Erdős numbers. Even I, frequent failure of college Mathematics, holder of an uncountable Erdős number, have been positively influenced by The Man Who Loved Only Numbers. Mere knowledge of his resolute pursuit of Mathematics as a social practice is an important reason why I buy into the idea of "learn generously". A practice that enriches my life greatly, and one I wish to see more of in the world.↩︎

  2. No we are not going to secretly refactor everything into Lisp because paulg said that's how a small team can beat the averages.↩︎

  3. Dots only connect in reverse. Over the last two decades, I frequently happened to market, sell, co-found, product manage, test, operate, code, hire for, learn, use, teach software things. SaaS, mostly B2B, has been a core thread through all of that career vagabonding. Now, that is my wheelhouse!↩︎