How to become a 10X technical writer in the workplace
- Background
- Tip #1: Record your meetings with engineers to listen again later
- Tip #2: Respond quickly to emails and messages
- Tip #3: Iterate on content with ever-expanding layers of reviewers
- Tip #4: Put some work back on those who request it
- Tip #5: Learn to say no so you can focus on fewer projects with deeper engagement
- What are your tips?
Listen here:
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 documentation (it’s a dream, I know).
Granted, these storyteller podcasters shape and edit and likely rearrange the clips of their interviews for hours to construct the story flow. But they have a clear shape in mind, and it seems like they naturally evoke the needed details to paint the story arc. Doc interviews could work the same way if I could focus on the shape of documentation ahead of time (asking what goals users have, the prerequisites to the task, asking for a demo, evaluating the result, probing what could go wrong, etc.)
Tip #2: Respond quickly to emails and messages
Let’s move on to tip #2: responsiveness. The quicker I respond to emails and messages, the more people feel connected and listened to. Even if I can respond in a terse way (logging the issue as a ticket for further work later), this responsiveness helps build rapport and trust. In fact, knowing that often the faster I respond, the less detail I need to include, can be a motivator for responding quickly. (Also, my kids tell me that with texts, lengthy responses are a sign that I’m getting old. They also don’t use punctuation. My 18-year daughter gets freaked out if I use periods in texts. She says it makes me look formal and angry.)
I’m not quite sure how to respond quickly to email and messages without losing efficiency and flow with my current tasks. I know some productivity experts recommend shutting down email and blocking out all other distractions so you can focus. And yet, prompt responses seem to improve relationships and communication so much, I’m hesitant to let messages sit (and easily get buried and forgotten).
I’ve noticed that people seem to reach out to me more at work, in part because I come across as approachable — because I respond. People message me all the time through Chime, especially younger engineers. As a result, I’ve learned to feel more comfortable reaching out to them as well. This increased communication flow surely plugs into productivity equations, since learning to get information from others, quickly interacting with various people to find the right resources or contacts you need, can be huge in terms of its productivity boost.
In my mind, a 10X technical writer, especially at a big company with thousands of people, is one who can figure out who to contact, in which department, about various resources, access, permissions, or other knowledge, in a fast way, by navigating messaging and email. Communication, especially prompt communication, is at the heart of this productivity.
In a previous post about motivating users to provide feedback, I noted that prompt replies to incoming feedback encourages users to share more, especially as they’re usually still in the midst of some challenge and will often provide more details and ask additional questions. The email exchange builds a relationship of trust. But if you let days build up before responding, the conversation dies.
Tip #3: Iterate on content with ever-expanding layers of reviewers
Writing docs for complex content requires a few iterations to get right. Once I get the right SMEs reviewing the content, I try to take them through several rounds of reviews and edits before I get it to the needed level. Most of my documents go through half a dozen or more SME reviews before they’re ready for distribution. First drafts are almost always poor, but by the time I get to versions 7-8, the content looks solid. I try to go in with the assumption that I’m going to be generating lots of drafts before I get this content right.
For the first draft, I don’t spend too much time on language and granular details. I make sure I have the general shape and content chunking right. Most of the time, I talk SMEs through what I’ve written in the first draft (rather than having them read it) so I can gauge whether I have the puzzle pieces in the right order. Many times I don’t have the fundamental shape right, and I’m glad I didn’t spend more time finessing the content.
Getting engineers to review these docs is only the first step. After engineers approve it, then I expand the audience to include the product manager. And then the field engineers. And then the support team. The circle of reviewers grows wider and wider.
More perspectives usually enrich the doc, and while my primary purpose is to strengthen the information and remove any gaps or inaccuracies, I’m also making others aware of the documentation, aware of my role as an information producer, and aware of the value I’m adding to the company.
This awareness builds trust and lets others know just how to contact me when they have doc-related issues or requests. In short, expanding the circle of reviewers expands my own influence in the company, moving me more towards the 10X technical writer.
For more on iterative doc development, see Principle 9: Iterate and increment on content following an agile approach in my series on Simplifying Complexity.
By the way, when I review content with SMEs, I rarely give them more than 1-2 topics to review at a time. I’ve never met a SME who has the bandwidth to get through dozens of pages of content to review.
Also, although I’ll often include email groups that contain long lists of people (e.g., all field engineers, all support, etc.), I don’t expect much feedback from blanket requests like this. I also single people out and specifically ask them to review content.
Tip #4: Put some work back on those who request it
My colleague once gave me this tip, and it’s golden. Many times you will encounter people whose job it is merely to check boxes and make sure your work gets done. At work, we call these people “technical program managers.” It seems like all they want to do is check a box indicating that the documentation (and everything else for the project) is complete. (I know their role has more merit that I’m not really acknowledging here.) They can be quite annoying because they don’t seem to add much value other than to goad me to finish the work, hoping to hear the much-awaited “yes, docs are complete” response.
My colleague says that when people ask you to do something, find a way to put some of the work back on them. For example, you can ask a technical program manager to review some of the content. Or you can note that you need help tracking an unknown SME in order to gather more information. Or you can ask for more information about user profiles and environments.
You’ll find that as soon as you start putting some work back on these people, asking them to do something, they often disappear. It’s really ingenious. But Tom, how does this help you become a 10X technical writer? Aren’t you trying to get out of work with this tactic?
Not at all. To be a 10X technical writer, you can’t try to do everything yourself. The ability to delegate and distribute the work factors into efficiency strategies. I’ve also found that if I do put some of the work back on those who request it, and they do it, their effort shows real sincerity about their requests.
One story from my time as a Mormon stands out here. Once a visiting church leader (an area authority) came to a congregation to evaluate the leadership. As he entered the chapel, he found the local leader putting away hundreds of chairs all by himself. The next day the visiting area authority released the local leader from his position. Why? Because any leader who tries to do everything himself, without delegating and distributing tasks to others, even a task as simple as putting away chairs, will almost always fail.
I have a tendency with doc projects to want to do everything myself. This is one of my character weaknesses, I think. I don’t trust that others will do things, or if they will do them, that they will do them the correct way. By pushing back on people who throw tasks at my feet, it’s my little way of trying to distribute and delegate the work.
Tip #5: Learn to say no so you can focus on fewer projects with deeper engagement
Now let’s get to the heart of the matter. What is preventing me from being a 10X technical writer in the workplace? Aren’t I implementing all of these nifty tips? Yes, more or less. But the above tips don’t really get at the heart of the issue, nor do they explain why I felt I’d lost my edge at work.
Without going into too many details, the issues center around bandwidth and resources. We lost a couple of writers, and with various re-orgs and shifting managers, our team was basically cut in half. But our project load stayed the same. I felt like I had less and less time to go in-depth on any project. I started working more to compensate, even sacrificing some weekends, but it seemed that the work never ended. We had an open position to fill, but the hiring process was so difficult and onerous (as well as time consuming), we didn’t make much progress.
A while ago I attended an internal tech comm conference in Seattle where Anne Gentle actually gave the keynote. Later, Anne attended some of the sessions. During one session we attended together, the presenter (a technical writer) explained how she attends every project meeting, logs bugs, provides input on design and the feature roadmap. She keeps pace with the sprints, making sure the doc always reflects the latest work (even if it changes from sprint to sprint). This writer was fully immersed and engaged with the team, firing on all cylinders to contribute in every way.
After the presentation, Anne said this person was the classic 10X technical writer. I actually had never heard the word “10X” before to describe someone, but this adjective fit the presenter perfectly. I asked the 10X writer if she was a sole writer embedded with a somewhat small engineering team, or if she was part of a centralized writing group that provided docs for lots of different engineering teams. She said it was the former not the latter.
I’m fairly persuaded that the path to becoming a 10X technical writer can rarely be achieved in a writing group that is centralized. By centralized, I mean you’re a tech writing team that provides docs for 20+ engineering teams through the organization, and you bounce from group to group as they near releases and have documentation needs.
To become a 10X technical writer, you have to limit your scope, focusing in on a few projects with greater depth. You have to ramp up on a product, becoming a SME. You build test apps. You push tasks through the whole process, from end to end. You work closely with engineers, logging bugs and providing insight on the roadmap. You profile and interact with the users, and maybe even participate in usability testing. You immerse yourself learning the industry tech, and keep up with both internal and external news related to the product. You can actually do all of this if you just have a few projects.
But when you have many, many projects, and you’re constantly shifting from one team to the next, without any real continuity, always coming in as an outsider, like the incoming Santa Claus tech writer (“St. Techwriter”) that Larry Kunz once wrote about, who comes in at the last minute (Christmas Eve), swooping in from seemingly nowhere to write docs for a poorly designed app, saving the day with docs that clarify and illuminate processes that engineers failed to make simple — with this model you can’t provide deeper engagement on projects.
If you want to be a 10X technical writer, you need to reduce your scope so that you can go deeper. Right? If so, the questions become as follows:
- How do you say no to projects in order to reduce your scope?
- How do you get the resources you need to expand when needed?
- How do you immerse yourself in another team when you’re an outsider?
These are all questions for which I have few answers. The standard technique for pushing back is not necessarily to say no, but to size up the scope and then start plotting distant dates on a calendar. For example, “Sure we can do Project A, B, C, D, E, and F. Since Project F has the least priority, based on the amount of documentation required for Project F and the number of resources available, we can complete that in Q3. Of course we can speed up that timeline by either reducing the scope of the documentation or increase the available resources…”
That’s basically the equivalent of saying “no” in a politically tactful way. Given that Project F is probably launching in Q2, this response will likely frustrate them.
Last year we did tell some groups in a more straightforward way that we didn’t have bandwidth for their projects. I noticed some interesting trends result — the teams started posting job advertisements for technical writers to join their teams. This happened in at least two other groups in my organization. Had we continued to say “yes” to every project and run ourselves ragged, these positions might have never opened. Simply saying no led product owners to eventually admit that they needed to fund a position to do the work.
However, because these positions opened up on a specific team, these new writers will need to figure out many details for themselves — how to work with the group and track tasks, how plug into agile flows, what tools to use to author and publish content, etc. The benefits of a centralized doc group are that we already have this model figured out. Lone writers have more flexibility, but they also have more burden.
Overall, if you want to be a 10X technical writer, I’m convinced that you have to learn to push back in order to focus your efforts on fewer projects in deeper ways. Ironically, pushing back sort of undercuts the whole premise of being a 10X writer, because by definition a 10X writer can supposedly cover 10 times more territory. So I guess in conclusion, I’m a bit mixed. The 10X doesn’t necessarily mean the amount of docs written, but rather the impact of the tech writer role within the team. This impact extends far beyond just writing docs.
What are your tips?
I’d like to hear what your tips are for being a 10X technical writer at work. What are you doing to be more productive in your tech comm role? I want to hear your insights and strategies. Use the embedded survey below or the comment form. You can view the results here.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.