Making Meaning

Back when I was an undergrad (please do not stop and linger long enough to consider how long ago that was), and I declared that I would be an “English major,” that declaration struck fear in the hearts of many. It did so because to those not-so-intrepid folks, that meant I believed, in folly, that I could write the Great American Novel, or that I would be content living a life for a few years as a starving poet, only to eventually cave in and become a teacher. My mother was a high school English teacher. Her mother was a sixth grade English teacher. The path appeared to have been laid.

I, however, had no real intention of becoming a traditional high school English teacher. I did enjoy a stint for a two-year period as a “teaching artist” at a performing arts magnet school where I had the luxury of teaching creative nonfiction for two and a half hours each afternoon, but I seriously cannot put that in the same bucket as mapping out rubrics for Huckleberry Finn or Hamlet for ninth graders.

Instead, that time provided me with a fantastic foundation for my own writing, which I still do (you are reading some of it at this moment), and the luxury of my mornings free. It was a great time. It launched me into other cool projects, and I got to work with aspiring writers without ever having to get my teaching certificate. I’ll take that as a win.

I moved through writing positions, always knowing what those early doubters knew: people think writing is easy, until it isn’t.

It is only in fairly recent history that writers have dovetailed so well with users and designers. (I have another post about this, so take a look at some older posts and you’ll see my position on UX and writing – I was ahead of the curve!) User Experience, or UX, was for a while considered to be a design concept, not a language one. Few people thought that the words themselves contained meaning. Most believed that an arrow was just an arrow – it could point users to what they needed, and whether it contained text was of no importance. That is, we thought that it didn’t matter what the pop-up or tab had written on it, just that there was a pop-up or tab. It’s not until we had dozens of those tabs from which to choose that things got murky.

But those of us who focus on words intervened to disagree. We started to ask, would users rather “click” or “select?” Is it a “flyer” or a “flier?” Are we really going to have yet another discussion about “dropdown” versus “pulldown?” We absolutely are going to have that discussion. And our customers will be glad we did. That disruptive error message a user gets – if it isn’t too disruptive, a customer won’t give up on using the software we have so lovingly designed. So, while marketing copywriters are diligently working to bring us customers, if we as tech writers and UX writers ensure a smooth journey through the software, we can keep those customers around for a long, long time. They will have had meaningful interactions with our product and our interventions.

Let the marketers worry about conversion. Let the us, as UX and Tech writers, worry about facilitation.

One of the things I have enjoyed most about technical writing is just that – facilitation. I often say that a big part of my job is “smoothing out the pain points” for those who use my software. I joke that no one reads the doc, but that is not entirely true. They read the doc when they have a specific need. That need is at installation: when they are brand-new and want to ramp up fast. Or, they read it when they hit a trouble spot: they want a solution to a problem. But there is a whole lot of “doc” in the interim, and that doc is within the product itself – the entirety of the product design contains compelling microcopy (or sometimes the microcopy is the opposite of compelling, let’s be honest). Prioritizing the user journey not just visually, but textually, a good writer can work with a good designer, and hit the jackpot, so-to-speak.

Extremely good UX means an extremely satisfied customer. A customer whose needs are highlighted by thoughtful text is one who sees a compelling product, I assure you. I feel the same way about technical documentation. If the tech doc supports a well-crafted product, and supports it concisely, there is little need for a stressful support call. Not all software (or any other product, for that matter) can be so well designed that it needs no documentation whatsoever. What we must do as writers in all realms is to create an experience, from microcopy to large-scale content, that is smooth and clean. If we do that, we’ll have done our jobs well. We will have made not just copy, but meaning.

Let’s Talk About Creativity

 

It is an almost universal refrain

when I tell someone that I am a “Technical Writer for a Software Company.”

“Oh, so not exactly exciting work, huh?”

“That would bore me to tears.”

“I couldn’t stand that kind of mundane work.”

To which I roll my eyes with boredom. Come up with something better, people. Do you really think I voluntarily spend my days sweeping cobwebs from my brain? Do you think it is fair game to insult my vocation simply because you are not bright enough to comprehend what I do?

Apparently, yes.

I’ll correct the record. What I do, while at times highly technical, is also quite creative and enjoyable. And highly technical does not cancel out creative and enjoyable, by the way. I spend my days problem solving and inventing solutions to problems that make users’ lives easier, that attack pain points and smooth out issues. It’s pretty cool.

