Summary: Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Background The term “10X engineer” (pronounced 10-ex) is sometimes used to describe engineers who are ten times more productive than other engineers. It describes someone who is simply more efficient, capable, and accomplishes more than others. The Silicon Valley Dictionary explains: “10X-engineer”: A concept sometimes used in Silicon Valley to describe an engineer that is 10X more productive than an average engineer although the 10X metric is figurative. Sometimes referred to as “Ninjas”, these engineers are highly sought after by all tech companies Jim: You gave me 100 resumes but none of these guys are 10X engineers. Why hire a few of these guys to slow us down when a 10X engineer is so much more productive? For more on this term, see 10X Engineer Series. What has prompted my interest in becoming a 10X technical writer? Well, lately I feel like I’ve let my edge slip a bit at work. I don’t feel as influential and effective in the workplace as I feel online through my blog and podcast. I’ll return to this idea a bit later in this post (in Tip #5), but to get moving towards the 10X goal, let me throw out a few simple strategies first. (Note: In an earlier version of this post, I used the term “rock star” instead of 10X, but some commenters pointed out that “rock star” is a gendered term that is somewhat problematic. I like 10X better anyway, as it more closely gets to my larger desire, which is increased productivity, not increased notoriety. In the revision of this post, I expanded the content in many places, approximately doubling the length and replacing a tip.) Tip #1: Record your meetings with engineers to listen again later With developer doc projects, engineers can quickly jump into excessive jargon and assumptions about your technical knowledge and familiarity with the code. This can be like a firehose of information that is too overwhelming to comprehend fully at the time (at least not to the extent that one can write documentation). If you can’t absorb the information in the meeting, you might need to set up multiple meetings with engineers, tiring their patience. Or you might need to rack your brain for all the details that you’ve forgotten. Or take up study of the topic on your own. What’s the solution for more productive meetings with engineers? Record the meetings! When I record meetings with engineers, I can go back over what they say numerous times and slowly piece the details together. Most online meeting tools (e.g, Chime) have a record function, and in-person meeting tools like Evernote also provide recording capabilities built in to the editor. If I have to delay a project for a while, having the recording to listen to allows me to refresh my memory perfectly even after weeks of focusing on other projects. Almost no one objects to being recorded, and when I produce documentation that recalls all the details at a perfectly granular level, SMEs are really impressed. I remember one meeting I had with a PM at a gamification startup company. The PM (a former engineer) outlined a complicated technical concept that was over my head at the time. But I recorded it with Evernote. All I needed to do was write a one page doc topic. I leveraged the recording quickly to generate the doc — getting the technical terms and phrases just right. The PM was impressed at how accurate and on-target the doc was — from just one short meeting. Ideally, I’d like to get more expert at pulling information out of engineers’ heads similar to how storyteller podcasters (e.g., Ira Glass with This American Life) can pull information out of interviewees in a story format. Theoretically, all the needed technical knowledge is inside the engineer’s head, but it often comes out in random structures and tangents. I want to learn to shape and control that information so that essentially I can just clean up my recorded notes and turn them into documen
