The World's Smallest Instruction Manual

3.5 X 4.25 inches
Single sheet of paper, printed on one side.
(Instructions for a pocket calculator.)

The Work We Do

I recently changed jobs. As a consequence I am no longer "doing" Knowledge Management. I am reminded of this fact by friends who ask me how much KM is involved in my new job. The simple answer is none. But to be honest, that's not entirely true.

My new role brings me back to my roots in Technical Writing, Information Architecture, and what is currently known as "Content Strategy". (Although "Content Strategy" appears to be having the same sort of identity crisis KM and IA go through on a regular basis.)

Which may also explain why my new role doesn't feel so different. In my previous profession, people would ask me how Information Architecture relates to Knowledge Management. My pat answer was that KM is the architectural design of potential -- rather than existing -- information.

My response was flippant, but also quite accurate. Whether you are defining the structure of a website for well-understood content or designing an interface for some as-yet-undefined content that will be chosen by people in the future... the tools, the methods, and the experience you use are much the same.

Ditto technical writing, which is very much like information architecture except on a much smaller scale. (What goes in this document vs. another? Where do we put the introductory information so the user can't help tripping over it? etc.)

Now, I know there are technical writers that do nothing but write and are affronted if you suggest they "design" things. Just as there are Information Architects that design taxonomies and not much else. But the fields themselves are much bigger than that. Which is where the confusion and bickering comes in.

I seem to be constantly in the middle of one battle or another no matter which of my various "professions" I am practicing. The reason for that is because the boundaries are very fuzzy. And ambiguity makes people uncomfortable.

So they try to delineate their roles. On the one hand, practitioners try to define the field by how they currently practice it: the tools they use or the methodology they have adopted. While others with a more philosophical bent try to expand the scope, often treading on the toes of their neighboring professions.

Currently, information architects are arguing whether IA even exists or if it (and several other forms of design) are all just different flavors of a new profession, user experience design. Or is it interaction design? Or is it...

Similarly, KM practitioners (and pundits from other fields) are trying to decide if there is a battle going on between KM and social media. Excuse me? There is no battle unless you assume KM as a field of study has to be practiced in a specific way or within a predefined, limited field of vision.

I feel like channeling a famous ex-wrestler and shouting "It doesn't matter what your profession is!"

The names we make up for our jobs help avoid conflicts when working with others by divvying up the territory. They also give us a ready answer to social situations when someone asks "what is it you do?"

Unfortunately, these names also create unnecessary barriers to getting work done. If you define your role by specific tools or tasks, you are also defining the boundaries for the solutions you can provide. You doom yourself to repeating the same work over and over... even when the environment around you changes, as it inevitably will.

The fact is that all of my professions are variations on addressing the traditional dilemma of communications theory. Whether it is communication between management and employees, among the employees themselves, between the company and customers, or among the current and potential customers the company seeks, the professions I travel with are all trying to resolve the problem of getting information into the right hands at the right time.

In knowledge management it is creating channels for the ambient knowledge within whatever community you support. In this case, your audience is often both content providers and consumers at different times. You don't control the content, you try to maximize the channel.

In information architecture it is sorting, defining, and providing a clear logical structure to at least that part of the information space you have control over (whether that be a web site, marketing, promotion, community facilitation, or whatever). You manage the content, somewhat like an orchestra conductor. But you are not the composer.

In user experience and usability design it is tuning the communication channel to be as effective as possible. You don't control the content or the structure, but you control how the audience interacts with it. (Of course, this is untrue in actuality because the interface becomes part of the message. Wasn't it McLuhan who said the medium is the message? But this is just another example of how the professions overlap...)

And in technical writing it is creating the perfect communication, including content and structure, but within the limited scope of the channel you have available to you (whether that be books, online help, training modules, or a web site). You have complete control over the content, but less over the channel and still less over the audience.

They all address the issue of communication from different angles. And taken together, provide an endless array of solutions and approaches when faced with any problem related to information.

That's why I like it.

And that's what I do.