Technical writing is probably most simply described as the communication of specialized, instructional, or otherwise complex content. This sounds simple enough, but if you consider all of the written content your team and organisation might have or need, the list grows quickly. Consider these examples:

• Standards
• Emails and Letters
• Developer/API Documentation
• IT documentation
• Procedures and Policy
• Proposals
• User Guides
• Health & Safety Instructions
• Office Procedures
• Staff Onboarding Steps
• Manuals and Books
• Whitepapers and Articles
• Online Help
• Audit Documents
• Reports and Memos
• Manual Pages
• Release Notes
• Packaging
• UX Notes
• Website Text
• Errata
• Marketing and Media
• Blogs and Social Media
• Knowledgebase Articles
• Design and Functional Specifications
• etc...

All of this is enough to keep anyone busy! These documents need to be accurate, updated, and widely considered useful to really have an impact on their audience and encourage engagement.

However, documentation does not exist in a vacuum and is often written on a wiki or document management system/server, it may need to be versioned, printed and laminated, and it may have permissions and access tiers, require multiple backups, have legislative and legal implications and requirements, be damaging or embarrassing to your organisation if leaked, be highly confidential, or assist nefarious actors, be crucial to (or hated by) developers, be somebody's savior in an emergency, written in a standard language with standardized structures, or may require strict compatibility with your existing infrastructure and workflow. Or sometimes all of these.

In other words, documentation is important. Doing documentation properly is very important.

However, not all people genuinely like to write documentation, and fewer combine that with a relevant technical background. Developers are well-placed to write documentation, and sensibly automated content is a possibility to make life easier for developers (such as APIs). But developers, rightfully so, might say things like:

Or:

• "My skills are in software development, not writing"
• "Nobody reads it"
• "It's dull"
• "I don't have time"
• "I'm too close to the product"

This is all fair enough - devs are gonna dev. Enter the technical writer! A good technical writer:

• Responds to the needs of the audience
• Elicits information from subject matter experts and teams
• Understands the product/system/service intimately
• Understands the business drivers behind each item of content
• Can translate and explain technical language/concepts simply
• Has a very high command of language
• Is technically-minded and adaptive enough to integrate with existing tools
• Is prepared to automate content when it makes sense
• Can integrate with delivery methods and workflow
• Responds to feedback and conducts surveys
• Can write for multiple platforms
• Makes judgments from hard consumption data
• Communicates and markets effectively via the written word
• Has a passion for collating and sharing knowledge via writing
• Often is very passionate about which keyboard they use...

Overall, great documentation serves the needs of an audience, clarifies technical concepts and language, and provides precisely what is needed at the right time. Bad documentation will usually languish and become ignored, and even detrimental.

If you are looking to move into a technical writing profession, dive in, perhaps set up a free wiki, and start writing! Remember that it is both a creative process and a technical process, so experiment with things like categorizing and documenting the contents of your house, or the components that make up a computer and how they work, or write guides on anything you can imagine for any audience you can imagine!

My favorite corporate interview question to date is still "Describe in 200 words or less how to make a bed." While simple experiments like these might seem trivial, they genuinely help cement and demonstrate how a document or guide might be best structured for its audience, which is what always underpins quality and useful content.

Thanks for reading my first article as a Steemian. I hope this has been informative as an introduction to technical writing.

Any questions you have are more than welcome! :-)