When I was at Write the Docs 2015, several people asked me about the title I have in my LinkedIn heading: Documentation Architect.
What did I mean by that? How is it different than content management or development architecture?
What a documentation architect isn’t
A documentation architect isn’t psychic. They can’t figure out your business needs unless you tell them.
They aren’t necessarily managers. They are designing the documents and process, not the team to build out the documents.
They’re not community managers. That’s a underrated specialty that combines amazing amounts of patience, charm, and detail-orientation. You should have a community manager, but it’s very difficult to combine with document architecture.
It’s not data architecture. The positions seem superficially related, but in this sense, data is the communication software has with itself and other software. Documentation is the communication software has with humans.
What a documentation architect is
Technical writing, like most jobs, is a combination of disciplines in different proportions. I can set up a documentation set, choose a documentation tool, predict usability pitfalls, monitor a translation agency, and conduct user testing.
I also have some less tangible, but equally important skills for building an organization’s first documentation set. I have enough moxie to tell people they are slow in getting their documentation going. I have seen enough successes and failures to have design models for several delivery methods across several industries. I can extrapolate from meetings what is most likely to need documenting in a month, or three, and what we should do about that.
Much like a software architect, I can build something novel, thought-out, and designed to guide less-experienced creators to assemble a product that will succeed over a period of time. Also like a software architect, I need to understand both the business needs of an organization and the skill sets required to accomplish my goal. I’ve come to realize that this form of architecture is about systems thinking and how the pieces come together to form the whole.
The other aspect of my specialty is experience. I don’t just understand technical communications problems intellectually, I have failed and succeeded at almost every type of project you can name. I’ve been doing this for long enough to know the failure modes of so many more projects than newer writers can have had time for. I also have had enough experience in different fields and organizations that I can identify nuances that more settled writers have not been exposed to.
When you are looking for a writer, or a user experience designer, or a developer, ask yourself if you are interested in someone who can learn and grow with your product, perhaps with a little guidance, or whether you are looking for someone who can understand and build aspects of the product in partnership at a higher level. Making that distinction will save you a lot of time both in the hiring process and when you are working with the new hire.
(cross-posted from LinkedIn)