We asked on Social Media:

Someone joins as/becomes a manager of technical writing team.

What would you advise they do in their first 90-100 days?

In this podcast episode, we go through the responses we received.

Transcript

This is the Cherryleaf Podcast.
Hello and welcome again to the Cherryleaf Podcast I’m Ellis Pratt, one of the directors at Cherryleaf.
This episode we’re going to look at what you should do if you’ve been given responsibility for team of authors or is responsible for a documentation project and you want to set some goals that can be achieved within a short period of time. For example, 90 or 100 days.
In addressing this topic, what we have done is pose this question or social media: on Twitter and on LinkedIn and also to the Write The Docs forum. And what I thought I’d do is go through some of these suggestions that those people have made on those particular forums.
When we posed this question. One person came back, Fabrizio Ferri, and asked the clarification whether this was for somebody who had an existing team of writers that they needed to manage or without. And so what we said was, let’s assume that they had an existing team of writers as managers.
So let’s start with the responses on the right of the docs forum and one from Aaron Collier and he wrote.
“Some thoughts:
• Get to know the members of the team
• Figure out the product area and how the product fits
• If not existing, determine a mission and vision for the team
• Conduct an audit of existing materials and processes, maybe something like strengths, weaknesses, opportunities, threats
• Determine a plan for how to address what’s found in audit
• Make sure the plan includes headcount”
I found this interesting because one of the things we’ve talked about on broadcast before is a strategy of explaining to people what the ultimate vision or goal is, explaining why that is important and explaining where everybody fits in to achieve that particular goal. And there’s consistency in what Aaron has said with that three-pronged approach.
SLB responded, (I can’t remember who SLB is):
“Get to know the team: strengths, weaknesses, working style, goals. Get to know the workload and roadmap: what’s coming up in the next 3 months and 12 months.
What’s coming up in the organisation that will affect the quantity, quality and type of TW work expected.
Who in management is a plus, minus or neutral as far as the TW team is concerned?
Is the team (number of people and range of skills) sufficient to handle the expected workload?”
Alia Michaels said, “in addition to SLB’s excellent points:
• What about evaluating oneself in relation to the team? Do I, as a manager, have to develop new skills to work with this team?
• Does the new manager have to ‘fill in’ for any missing skills or areas of expertise? If so, how can this be handled long term: training existing team members or hiring new personnel (or is being an individual contributor part of my responsibilities)? If I feel that training is needed, do I, as the manager, do the training, research training opportunities, or convince someone about this?
• Does the manager have to cultivate relationships elsewhere in the company so that the team can do its work effectively?”
Now that reminded me of a few managers I’ve had in the past where they’ve ended up having to firefight and get into the trenches as it were, and be part of the team that’s working to get the work done, and unfortunately they then didn’t have time to actually do any managing.
Suzie said, “take over any meetings and docs, ask the team what’s working and what’s not (meeting-wise, otherwise).”
And Daryl White had a number of suggestions as well. And he wrote,
“The manager must take on being the advocate and way keeper for the doc team within the org. To that end:
• Get to know what the other teams in the org expect/want from the tech writing team.
• Understand the role of TW within the business goals and how the team contributes to meeting those goals.
• Learn what is needed or missing to aid other teams (support, sales, customer success, product).
Of course, getting to know the team as it is and its current challenges and strengths is also vital, but I think the cross-org function is even more critical in those early days.
Understanding what the org needs from the team is going to drive how they manage the team. How they understand what is working and not. How they understand what each member is contributing and where they can help each team member grow to contribute better/more.
Understanding the team’s role within the org is also going to be very important in being the team’s advocate and defender in management meetings, budget meetings, and all the rest. Until they know that, they won’t really be able to do their job.”
Understanding what the organisation needs from the team is going to drive how they manage the team, how they understand what is working and not how they understand what each member is.
Again, that’s back to that thing important for vision. Why is it important? Where does everybody fit in?
The Write The Docs forum has a focus on developer-orientated documentation.

We asked the question, as I said, to a number of channels. Another one was LinkedIn. So let’s look at some of the responses from there, see if they differ.
So one came from Rebekah Lawrence, who is a technical author at Zephr. And she said,
“Get to know the team – what do they love/hate, what are their motivations, career objectives, hobbies. Get them to take you through the current tooling and the pain points and most useful features – and the style guides if they exist. Read the current docs, try using them to get started with the product if possible. Once you understand what your team needs, get to know the wider team and start making the relationships that can support the changes needed to get the team where they need to be.”
And Salman Rashid commented on Rebecca’s response and said
“Couldn’t agree more with the other comments. 1. Get to know your team. You are only as good as the team you manage/represent. 2. Familiarise yourself with the product(s) that the team is responsible for documenting. 3. Get to know all the other stakeholders across the business that the team interacts with on a day-to-day basis (SMEs, Engineers, Product/Project Managers, Scrum masters and so on). 4. Get to know your manager so that you can understand and buy in to the vision that you are expected to deliver. 5. Take a step back to look at the bigger picture so that you can start envisioning a content strategy and ops that will help you deliver your medium to long term goals as effectively and efficiently as possible. Lastly, remember that perseverance commands success.”

And Maiken Blok, she responded or suggested,
“Spend some extra time to get to know everyone at the team to build good and strong relationships. I recommend to include at least these topics: What are their expectations to you as a leader, what motivates them, what kills their motivation, what are their development plans and which challenges do they face right now.”
So the LinkedIn responses, there were fewer of them. They were saying more the tool first and then know the objectives of the organisation. Whereas with the Write The Docs, it was a bit more of the other way round.

