In this post, Daniel Ferguson shares his journey as a technical writer and how MadCap Flare played a central role in getting him where he is today. This article was originally published in ISTC Communicator, Spring 2018 and the Smart Output blog by Daniel Ferguson, and reprinted with permission.
I know it sounds hyperbolic to claim that a help authoring tool re-ignited my career, but let me explain.
My first technical writing job
In the Spring of 2001, I walked off the university campus straight into my first technical writing job at a multinational technical organization. I was immediately immersed in creating user guides for UNIX system administrators. The learning curve was steep, but I loved being in the thick of the development cycle — meeting the SMEs (Subject Matter Experts) to review features, getting into the details of the technology, and creating documentation that, in many cases, was the primary user interface for our users. I remember one night staying late in the lab testing a procedure I had written for a new networking protocol. As I walked back to my apartment that night, I was enthralled by how much I enjoyed what I was doing, even if the complexity of the subject matter required that I put in extra working hours at times.
As I became more established in my role, I started taking on more responsibilities. For one assignment, I was paired with a member of our usability team to help conduct primary research on the usability of our documentation. We invited several of our customers into our usability lab to have them test our documentation. I was certain that we were going to pass with flying colors!
Halfway through the first test, I realized I was badly mistaken. Given the task to locate instructions for a given procedure, only about 30% of them could even find the right place in the guide. Then, the participants were given a scenario that required them to use those instructions. Sitting at their terminals, here is some of what I observed:
- One participant could not proceed because he had left his reading glasses in his hotel room and the printed font was too small for him to see.
- Most of the participants struggled to keep the published user guide open since the binding was too tight.
- A few of the participants got several steps into the procedure and then had to switch to an entirely different reference guidebook to find the exact parameters needed to complete the task.
- Once they switched to the reference guide, they never went back to the user guide. They just tinkered around in the system until they had completed the task.
A sense of shock came over me as I watched this all unfold. It became apparent to me that I had never really considered how our guides would be used once we finished authoring. As we continued through the testing, the participants were given the chance to offer verbal feedback. All I could do was listen and take notes. Their feedback was painful but golden.
Emboldened and humbled by what I had learned, I marched back to my office ready to start tackling the most pressing issues our users were facing with our documentation. We had serious issues to address. I wrote a report that summarised my top recommendations. I presented my report to my bosses and got approval to pursue a good number of them.
The flame extinguishes
What happened over the next few weeks was the beginning of the end of my career as a technical writer. Every single initiative that we identified either wasn’t possible in our authoring system or required enormous investment. Though I felt frustrated by this response, I still pressed on, not wanting to let challenges stop us from improving.
After working on these issues for a few weeks and not making any progress, I eventually shelved the project. I went back to focusing only on content development. But this experience had left me scarred. Knowing that my content was being delivered in nearly unusable formats zapped much of the enjoyment that I had found in my job. Ignoring all our valuable user feedback gnawed at me. Slowly, after six years of technical writing, its allure waned, and I wanted out. I started looking for something new.
Leaving technical writing
After a short search, I was able to find a job as a project manager in the same organization. I moved out of the world of technical documentation entirely, assuming that I would never go back. I took on my new project manager role with vigor and assumed that I was at the beginning of a new and exciting career path. It did not take long for me to realize, however, that I didn’t enjoy back-to-back meetings every single day, and that I did not thrive in the environment of navigating and closing complex negotiations and dealing with constant conflict.
After sticking with the project management job for five years, I found myself completely depleted of energy, lacking any motivation, and feeling a void in any creative impulse I once had. The truth is that I really missed technical writing. I missed diving deep into the technical details of projects. I missed translating technical jargon into usable content. I missed having blocks of time where I could put on my headphones and just completely sink into my work. At the same time, I knew a move back to my old technical writing team wasn’t going to satisfy me.
After 11 years at the organization that first hired me, I walked away willingly, hoping to find a job that made me feel alive again.
In just a few weeks, I found exactly the job that I wanted and applied. I got the interview. After sufficiently satisfying their questions about my sincerity of wanting to be back in technical writing, they took a chance on me and offered me the job. I packed up my life, moved to a new city, and started my new job as a technical writer once again.
Meeting MadCap Flare
My new team used a variety of different authoring tools, one of which was MadCap Flare. Until starting this job, I had never heard of Flare. The other writers on the team enjoyed authoring in Flare, so when my opportunity came to own a Flare project, I was excited about the possibilities.
What I experienced next completely transformed my career as a technical writer. The more I used Flare’s technical writing software, the more I enjoyed it. For the first time in years, I looked forward to getting up and going to work again. For the first time in my career, I was delivering results that my stakeholders were thrilled with, something that I never experienced in previous organizations.
What Flare allowed me to deliver
I was able to meet every requirement that was given to me, using the features and functions that Flare provided. For instance:
- Role-based output. Using Flare’s extensive single-sourcing capabilities, I was able to deliver role-based output for my most complex projects, without duplicating any content in my source files.
- Multiple output formats. I was able to deliver any format that my team needed. User guides, online help, mobile help, EPUB, and CHM were all formats that I delivered from Flare in my first six months on the job.
- Content styled for its need. Flare offered me complete stylistic control over my content. Flare uses standard CSS (cascading style sheets), and learning CSS enthralled me. I loved walking into review meetings with content that looked modern and professional. Even more, I loved being able to say ‘yes’ when I was asked if we could make a stylistic change.
I was having the most fun I had ever had in my career. I loved being able to deliver results to my stakeholders and customers that they adored. I loved being able to meet their requirements rather than explain to them the reasons why I couldn’t. I loved that I was able to do all this with authoring efficiency.
At this same time, I discovered the amazing community of Flare users. If I had a question or faced a challenge, I could post my question on the MadCap forum, and other Flare users swarmed to my questions to answer them. Soon, I started answering questions as well. I not only felt connected with my partners at the office but also felt a connection to other Flare users around the globe.
I had found exactly what I set out to find when I left my old job. I felt alive at work again.
An abrupt and unwelcome end
Unfortunately, this state of job bliss was short-lived. Only a year after I had started my new job, it all came to an abrupt end one afternoon. Called into my director’s office, I was told that my job was being eliminated. I felt crushed. I had just found my stride. I was working like I’d always wanted to work. I had experienced a complete career rejuvenation, and I was having more fun and delivering better results than at any point in my career. I dreaded seeing that come to an end and facing an uncertain future.
A new direction
After applying for a few jobs and doing a few interviews, I felt uninspired by the opportunities I had. None of the available jobs appealed to me. Slowly, I started coming around to the belief that maybe I could continue my Flare journey by starting my own Flare training and consulting organization. With a grand total of eight months of Flare experience, I launched my business. Within a couple of weeks, I had my first client.
It has now been nearly five years, and my Flare training and consulting business has been helping technical writers at companies all over the world experience the same kind of career transformation that I experienced. When I work with my clients, I don’t want to just teach them Flare. I want them to be excited to get up in the morning and go to work. I want them to feel empowered by what they are able to deliver. I want to help them do the best work they have ever done.
In my current role, I use Flare every day. I have had the privilege of working on hundreds of Flare projects for my clients. I have worked with great people at great companies to solve extremely challenging and complex documentation problems. I get to meet new people every week and help them see new possibilities and develop new skills.
I have used Flare for countless hours over the past five years, and the feeling of newness and excitement never wears off.