How to be a great technical writing leader

Before entering the software industry as a technical writer in 2020, I spent almost a decade as a freelance writer and editor for music, lifestyle, and pop-science publications. Across my twelve-year career I’ve held roles as an individual contributor as well as a project manager and a people leader, and I’ve learned quite a bit about how to set a team of writers up for success.

What follows are some of my thoughts on how to be a great leader of writers and content creators, drawing on my editorial experiences both inside and outside of the software industry. This is mostly relevant to remote-first orgs but should be broadly applicable to anyone leading an editorial team.

tl;dr:

Establish consistent and repeatable processes

Arguably the most important point I could make here is that you must establish clear, consistent, repeatable processes for publishing and project management.

All editorial work should revolve around the almighty final deadline. A good managing editor should be able to establish a steady cadence and maintain a publication calendar at least three to six months out so that all contributors have a consistent and predictable workload. This is often easier said than done, of course! But even a rough roadmap that’s subject to change is better than no roadmap at all.

To really be efficient, your writing team needs much more accountability than just a single due date on a calendar—they need project milestones to help keep them on track along the way. The best tool you can provide your writers with is a day-by-day, week-by-week framework outlining milestones from start to finish that they can apply to every project they tackle.

What repeatable processes look like in practice

This work begins by defining all of the different kinds of projects your team is responsible for: API documentation, blog posts, release notes, tutorials, etc. Each of these will have its own requirements for your direct team as well as stakeholders from other functions like design, engineering, marketing, and SEO.

Once you’ve identified all of the steps in the process for a given project type, then you can create milestones to break the project down into daily and weekly tasks that need to be completed on the way to the final publication deadline. There’s a fine balance to strike in terms of how granular to go with tasks and subtasks, and this kind of framework should always be a living document that changes over time according to the needs of your writers, editors, and other contributors.

To give an example, a team that I used to work with followed an eight-week cadence for new blog articles. This involved several rounds of editorial reviews from the first editor on up to the editor-in-chief, with weekly tasks such as requesting SEO reports and graphic assets, getting cross-team approval on headlines and hero images, and seeking out subject-matter experts (SMEs) to vet the technical content. Some outside collaborators were available with a 24-hour turnaround time, but others might’ve needed up to a week’s notice to be able to make time for our requests; in all cases, who to contact and what their preferences were for communication were always documented along the way.

At some point we determined that one of the editorial review steps wasn’t yielding very meaningful changes anymore—a testament to our team’s ability to arrive at a publishable draft more efficiently—and we were able to cut an entire week out of the cadence. That difference alone led to each contributor being able to publish (on average) seven articles per year instead of six—that’s a 16% increase! (More thoughts on metrics later in this article.)

Milestones give your writers a consistent and repeatable framework they can apply to every project, to take the guesswork out of the project management and give them the space to focus on what they do best: write excellent content. If you’re using a tool like Asana or Jira, you can create template cards with every task and subtask already defined for each type of project, so that all your writers need to do is fill in the details and the milestone deadlines and then start chipping away. Which leads nicely to my next point:

Err on the side of overcommunicating

Nobody should ever have to guess about where a project is at on its way to the final deadline. How can you ensure that your writers are actually keeping up with their project milestones?

Tools like Asana can aid in this by giving you a high-level overview of a project’s progress via checklists. But I encourage my colleagues to go a step further and provide routine status updates in addition to checking off list items, to provide a more complete picture of where they’re at and help keep the whole team aware of any potential delays or roadblocks.

What overcommunication looks like in practice

For example, at one publication where I served as an editor, there was a step in the process where our writers would often get hung up that involved obtaining a technical review from a SME outside of our organization. It was sometimes difficult to find the SME in the first place, and then it was often even more difficult to hold that person accountable and get them to follow through in a timely manner. If you checked in on the project’s Asana card, you’d usually see one of two things:

  1. A task labeled “SME Review” that hadn’t been checked off. The last update from the author was when they checked off the previous task a week earlier. Have they started looking for the SME yet? Have they found a suitable candidate? Has the candidate confirmed that they can meet the milestone deadline? Do they have any other potential cadidates if their first choice doesn’t follow through? Each of these pieces could take days to complete, but the actual time requirement is somewhat obscured by the simple task name, and there’s no way to know how this step is going just by looking at the card.

  2. An unfinished task labeled “SME Review” with a note from the author: “Contacted X, Y, and Z experts on Monday the 1st. No response from X, but Y said they could complete it by the 5th and Z said they might have time next week. If I don’t hear back from Y on the 5th then I’ll follow up with Z on the 6th—but just a heads up, this could potentially lead to a slight delay before the next editorial review.”

I think it’s pretty clear that the second scenario is always preferable. This ensures that all stakeholders know exactly where a project is at from day to day, and makes it possible for anyone else from the team to jump in at any point should they need to provide assistance or take over. This also makes it easier to anticipate when and where delays may occur, so everyone involved can be proactive about rearranging priorities to try to stay on track for the final deadline. They don’t have to be daily, and they don’t have to be polished; but these small status updates in between the milestones can provide a wealth of useful context to anyone tracking a project’s progress.

