I always thought I wanted to be a software developer. After starting my first job coding, I noticed very few of my colleagues had a plan for when work will be done. Not to say, they weren’t planning, but they were just moving along on their own individual schedules. At some point, I started posting release cycles for the whole team. At first, my fellow engineers were not interested in sharing their plans with the rest of the business, but when the email requests from sales and marketing went down, they were happy. From there, I started coordinating release plans and tended to take most of the meetings with the product managers and sales teams.
After a while, I found myself spending more time strategizing on products, building schedules, and speaking with customers. That was probably okay, because, if I will be honest, my code was not that good. It took me some time, but I finally fell into a groove bridging the divide between highly technical teams and [often] less tech-savvy business owners. Back then, you would call my first post-developer role that of a release manager. Then, I grew to what we call a product owner today.
Over time, I realized it was not just software development projects where those skills could be applied. I moved on to managing large-scale enterprise systems projects. While doing that work, I had a need to get those projects into a tool to understand how all the work flowed across various teams and skillsets. That is when I started working with popular project and document management tools.
After years of using project management tools for my projects, I then turned into a consultant, teaching others how to do the same. During that time, I did a lot of training, and people regularly asked me to write up a blog post, or record the training. That is when the light bulb went off, and I realized it was time to write a book on the subject. Well, books, but more on that in a moment.
When you write a book, specifically technical books, the dirty little secret is you rarely make much money on book sales. Where you make money is selling training. If you look at the people that write technical books, more often than not, they are consultants that sell their knowledge as services. You cannot just leave that content you wrote trapped in a binder to collect dust on a shelf.
Enter structured content
When you write a technical document, you need to make that content work for you. For example, I want to pull a segment of the book and with little or no work, and publish it as a blog post. If I want to turn the book into training material, I want to easily grab just the exercises that students must perform, and even output the slide decks for the presenter.
Earlier in this article, I mentioned that I wrote multiple books. Actually, I wrote one book. All the others were content pulled from the original master book. Instead of a customer paying, say, $100 for the whole book, I can sell portions of your content in smaller books that maybe only cost $9.99. Further, because the content is already in place — and properly written — it is easy to hand off work to someone that can take that print material and convert it into online training, brochures, and web content.
I certainly never invented all the tricks listed in this article. As a matter of fact, most of the popular technical writers use the methods I mention. Whether we know it or not, we are writing structured content. The idea is to use a write-once, share-anywhere writing methodology.
Corporations get this too. Imagine you are a pharmaceuticals company selling a drug. You have federally mandated content that must appear on the website, packaging, print ads, and much more. If you do not present the language precisely as it should be, then at minimum, you may be facing some severe litigation.
One piece of code
When software developers write code, they try to follow the same best practices. For example, when you log in to an account, there is [usually] one code base that manages all the logins. Developers can then write code on a phone, tablet, computer, or browser. All those apps may have a slightly different look and feel, but they are still only calling one piece of code to assist the customer in logging in with their account.
One thing software developers do not always get right is using consistent language. That can go from the online help, to consistent navigation labels, and even down to the name of a button or label. Structuring, tagging, and managing even those small details can mean the difference between the perception of your app being professional or shoddy. That method of managing even a button label is referred to as managing microcontent.
In this T-Suite Podcast, I speak with Rob Hanna, president and co-founder of Precision Content. He will walk us through the process and technical details you need to learn to write structured and microcontent. We also talk about how AI and machine learning is finding its way into the structured content space.
You can reach Rob on his company website or on Twitter.
Special thanks to Scott Abel, the Content Wrangler for introducing me to Rob Hanna.