But I get it. If you are not the sort of person who smiles when reading about coding syntax, then working in software documentation seems drab. (The funny thing is, a technical writer is a veritable savior when you can’t figure out how to install your new printer or why the WiFi isn’t working, amirite?)

The truth is, many of us could benefit from greater creativity in the workplace, not just those of us in technical fields. Most of us thrive if given some measure of creativity, even those who do not define themselves as ‘creatives.’ (Just for the record, I do, in fact, label myself as a creative person, and find outlets for just those tendencies both at work and in my personal life. I recommend it!)

Companies who hope to get the most innovative ideas from their workforce are wise to consider ways to encourage creative productivity in the office. I’ve got a few ideas I’d like to share. We use these on my team, and if you try some (or all – go for it) let me know what works, and add a few more to the tab.

  1. Support risk-taking. Cultivate a culture where risk-taking is just fine. I’m not talking about dangerous risks, but rather innovation risks. Try out a new project, allow for innovation time. At my company, we have periodic “innovation sprints” and “hackathons” to encourage new ideas and projects. Some of the fruit of these sessions have proven wildly successful, and some…have not. The best part is that both results are okay.
  2. Offer flexibility in how to do the work. A really cool thing is when you let your workforce test out ways to do things. While Sharon might do everything by the book and find that to be a super-effective way to get to the finish line, Roger might discover a nifty way to hack that project and the next thing you know, not following protocol will become the new protocol because Roger can show that the new way is a great way. Part of this can be offering a better work-life balance, like maybe Roger really can work better at 5AM than 9AM, and he is super productive then, so in-office time is not a priority, or perhaps Roger is really great at coming up with ideas that he jots down in a notebook first, even though typical company policy is to use only email. Get Roger an Evernote smart notebook, and you are on your way to big ideas!
  3. Think about communal space for idea sharing, even if it is offsite. Recently, my team of tech writers and I learned that our local coffee shop was hosting a 3PM “happy hour” and we decided to take a team meeting at that shop. Best. Idea. Ever. We met for an hour over hot java and solved some documentation issues that we’d not been able to solve at our own desks just by moving our thinking to a new location for an hour. And as a bonus, we all had some delicious coffee and a location break! It isn’t always necessary to move spots, and this time the company didn’t even pay for our meeting. We just had to jog our brains a little bit.
  4. Have fun. It is difficult sometimes to forge a genuine camaraderie, but it is also necessary. Break down silos and make an effort to not just be colleagues, but to be collegial. Creating a convivial mood by generating laughter, enjoying the office, and promoting a fun space generates creativity. Spin up a slack channel where everyone can post pictures of their pets, and pets only. If someone on the team doesn’t have a pet, find a workaround, like an animated pet – (come on, this is a creativity post!) Let inspiration flow freely in channels of communication.
  5. Focus on moving the ball forward in a way that everyone will succeed. Look, I work in technical communication and still the thing I want most is to be successful while I enjoy my work. Understanding that success might not always be money, but might be getting out of the office to enjoy sunshine at lunch time, or it might be the trust to work on a new project, or it might be an office space with better light – any of these are indeed ways to foster my creativity and make my workplace more enjoyable and my work product higher-level.

What’s the upshot of that for my company?

Happier customers, greater return on that investment, better work and for them – a bigger bottom line.

I don’t try very hard to correct people who think my job is boring and don’t understand it. I merely tell them, “Actually, technical writing is pretty cool. Your debit card works because I understand the code behind it and write the installation manual, so I bet you are pretty glad I do my job, right?”

They typically shrug and laugh, which is good enough for me. Little do they know, I have a lot of fun thinking of synonyms for a good part of the day, I create animated installation videos, I write VUI, and I spend a good deal of time daydreaming about the best, most innovative ways to make life easy. All because creativity in the workplace is important to me – so let me know if you can make it important in your tech writing space, too.

 

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.

Neural-Network-640x360

 

 

 

What to Do When Your Documentation Speaks… Literally

 

megaphones

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.

Eureka!

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.

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.”

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.

instructions2

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.

 

Why Developers Make Really Bad Tech Writers

 

coding-future

Every now and then, I come across a blog post or other article or column declaring that technical writing for software development is a dying career, lamenting that all of us in the tech writing game should plan our exit strategies and admit that if a product is truly well-designed, our services are simply not needed.

Surely, in some product cases this is true. However, in many high-level software instances, I defy you to successfully install and run the product without some help from your friendly neighborhood tech writer. I pose this challenge because developers think and behave like developers and users think and behave like users. There is a chasm as wide as the English Channel between developer and user, and only the talented technical writer can provide transport safely across.

