It’s All About AI. The Data Told Me So.

AIA conversation with a (junior) colleague this morning started off with “How did you decide to reformat your Best Practices Guide?” and moved on to things like “But how did you know that you should be working in Artificial Intelligence and VUI for this search stuff? I mean, how do you know it will work?”

I couldn’t help but chuckle to myself.

“Rest assured,” I said. “Part of it is just that you know what you know.  Watch your customers. Rely on your gut. But more importantly, trust the data.” The response was something of a blank stare, which was telling.

All too often, tech writers – software writers especially it seems, although I do not have the requisite studies to support that claim – are too steeped in their actual products to reach out and engage in customer usage data, to mine engagement models and determine what their users want when it comes to their doc. They are focused on things, albeit important things, like grammar, standards, style guides, and so on. This leaves little time for customer engagement, so that falls to the bottom of the “to-do” list until an NPS score shows up and that score is abysmal. By that time, if the documentation set is large (like mine) it’s time for triage. But can the doc be saved? Maybe, maybe not.

If you’re lucky like I am, you work for a company that practices Agile or SAFe and you write doc in an environment that doesn’t shunt you to the end of the development line, so you can take a crack at fixing what’s broken. (If you don’t work for a rainbow-in-the-clouds company like mine, I suggest you dust off your resume and find one. They are super fun! But, I digress.)

Back to the colleague-conversation. Here’s how I knew to reformat the BP Guide that prompted the morning conversation:

I am working toward making all of my documentation consistent through the use of templating and accompanying videos. Why? Research.

toiletAccording to Forrester, 79% of customers would rather use self-service documentation than a human-assisted support channel. According to an Aspect CX survey, 33% said they would rather “clean a toilet” than wait for Support. Seriously? Clean a toilet? That means I need to have some very user-friendly, easily accessible documentation that is clear, concise, and usable. My customers do NOT want to head over to support. It makes them angry. It’s squicky. They have very strong feelings about making support calls. I am not going to send my customers to support. The Acquity group says that 72% of customers buy only from vendors that can find product (support and documentation) content online. I want my customers’ experience to be smooth and easy. Super slick.

In retail sales, we already know that the day your product is offered on Amazon is the day you are no longer relevant in the traditional market so it’s a good thing that my company sells software by subscription and not washers and dryers. Companies that do not offer subscription models or create a top-notch customer experience cease to be relevant in a very short span of time thanks to thanks to changing interfaces.

Image result for artificial intelligence

I’m working to make the current customer support channel a fully automatable target. Why? It is low-risk, high-reward, and the right technology can automate the customer support representative out of a job. That’s not cruel or awful; it’s exciting, and it opens new opportunities. Think about the channels for new positions, new functions that support engineers. If the people who used to take support cal


ls instead now focus on designing smart user decision trees based on context and process tasks as contextual language designers, it’s a win. If former support analysts are in new roles as Voice of the Customer (VoC) Analysts, think about the huge gains in customer insights because they have the distinct ability to make deep analyses into our most valuable business questions rather than tackling mundane how-to questions and daily fixes that are instead handled by the deep learning of a smart VUI. It’s not magic; it’s today. These two new job titles are just two of the AI-based fields that are conjured by Joe McKendrick in a recent Forbes article so I am not alone in this thinking by far.

His research thinking aligns with mine. And Gartner predicts that by 2020, AI will create more jobs than it eliminates.

So as I nest these Best Practices guides, as I create more integrated documentation, as I rely on both my gut and my data, I know where my documentation is headed, because I rely on data. I look to what my customers tell me. I dive into charts and graphs and points on scales. The information is there, and AI will tell me more than I ever dreamed of…if I listen closely and follow the learning path.





Simplifying Complexity

Sometimes when I think about that task – simplifying the complex – it sounds as easy as boiling the ocean. Other times it comes as naturally to me as making toast. (Since I don’t eat toast, or even own a toaster, perhaps I should take that as a sign. It is never easy to make complex things simple. Not even making toast.)

Image result for toast

Yet every day, what I do in my work is to take cumbersome, complex tasks and recreate them in the simplest possible terms. When a huge banking system has millions of transactions per day and must synthesize them into calculable terms…I create language that can handle that. When there is an installation process that takes hundreds of functions that need to be done in seconds, not hours, I write the tasks that do that in ways that humans can understand without advanced degrees. I take complex ideas and distill them for actual people.

Brunch-MimosasMany years ago, when I was a bridesmaid for a dear friend, we hosted a brunch for the bride just a few days before her big day. In sunny Edmond, OK, just outside of Oklahoma City, we gathered around floral arrangements and mimosas for a few final gifts and sentiments. One of the things we had arranged for my dear friend was a book of recipes – not an atypical gift for a young bride. However, she was not your average young homemaker. We knew her so well that the homemade book, a collection to which we had all contributed, was filled with precious advice like “Vegetable Soup: Open can. Pour into saucepan. Do not overheat, boil, or otherwise burn.” And another great one: “Swedish Meatballs: Drive to your local Ikea. Once there, find the café. All will be well.” And perhaps the best: “Breakfast in bed: Open Pop Tarts box. Remove items from foil wrapper. Return to bed. Serves two.”

