Earlier this week, I was asked my opinion on whether a Documentation Manager was needed when the individual Technical Authors are embedded into Agile project teams.
My response was that a Documentation Manager mainly provides people management, project management, process management and content management. If a Technical Author is a member of a software project team, then that team’s Project Manager is probably providing the people management and the project management to the writer.
That leaves the need for someone to manage the processes and manage the content. I suggested managing the content could be done by someone with the role of Editor (or “Content Wrangler”). They might also look after the processes, or they could have another writer take on that responsibility.
It’s then a decision as to whether the organisation sees these roles as senior to the technical writing positions, or as a specialism and consequently on the same job grade.
It does leave the management of the writers’ career progression falling through the cracks, unfortunately.
How do others deal with this issue?
Hi Ellis,
The organisation I work for started down the Agile track a number of years ago – trialing it on a major development release.
We had already lost the Documentation Manager position some months before and by the time I moved onto the project development had begun, processes for design, development and QA were in place but documentation had not been considered. I have found the loss of the Doc Manager within the organisation affected the documentation team’s ability to be involved in process planning and design, estimating workloads and agreeing deliverables to support the products. We lost our advocate and voice at management level so became a very reactive department.
When your Technical Authors are embedded within SCRUM teams and there is no agreed list of deliverables we end up with different deliverables being shipped as the SCRUM teams decide what they can produce.
As the Senior Technical Author I have been looking around the organisation for someone to pick up this governance role which sits across the teams (I cannot do it as I am supporting three SCRUM teams so the others operate in isolation).
The Doc Manager not only looks after the career path of the authors within their team but they provide a layer of documentation governance and quality control that guarantees a level of consistency in the documentation artefacts and quality of the information being shipped.
I personally lament the loss of our Documentation Manager. The Technical Authors in my organisation now report to different managers at the different sites who have differing agendas, opinions and values on the documentation set.
Like a ship without a main sail we drift on the tides.
Hallo Ellis
Great discussion! I agree with the gist of Rob’s comment. A documentation team manager plays a vital role. Technical writers need a manager who understands the domain of technical communication, and can co-ordinate the team’s activities accordingly. I work in an agile environment, where the writers are embedded in the development teams. We have a technical writing team lead. We also get together regularly as a team and manage techcomm- specific strategies and projects across the team.
Cheers, Sarah
Hi Ellis,
I agree with Rob and Sarah.
We have a Documentation Manager for each product who manages the writers, (not all project managers want to manage writers). Our TechCom manager is writer’s representative at the product management level. The manager drives our regular interlock meetings with all the stakeholders in a product such as R&D, Writers, Support Team, Sustaining etc. Having a Documentation Manager exposed at the product management level ensures that we have a face and voice at that level. She is also the best source of communication for all major decisions.
I have worked in a project where I was a sole writer and my doc manager had no involvement in the project management. It results in a little ambiguity, lack of clarity for writers and may affect the overall productivity of the writer as the writer is juggling all balls in the air.
Having writers embedded with the Agile teams is a great idea. Eliminating the documentation manager role: not so great.
From a corporate level, there needs to be some level of consistency across all the products and someone to advocate for the content strategy across domains. Implementing the strategy is not just the domain of the product managers but the writers as well. Without some level of guidance that is divorced from the individual teams, there is no strategy. What Rob and Sarah say is true on many levels and without someone guiding the writers across teams and advocating for the content strategy across the products, you have content anarchy.
Great article.
I think you can be both. I’m a Documentation Manager, but like many, I still write, and I am also embedded on multiple agile teams – not for every sprint, but for any UI/feature sprints.
It gets a little hectic at times, but the upside is I can effectively coach other writers and keep working on improving how we work within those teams because I’m “living” it too.
Being realistic about the time you have to commit to the sprint, and communicating this upfront during sprint planning lets you juggle the weeks where you may have a heavier “manager” work load – such as mid-year reviews.
Whether you call them Documentation Manager, Team Lead, or overall Content Architect, I agree you need the role – it just might be embodied in a person who is exposed to both sprint and non-sprint work.
Interesting thoughts, Ellis. I agree with Rob and Sarah.
For the last eight years, in two different organizations, I’ve worked under the “de-centralized” model. Each of us reported to a different development manager. Our career development definitely takes a hit, for the following key reasons:
(1) The manager changes frequently, because we’re shifted around to different projects and managers according to the workload.
(2) To the development manager, a technical writer is the most negligible member of the team as far as career development goes (sad but true, even in Agile projects)
(3) The development manager doesn’t know anything about technical writing, so excellence goes unnoticed.
(4) At appraisal time, the technical writer’s achievements are compared with the technical achievements and innovations of developers and testers.
When I (and probably the other technical writers as well) brought up these concerns about our career development, management decided to move us under one manager, who is a test manager, and has no experience or knowledge about technical writing.
Despite my apprehensions, I’m supportive of the change and would like to see how things work out in the coming months. (Also, there’s little I can do, other than being supportive!) This just happened last week, so your post could not be more timely!
What do you think? Will our situation improve or stay unchanged?
Hi Abby
I don’t know. I wonder if this is a symptom of the company not knowing the value of documentation. You might need to measure how many read the documents, how many support calls are avoided etc.
Yes, you do! Otherwise, Help and Documentation issues only ever get an airing in management meetings when there are escalated problems. Reaction, not proaction. Long-term and broad-scope strategy and planning for ‘Tech Pubs’? Forget it! Tech Authors feeling that they do not have a voice? You bet! Consistency in style and quality across the product range? You’ll be lucky! Motivations for personal development? None, as Tech Authors, other than to change roles, or leave the company that clearly under-values their worth! Well, I guess you know how I feel about it…
[…] Do you need a Documentation Manager when Technical Authors are embedded into Agile project teams? […]