Leah Guren’s Fish Tale at TCUK12

After opening remarks by conference organizer David Farbey, Leah Guren‘s keynote relevant and entertaining keynote address presented several lessons from the animal world:  A Fish Tale: Improve your Career by Watching Fish!

  1. Take a leap of faith – like salmon. It simply takes some guts and a little bit of faith that tech comm is here to stay, else you won’t be able to make a long-term plan and get behind it.
  2. Stay in school for better chances of survival – once you took that leap, keep honing your skills, keep developing. There are lots of ways and many don’t require the same amount of time and money as going to a conference, whether it’s e-zines, forums, user groups or webinars (some excellent ones are actually free!) Be sure to make your professional development part of your regular work schedule.
  3. Invest in better PR – the difference between a carp and coi is mainly the prize tag – which is thanks to better PR for the coi. Communicate your value that you bring to the company and to its customers. We know how much words matter, so we can do better than calling ourselves technical writers. “Information architects”, “content strategists”, even “technical comunicators” can make more money.
  4. Find the right stress – (sorry, I forgot how this related to fish… 😉 ) Tackle your fears, get a new challenge and pick the kind of stress where you’re still in control, feel stimulated and can grow.
  5. Active swim in a larger pond – because like a carp you will grow (professionally) in relation to the size of your “pond”. Find opportunities for growth how you can be the expert in your environment.

I’m sure I forgot a couple of Leah’s lessons. Nevertheless, I want to add an additional lesson that I’ve found important: Know the secret of the birds. That means know how your enemies tick, so they don’t eat you. Or if they’re not threatening: Seek heroes outside of your immediate field. Sure, you won’t be able to fly like a bird, but you can still find birds inspiring.

Advertisements

James Conklin, Overcoming Change Resistance at STC12

In “Understanding and Overcoming Resistance to Change”, James Conklin focuses on change, rather than on management as most change management seems to do.

Why change fails

The problem with many change management initiatives is that they fail. Too many of the involved people perceive change as a thing that is “out there”. So instead of embracing the new, they resist this “external change thing” on several related levels:

  • Fear. Change threatens to undermine the skills, power and security that people have built up.
  • Reason. People argue rationally against the change because it contradicts their goals or because they simply do not understand how it will improve things.
  • Personal attributes. People may resist change because it doesn’t address their age group or their learning styles or their cultural or ethnic background.
  • Psychology. Change can incite strong emotions that leads to denial and, once again, to fear.

Why the explanation fails

James points out that these reactions involve a significant “attribution error”. We tend to blame other people’s resistance to change on them, their attributes, their lack of skills, their stubbornness. But we often blame our own resistance to change on our situation, lack of time or resources, etc.

What resistance is

There’s a more constructive, alternative perspective on resistance which is compatible with both sides of the attribution error: Resistance is one of the ways we make sense of life, specifically of our experiences in the workplace.

If we perceive resistance as a clash of narratives of different experiences, we can get away from an opposition of stubborn persons and towards an open-ended, negotiable inquiry – without losing sight of the goals! We can focus on fixing the situation by redistributing power and autonomy instead of blaming people and transforming their tasks.

What sounds very theoretical up to here, has been born out by studies from Canadian nursing homes where nurses and caretakers had initially resisted changing their procedures. I’m also reminded of other successful changes in the workplace, whether it’s Best Buy’s ROWE initiative or schemes that empower people to work remotely and still manage to hold them accountable for their work and results.

What this has to do with techcomm

For many in the audience (myself included), it was obvious that James speaks about change that technical communicators find themselves in. But James also points out that technical communicators play an essential part in shaping narratives of change.

We set the tone in customer-facing documentation: If we know their situation, we can join their conversation, explicitly compare their current situation to a new way of doing things. Then we take them seriously and address a change in processes constructively. We can even engage in their conversations directly, for example in forums or other user feedback.

If we recognize the importance that our users place on the purpose and value of their work, if we reflect not just the metrics of their work, but also the quality they attribute to it, we can improve the user experience and help to facilitate change with technical communications.

My webinar slides as PDF handout

If you’ve attended my webinar “Getting ahead as a lone writer”, you might be interested in the slides in PDF:

They were supposed to be made available to attendees by the STC, but apparently that hasn’t happened as I’ve just learned yesterday.

If you have any more questions about the webinar or being a lone writer, feel free to browse my previous posts or pose your questions in a comment below.

Get ahead as a lone tech writer with a STC webinar

A compact 1-hour STC webinar gives you the low-down about getting ahead as a lone writer, from tools to strategy – plus two words every lone writer should know how to use.