This gift indeed made the complex simple. It did not, however, lead to a gourmet life for the newlyweds. Nor did it improve her cooking skills. Hopefully she took some cooking classes or they made lots of reservations. No matter, she eventually became a successful oncologist and he a high school biology teacher. No one starved.

chocolate chip

The kitchen is the perfect example of where good writing, clean instructions, are essential to making the complex simple. Baking is an intricate act of chemistry that, if not executed properly, can yield disastrous results. The chemical process involved in baking bread is a dance of molecules that defies the odds of nature, and yet displays the beautiful synergy of both science and art.

On the other hand, missteps in the kitchen can yield fantastic new gifts, too. Who can overlook the great story on any package of Nestle chocolate chips, telling the untrue tale of Ruth Graves Wakefield and her adventures in creating Toll House cookies? (I hate to break it to you, but they were not really a mistake. Ruth was not trying to create chocolate cookies. She meant to keep those little chocolate nuggets intact, after all.)

My point is that every chocolate chip cookie recipe has a slightly different taste based upon a simple change: the recipe. Making the complex recipe ingredients: let’s face it, there are frequently at least TEN ingredients in the cookie recipe – and their variants.

Think about the variants alone:

Salt or no salt (I’ve tried it both ways, to varying result)

The # of eggs can differ

Fat – this is butter vs margarine or shortening. The variations in recipes is astonishing

A leavening agent – typically baking powder, but sometimes baking soda

The amount of flour, also the kind of flour

Whether to cream all of the fats and liquids before adding the sugars

The ratio of fats to flours

The ratio of ingredients and mixing and cooking times

All this is to say that just when you thought a simple task – making a batch of chocolate chip cookies – was just that, a simple task, you forgot that a whole lot of design and consideration went into the planning of that document. Or did it? Probably not. Your mom or her mom wrote down the recipe and you either liked her cookies or you liked someone else’s mom’s cookies. (My daughter prefers her friend Evan’s mom’s cookies to mine, if I am honest. And this is a good thing, because I shun carbohydrates and sugars like they bear the plague upon my house, so I cannot be trusted to bake anyway. I send college care packages of kale chips and they are darn good!) But when mom was perfecting that recipe, writing down all of the tweaks and updates, she was user-testing and updating the technical document. She just didn’t know it.

Even the original plan – the measuring of ingredients and the testing of oven temperature and the execution of the recipe – all of that was fragile and technical and required patience and repetition. The information that first started out on a sheet of paper next to the oven had to be user-tested and rethought once or twice. Or five times. It’s just that no one labeled it “tech writing” before they put it on a recipe card.

So now, all of these years later, while I am plotting out the schema for decoupling a conversational AI documentation scenario, I hope you will bear with me. I think one of the primary questions I will look into this week is, “Alexa, what is the ideal number of chocolate chips to put into a single cookie?” While I am researching the pure voice interactions and trying to nail down the intents and utterances and the minute specifics of how we can integrate this practice into the fiber of our lives, remember, it all started with the desire to simplify – and to make a cookie. So I’ll begin with that question about how many chips.

Once I have that answer, I will report back to you on the salt or no salt question, and then I will move on to the perfect flour ratio, and we’ll move on from there.  Or maybe I will create the ultimate kale chip recipe for a college care package.




What to Do When Your Documentation Speaks… Literally



So. It’s just after the holidays, and a whole slew of people opened a new Amazon Echo or Google Home brought by a jolly elf as a gift. Now, they are rolling their eyes or scratching their foreheads over the responses they get from their supposedly smart home assistants, or (if they are like one of my office colleagues) they are claiming the thing is trash, but perhaps better, they are praising the heavens and enjoying the heck out of artificial intelligence and Voice-User-Interface. Hallelujah for converts!

Many along any point on that spectrum are wondering how the heck it could be so difficult to get that stuff right, and many of you, dear readers, are wondering what this has to do with the price of peas and technical writing.

Allow me.

innovationYou see, a few weeks ago, my development team here at my office had what we all an “innovation sprint.” That is where we get to blow off some steam and quit working on our traditional run of the mill development tasks and think, instead, about the kinds of things we would do if we didn’t have customer deadlines and goals. We get to open up our imaginations and play around a bit – so what we did was to imagine what would happen if we could get something like the Amazon Echo to talk to mainframe computers and therefore get mainframe computers to talk back to the Amazon Echo – the ultimate in automation processes, as it were. Now mind you, the entire team does not have to participate. This process is totally voluntary. Team members can catch up on overdue work or sketch out other projects that they may want to work on in the future. They can conceive of ways to make their workdays easier or to otherwise improve the customer experience, that sort of thing.

But I was sticking with the Echo. I did not think it would work, but I am a glutton for impossible tasks.

I was right, and we failed fast. Too many security issues, turns out. But what did work, and what tickled me to no end, was that it IS possible to ask the adorable Voice User Interface to search my well-crafted user documentation (a tome that would be some 6,000 pages if it were printed, mind you) for any string of words or numbers that you wish to find, and the marvelous Alexa can be taught to return results with alarming accuracy. Voila!

