"Solving business problems."  That's how a friend of Lavacon's Jack Molisani describes her work.  That's what a tech writer does. But what does that really mean?

If you look at job postings, technical writing related jobs have so many job titles it's more ambiguous than describing someone as a business analyst.  In fact, several postings I've read in the last few months use the term "analyst."  Some postings are actually describing programmers, some instructional designers, content developers, documentation specialists, the list goes on. But it all boils down to the "solving business problems" analogy.  

My latest full-time position was "training manager," and before that I was a "learning coordinator."  Essentially, I was an instructional designer who both developed online training and managed that training.  But in my mind, I was still a technical writer.  Instead of developing work instructions, I was translating them into interactive, online learning.  And instead of developing and maintaining knowledgebases for a help desk, I was creating an internal knowledgebase on the authoring tools and technical issues surrounding online learning.  

The concepts are the same, even if the delivery is slightly different.  Information needs to be communicated and accessible, and it needs to be developed in a manner that the users -- or learners -- find accessible. That can change depending on so many factors and not just familiarity with the topic.  And one-size does not fit all; no solution will work for every organization or even every group in an organization, even in the same location.

Those problems that occur, are always solved through communication, whether it's instructor led training, self paced learning, or having materials with useful content that is available and easily accessible on demand.