We posed the question on Twitter. We got a variety of responses.
Adrian Warman said
“Have or work towards rock-solid:
– Version control and change management.
– Accessibility testing and compliance.
– Engagement and awareness processes to work with stakeholders.
– Multimedia capabilities eg audio/video.
– Learning & Development career paths for all.”

Craig Wright said.
Priority for me would be to talk to the team in-depth, get to grips with how they do things currently, what they view as the pain points. Then speak to other depts to get their view. Get the bigger picture of what’s going on.

Larry Kunz said,
“Picking up on Craig’s comment:
1. Find out from the team if they have what they need to do their jobs (tools, access to information, whatever) and set about fixing whatever is lacking.
2. Assess the team’s relationships with other parts of the company — development, marketing, tech support, c-suite — and with customers. Then set about fixing those relationships (where broken), cultivating them (where already good), or creating them (where non existent).”

And Bill Swallow commented
“These two are critical. Know your staff and know where and how things work well and where and how they break down.”
Now I say, for the Twitter ones, those that question will focus on relationships but also on operations. The tools that are needed to do the job and avoiding any problems or issues around that.
That reminded me of one of the early podcasts that we did podcast #36, which was an interview with Stella Crowhurst, are one of those we touched on in that interview was what she did when she became the manager of the technical writing team there. Now I remember that what she asked the team to do was to have a spreadsheet and to record on that spreadsheet the situations where the team encountered waste. The classic sort of Lean or Agile issue of waste due to repetition, waste caused by waiting, and by poor quality. That episode is one of the most popular episodes we’ve had on this podcast, and if you haven’t listened to it so far, I’d recommend you have a listen to it. It’s a very good interview; lots of useful content from Stella.
I also asked the personal in charge of managing projects at Cherryleaf for their thoughts on this topic. And she said,
“Anything I would have said has already been covered in the thread below.
I might add the new person must understand why they were hired for this role and what is important for the people doing the hiring – it’s important to understand where those people are coming from, what challenges and issues they face that they hope the new employee may resolve – know your audience.”
So what do I think? Today ,we haven’t been asked to act as interim documentation managers for a client. Most of the work that we do is project-based, and often we are using the tools that an organisation uses and moving from one tool to the next.
And so our experience of managing a team is different from that that you might see within a regular technical writing team. Having said that, there are three actions that I would consider in addition to those that have been mentioned already. And in no particular order one would be to do an inventory of what content exists and prioritise what is judged to be the important information that’s either missing or needs to be updated.
The second thing would be to celebrate for wins, identify where when you can celebrate the times when the team has achieved something because that can help make other people within the organisation aware of your team’s value. And it can help with the self-esteem of yourself as the manager and of the team as writers.
So that might be the publication of new content. It might be a milestone in the number of support calls that have been deflected by people reading the documentation. It can be a number of different measures.
And the third thing that I would do, which is to an extent being mentioned already, is to create understandable, communicable, measures or questions. What would those questions be? One approach you could use is to use the five pillars of content strategy that Rahal Anne Bailie developed when she was at Scroll. And I’ll provide a link to that in the show notes. And those five pillars are these:
One is that you have a way of measuring. That you’re meeting the organisation needs by asking the question and having a way of assessing how does what you do affect the business and that might be what return on investment you get from the content.
What factors do you use to measure or calculate any rate of return or return of investment?
What business problems or goals are being addressed by you providing content?
How vital is the content to doing the business?
Asking those questions and making people aware of how those are answered.
The second pillar in Rahel’s five pillars is user needs.
Can users do the thing that they want to do?
Can they succeed through the documentation that you provide?
Now the organisation’s objectives and the users’ needs can often coincide, but sometimes they’re different.
And you can ask the questions:
What kinds of content do you provide to your customers / end users?
Is there content that you wish could be providing if you could figure out how?
How do users access your content now?
The third pillar is the content needs.
Do you have the right information architecture? The right types of content, metadata or structures and outputs.
And do you have the right amount of content in terms of quantity and in terms of quality?
So within this, you can have quality measures like: is your content accurate? Legally OK? Complete? Findable? And also within that, you can ask questions like what kind of content do you currently produce? How many different formats? What is the condition of the content at the moment?
And the fourth pillar is around content operations, the operational needs.
Do you have an effective and efficient content operation the way you produce content?
The way you author it, you review it, you approve it, you maintain it, you measure it. nd what are the pain points, and can Those be resolved?
And finally, 5th pillar is the technology needs.
Do you have an adequate technical infrastructure to meet the requirements of all the other four pillars?
So by not looking at those different pillars you can create different measures of tracking what you’re doing. And there is a need to improve so that you have a benchmark. And you can start to build a roadmap so that people can see where you are and the direction in which the organisation is going.
So in this episode, we’ve covered a wide variety of opinions and ideas and viewpoints. We’re very grateful for the feedback, responses, to the questions we asked. And there may be other thoughts that you have in that. And again, like with all of our podcasts, you’re always welcome to give us feedback. Share your thoughts, easiest ways by emailing us info@cherryleaf.com. So that’s it for this episode. If you want to learn more about Cherryleaf from our technical writing services our website is www.cherryleaf.com. Apart from that, thank you again for listening to the podcast and I hope to speak to you soon.