Just like Alexa can learn movie trivia or what time the bus will arrive at my stop, just like this model of artificial intelligence can archive my weekly grocery list and take on my daily calendar or read each day’s news from a variety of prescribed sources, this cylindrical wonder will root through those words upon words upon numbers and more words, and even acronyms and reveal the right answer time after time. Once we program her.


In addition to these innovation sprints, my company also supports a project called the Accelerator. Think “incubator” but with less risk. A gargantuan company helping to nurture fledgling startups. It’s pretty great. First there is a rigorous application process and proving ground, naturally, but once you’ve run the gauntlet, it’s quite the ride – a supported startup, if you will. And that is where I am headed, my Alexa by my side.

A technical writer’s dream, and maybe nightmare, all at once.

It seems I have opened an oyster of sorts.oyster

I found a path to documentation using VUIs, a search tool for the largest documentation set with which I have worked. And after all, the Alexa was named after the Library at Alexandria, so it stands to reason. I am pleased as punch. Let the innovation continue, and the documentation shall “speak” for itself.

Please Release Me!


As soon as I thought about writing a post about Release Notes, I got that old Englebert Humperdink song stuck in my head, “Please release me, let me go..” and it’s been stuck in there ever since. When that played on the radio when I was a kid, it was the worst earworm ever! But it has nothing to do with writing a good set of release notes, and it just serves to distract me from the task at hand.

As technical writers, we are tasked with documenting (we hope) multiple releases of successful software products. A vital part of that job is letting customers know what has changed from one release to another, especially when something might alter the way a customer uses the product. Sometimes the change is exciting – like a new feature. Sometimes it’s less glamorous, like the deprecation of code functions.

At their most minimal, release notes are merely called changelogs, and are not full-blown release notes at all. Changelogs are just companions to the documentation that can be sent along periodically and take far less work than the notes that accompany a Generally-Available Release. For a major GA release, you can and should anticipate preparing not just technical notes, but a greater suite of materials that will help your product succeed in the market.

Ahh..but I am just a lowly tech writer, you say. Well, if you choose to remain so, then only prep a section of tech doc that discusses the technical aspects of the release, and there you have it. If you want to view your software as an asset and you’d like to continue writing doc for it and for your company, listen well.

What to Include in Release Notes:

New Features and Functionsnew-sign-ID-33314

Let readers know what new features are packed in to the product, and how those enhance their experiences. The Release Notes section allows for a teensy bit of latitude where you can provide an information-loaded summary of what that feature means and how users can implement it. What does it mean to them? What is the business value? Depending on your business’ practice, you might be able to include a screenshot, an illustration, or a video demo.

If the feature or function came out of ideation, you could link to the community where the request was made, so that customers know that their voices are being heard. They really dig that.

Make sure that New features is the first item in your Release Notes. Don’t let it be overshadowed by anything else, like…

Bug Fixes                                                                                         scared-bug

Listing the bugs that your team has encountered and corrected is important in the upfront Release Notes, but even more important is linking to the documentation where the bug reports and further information resides. It’s no good to just say, “hey we fixed this,” but not to say “here’s where to get that new stuff.” I’ve seen plenty of doc that does the former but not the latter. It’s just a courtesy to point your users directly to the goods.

It is important to note the Bug Fixes, but don’t let them get anyone down. They were glitches, after all, so celebrate the fact that they were Fixed! Go, you! Because next up, you deed to call attention to deprecations.

Deprecations                                                                    Fox

Nobody celebrates these, and yet you have to let users know about the parts and pieces that are just no longer useful. If part of your product is headed out to pasture, you’ve got to say, “sorry, folks, this is being taken off the shelf.” You don’t necessarily have to say why, because hopefully you’ve covered that in sprint reviews and whatnot, but you do have to make sure you place this prominently in your Release Notes, because not everyone attends those review meetings, or knows in advance about such retirements.

On the other hand, don’t dwell. Do let customers know if there is an alternative – like substituting margarine for butter or stevia for sugar, that sort of thing. Absolutely link to a migration guide so that they know how to get the job done moving from one release to another. Don’t leave anyone hanging without the tools they need.

Why did I bother to put this little guide together?

Well, because I have seen some good release notes and I have seen some bad release notes. I troll around in other product documentation; I don’t keep my head in the box at my own company. I find it intriguing to look around at best practices and see what’s going on. I strategize and learn. One of the things I like to do is to put myself in the shoes of my user. If you don’t do that, you are not a good writer. There. I said it. We are not writing fiction here, folks. These are user guides. USER.  So look at things from that vantage point and see if it works. Not only if it works, but if it is easy. Do you enjoy it? I don’t mean if it’s superfun, because no, it is not super fun. Dancing on Saturday night with your besties is super fun, but is it a pleasant experience that you do not hate at 2:00 on a Thursday? Good. Then you wrote some good documentation and that is all we can ask for. Congratulations.

notes (1)