It’s not that developers are incapable of writing well or that they cannot write documentation, and it is not that users cannot ferret their way through intricate software. Developers could write supporting documentation – IF they weren’t developing that particular product. But alas, developers are too close to the products they are developing. They lack adequate perspective when it comes to their fledgling software, and they have great difficulty seeing it from a user’s point of view. The software, to a developer, makes sense. Developers arrive at a use-stance with some assumptions about functionality and behavior already in hand. So they make lousy content writers because they can’t see it from a user standpoint.

A shift needs to occur in order to artfully create usable content. A developer’s view is, “this is the product, and here are its amazing features,” whereas a technical writer will approach the very same thing from a perch saying, “here is how to do some amazing stuff with this new product.”

Technical writing shifts the focus to a user-centric view that is very difficult for a developer to take. It’s also no small thing that technical writers have been trying to master language, grammar and syntax for the better part of their educations. It’s a sure bet that developers have taken English courses as part of their college education. There are no programmers out there who are illiterate, don’t get me wrong. I work with some really smart people, no doubt about it! But when I tell them that all of our documentation is better perceived in active voice rather than passive, I tend to get a room filled with glassy-eyed folks who really want to get back to their work creating dynamic rules instead of determining whether or not they need a helping verb.

Technical writing in the software field is far from dying. What it IS doing is merging – tightly – with user interaction. It is absolutely, inarguably true that users wish they did not have to read so much in order to get started when they have a new product in their hands. So when we design documentation, we had better design it to work well. Lean documentation is essential – Strunk and White and their mantra “omit needless words” were not kidding.

Working with developers is an art. Letting them do what they do best, and making way for what writers do best, is a science.

I’ve argued more than once that mastering a given tool, like Dita or Framemaker, is fruitful but only if the situation calls for it. I have a totally separate set of tools that I use in my job, and they may or may not prove to be portable, but the skill that is 100% portable is that I can talk to, work with, communicate with, and understand – developers. I let them do their jobs with great enthusiasm, and I encourage them to let me do mine. It’s a synergy that keeps us all smiling, and pushing software out the door at a high rate of success. I work on UX, I design good doc, I focus on usability, I listen to my data.  I look at those sills that simply crackle with career stability. I let the developers tell me everything else that is important. And…I don’t make them write too much. Why? Because they don’t really enjoy it anyway.

And developers make really bad tech writers.

#Ilooklikeatechwriter

 

International-Womens-DayI know I just posted yesterday, but I have had a working draft of this piece in the hopper for a while; it just never quite grew its feet, as I like to say. And I can’t put a piece on the blog until it has its own feet. But today, being Women’s Day and all, the piece found its feet.

I recalled Isis Anchalee – remember her? She’s the bright, talented, strong, and yes, beautiful platform engineer from the Tech Startup OneLogin who asked her to participate in their ad campaign, which then sparked the #ilooklikeanengineer hashtag movement. It didn’t take long for the misogynists among us to determine that Isis was simply too pretty to be a “real” platform engineer. There’s just no way a smart brain could be housed in that attractive body.

The movement caught on fast, but it has faded just as quickly. It’s not enough to repeatedly have lists like Forbes top 30 women under 30, although that’s a great list. I say it’s not enough, because when a company like Microsoft reveals its diversity numbers to reflect the staggeringly awful truth: over 75% male and 60% white, with an only 29% female workforce globally, that’s alarming. And then comes the real hit: only 12.5% of Microsoft’s senior leadership in America is female. (Source: Forbes). This is happening even though we know that women are generally better at coding tasks than men.

But we also have to reveal the truth that, according to the US Department of Labor, only 12% of Computer Science graduates today are women.

Why? What about this environment is blocking women? Are we really just not cut out for this field?

ways-to-celebrate-international-womens-day-online

Not really. According to Gayle Laakman McDowell, author of Cracking the Interview, and a coder herself, it’s primarily that girls, when they are girls, are mostly sent the message that, “hey, this stuff is not for you.” Subtly or overtly, young women are, from a very young age, steered toward the humanities while young men are steered toward hard sciences. (We’ve known this for a long time, but I’m providing ethos here. I’m a writer, so to show you I have backup, I provide a subject-matter-expert, okay?)

So we tell girls and young women that they just don’t look like coders. They look like teachers, they look like nurses, they look like bank tellers or whatever, but they do not look like they fit in the cubicle-hive style pressure system that is software development or platform engineering. Is that it?