What?

Writers are often the only person in a company who create and maintain documentation. Lone writers who operate without a dedicated budget or specific managerial guidance find it hard to excel in their work. In this webinar, I will draw on my experience and explain how to make the most of this “benign neglect”:

  • Develop your skills—and your career
  • Raise your profile with management and colleagues
  • Contribute to a corporate communication strategy
  • Help your company to turn documentation from a cost center into assets

When?

Wednesday, 29 February 2012, wherever you are, right at your PC via the web:

  • 10:00-11:00 PST – Los Angeles
  • 11:00-12 noon MST – Denver
  • 12:00-1:00 pm CST – Chicago
  • 1:00-2:00 pm EST – New York City
  • 18:00-19:00 GMT – London, Dublin
  • 19:00-20:00 CET – Copenhagen, Berlin, Paris, Rome
  • 23:30-0:30 IST – Mumbai, Bangalore

How?

Available as webinar, live or recorded, via the STC’s webinar site:

  • STC student members: US$ 29
  • STC members, sale price: US$ 59
  • Not yet STC members: US$ 149

I hope to see you there!

Half-way DITA: Why some is better than none

If DITA seems like a good idea, but you cannot make the case for it, you can move towards structured writing and make your documentation “future-proof” by meeting the standard half-way.

At the company I work for, we tech writers created manuals in parallel, but separate to online help. Over time, this gave us a documentation set that was inconsistent in places and hard to maintain to boot. Topic-based authoring which reuses topics in print and online can fix that, of course.

First, a documentation standard

Deciding on the method is one thing, but we also wanted a consistent structure that made the documentation easier and clearer to use – and easier to maintain for us writers. That required a model that specifies which kinds of topics we want to offer, how these topics are structured inside and how they relate to one another.

As we looked towards a documentation standard, we had two options:

  • We could create a content inventory of our documentation, analyse and segment it to tease some structure from that.
  • Or we could rely that others had solved a similar problem before and see if we can’t use the wheel someone else had already invented.

Turns out the second option was quite feasible: The DITA 1.2 specification gives us about all the structure we need – and more. We left out the parts we didn’t need (for example, some of the more intricate metadata for printed books) and adopted a kind of DITA 1.2 “light” as our information model.

Second, the tools

Note that I haven’t mentioned any systems or tools so far! Even though it happened in parallel to the rolling out topic-based authoring as our method and DITA light as our information model, the tool selection was mainly driven by our requirements on documentation workflows, structure, deliverables, and budget.

The tool that suited us best turned out to be MadCap Flare – even though it doesn’t create or validate DITA!

Using our information model in Flare, we believe we get most of the benefits of DITA – and considerable improvement over our less-than-structured legacy content. And speaking to people at WritersUA 2011, it seems that we’re not the only one to move from less-than-structured writing to XML and something “close to DITA”.

Technically, we’ve defined the DITA elements we need as divs in the Flare stylesheets, but otherwise use the straight Flare authoring-to-publishing workflow. Flare is agnostic to whether a topic complies with DITA, is somehow structured but not complying or totally unstructured.

The benefits of DITA, half-way

To us tech writers, the largest benefit of DITA, half-way, is that we can actually do it. We could not have gotten away with DITA, the full monty, which would have required a much longer project, a much bigger migration effort and hence, uncertain ROI.

For new topics, we are committed to writing them structured, so they follow the information model. To migrate legacy topics, we’ll have to ensure they have an identifiable topic type and a suitable heading, but we can cleaning up their insides in a “soft fade”, moving them towards structure one by one. This gives us a quicker win than cleaning up literally thousands of topics before having anything to show in the new method, model or system.

So we will have been working in Flare and with our home-grown information model for a long while, before all topics actually comply with the model. But then we will have a documentation set which we can feasibly move into real structure, whether we opt for DITA or some other XML-based CMS, with or without a CMS.

This post is an elaboration of a comment thread on the “Why DITA?” guest post on Keith Soltys’ Core Dump 2.0 blog.

Tech comm trends 2012, mashed up and commented

2012 is the year when tech comm’ers need to understand business processes and align documentation with new technologies, say tech comm pundits – and yours truly.

What I expect for 2012

Tech comm’ers need to understand business processes.

Okay, so this trend is not exactly new, but I expect it will gain traction this year. Scott Abel thinks so, too. Business processes are crucial for us tech writers in more ways than we might think. Ideally, we understand them in three domains:

  • In tech comm, we need to understand business processes to do our job efficiently, to improve how we work and to measure if (or prove when) we are understaffed.
  • In our employer’s business (or whoever has ordered the documentation we provide), we need to understand processes to contribute to the bottom line and to get out of the cost center corner.
  • In our customer’s business (or whoever uses the documentation we provide), we need to understand processes to ensure these customers or users are efficient and happy with both, the product we describe and the documentation we create.

