Organizing the Docs Team at Linode

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Get more video from Redmonk, Subscribe!

Summary

KellyAnn Fitzpatrick of RedMonk and Andy Stevens (Technical Content Manager, Linode) discuss the organization and responsibilities of the six-person documentation team at Linode (including the types of documentation it produces), where the team is located in the larger org structure, and some of the professional backgrounds of team members.

Transcript

Kelly: Can you speak a bit more broadly about the types of documentation that Linode users can expect and which parts of that your team is responsible for?

Andy: Sure. So at Linode, there are three major types of documentation. There’s product documentation, which focuses on our getting started with product documentation or different product guides and more of their use cases. There’s API documentation and then there’s kind of our more expansive section of Linode guides and tutorials. All three of those things are authored by the members of the documentation team at Linode. So whereas sometimes engineering teams or developer teams will write their own product documentation, we have a person on the team whose sole focus is that. We have a person who is responsible for our API documentation and their main focus is that. And then we also have a number of writers from the community and writers on our team that author these kind of how to create a video streaming guide on React, video streaming app on React, or how to set up Canvas learning management software, or the list goes on. And while we have these focuses, everyone kind of also has a responsibility to make sure we’re continually producing that kind of content.

Kelly: I know a lot of tech writers that I talk to are the sole or lone tech writer at their organization or on their team, depending on the setup of where they are. But you have like an entire team, which is great. Can you talk a little bit more about the team’s structure, not only within the Linode org chart, but how the team runs itself?

Andy: Sure. We’re very, very lucky to be able to have a team of six writers. I know at some point there would have been only one writer at the company. And we’ve been able to grow our program because we have all that manpower. The team itself, in kind of an odd position, is structured within the marketing team, which is a little bit different than what you see in a lot of places where they’re on the engineering or product sides or they’re in a support role. This allows us to do a lot of really cool things, like how marketing publishes ebooks or white papers or benchmarking reports or all of this kind of collateral that is marketing at the core, but requires some sort of technical proficiency to do really well. And then within the team itself, everybody, as I said, has kind of one thing that their major focus is on. So that could be community engagement. We get a lot of requests from the general community and also from the community within Linode to update old guides or to offer new guides. We have the API documentation. We have the product documentation, and we have other roles that are almost more like editor roles where they’re working with a number of outside contributors or what have you to continually produce more and more content.

Andy: In terms of the makeup of the individuals. We have a very diverse team. A number of the writers have come on from support roles, but their backgrounds are anywhere from being an engineer or a website designer before they came to Linode, to cultural studies majors, to completely self-taught. And the end result of that is a very well rounded team that has core competencies in writing and problem solving and in asking questions. Because I feel like and I think this would be echoed amongst any technical writer that you might interview, is that you need to be able to realize the questions a user might have in advance to kind of provide the answers that they’re looking for before they even knew that they needed those answers.

Kelly: Yeah, that idea to get outside of your own level of expertise to kind of empathize with someone who’s not looking at it from the same point of view as you. And that does have this great kind of diverse background in terms of your team. And as someone who has trained technical writers who ranged from not cultural studies majors, but definitely kind of like post-structuralist-like poet types to like software developers who wanted to become tech writers, it’s great to see that that is happening elsewhere, that people are falling into technical writing.

Related videos

More in this series

Conversations (12)