In other areas of their lives, we are telling them to be “totally natural,” or to be proud of what they look like. We tell them to embrace their body types and to live their lives with gusto. Kate Winslett recently signed a modeling deal with L’Oreal that has a “no Photoshop” clause, and we applaud this honesty and truth to herself.

But we haven’t told young girls that if their true beauty is in writing code, that they are totally entitled to that gorgeousness?

The percentage of women who work in tech companies remains consistent, at around 30%. So there ARE women who do this stuff, but it’s stagnant. It is failing to grow. Even though more women go to college, and an even greater number of women attain graduate degrees, the percentage stays flat. Now, what I find truly remarkable is that the percentage of women in technical or leadership roles – roles where they can actually influence the direction the company takes, is even lower. This difficulty may be the result of well-known sexism in the technology sector, or at least an unwillingness to combat it. The New York Times ran a great piece in April of 2014 called “Technology’s Man Problem,” documenting just this trend, and not much has changed in the last two years, but some things have.

It is not just a matter of moving more girls into a pipeline of studying STEM, because the high rate of attrition in tech moves them right on out the door just as quickly. Teaching women and girls that the tech field is appealing, lucrative, and open to them is not the quick fix we hoped it would be. Instead, fixing the culture that says, “you don’t look like an engineer, coder, tech writer…” THAT is the solution, or at least part of it. In the UK, a campaign called “This Girl Can” strives to connect young women through physical activity and inspiration, while here in the US, Target recently launched an ad campaign called Target Loves Every Body.

I believe we need a culture shift that defines, or redefines, the landscape to show that coders look like lots of things, and writers look like lots of things. Women in many careers have been trying to reshape their images from Hollywood to magazine covers, so why not in Silicon Valley, too?

Women helping women is the key to confidence and the key to success. If tech culture is going to change, everyone needs to change. The emotional and professional cost is simply too high not to. So on this, Women’s Day, the challenge is to reach out to a woman in your field – or a woman not yet in your field – and mentor or inspire, encourage or reassure her. That is how it gets done. Make a pledge to yourself that you will make room in tech for one more young woman, or that you will make additional room for one more established woman. It’s a jungle in here. Even women who have worked in here for years can get lost in the tangle of tasks, so have lunch this week, next, and next month too. There is networking to be done, and we could all use it. Today does not need to be the only Woman’s Day you have this year. Let the women in your life, especially in your tech life, know that they LOOK like accomplishers, achievers, builders, and leaders.

And then, if you are a woman, make sure you accomplish, achieve, build, and lead.

iwd-women

Wanna Be?

im_not_technical_writer_but_ill_take_a_look_tags_for_luggage-r22932d3fe69a44a28354b2de672858c5_fuy1s_8byvr_324

What makes you want to be a technical writer?

I recently saw a (rather poorly written) post on this very topic. It’s not a big mystery, why people go into technical writing, and yet I see posts that are similar to this all the time.

Oooh, why would you go into technical writing? It seems boring. Isn’t it dry? You seem so creative. You should write poetry. Don’t you write fiction, too? The answers are pure, they are simple; they are common. Anyone who varies too greatly from these is either naïve or lying.

  1. I am a technical writer because the job is fairly secure. While the world of creative writing is fun and soul-filling, it is as secure as acting or ballet. There is no guarantee of a paycheck next week in the creative and performing arts. So, while my BA is indeed in creative writing, and I think I am fully capable of writing the Great American novel, I am just a tiny bit risk-averse. My MA is in Rhetoric. So, I ply my trade week in and week out by putting as much creative spin as my company allows on the technical prose of mainframe computing. In my extra time, I blog. I write flowery emails. There you have it. Technical writing pays the bills. It allows me to be a professional. Mystery solved.
  2. I am interested in the field. Let’s face it, even if I believed and professed all of the things I’ve written above with my whole heart, if I lacked interest and acumen in technology, I could not write about it. I’m fairly certain that the greatest poets in the world could not be successful technical writers, because they lack an interest in what I do. One of the things that I believe landed me this job was the ability to discuss, articulately, topics like the internet of things, chunking, and what I would do if I simply did not understand how a software program works. I conversed in SMEs and design documents fluently enough that my interviewers saw that I was willing to work through problems and learn new systems. I don’t know if Salinger did that.
  3. I get to work with incredibly smart people. Sure, you could hear this in more fields than just technology, but this is especially true in technology. Many of the brightest minds work in tech fields, and that isn’t going to change any time soon. There are smart people working in real estate, hospitality, landscaping and a host of other fields, of course, and I am not set to disparage those careers in any way. But technology is a rapidly-expanding territory, which leads me to the last criteria for what makes me enjoy this field tremendously.keyboard
  4. I get to shape the language that shapes the things you use and buy and implement. I have insider information about the waves of the future. That new app? I get to hear about it early. The Internet of Things? That’s in my house. Indeed, I already turn my lights on with my cell phone, unlock my doors with an app, I use the internet to bank, heat my home and order food. I research driverless cars and automated delivery systems. But it’s not just toys and games. I learn about how medicine interfaces with human-computer interaction and how we are learning to send information instantaneously across continents. I design documents that can be read by machines and how diagrams can be interpreted in multiple languages and translated for those without sight. Some of this is job, and some of this is just fun for me.