Once you have that all set and in place, jot down a section of “Other Notes.” This is stuff you grab from UX, from your internal SMEs, things that are overlooked and the orphans of the whole set. The “junk drawer,” if you will. Toss it in a section, build something for it. There is a reason that nearly all of us have a junk drawer in our kitchens – we have odds and ends, but they are useful little nuggets. Your Release Notes might have those, too. But before you toss in too much stuff, take a good look at those nuggets and really ask if they don’t belong in one of those other categories. They truly might. A very smart designer friend of mine once told me that stacks of things are really just unmade decisions. She’s right. So don’t stack your stuff, that junk drawer of doc, just because you don’t want to deal with it. Make some decisions. But even that smart designer friend has a junk drawer. It’s just a nearly-empty junk drawer.

And there you have it. Delight your customers with neat, tidy, efficient user-friendly Release Notes, and be on your merry way. Strategy 101.

By the way, I think the real reason I wrote this is because…guess what…I just finished writing, you guessed it…a whole new set of release notes. With a very small junk drawer. Yay, me.

Strategically Named



So very often I hear about how tech writing is a dying industry, and it makes me sad. Then, I remember that our name has just changed. The bluster is just bluster. We are content managers, information engineers, media strategists, and so on. The funny thing about some of this rebranding is, I recently looked on Glassdoor, and learned that, depending on what you call yourself, the salary for those titles varies widely.

For example, the average “media strategist” nationally is clocking in at $46,736, while the national average for a “content strategist” $70,000. I’m wondering what the huge distinction is, to be honest. And, I can admit that I don’t really know. My work title is information engineer because I am in a company full of engineers. We make software, we build solutions in the fast-paced software world, so my work is a little more specialized. If you want to know the national average on that salary, I’ll let you do your own research, and then I’ll reassure you that I am not making what Glassdoor says.

smart girlI looked on Wikipedia, and the generalist definition of Information Engineering is that we take a software engineering approach to writing and developing information systems, or that mostly we are computer geeks who write. Well…I’m actually a writer who enjoys software systems. I was hired to work specifically on mainframe systems even though I knew almost nothing about mainframes when I joined the company. I think the big distinction is that, as writers, we know how to communicate complex information and that we have knack for learning things. Definitely if I was not into learning, I would stink at this job. But what actually separates me from a “media strategist” in terms of my skillset? That is to say, what if I wanted to leapfrog from my current job into media strategy? Am I working on the tools that might be portable enough to move from one position to another? Yes. And you should too.

In this field, I argue that it is critically important to continue honing not just the technical acumen, but the strategy, to keep abreast of what is going on in other writing areas in order to be as portable as possible. My specific company is using what might not be considered the most cutting-edge authoring tools, so I make sure I learn some techniques and tools outside of my daily grind in order to stay on top of what’s out there elsewhere. So, if you are in a particular niche, say Information Engineering, it is not an altogether terrible thing to make sure that you know that a “media strategist,” for example, is an increasingly complex role that puts you in charge of content delivery in broadcast arenas. Knowing this, in my role as a software documentation writer, I step up on a regular basis and record videos, work with a program called Captivate (an Adobe product) and just play around with what is out there on YouTube in instructional video land. Admittedly, this is never going to put me in the C-Suite of media strategy, but neither is it going to leave me looking like a gasping fish.

Likewise, I try to keep tabs on other media and collaborative tools like #slack or Asana for collaboration tools. If you are knee-deep in managing content projects, you’ll surely want to be adept with these beauties, or at least one of them. My company is currently using Flowdock. It’s not my favorite, but it is a powerful tool, proven with doc-sharing and it gets  around. Some companies are making great use of Yammer as a powerful intranet communication device as well. I recommend at least having a working knowledge of these gadgets. You can’t go wrong, and a broad skills base is never a bad thing, right? Right.

What about the idea of content strategy, you say? These things lean on media management. A recent post was about content, and I daresay I could reiterate that everything I do is about content – content is text, video, graphics, interfacing all of these things into a usable, consumable, findable set or even suite of instructions and understandable items that users can then put to use, find again if necelightbulbssary and move on if not. From an installation guide to a set of scenarios for implementation to third-party software agreements, it all has to be chunked into usable bits of information in the best way(s) possible, and it is up to us – the wordsmiths, the video script writers, the graphic designers, and the UX specialists, to get it right. And often, more and more and more often – we are the same person.



I suppose all of this goes to say that in the pool of tech writing tools, we aren’t supposed to stay focused only on the items that specifically make us “tech” writers. So grab that pint and start spending part of your day – every single day – finding what’s out there to make you the best writer, editor, designer and consumer. Because that is your new name. It’s been mine for a while. Communications specialist? A rose is a rose is a technical writer is a media strategist is a content implementation designer. All I know is I craft exceptional messaging every day.


Nice to meet you.



Is it Writing or is it Content?




In my not-so-distant past, I read an article by a writer, who posts things in a forum which I respect, pleading that we no longer call our writing Content. She ruminated deeply on this topic, outlining reason after reason why we should respect writing enough to ditch this term, (she called it a “catchall”) and give ourselves the respect that we deserve. She argued that there was, in fact, no way that a writer came up with the term “content” to describe what we put into phrases and paragraphs every day for a living.

