Even though I’m not convinced that working in public is always useful, I am absolutely certain that being a prolific and also fairly decent (in that order) writer is always useful as an engineer.

Here I’m going to try explaining briefly why I think that is, and then provide some insight into how I approach writing in an engineering context.

Why?

  • To get better at writing. Yes, I realize it’s a bit cruel to include this recursive reference at the top of a list. Nevertheless, if you do find yourself believing that writing is a high-leverage activity for engineers, the only way to get better at it is to write often.
  • Async is better. In order to collaborate on any project, we need to communicate with stakeholders. Written artifacts allow this to happen asynchronously, and possibly even over long periods of time. Asynchronous communication is better, not only for remote work but for all work, because (a) assuming that all relevant stakeholders can attend the same meeting at the same time in a big org is bonkers and (b) most (all?) people are not able to provide their best feedback off-the-cuff in a 30 minute meeting stuffed around a conference table.

How?

  • Write lots. This is the only surefire way to get better at writing, and it’s the main reason I keep things like blogs around. I write a ton at work, but it’s helpful to zoom out a bit periodically and write about different topics/for different audiences. I’m not an amazing writer (yet!), but I keep sharpening the saw.
  • LNO. My manager once pointed me to a presentation/Tweet storm from a PM at Stripe which changed my approach to work forever. Basically, everything at work can be categorized into “leverage,” “neutral,” and “overhead.” “Leverage” tasks are those which you anticipate getting an outsized ROI on. “Neutral” tasks are those which you anticipate breaking even on. “Overhead” tasks are those which are necessary but low ROI. Your success at work depends on properly identifying which tasks go into which bucket, and investing your time and energy accordingly. My manager and I now have a shorthand that we sometimes use, especially in cases where it seems like we’re not seeing eye-to-eye on the amount of effort a task deserves. Instead of focusing on the concrete issue, we jump into a meta-discussion about how much leverage the task affords—this is usually at the heart of our difference. Once we agree on the importance of a task, it’s easy to agree on the amount of effort it deserves. Anyway, this is extremely important when it comes to writing, since any writing task is effectively unbounded. The LNO framework makes it easier to decide up-front how much effort a writing task deserves. For example, I treat most blog posts as “neutral” at-best, and therefore aim to spend no more than 30 minutes writing them.
  • Structure. A very effective way to get ideas onto a page quickly is to start with the outline and then flesh out each piece. That’s how I wrote this blog post—I wrote the introductory paragraph, and then I added “why” and “how” as headings, and then I added 1-3 word bullet points under each, and then I added a paragraph to those. If this was a “leverage” piece I probably would have started exactly the same way, but then spent more time editing afterwards.
  • Templates. There’s no reason to re-invent structure every time you write. I use all sorts of templates in my writing; some of them are formal enough that the templated structure is still visible in the final artifact (e.g. design docs which always have the same headings) and other times it would be difficult to tell that there was a prescribed structure initially. One framework that I’ve been investigating lately for technical/business writing is SCQA.