I hope to integrate word strings so that one day a computer can do my job – the typing, not the thinking.

 

I am still very much an artist in the poetics and fiction and creativity department. I enjoy the artistry of the well-told tale, and I’ll never cancel my subscription to the New Yorker, trust me. But when you examine a vitamin bottle, or tap the box on the screen at the  ATM, keep a fond place for me in your heart, because odds are a chum of mine – known or unknown – drafted that prose. Demonstrating skill in the world of tech doc is a pretty fun gig when it comes right down to it. And you probably couldn’t install that version of your newest software if it wasn’t for a girl like me.

Can Software Write This Better than Me?

In my job, Icomputer writer’m expected to use a variety of tools to ensure accuracy, word count, compliance, style – adherence to a host of things that keep me “in line” with the company’s overall design and standards. This causes me to wonder: as part of a team of software developers, could my team design software that automates the process of writing the documentation for their own software with enough accuracy that the documentation specialist goes the way of the dinosaur?

I mean, the whole point of some of my products is to automate processes that human beings used to perform, and to automate them to such a degree of precision that people are hardly required to be cognizant, let alone present, for the actions these programs perform. We’ve designed such reliable systems that banking, health care, military information and community design can count on big data to gather and maintain the necessary materials to run our daily lives, and to store that data, to anticipate problems before the occur, and to rectify those problems with limited human intervention.

When you think, “but this type of automation cannot be applied to writing…writing requires critical thinking and analysis!” You would be correct. But you would be overlooking tools like the lexical analyzer Wordsmith, and the automated writing tool also named Wordsmith. Created by Automated Insights, Wordsmith is the API responsible for turning structured data into prose – it literally takes baseline information and makes an article. Could I be out of a job?

Feed me some data, and I write articles, too, only you have to pay me and occasionally socialize with me. Not so for Wordsmith.

The freakish thing about Wordsmith is its accuracy. I’ve studied a good bit about semantic language interpretation, and in my graduate program at Carnegie Mellon University, I dabbled in software interpretation of language, working with a pretty notable team on designing huge dictionaries of strings of language. The thing is, computers are great at reading – they can read at much faster rates than humans, they can digest huge chunks of information and store that information at infinitely larger capacities than the human brain can and their recall is spectacular. Skeptical? Just watch the amazing Jeopardy matches between IBM’s Watson and you’ll soon see that computing power can be harnessed to cull through the informational equivalent of roughly one million books per second. Humans just can’t keep up. Humans who write can’t touch that.

If computers learn a perfect formula for the Great American Novel, we are doomed.

Something to consider. Let’s try to keep this a secret from my bosses, shall we? My team of very excellent software developers may decide that this is a project worth undertaking, and the next thing you know, it won’t be just data that Wordsmith will be analyzing.

In the meantime, I will rely on the human eye and the need for context clues and interpretation that Wordsmith and Watson lack. I’ll count on the systems of reliability and emotion. I’ll count on what I know. What I learned in that high-functioning graduate analysis: A computer cannot tell the significant difference between these two exchanges:

Scene 1: A funeral home. A somber affair, all is quiet. A man says to a woman:

“Sorry for your loss.”

The appropriate response? She shakes his hand and nods, quietly.

Scene 2: A soccer game. A sunny afternoon. The breeze is blowing gently.

A boy says to a girl:

“Sorry for your loss.”

The appropriate response? She high-fives him and replies, “No sweat! Let’s grab some pizza! Woooo hooo!” As they tumble into a minivan, shouting jubilantly, kicking off their shoes.

No computer can decipher the differences in – “Sorry for your loss.”

Sorry, Wordsmith.

I’m going out for pizza.