I felt maligned. Insulted, even. My feelings were hurt partly because I am currently writing-voicepursuing a certification in Content Strategy. Yes, content. I rather enjoy thinking of my writing as “content.” While I agree that there may be more nuanced terms for some forms of writing – and we may be more specific: poetry, haiku, essay, short story, etc., in the world of technical communication, marketing and corporate communications, what we create is…wait for it…content. But I was more bent out of shape because when asked, I introduce myself as a writer. I rarely qualify this term unless I need to.

I am a writer.writer

The words, phrases, and paragraphs that I construct are inextricably linked to a perception of the company for which I work, its products and its mindset. What I write for them is not the great American novel, nor do I wish it to be. This writer argued that “to write is to find out what you think.” How very noble. I wish that I was finding out what I am thinking while I am creating dozens of web pages that instruct software users in the intricacies of an installation process that is many steps long and requires detailed diagrams to accompany my flowery prose. Alas, I am not. What I am doing is creating useful, tangible prose that goes out into the world and does real good. My writing takes root, grows, and from it blooms a garden of procedures. Those procedures help make sure that your debit card works every Monday morning. It’s a beautiful thing, but I won’t be nominated for a Pen Faulkner any time soon.

Because I create content.

She even maligns content as a marketing strategy, which I found specious. I generate literally dozens of tweets per month in order to forward the ideas and goals of my company. That is writing – and it’s hard writing. I have to be creative, pithy, sometimes funny, sometimes I do a lot of research – and all in a very tight space. It’s called brevity, and Mark Twain said that was the soul of wit. I’m with him. And it’s writing. It’s writing content. That content helps users get to my products and helps people understand my work. Plus it’s darn good writing. So there.

books4People consume my content, not the way they consume a classic novel or even a beach read. They do not recommend my work to their friends as the next great thing to read, and they do not say, “Hey, did you see that great process that Susan just created? Wow! Talk about incredibly lean doc!” That, my friends, is the dream of any software documentation writer, I assure you. But maybe, just maybe, what some of my friends say is, “Susan wrote an insightful blog about the value of Content Writing and how it is important, just like writing your memoir. After all, that technical document will show you how to set up your new laptop so that you can write your memoir. And then you can stick your nose in the air and claim that is real writing, not merely content.”

Picking up the #Slack

I recently read a post that another tech writer wrote about the great value he got out of attending a conference, and it got me to thinking about whether I missed the academic conferences I used to attend when I was in Higher Education, that conference-heavy publish-or-perish world that used to frame my professional life.

I do rather miss those conferences, but not because they helped in my professional conferencedevelopment at all. I miss them because they were rather fantastic social networking events where I got to visit nifty cities and see old friends, meet new friends and make some cool connections that would become Facebook pals I’d never see again anywhere other than social media. I’d occasionally hear a good lecture, but more often than not I would gain little professionally and more socially from those conferences. Even the ones where I was a presenter. Don’t get me wrong – there is assuredly professional gain. It is a boon to my resume that I gave a talk at The Rhetoric Society of America. That I delivered a conference paper at The Conference on College Composition and Communication when it was in New York City. It’s kind of a big deal. I did my share of networking, it’s true.

But it is also true that when I was at a conference for Professional and Technical Writing programs and a primary speaker was delivering a talk about women in the professions and helping each other through academic networking I sought her out afterward, only to email her and never hear from her again. Talk about deflating. I did, though, enjoy the venue and the cocktail hour and I made a friend there who is totally into mountain biking and lives in Colorado and we are Facebook pals and we swear one of these days we are going to get together and bike in Utah which we both love. We’ll do it, too, I just know it! The experience of making that Facebook friend is obviously the more valuable experience. Totally worth the money I spent on the conference.

In my professional life, I gain much, much more from networking threads like Slack and Google Plus or Google Docs because I get actual work done there. I collaborate on the daily with other professionals who do what I do, who think like I think, and they interact and respond in real time without the hotel bar chit chat and the façade of friendly. I’ve yet to have a Google hangout with my colleagues fail to result in real feedback, but I’ve definitely had conferences end with “sure, I’d love to look at that manuscript,” only to have neither party send a manuscript or even reach out with a professional email. At conferencing events, offers of reach-out are made, but they are sometimes disingenuous. With options like LinkedIn or Slack, the work is in front of you and the gift is made. It’s in print – albeit digital print. It is more difficult to retract if the ask is not made with a glass of pinot noir in one hand. The work is sincere and the response is real. We work hard in this business, or in any business, and time is short, days are long but wide. It is time to put shoulders to the grindstone if we want real results.

New-Orleans-for-desktopDigital is the new real, and though those professional conferences sure are delightful if they are in Vegas or New Orleans or New York, I’d rather get my work done from my Pittsburgh home office and go out to celebrate after the amazing writing hits the screen – like it just did!

Messaging from the Inside Out


The most important messaging of all might not be advertising, tweeting, or all those posts on LinkedIn. Sometimes, it’s the internal message that rings loudest and clearest.

