Writing as Strategy

You’ve probably heard the phrase “writing is thinking” before. The idea is that as you put thoughts into words, the thoughts themselves start to change, and new thoughts emerge. I’ve experienced the transformative power of putting words to paper, and it alone is a great reason to take the time to write. But there are also other, less well-publicized benefits to writing. Here are five use cases that I’ve found to be most useful and interesting.

1. Writing is managing

When I was early in my career, I’d get excited by almost any new idea that came my way. I’d read a blog post and send a message to my boss saying, “We’ve gotta do this!” Or I’d sit in on a phone call with a potential customer and feel the need to solve all of their specific problems, with little regard for the company’s overall strategy. Each time something like this happened, my boss would patiently remind me of the company’s goals and attempt to convince me that we should stick with the plan, rather than chase every shiny new object that caught my eye.

I soon realized that I was going to get excited about a lot of things, and there was no sense in trying to change this about myself. But I did have to admit that acting on that excitement by going to my boss with the idea was hurting my credibility. So I had to do something different. Writing as a form of self-management (and eventually as a form of managing others) is the best solution I’ve found so far.

When you take the time to write down your goals and the strategy for achieving them, in addition to the well-known benefit of forcing clarity, it also freezes a version of yourself in time that you can return to when you’re excited about a new idea. Instead of consulting your manager, you can consult your past self. This is often just as good. I’ve found by referring to my writing when I’m unsure what to do, I often get to the right answer quickly. It makes me a steadier and more self-sufficient worker. Even better, by staying on track, my efforts compound more over time.

2. Writing is engineering

Software is built by creating a bunch of small components—like a header, a button, a sidebar, etc.—and composing them into an overall screen. Each component is a mostly self-contained thing: it manages its own functionality internally and has limited interdependencies with the larger system. By building software this way, you can reuse components in multiple screens, so when you want to create a new screen, you have a starting point of building blocks that you’ve already created.

You can approach writing the same way, and reap the same benefits, for the same reasons.

Recently I was working with a software engineer on a test project for Lex, and I needed to send them a document with an overview of Lex and a few options for different directions we could take the project. Luckily, I already had a lot of the components of such a document pre-made, so I could copy and paste and lightly modify relevant sections from other documents I had already written. If I had to write it all from scratch each time, it would take too long, and I’d probably be tempted to keep it sparse and fill in any details on the phone or via chat.

The challenge, in both software engineering and in writing, is to find the right balance between up-front effort and just-in-time scrappiness. For some people, it’s easy to spend a whole day building beautiful scalable systems that end up never needing to scale because they’re based on a few critical false assumptions. For others, “do things that don’t scale” and “keep it simple” become terminally limiting mottos, preventing greatness rather than enabling it. Balance is the key.