Individual contributors in remote settings will sometimes worry that they’re being annoying by pinging other stakeholders on multiple platforms (Asana, Slack, email, etc.), so I think it’s important to lead by example on this front. Let your people know that it’s always a good thing to seek confirmation that their messages have been received—it’s all too easy for a random notification to slip through the cracks. Make sure they know that you always appreciate their status updates.

Cultivate a culture of continuous feedback

Speaking of appreciation: providing thorough, constructive feedback is one of the best ways to show your writers that you appreciate their work and care about their professional growth. And you should make it clear that this is a two-way street—in fact, any and all feedback you’re able to solicit from your direct reports is a gift and should be treated as such.

As with routine overcommunication, the best way to foster a culture of continuous feedback is to lead by example. Give and receive feedback graciously; build multiple opportunities for feedback into your project milestones and retrospectives; and explore ways to provide feedback both privately and publicly across multiple channels.

What continuous feedback looks like in practice

For writers, feedback in its simplest form comes from editorial reviews. As you get to know your writers you’ll start to observe their idiosyncratic patterns and better understand the kinds of feedback they need to improve their work. Beyond line-by-line and draft-by-draft reviews, you should provide your writers with periodic (quarterly is good start) performance reviews to assess how they’re growing over time and offer bigger-picture feedback.

When you receive positive feedback from readers, end users, or collaborators outside of your team, be sure to spread the love internally. Share the wins with your direct reports as well as senior stakeholders so everyone has visibility on the great work your people are delivering.

When you refine your processes or introduce new tools as a result of feedback from your team, you should also make sure to highlight this so everyone can see that you’re open to listening and adapting to their needs. It can be a real morale killer when teams feel like their feedback always falls on deaf ears. Just as they need to know that you care about their professional development, they need to see that you value their ideas.

Advocate for your team with clear metrics

The business of “content” and the value of its creators is in a state of thorough re-evaluation lately thanks to the advent of large language models, which (for better or worse) actually can replace at least some of the work we’d normally assign to interns, copywriters, or proofreaders.

That’s a can of worms I’m not particularly interested in opening for this article, but I bring it up to underscore how important it is for content leads and managers to advocate internally on behalf of their writers and editors. This is particularly crucial for software companies, where leaders who arise from careers in engineering sometimes have a tendency to undervalue the work of their “less technical” colleagues in marketing and communications. When tech companies do layoffs, it’s often these departments that get hit first and hardest—and that was true long before anyone had ever heard of ChatGPT.

How do you communicate the value of your team in terms that executive stakeholders can easily get behind? Through simple, agreed-upon metrics and KPIs that directly connect to the company’s North Star—likely revenue and/or user count.

Technical writing is an interdisciplinary function that can find a home in the org structure under engineering, marketing, product, or developer experience teams—and there are pros and cons for each. Regardless of where they live, technical writers tend to touch many different communication surfaces and so they share at least some of the responsibility for driving conversion, satisfaction, and retention.

What good metrics look like in practice

When deciding on metrics for your technical writing team, consider a healthy mix of quantitative and qualitative data. Set goals based on both deliverables (things that are directly under your control) and user behavior (things that are less predictable but nonetheless can be influenced, and traced back to work that your team delivered).

Don’t lean too hard on vanity metrics like social media engagement, but don’t discount them entirely—they can be useful to help determine what kind of messaging and content strategies resonate the most with your target users. If you (or your colleagues in marketing) have robust reporting processes in place, keep track of how the content your team publishes leads to deeper engagement with the product itself: conversion, email newsletter signups, likes and follows on social media, etc.

If I were to take ownership of an open-source software company’s technical writing program, I would start by setting quarterly goals based on the following metrics:

User satisfaction can be tricky to evaluate over time. When it comes to documentation, there are a few different ways I’ve found to gauge satisfaction:

  1. Routine surveys – once or twice per year, ask users to fill out a survey that includes questions about their satisfaction of the docs. This is a great way to observe how big-picture initiatives like content audits and deep editorial revisions perform over time.
  2. Realtime feedback forms – add a form to every page that prompts users to comment on what they liked or didn’t like. These in-the-moment experiences of frustration and joy can also show you how users think about their problems and how they expect your product to solve them, which can be really useful for future initiatives.
  3. GitHub and Stack Overflow – GH issues and SO posts can expose the areas where users find your docs lacking; once you’re properly calibrated on the signal-to-noise ratio of this kind of feedback, you can start to suss out patterns and use them to help inform your project roadmap. In this realm, it’s often the case that “no news is good news”—a lack of reports about problems with your docs is a pretty good sign that your team is meeting users’ needs.

When advocating for my team’s work internally, this is one of the best one-two punch combos I could deliver:

When things go right, your technical writing team can become a well-oiled machine with efficient, repeatable processes that you employ to draw in new customers, delight your user base, and cultivate superfans from your developer community—what more could your company ask for?