Where does the ‘documentation manager’ fit in an organisation?
As our company grows and we push ourselves to be better it is envitable that some people will end up in slightly different roles than they envisaged. Thankfully my current company isn’t too bogged down on job titles and org charts, preferring to make sure that roles and responsibilities are defined and allow people to get on with getting things done.
So, I currently find myself conducting a mini content audit, across most of the company, in an effort to find the big gaps that may or may not exist (ok, that definitely do as every company has them) and working with a couple of other people in different areas of the company to make it happen.
It’s a switch away from concentrating on writing and managing the product documentation but it is an area I’ve long since considered something that someone in my position SHOULD be driving forward.
This exercise has given me the opportunity to touch base with most other areas of the company, and it’s telling that very few have a full product view. In fact I’d say it’s fair to say that none of them have (and rightly so) and so I often find myself pointing out that documentA is already in progress by teamB, so teamX doesn’t need to do write their own.
It also means that, once we have finished the audit and written up the missing information, we should have a cohesive and complete story through all the various touching points our customers have with our company. It should make our offering easier to sell, easier to understand and back up the fact that our product is excellent and our staff are a bunch of smart people!
I have a double interest at play here though, as I also have a developer community which I need to feed far more regularly than I have been, so any content is ‘good content’ as far as they are concerned.
An interesting time which, once again, reminds me why I love this profession of ours, after all who else gets to stick their finger in so many pies.