Role of a technical lead (TL)

What does a technical lead (TL) do in a technical writing team? How does the role of a TL differ from that of a manager, or from that of another technical writer? In this blog post, I hope to answer those questions and to start a discussion where others can add their thoughts too.

I’ve been TL of a technical writing team for a couple of years. In fact, my current team includes people working in several roles: technical writers, developer relations engineers, instructional designers, and program managers. In the past, I’ve also been TL of a team that consisted solely of technical writers.

The TL role is interesting, challenging, and rewarding. I think the first thing to be aware of is that the role varies depending on multiple factors: the structure of the organization you belong to, the size of the team, the nature of the documentation and other content that you’re looking after, the audience for that documentation, and most importantly, the people in your team.

With all of that in mind, I’ll describe my role as an example.

What does a TL do?

A technical lead ensures that the team’s goals are in sync with those of the stakeholders, that the team can work happily and efficiently, and that everyone knows what’s going on.

In my experience, the most important (and most time consuming) part of the TL role is communication. As a TL, everything you do involves communication, whether you’re planning the team’s work for the next period, keeping your stakeholders informed about the team’s progress, or keeping the team informed about things that are happening around them. So let’s start there.

Communication

As a TL, I see myself as having two major communication goals.

A moth on the outside looking in.

The first goal is to keep my management chain and the product-area stakeholders informed about the work that the team is doing. What are our goals, how are we tracking against those goals, and what have we produced recently?

I do this in various ways, including the following:

• Write and then talk through informal periodic (e.g. monthly) status reports at pre-scheduled meetings. These meetings are very useful for me as well as for the stakeholders, as an opportunity to get instant feedback on progress and to ask questions about prioritization and overcoming blockers.
• Contribute snippets to periodic formal reports (sometimes called news letters) for higher-level leadership. This type of reporting is often onerous, as the content needs to be more strategic in nature than the informal status discussions and has constraints around format and length. If you can use existing templates or get the help of others in compiling these reports, so much the better!
• Ensure that we as a team publish announcements of our launches or other successes, using whatever channels are best suited in our environment.

Patterns made by crabs on a beach.

The second communication goal is to keep the team informed about the strategies and goals of our management team and of the product and engineering teams who’re building the product that we document.

The team is a unit, working on a subset of patterns that fits into a larger set of patterns. It can be hard for people to know how they and their work fit into the larger pattern. The TL’s role is to help team members see the patterns.

A few tips about communication:

• Err on the side of over-communication rather than under-communication. People may miss a message because they’re away or just too busy to pay attention right now.
• Use multiple communication channels: Email, chat, meetings, planning docs, and so on. People absorb information in different ways.
• Avoid falling under the curse of knowledge: that predisposition, shared by all people in the know, to omit what seems obvious. This predisposition makes it almost impossible for experts to explain something to a new starter. As technical writers, we’re very aware of the curse of knowledge. We know that the documentation needs to include information that may seem obvious to our subject matter experts. As TL, though, you might find yourself falling under the curse of knowledge too. You’re aware of activities and messages that your team and stakeholders don’t know about, but it can be hard to remember that they don’t know. When you receive an item of news, share it with everyone who might find it useful.

Building a framework for other people’s success

Another essential aspect of the role is creating a framework in which the team members can succeed. I find it helpful to remind myself of this goal, because it helps me to focus on the important elements of my role.

Part of creating that framework is to do regular and thorough planning of the team’s goals. Help people understand where we’re headed as a team.

Planning of team goals

In my current team, we do in-depth quarterly planning as well as high-level annual planning. The annual goals tend to be more strategic. They set the pattern for the quarterly, tactical goals.

For our quarterly goals, we use the OKR framework. OKR stands for Objectives and Key Results. We use the objectives to reflect our strategic goals. Often an objective corresponds to a theme in our annual strategy — something like “Improve the getting-started experience” or “Increase adoption of product X”.

We group our key results under the various objectives. Key results are more tactical (more task-like) and reflect goals that we aim to achieve within the quarter — something like “A design doc approved for user journey X” or “80% of onboarding docs complete”. So, an objective might stay the same across multiple quarters, while the key results grouped under it will change from quarter to quarter.

As with everything, communication plays a key role in the planning. As TL, I need to consult our stakeholders and management team, to find out what their goals are. I consult my team members on the details of their long-running goals and shorter-term goals. I put together draft OKRs, then review them in person with multiple groups of people before coming to an agreed set of goals for the quarter.

