How to Grow a TechDocs Team
Getting a handle on technical documentation is an essential part of any software project, yet this fact seems to get forgotten by most companies during their staffing discussions. Rarely does a tech startup co-founder think to hire a technical writer as part of their initial engineering team. Many companies do not even have a single dedicated person on documentation. So, let's start there.
NOTE: This is the second article of a three-part series. The first part discusses strategy while the third part wraps up with some more in depth discussion.
Team Size: 0
Even without a dedicated documentarian, your company can still use the strategies outlined in this post. Instead of a formalized TechDocs team, create an internal meta-team composed of docs-curious engineers, designers, managers and marketers. This meta-team should start with the Platform and Policy tier, collaborating to create company-wide resources that everyone can use. A regularly-scheduled Doc Day once a month (or even once a quarter) can keep the forest fires contained, even if the backlog never really seems to get any smaller. Individuals can be tasked to #WriteTheDocs for important projects, or assign themselves as the de facto Docs DRI for their team. When working on docs, don't forget to Put A Number On It to hold yourself accountable and have success stories to use when making the case for your first full-time documentarian.
Team Size: 1-5
You don't know how happy I am that you're reading this section. That means that your company has taken a leap of faith, realized that technical documentation is crucial to the success of their product, and put their money into action by hiring a dedicated documentarian. THIS IS AWESOME! (Cue "Everything is Awesome" from the Lego Movie soundtrack).
No one at the company is even sure what that word documentarian means yet, but the hardest part is already over. So, where do you start?
1: An Army Of One
If you're the only documentarian at your company, congratulations! You're the Director of Technical Documentation now. Whether or not you have that title, that's your job. You are not there to write docs. You are there to run a doc-writing program.
Advice: You should focus your time primarily on Platform and Policy (50%), with Mentorship and #WriteTheDocs both consuming roughly 25% of your time.
Capacity:
- Platform and Policy (50%): 1 platform improvement per quarter, 4 per year
- Mentorship (25%): 1 engagement per quarter, 4 per year
- #WriteTheDocs (25%): 1 major writing project per quarter, 2 per year*
*If you have a #WriteTheDocs deadline shorter than 6 months, cut into the Mentorship/Platform time budget to accomplish it. In general, try to avoid these large writing projects at this stage.
Justification: It's very likely that your company has more engineers than it does documentarians at this point. By investing in Platform and Policy, you can activate your engineers to be perfectly adequate documentarians in their spare time. Your Mentorship efforts will help them develop a better culture. And when it's really important, for about a quarter every year, you can roll up your sleeves to #WriteTheDocs and get to the wordsmithing you love to do.
Growing: You know that your company needs more than one documentarian, but you need to prove it. You're the expert and also the experiment that they are using to decide if they should invest further or not. Pay close attention to your metrics and make sure that you can prove the ROI of your work. Those stories will support you when you make your case to hire the next one, two, ten or twenty documentarians.
2: Two Minds Are Better Than One
You did it! You proved your value, asked for more help, and they said that most magic of words: YES!. So what should this new person be doing? More of the same? Should you hire for someone who is a generalist, more of a writer, or more of an engineer? Well, it depends.
Advice: A team of two still isn't enough to specialize. When hiring for this second role, you'll need to take a good look at yourself and at your company and try to figure out where your strengths and weaknesses are. Hire someone who is strong where you are weak. If you have a solid engineering background, or a engineering staff who is willing to help build out your docs platform tooling, then there's no need to hire someone with specialized engineering skills. You might do better investing in someone with a strong writing background, or vice-versa.
Either way, at this stage you will still be focusing on Platform and Policy and increasing your capacity for Mentorship. It still doesn't make sense to spend any additional individual contribution time on #WriteTheDocs, but having two people will double your output. One person should take the role of Mentorship Lead and the other as Platform Lead.
Capacity:
Overall:
- Platform and Policy (37.5%): 1.5 major improvement to the platform per quarter, 6 per year
- Mentorship (37.5%): 3 engagements per quarter, 12 per year
- #WriteTheDocs (25%): 1 major writing project per quarter, 4 per year
Person 1: Mentorship Lead
- Mentorship (50%): 2 engagements per quarter, 8 per year
- Platform and Policy (25%): .5 major improvement to the platform per quarter, 2 per year
- #WriteTheDocs (25%): 0.5 major writing projects per quarter, 2 per year*
Person 2: Platform Lead
- Platform and Policy (50%): 1 major improvement to the platform per quarter, 4 per year
- Mentorship (25%): 1 engagement per quarter, 4 per year
- #WriteTheDocs (25%): 0.5 major writing projects per quarter, 2 per year*
*If you have a #WriteTheDocs deadline shorter than 6 months, cut into the Mentorship/Platform time budget to accomplish it. In general, try to avoid these large writing projects at this stage.
Justification: You're still too small to make any kind of a real impact as individual contributors. Focusing on mentoring engineers to be better writers and building out your platform with more guidance docs is the best way to spend your resources.
Growing: Pretty soon someone is going to ask, "Why do we have two tech-writers on staff, but they spend very little of their time actually writing docs?"…
3: Three's Company Too
Great news! Your dynamic duo is doing a great job and despite some lack of understanding of exactly what you do here the company has decided to give you another person. I think you know by now what this person should be doing: focus on writing!
Advice: As usual, you want to hire for your weaknesses, and your weakness at this stage is the lack of a dedicated writer for important projects. You need a Writing Lead. Your first two folks should keep on keeping on exactly as they have been.
Capacity:
Overall:
- Platform and Policy (33.3%): 2 major improvement to the platform per quarter, 8 per year
- Mentorship (33.3%): 4 engagements per quarter, 16 per year
- #WriteTheDocs (33.3%): 2 major writing projects per quarter, 8 per year
Person 1: Mentorship Lead
- Mentorship (50%): 2 engagements per quarter, 8 per year
- Platform and Policy (25%): .5 major improvement to the platform per quarter, 2 per year
- #WriteTheDocs (25%): 0.5 major writing projects per quarter, 2 per year
Person 2: Platform Lead
- Platform and Policy (50%): 1 major improvement to the platform per quarter, 4 per year
- Mentorship (25%): 1 engagement per quarter, 4 per year
- #WriteTheDocs (25%): 0.5 major writing projects per quarter, 2 per year
Person 3: Writing Lead
- #WriteTheDocs (50%): 1 major writing project per quarter, 4 per year*
- Platform and Policy (25%): .5 major improvement to the platform per quarter, 2 per year
- Mentorship (25%): 1 engagement per quarter, 4 per year
*Now is the time to take on those large writing projects you've been deferring.
4, 5: Do More With Less
Grow that team!! Your next two hires should follow the same priority schedule as before.
Advice: #4 should be a TechDocs Mentor, focusing on more Mentorship, and #5 should be a dedicated Platform Engineer for your growing body of policies and tools.
Capacity:
*NOTE: Your three leads will keep going as before, so we won't bother repeating that breakdown here.
Overall:
- Platform and Policy (33.3%): 4 major improvements to the platform per quarter, per year
- Mentorship (33.3%): 8 engagements per quarter, 32 per year
- #WriteTheDocs (33.3%): 2 major writing projects per quarter, 8 per year
Person 4: TechDocs Mentor
- Mentorship (100%): 4 engagements per quarter, 16 per year
Person 5: Platform Engineer
- Platform and Policy (100%): 2 major improvements to the platform per quarter, 8 per year
Justification: By the time you're a team of five (5), you've probably got some bespoke tooling, and need a dedicated engineer to maintain, operate, and develop it. Mentorship is still your best bet, and doing 32 engagements per year allows you to service a medium-sized engineering organization. If we assume that each engineering team is about five (5) people on average, that means your team of five (5) is mentoring a group of ~160 engineers every year. If that's all the engineers, great! If that's 50%, that's still pretty good! Your ratio makes a big difference here.
If you're like us at Twitter, with a 750:1 ratio, this is still not really enough, as that's only about 10% of the engineers who are receiving mentorship each year. Hopefully they will talk to the other 90%, but we can't really rely on that, now can we?
Growing: With a team of five (5) people, you're probably going to notice a major vacuum in leadership. Your next hire should be someone to function as a dedicated manager for this growing team.
Team Size: 6-11
Now that we've seen what 0-5 looks like, in a lot of detail, the next tier of growth should be fairly intuitive. I'll just sketch out the basics:
6: Coordination and Management
For any team of five (5) people or more, you need a dedicated manager. It's too much overhead for the leads to constantly explain the direction and purpose, and stand-ups are getting a little chaotic because your Tech Docs Mentor spends a lot of time explaining the needs of the numerous teams they are working with, while your Platform Engineer gets tediously nerdy about the details of why your docs publishing platform crashed (again) last week. Someone needs to get this crew on the same page, and needs to explain this growing expenditure to the higher-ups, and field in-bound requests from other teams and organizations for your help. Your TechDocs Manager will do all of those functions without batting an eye, and still remember everyone's birthday, and plan regular off-sites to keep everyone glowing with happiness, by positively reinforcing your successes… They can also spend their time focusing on hiring the next 5 to 95 people that will make up your organization.
7 to 10: Grow and Specialize
The next four (4) hires should look something like this:
- 7: +1 mentorship
- 8: +1 writing
- 9: +1 platform
- 10: +1 mentorship
At a team size of ten (10), your roles will be: 4 mentorship, 3 platform, 2 writing, 1 manager.
You'll notice a small shift in priorities here, with less emphasis on platform and more on mentorship and writing. You have your first dedicated Tech Writer at #8, cranking out eight (8) projects per year by themselves. The beauty of scalable tools is that they need less and less investment over time, not more, so your two (2) dedicated Platform Engineers, and their lead should be able to keep up fine. The cross-functional leads will specialize more, and stop trying to do everything at the same time, focusing just on their niche.
11: We Need Some Structure
At this point we have three (3) full time mentors, with a lead, two (2) full time platform engineers, with a lead, and one (1) full time writer, with a lead, and a manager overseeing all of this glorious documentation activity.
Should we continue like this ad infinitum? Is there something else we are missing?
There is. Your writers are cranking out 12 projects every year, and your mentors are talking to 56 teams a year (~300 engineers). Those engineering teams are probably writing at least one documentation project for each team, maybe more. So you're seeing a growth in docs of about 60-70 projects a year. You've got good tooling for search, but it's still hard to dig through this massive corpus. You need someone to organize the universe. You need an Information Architect.
Your #11 hire should be someone who works entirely on Information Architecture (IA). This person will create vertical pillars through your docs focusing and segmenting the readers, making sure they can easily browse their way to success, in addition to search.
Team Size: 12-20
As you grow beyond this, you'll need to incrementally scale each effort. As the separate functions within your now-massive TechDocs team grow beyond five (5) individual contributors (ICs), it's time to promote those leads to be managers, and make sub-organizations that are independently managed.
Your former TechDocs Manager becomes a Director of Technical Documentation. Your leads become Mentorship Team Manager, Writing Team Manager and Platform Team Manager.
- 12: +1 mentorship; mentorship lead → manager
- 13: +1 platform
- 14: +1 writing
- 15: +1 platform; platform lead → manager
- 16: +1 writing
- 17: +1 writing; writing lead → manager
- 18: +1 IA
- 19: +1 mentorship
- 20: +1 writing
At a team size of twenty (20), your roles will be:
- 5 mentorship ICs, 1 mentorship manager
- 4 platform ICs, 1 platform manager
- 5 writing ICs, 1 writing manager
- 1 director.
Team Size: 20-100
So, I kind of lied. I'm not going to tell you exactly what to do after this point. By now you're the Director of Technical Documentation, with four (4) teams under you. It's likely been a number of years to get here. You probably know what you need, and you know how to grow your team responsibly.
That said, it's worth thinking about your mentorship program and tooling. TechDocs should own docs publishing, internally and externally, as well as information discovery and internal education. Maybe you've got an internal full-text search engine by now? Maybe you're running classes on writing, or just running classes on engineering topics? Maybe you're looking at dashboards of engineering writing activity? Maybe your platform engineers are making interactive documentation tools, so customers can execute examples directly from the browser against real APIs? Maybe you're getting your company policies updated so that documentation is a part of the engineering ladder for promotion? Maybe you're not just consulting with teams, but actually embedding mentors and writers full-time, or maybe just full-time-for-a-quarter?
Grow your team in a way that makes you proud, and don't forget to take some time to write the next best version of this blog post. In fact, go further than that. Release your tools into open source. Send your documentarians out to speak at conferences. Do more. Be part of the community. Give back. Lead your industry, not just your team.
And through all of it, never forget: Docs or it didn't happen!
Next: Discussion
I hope this description of how to grow a team proves valuable to you. If you do go down this path, there are a few points where you may want more clarity. Read on for a discussion between myself and my esteemed coworker Greg Poulos (@gregpoo). If you haven't already, you may want to check out Part 1: A Scalable Strategy for TechDocs.