Why? Because that is the message that carries far past social media and proves that a company is worth working for, and sticking with. A clear internal message increases productivity, which increases growth, and we all know what happens next.

According to Karen Johnson of, effective internal communication “is particularly critical during tumultuous times for an organization to ease anxieties, boost morale and inhibit inaccurate information.” If employees know that their company has a solid plan in place, that eases tensions across the spectrum. But even if the staff knows and recognizes that the company is on unsure footing, if that is communicated well – and openly – they know they can trust upper management and will follow as a team.

Team-builnewpathding and loyalty is perhaps what is at the very epicenter of good internal messaging. When a company is trying out a new path, forging new avenues into new markets, a straightforward, clear internal communications plan is essential. Knowing
that while some areas of the business are under reconstruction, others are steady and moving along as predictable honesty and thoroughness is as important as it gets. What I mean to say here is that especially in a large company, if change is afoot, it is essential to let staff know in the most assuring ways possible that rollouts are going well (when they are going well) because the rumor mill is stronger than any tweet, LinkedIn post or slide deck. Employees will fill in the blanks with conjecture, so it’s far better to have a strong team approach, even when the future is unclear. A well-crafted message can often be the steadiest hand in the entire organization.

Let’s not forget what was perhaps Yahoo’s greatest stumble. Just when they could have been focusing on long or short-term development goals, they decided to pivot toward using Microsoft’s failed QPR (Quarterly Performance Review) system, whereby team members were stack-ranked.

This created an interior bias sentiment, rather than a feeling of open communication system-wide. Stack-ranking is generallyteam-rocks perceived to be a non-transparent business communication system, and a poor employee motivational approach. While it is not strictly a communication practice and is more closely related to HR, the rollout in Yahoo’s case was greeted with a great deal of pushback on Yahoo’s own communication message boards. It was met with deafening silence from Yahoo’s CEO, Melissa Mayer. The response is the internal communication failure. The non-collaborative practice practically urges people to stop working together. When expectations are unclear and competition is the goal, people almost always underperform.

If the internal messaging is strong, employees feel connected to their company and feel confident in the direction it is taking. This, in turn, creates a connective tissue which bonds the team together, and creates a greater return on the productivity of the team. With strong communication, a company is without a doubt greater than the sum of its parts. The tensile strength can be tested and measured in terms of its output.

This begs the question, then, how do we get internal communication right instead of wrong?

I have some ideas about this. (You probably guessed that , or I would not be blogging on the topic!)

First, connect actions and words. We have tons of jargon in every professional field, and we say that some things are important, but we must follow through. We only develop trust if the actions follow the words. If a promise is made in a document, it must be adhered to in action.

Th100ese days, trust is hard to keep. It is easy for a slide deck to appear in New York, and for those employees to tweet the content of that deck to their colleagues in LA to let the cat out of the bag before the presentation is even complete. We must be trustworthy in all our messaging. This means that those of us who are preparing internal messaging must be certain that we are on point long before the cow leaves
the barn. No guessing, no conjecture, no half-baked plans. We owe it to our colleagues to be sure before we print, upload or speak. If we cannot be 100% certain, we must be 100% open about that as well. We must be willing to say, broadly and loudly, that whatever plans we have in place are conjecture. Or else we should not be publicizing those plans.

As communicators, we must be willing and ready to work with managers to build daily, intimate relationships with leadership and staff alike, not sheltering ourselves from both customers and idea-makers in order to understand the whole ball of wax. Internal communicators have a great view, from the top, from the bottom and from the middle. What a great opportunity to see the inner workings of a company, and what great trust is bestowed on the messengers, eh? A vision like no other. But if a communicator is unwilling to see that the message can be transparent but not translucent, then we have done a bad job of being what the company – and the staff needs us to be.

plainlanguageClear and consistent jargon-free messaging has to become part of the company culture. If we can’t get past all of the marketing pizzazz, which is necessary, and the emotional protection, which is also necessary, then we weaken the relationship that we strive to build. Erwin Steinberg, the ubiquitous professor of Professional Writing at Carnegie Mellon University captained “plain language” writing in the professional sphere. That is precisely what is called for here. If we can master that, we will all have done our growing companies the best service of all.

All of these together – simplification in communication, building trust between leadership and staff through openness and idea-sharing, and delivering clear, consistent content in internal communication without the outdated and misguided notion that employees should be somehow shielded or separated from the plan – this is what forward-thinking corporate communications is about. I’m not saying that any company today, especially a large-scale one, should be completely revelatory to the entire workforce. That would be risky and unnecessary. What I mean is that a new level of transparency begets a new level of loyalty, trust, and productivity. We expect our teams today to be agile, responsive, and to deliver not just products but ideas in rapid turnaround. We ask for nearly unprecedented levels of buy-in and conceptual trust at the development level as we test methods of agile release trains and try to get to market faster, better, and leaner than ever before.

If organizations, in turn, create messaging at a similar level of speed, engagement, and positivity, the sky’s the limit in terms of engagement and trust. A facile win for all. Indeed, the communication will flow from the inside out – a great investment.


Shifting Seats