In a nutshell: We need to know business processes, so we know which are the right things to do, whether it’s moving our documentation to a CMS, aligning our deliverables with the corporate content strategy, or updating our personas. At the same time, we need to hang on to our tech comm skills, so we know how to do things right.

What others expect for 2012

Here are two trends predicted by Sarah O’Keefe and Connie Giordano that resonated with me. (And I recommend you follow the links to get the experts’ predictions first hand!)

Creating documentation moves to the cloud.

Documentation will follow other content production to the cloud, such as collaborative Google Docs, blogs, and wikis. With this trend, I’m wondering:

  • Compelling event? Will cloud-based tech comm creation take off now – or do we need a more compelling event than ubiquitous access and the (alleged) lower operational costs?
  • Whose market? Will conventional HAT vendors be the major players, so their customers can keep their sources and move them to the cloud – or will HAT vendors (and tech comm’ers sources) be disrupted by other providers?

Documentation design aligns with mobile UX.

Tri-pane web sites are too large for effective user assistance on mobile devices which require new, condensed documentation designs. These will in turn feed back into other documentation formats. Here, I’m wondering:

  • Turf wars? Will tech comm’ers and UX designers engage in turf wars – or pool their skills and resources for better user assistance?
  • Innovation? Will the reduced real estate lead to genuinely new ways of presenting user assistance – or to a resurgence of minimalism?

What no one expects for 2012

The survival of the classical tech comm job profile

Virtually all tech comm predictions and trends for 2012 are driven by external forces of change: The cloud, mobile devices, or new social media habits which expect collaborative documentation and user-generated content.

At the same time, the trends and predictions I’ve seen show little initiative to define or advance technical communications as a profession around a set of skills and tools, methods and processes. The classical tech comm job profile (as described in the Occupational Outlook Handbook by the U.S. Bureau of Labor Statistics, for example) that is centered around deliverables and tools, formats and styles seems to wane.

In many sectors, technical communications has instead become a function that contributes to corporate assets and the bottom line. Technical communicators provide it, as do content strategists, information architects or UX designers. And whoever pays them doesn’t necessarily care who does it – or even know the difference.

In a way, this is the other side of the coin of the trends above. Scott Abel points out:

The real value we provide is not our mastery of the style guide. Rather, it’s our ability to impact the customer experience in positive ways.

And Connie Giordano calls for the evolution of “integrated technical communications” to coordinate and integrate

all technical communication processes, tools, functions, and sources within an organization to convey information and knowledge relevant to optimizing the users’ product experience.

So I believe technical communications is here to stay – but we may have to look for news ways of selling what we do and deliver.

What do you expect for 2012?

Will you follow the trends above? Are there others in your future? Please join the discussion, leave a comment.

Top 3 tech comm lessons in 2011

2011 was an eventful year for me as a tech writer. Here are the three most important lessons I learned this year.

Content strategy can change tech comm in 2 ways

… and only one of them is up to us tech writers:

  • Tech comm departments can engage in content strategy bottom-up, connect with stakeholders in training, customer services, marketing, and producct management to try to break down silos, reuse content and make content a corporate asset. One way to do this was the topic of Ray Gallon’s webinar “Content Strategy for Software Development”.
  • Corporations can can engage in content strategy top-down and essentially change the way the organization works. The objective is essentially the same as above, the main difference is who’s driving it. While tech writers cannot do it without management support, managers may decide to relegate tech comms to one of many stakeholders – which I think would be a pity. tekom’s Content Strategy day offered several sessions which discussed corporate content strategies.

The “big disconnect” is closing

The “big disconnect” is the difference in IT innovation between consumer IT and corporate IT. Geoffrey Moore coined the phrase in an AIIM white paper and presentation: “How can it be that I am so powerful as a consumer and so lame as an employee?” Earlier, I wrote about exploiting the big disconnect as a tech writer.

The reason it’s closing in tech comm is that consumer web sites have appropriated help systems and all their benefits, so the use cases and business models finally catch up with user demands and technologies, as Scott Abel pointed out in his tekom keynote address.

Content migration is about people first

In summer, our team of writers embarked on the journey towards structured authoring. One of the surprises to me as we proceeded was that metaphorically speaking, for every hour I spend moving content, I’m spending another hour moving minds.

Your turn

What did you learn about tech writing in 2011? Feel free to leave a comment.