A guest post by Andy Koopmans, Senior Technical Writer at F5
When we started KCS at F5, I was skeptical and concerned. As a technical writer on the AskF5 team for several years, my colleagues and I have worked hard every day to make F5 documentation the best, easiest-to-read, and most helpful possible. The idea of turning a bunch of non-writers loose on the precious knowledge base was intimidating, scary, and demoralizing. As I said to a colleague at the time, it’s like we’ve spent all this time cleaning the carpet and now we’re going to let the kids with the muddy feet run all over it. You see, I’ve never been in a situation like this before, and my first reaction to uncertainty is often fear.
I’ve spent more than twenty years working in documentation shops at major and minor companies, and documentation in those companies was exclusively the job of writers and editors. On the other side of the wall were the technical folks who made the products happen, and the two groups did not often intermingle, except for interviews and other kinds of knowledge-extraction and -transfer activities.
Working at AskF5 was a different story for me from the start. We already had engineers practiced in creating documentation do the initial drafts. Then we had the writers who worked to, as we in the tech writing trade often say with a wry smile, “translate engineer into English.” But still, our small team of writers held the only keys to publishing, so we could make sure that everything that got in front of the customers was as clear and understandable as we could make it. This arrangement has always made sense to me because technical writers are documentation and language specialists, and we applied our specialty on top of the engineers’ various technical specialties.
Then came KCS to change it all. Of course, change is always scary, particularly when it sometimes sounds suspiciously like its purpose is to eliminate my profession and put the customers at the mercy of people who often don’t have professionally trained communication skills. Another problem is that arguing the value of the work we writers do is often difficult because when you read good documentation, editing is almost invisible. Good writing is easy to read—you don’t pay attention to the words but to the meaning, and a good editor’s job is to make sure that you don’t see the effort behind the words. It’s typically only when you have trouble understanding writing that you pay attention to the mechanics of it.
I worried that the significant value we writers provide along the way to the customer would be overlooked by those who thought we just dot i’s and cross t’s when we in fact work on each sentence and paragraph and article to make the language and concepts as easy to understand as possible for as wide an audience as possible. I worried that, without our intervention, our precious knowledge base would become a sea of semi-understandable technical jargon like so many sites I’ve experienced.
So, in the first weeks and months that we started planning the KCS program, I began thinking I was going to be looking for a new job, either out of lack of work or because I couldn’t bear to work the new way. Fear. Worry. Concern. They were all having a party in the pit of my stomach.
Turns out, that didn’t happen because, thankfully, I was able to begin to change how I thought and felt. I began to open myself up to the possibilities of a different kind of future here at F5. If I had to mark the point at which that change began to happen, it was during my first post-Fundamentals course, Beth Haggett’s KCS Coach Training course (which, because of timing, I took before the KCS v6 Practices Workshop). There, for the first time, I heard that, because of various long-standing institutionalized reasons, we were not giving customers all the information we could be giving them, much of it vitally important and time-sensitive. I learned that there was a vast sea of knowledge shared among engineers and other professionals all over the company that was never getting to the customers because of the old technical/communication division.
I also came to understand, more poignantly for me, that many of the people who had this hidden knowledge were not sharing it because they were afraid to. During the coaching course, I heard how scared and even angry a lot of engineers were about the way knowledge documentation was handled. Many of them had even tried to share their wealth of knowledge and been knocked back, admonished, shamed, rejected. It was hard to hear, and it hit home for me, perhaps in particular because I worked for years as a professional author who writhed in pain to see my manuscripts come back from the editors covered in red ink comments that I had to address. I knew what it was to feel as though my work wasn’t good enough. And it hit me even more so because I’d also spent a few years as a college English instructor and an English as a Second Language tutor who spent most of my time trying to alleviate fear and encourage people to share what was in their minds and hearts. To hear people frustrated, angry, or scared about writing hurt my teacher’s soul and made me reevaluate my role in creating that pernicious situation.
Through the coaching course and later the KCS v6 Practices Workshop, I began to understand how I could still contribute quality to the knowledge base while also using my teaching skills and instincts to help others add their voice and expertise. In short, the more I learned about what KCS was and how it worked, the more my fears and concerns began to shift and abate. It was a gradual process, but it was on its way. I was excited. I was reinvigorated about my work in a way I hadn’t been for years.
Now, let me be honest: unless I’m AQI-ing or helping a coachee, I still try not to look at the Support solution articles all that often because I’m one of those people who can’t help wanting to edit them. It’s involuntary. I’m the guy who silently copy-edits your PowerPoint slides in my head during presentations. Since childhood, I have been acutely aware of language and problems in it. I used to (and still do) recreationally read dictionaries, encyclopedias, and style manuals. So, when I see Support solutions, I often see things I would do differently and want to go in and fix. However, I also have come to recognize that, even if I might write things differently in a particular article, the communication is usually successful. The articles are usually, yes, Sufficient to Solve; if they aren’t, Reuse is Revision.
Aside: I want to briefly address a misconception that a lot of non-tech writers have about our profession: we aren’t trying to be perfect or create literary masterpieces. We are trained to recognize where organization, language, style, or punctuation may create misunderstanding. Things that people think are nitpicky like style and punctuation and grammar are actually important, invisible helpers (invisible particularly to native English speakers reading their own language) that make comprehension easier and at times simply possible. However, because of the way KCS works, with its well-thought-out processes and Support solution format, these concerns can be, if not eradicated, significantly alleviated. And, of course, opening the publishing gates to many more people means we make more of our knowledge public, which is all the better for our customers.
But, more importantly for this post, KCS is based on trust. Let me tell you a secret: because of who I am, I don’t trust easily. My brain has always made me feel like an outsider. My first reaction is typically skepticism and caution. These practices have held me in good stead in many aspects in my life, keeping me out of trouble, preventing me from being gullible, etc. But in many circumstances, it’s not a happy way to be, and, not to get too grandiose or melodramatic, working for AskF5 in general and with KCS in particular has helped change my ability to trust. I work around so many brilliant, decent, and trustworthy people. I not only trust my team, but my larger group, my organization, our company, the leadership, and the products we put into the world. That is probably something you’d say at an interview to get hired or get a raise, but in this case it’s just the truth.
With KCS, I have been able to alleviate the fear and reluctance of trusting the keys to the precious knowledge base to the hands of those outside our technical writing team. I have come to see how dedicated, hard-working, and trustworthy our knowledge workers are. They are doing their best to help the customers, and, at its root, that is what this kind of writing is about: folks helping folks. If we accomplish that, then we have a win. And we are seeing a lot of wins. Sure, mistakes happen all the time, but that’s life. I make mistakes too. But mistakes are not only human but necessary and highly instructive: as one of our knowledge workers recently said in a coaching interview: you learn best from the mistakes you make and correct yourself. From what I’m observing, we’re all learning a lot from our mistakes and making our knowledge base and our organization and interconnections all the stronger for it.
They are doing their best to help the customers, and, at its root, that is what this kind of writing is about: folks helping folks.
What I’ve seen in the way of “negatives” in the KCS processes and program have been truly negligible compared to these benefits. I’ve also been thrilled to hear and see people who have never written for public consumption before or never shared their ideas and knowledge before do so and receive the well-deserved recognition that they contributed, they helped, they achieved. I see how hard every one of the knowledge workers strives to help the customers. And I’ve come to understand how I can use my existing skills and develop new ones to interact with and support this process. My profession and I are only under threat if we become ossified and unwilling or unable to grow, change, develop, and trust. It’s scary, but it’s also thrilling, interesting, and actually fun. Because of KCS, I’ve learned more and grown more in my own profession in the past couple of years than I had in several before it. So, thanks for that. I mean it. Trust me. 😊
About the Author
Andy Koopmans, Senior Technical Writer at F5, is a writer, editor, and producer with experience in creating and improving compelling written and video content in the fields of technology, science, health, business, academia, entertainment, and publishing. Connect with Andy on LinkedIn.