November is that time of year when I am involved in a fantastic event in Pittsburgh called Red Chair.


It is not a Pittsburgh-only event; it’s an event held in many locations around the country for women in technical fields, STEM fields, and it should be much more active than it is, but it’s a grassroots thing, and it’s taking hold. It takes time to build, it takes momentum and it takes money and dedication, but it’ll get there. The idea is big, and hopefully it will grow. But we struggle. The question is, why ?

There are plenty of smart women, talented women, out there, and the numbers of us are growing, and we are not as timid as we were a generation ago, so that’s all good news. But according to a 2016 survey of 263 tech firms, 18% of those companies said their offices were 25% or less female, and 2% had no women at all ( 2016). Perhaps of the greatest concern in all this is that, according to Fortune Magazine, although “the majority of tech execs in London realize that their firms don’t have a diverse workforce…a full 46% of them don’t think increasing diversity would improve their company’s growth” (Fortune, 2016).

There have been plenty of articles written about this, and lots of research in the field, and yet we still lag behind. I’m no expert, but that won’t prevent me from trying one more time (one hundred more times) from weighing in, from passing along the knowledge of others to try to keep the conversation going. Because keeping the conversation going is the crux of the movement, ladies.

A September, 2013 piece in the Harvard Business Review noted that many CEO’s make gender diversity a priority, choosing to insist on placing women in top positions, trying to guide women to senior positions. That was three years ago, so you would think we’d have seen some results, right? Well, part of the problem with those leaders’ approaches, we’ve found, is that they “don’t address the often fragile process of coming to see oneself, and to be seen by others, as a leader” (Ibarra, 2013). There is a tendency to inadvertently undermine a woman’s trajectory toward leadership when advising her to actively seek a role for which she feels mismatched. According to that same article, “the context must support a woman’s motivation to lead and also increase the likelihood that others will recognize and encourage her efforts.” What this means is that the surrounding employees have to see her as a leader, too. That is not always the case.

how-women-leadWomen who are encouraged to be leaders have to internalize that role and believe that they can be that role. Leadership is an identity, not just a title. Part of what stymies women in escalating toward these roles is the “human tendency to gravitate to people like oneself,” in which case women are lacking in examples of other powerful women (Ibarra, 2013).

The Red Chair event is not just about women in technology, or I wouldn’t have written the last two paragraphs about leadership. Women leaders encourage growth in female staffers. Perhaps they do so no better than their male colleagues, but perhaps they do. The jury’s out, because we lack a breadth of examples, it would seem.

The problem is “that business execs still don’t understand the benefits of having a diverse workforce” (Fortune, 2016). Many organizational structures are, quite simply, designed to fit the lives of men more than they are the lives of women. Consider it – climbing up the career ladder sometimes assumes mobility of place, leadershipwhich then assumes the “trailing spouse” (wife) who can pack up and move along with the new job offer. A wife who has no career can easily pack up with the kids and relocate with little trouble to follow the new promotion opportunity. This work-value is much more difficult if the “trailing spouse” is a man with a career trajectory similar to that of his wife.

These practices did not set out to stifle women, but nevertheless they do. Women tend to steer clear of jobs, opportunities, and even promotions that might require those types of challenges. We even steer clear of those lines of work completely. And gender-biased hiring managers who do not intend to be gender-biased may consider whether a woman will have the mobility or willingness to pursue the opportunities that a job could offer, both in hiring and promotion.

It’s not so clear, and yet it’s all too apparent.

The weird offshoot of this is that the women who DO succeed end up being the exceptions, not the rule.

At Red Chair, I was surrounded by women who moved across the country, their husbands either followed or they had no husbands. They were either supported or they were alone. Either way, they were touted as exceptional. Why not the norm? There were successful men there who were just…successful. There were women who had “executive presence,” as though this was a characteristic that is unusual. Why so? Many of the men stood tall in their business suits, commanding a certain executive presence merely by being in the room, holding a beer.

Fortunately, the keynote speaker, Lenore Blum,truly is a remarkable woman who deserves to be set apart from the rest. Her accomplishments in the field of mathematics are noteworthy by any standard. She teaches at my alma mater and I admire her work on many levels in the technological field. Many women could look to her and be in awe.

But all of the women in the room were successful, and we need to pull many others in to the room with us, every day, day in and day out, to sit with us in the red chairs, technological and otherwise. We must show our male colleagues and our female colleagues that careers from technical writing to product development are as open to us as anyone, and that our presence in the field improves the field overall. That second-generation bias is present, and unfortunate, but present.

Consider which person in your sphere could use a hand. See if you are the hand she needs.




Refiguring The Primary Measure of Progress

pencilIn Agile Software Development,

“working software is the primary measure of progress” and the manifesto values “working software over comprehensive documentation.”  That is all well and good, but as a writer, I often pause on that one word – comprehensive. I take a moment there and wonder who determines what comprehensive means, and whether sometimes we leave the customer, and the customer’s needs, in the dust when we use that word.


