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.

Neil Perlin, Developing for the Unknown at STC12

It’s of course impossible to develop techcomm content for formats that don’t exist yet, but Neil Perlin shows how you can prepare for them to future-proof your work – and job.


The problem he addresses is that content formats will change, we just don’t know yet how. The answer is generally to create solid content by setting and using open standards. By doing that (and avoiding proprietary standards, hacking code and tweaking our tools), we can ensure that our content will have a good life and be relatively easier to use in any future formats that might come down the line. And keeping with developments is important, so we decide which standards and tools can help us in the future.

Better structure

On the structural level, you can best standardize your content by using information types (also called “topic types”), such as task, concept, reference, troubleshooting, “show me”, etc. Try to keep your number of types below 10. (DITA, a structured authoring standard has only 1 general topic type and the first 3, I’ve just mentioned.)

Once you have your information types defined, you can create templates that already contain the topic structure plus some explanatory boilerplate text which you and other writers can replace with your actual content.

Multiple output formats

On the technical level, CSS is a great medium to future-proof your content: It lets you create your topics independent of layout. And it is powerful enough to support just about any HTML-based format to make your content (and you as its author) look good on the web, on tablets and on mobile.

Using CSS to future-proof your content means, among other things:

  • Keep your CSS definition simple and clear for easier use and better maintenance.
  • Define all your output formats in one CSS file by defining different media types for different devices, web and print.
  • Check that the most common browsers and devices which you write for support CSS correctly. (If not you may have to live without some CSS features for the time being.)
  • Use relative style size units instead of points (“pt”) which are not resizable.
  • Use styles for tables instead of hand-tweaking column width, etc.
  • Use character styles instead of “Bold” or “Italics” as in Word’s style toolbar.

To migrate your content from more proprietary formats may require some cleanup of embedded and inline styles. Some of this can be scripted, but you may still find yourself with a lot of semi-automatic search and replace.

Adopt, don’t adapt

On a methodological level, Neil advises to adopt a standard because it suits you and your business needs. Adapting your content to a standard because it’s common or new without a business case is not a good idea. So put your company and your job first and build up in-house knowledge about standards, formats and tools, so you can make the right choices.


It takes Neil’s long experience to successfully combine general career advice with specific tips about CSS. I really enjoyed this session. I’ve learned a few new tricks and got general confirmation that our strategy to migrate our documentation to XML in a DITA-derived structure was the sensible thing to do.