Of course, the job doesn’t end once the OKRs and strategic plans are created. We need to do periodic assessments of progress against the original plans, make adjustments where necessary, communicate those adjustments. If some goal has been significantly derailed, the TL is the one who’ll discuss readjusting priorities and communicate the results to stakeholders, management, and the team.

Creating specifications for junior team members to work from

Another aspect of building a framework for success is to create requirements specifications and design docs that the more junior team members or new starters can implement. As a TL, it’s often the case that you won’t be the one writing the docs even if you’ve done the analysis and design. Instead, you’ll hand the specifications over to another writer or group of writers. This is especially true if you have new team members who don’t yet have the depth of product knowledge required to design a significant doc update. I’ve touched on the topic of design docs and doc plans in two earlier posts: The power of a doc plan or design doc and Writing a one-pager to pitch a doc idea.

A content strategy doc is often useful to set high-level goals and define strategies for meeting those goals. For example you might create a content strategy doc to help the team and stakeholders outline the goals and strategies for the coming year. Or you might define a high-level strategy for a particular product area or user journey. Other team members can use the strategy doc as a basis for more detailed planning and designs.

I could write an entire blog post about content strategy docs. I’ll leave that for another time perhaps!

Mentoring

Another important part of a TL’s role is mentoring of team members. Mentoring isn’t confined to the TL role: any team member can mentor others. But for a TL, it’s a logical, natural part of the role. Typically, this type of mentoring involves working with team members to manage priorities, smoothing out any technical problems the team member may encounter, advising them on how to communicate with stakeholders, and helping the team member to decide whether a particular issue is on that they should take to their manager.

I think that the most important goal here is to help people find the best way to be successful in their roles. That means helping them figure out how best to complete their assigned tasks and making it clear to them that you’re available to offer advice.

How does the TL role differ from that of a manager?

Although much of the TL role involves working with team members, a TL isn’t a manager.

A Hakea seed pod, which reminds me of the Yin Yang symbol.

The focus of the TL is on the projects that the team is responsible for. The focus of the manager is on the people in the team. The manager helps team members reach their career goals and navigate any organizational complexities.

In reality, there’s no hard line between the two roles. The TL and manager need to consult often. They work as a leadership team, sharing responsibility for the well-being of the team.

In particular, TL and manager work closely together on strategic planning. The high-level planning affects the well-being of the team members, the assessment of the team size and the potential requirement to add more people to the team. High-level planning incorporates goals that stem from tech writer management as well as from the product areas whose docs we’re responsible for.

Many organizations have a hybrid Tech Lead / Manager (TLM) role, which is a blend of the two roles. The TLM role is all-consuming, and works only for a small team (fewer than 10 people) otherwise the TLM is swamped.

How does the role of TL differ from that of another technical writer?

Looking across the opening of Sydney Harbour towards the Pacific Ocean.

If you’re a singleton technical writer (that is, the sole technical writer working with a product team on a set of documentation), there are many similarities between your role and that of a TL. Singleton writers have to do a lot of planning and communication. The main difference is that they’re doing it for their own work only, not for a team.

Both TLs and singleton writers face a similar problem: how do you fit in any work on the actual documentation, when you’re spending so much time planning it, reporting it, and communicating with everyone?

Tips

A Huntsman spider on a biking map. The spider is on the inside of the glass, and my finger is outside.

The TL role can be a tough one. I hang on to the fact that by doing this role well, I’m guiding others through the tricky bits of a technical writer’s role and helping managers and stakeholders do their job too.

My top tip is to make sure you find the time to do the things that make your job rewarding for you. Make this part of your prioritisation exercise. It’s important.

For me, the best part of the technical writing role is when I can focus on the documentation and the users’ experience of the product through that documentation. If I can get in the zone for at least part of the day, by fixing doc bugs, or designing major doc updates, or best of all by actually writing a doc that helps a user accomplish a task, then I’m happy at the end of the day.

A happy TL makes for a productive team.

Another top tip is to learn the art of saying no. It’s actually helpful to stakeholders and other leads when you give a clear “no” backed up with reasoning and an explanation of the higher priorities that the team is currently working on.

Potentially, you could soften the blow with a suggestion on how the stakeholder can add the task to the queue for prioritisation in the next quarter. If the stakeholder judges the requested task to be of higher priority than current tasks, work with that stakeholder and the product leads to decide which tasks can be deprioritised. Include an estimate of the amount of time wasted when the technical writer(s) have to switch context and ramp up on a new task.

Wrapping up

What have a missed? Let me know. 🙂