Before every developer everywhere has a head explosion, I think we can all agree that expansive documentation is silly and frivolous. So maybe I would swap out comprehensive for expansive. Perhaps I’d have chosen “frivolous documentation,” or “needless documentation.” I’m just not sure I would have chosen the word comprehensive. I get what the manifesto is going for. I do. I want to create lean, usable doc every time. I don’t want to give more than is needed. I want to respond to change fast. My goal is accurate, deliverable doc that addresses stakeholder needs. I suppose I would like to think that, by definition then, my doc is complete, or…comprehensive…in that it includes everything a customer needs. But I agree that I don’t want it to include anything more. I just want to avoid coming up short.

What if I rewrote the twelve principles from a doc-centric focus? Would they work just as well?

  1. My highest priority is to satisfy the customer through early and continuous delivery of valuable documentation.
  2. Welcome changing requirements, even late in documentation. Agile processes harness edits for the customer’s competitive advantage.
  3. Deliver accurate documentation frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
  4. Business people, developers, and writers must work together daily throughout the project.
  5. Write documentation around motivated individuals. Give them the environment and support they need and trust them to get the doc written.
  6. The most efficient and effective method of conveying information to and within a writing team is face-to-face conversation.
  7. Clear, concise documentation is the primary measure of progress.
  8. Agile processes promote sustainable writing. All team members should be able to maintain a constant pace indefinitely.
  9. Continuous attention to linguistic excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of writing not done or words not written – is essential.
  11. The best architectures, sites, and manuals emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to create more effective doc and then adjusts accordingly.

Okay, so some of this is silly, and I just wasted twelve lines by playing it out all the way to the end, but it was for good reason. Continuous deployment can happen not just with techmanualdeveloping software, but in the embracing of documentation as part of that software, but instead it is often “kicked to the curb” by many teams as a misinterpretation of that one element of the original manifesto.



It’s not that documentation should be cast aside; it’s that comprehensive documentation is being misunderstood as frivolous or extraneous documentation.

I did not realize that this was a pernicious issue quite so much until I was giving a workshop to a small class of new developers from across my company, hailing from a variety of offices, and they looked at me funny when I described some of how my team does doc (we are pretty good at the whole agile thing, but sometimes we regress into “mini-waterfalls” and I hate them). One of the young devs was astonished that I manage to get my developers to hand over documentation early in the process so that I have it in a draft state, while the code is still being written, not after the code is all in place. It’s a struggle, I’ll admit, but when I this happens, the result is a joyous celebration of shared workload and well-written doc. We can collaborate, change, shift and learn. And the sprint goes more smoothly with only minor changes at the end, not a doc dump in week 4.

To teams who are not doing this: cut it out with the waterfall, guys. Doc is essential, and your users need it. Otherwise, they are calling support and costing your company thousands with every call. Change your practice and build your doc while you build your product.

You might be asking, “How can you possibly write the doc when you haven’t written the code?”

You are not the first person to ask this, trust me. The answer is pretty simple. A long, long time ago, you couldn’t. Or, at least it wasn’t wise to, because it was a redoubling of work. When writers put their stuff into pdfs or word documents, and then had to make major changes, it meant a bunch of editing and rewriting things. Therefore, developers got in the habit of writing all of the code, then examining the processes and hunkering down to crank out the doc. Fair enough. Now, though, we developed wiki spaces and collaborative tech writing tools that now allow inline editing and let developers look at the cool formatting and linking that tech writers have done with our work.

And – before the code even gets written, there is a design plan in place, and usually a design document to go with it. There are code specifications, right? You can have a nice chat with your friendly tech writer and go over this, either through a face-to-face (see Agile point #6) or via any of the vast number of other tools designed to communicate with your team. Before a developer starts coding, there is a project plan – share that plan. Once the general information has stabilized, it’s okay to let the writer have at it. The benefit is that the writer is having her way with the general plan while the developer is coding away. At the end of both work days, the writer and developer have each created something. In a typically short iteration, it is unlikely that the coding will change significantly, so the two can touch base frequently to mark changes (See Agile point #4).

Are there risks to this process? Of course, just like there are with waterfall. Remember that with waterfall, there were a fair amount of times that programming crept right up to the deadline and documentation was hastily delivered and could therefore be sloppy and lacking. And in this method, it is far easier to tell you about writing documentation continuously than it is to actually do it. It takes time, it takes effort, and it takes dedication – because the primary risk for doc is the same as it is for the software: that the customer’s need will change midstream. That problem was (more or less) solved by short iterations in development, and it is (more or less) solved the same way in documentation.mario

The benefit is this – by writing the doc alongside the development, you can be sure that you deliver the doc in sync with the product. You’ll never sent the product out the door with insufficient instruction, and you will never cost your company thousands of dollars in support calls because your customers don’t understand how the product works or how to migrate it. But deliver a product without comprehensive – yes, I’m back to that word – deliver it without a complete doc set, and you may regret it. Trial and error is okay if you want to see how fast Mario can get his Kart down the hill in order to beat Luigi and save the princess, but do you really want to rely on that when the client is a multi-million dollar bank?

I’ve been teaching writing and writing processes for a very long time, and believe me, the action of draft, revise, revise, revise is not new.

It’s just Agile.