A Technical Communication Conversation — Ray Gallon

This is part of the series of conversations that I originally published in ContentHug, in 2015.

Thank you Ray Gallon.

[CH]: Technical communication has really evolved from merely planning and writing user manuals, to an ROI driven approach, UG content, and a new set of web based authoring tools. I must say these are all integration points with content strategy, towards the common goal. Considering this convergence, what exactly ‘content’ community needs to address? For example if we talk about titles, what can be the next title of a senior technical writer or a documentation manager that can explain what you are trying to do for an organization?

[RG]: I have a visualisation that I call “The hairball of content.” It goes like this: At the centre of the universe, there is great huge, tangled-up hairball, like the kind your cat spits up. Enclosing it and spinning around it is a large polyhedron. On each facet of the polyhedron, there’s a door, and each door has a label:

Technical communicator | Content strategist | Science writer | Medical writer | Specification writer | Information architect | Journalist | Web designer | Graphic designer | Content marketer | Content architect | Documentation engineer | Knowledge manager | Digital Asset manager | User Experience designer | Instructional designer | Learning specialist | Multimedia producer | Radio producer | TV producer | Video maker | Audio maker

…and so on. You can walk through any of these doors, and your objective is going to be the same: untangling the hairball, and making sense of it for your audience. Each of the specializations I’ve mentioned above (and there are lots more) provides a different methodology, or flavour of methodology, for doing this. We each have our specific training. But we also occupy the same, limited space inside the polyhedron, and we all want to untangle that same hairball, so we necessarily get our hand dirty in each other’s mudpies.

I’m doing a tech comm taxonomy, and I want my users to be able to navigate it correctly, so I get into Information Architecture, even if I’m not an Information Architect. When I do a business analysis for my client, to show the ROI of certain kinds of technical communication investments, I’m also doing content strategy. Can’t be helped. Every day, we “content workers” do things of great value for our employers and clients, that are not in our job descriptions.

If I were to invent a global title, it might be something like “facilitator of common sense,” or something like that — but no one is going to hire a person with that title. The truth is, there is no one title that is going to work for all of us, and part of the joy, but also the frustration of the work we do is that it so evades defining.

In the STC, we decided to stop trying to define a profession called “Technical Communication” and refer, instead, to a discipline. I think that is the best approach. We practice the content disciplines, in all their myriad shapes, forms, sizes, and varieties. Now that the word “content” has become fashionable, I don’t see why we don’t simply flaunt that as our strength, and move on to more interesting questions that get to heart of what quality means, or where the source of value lies.

[CH]: Assume that you get your dream job or contract, lead or otherwise. What is the most important thing that you have learnt so far that you will put into practice there?

[RG]: Well, I’ve already had my dream job. I got to coordinate the development of almost all the customer-facing information for a new software platform that covered different types of software with different interaction models, and that were being developed by teams around the world: France, USA, UK, Israel, and China. We had to develop common standards for user interfaces that would be familiar to customers using more than one product, while not hamstringing the different needs of each type of software. We also had to mediate between each development team’ understanding of English — we were using that as our common language, but none of us spoke the same “version” of English, as you might expect. We had to transcend cultural differences — both national and corporate — and we had to conform to regulations in multiple countries.

Our software was localized into 33 languages, and our embedded information — sometimes in software, sometimes on paper — had to be consistent and coherent, not only with itself, but with our web site, which meant I also had to work very closely with the web team, graphic and interaction designers, product managers, the business development manager, and even the CEO of the company. What a fantastic sandbox! What learned by playing in it, was how hard it is to do this job, especially when you are nobody’s boss — I had no power, and had to work by influence.

One of the things I also learned, was my own limits, when dealing with toxic personalities (only one or two, but significant ones). I could have, and should have, been more subtle at managing them, but eventually just couldn’t suffer fools gladly any more — something I regret, however justified I might have felt at the time.

The bottom line for all this is that working with content means working with people — and being adaptable to languages, cultures, working methods, personalities. Those of us who are really good at it have to do this every day, and it’s a great and wonderful challenge.

[CH]: There are times when we need to push things around, such as to get a buy in. Can you share some experience when you had to take a really tough call, such as for style guide, for user education, for a new authoring environment, or for deliverables?

[RG]: I consider pushing things around to be contrary to getting buy-in. If you have to call in the guns, you’ve failed. But sometimes you do have to do it. We spent two weeks once, in costly international phone links, debating which colour blue would be the right one to use in a variety of interface situations. I finally asked my boss if he would just arbitrarily choose a shade of blue, and that’s the one we went with. SHEESH!

[CH]: How do organizations address the content ownership concerns when we have content strategists, content marketers, technical communicators, and even data scientists? How do you see your role in defining the content ownership process?

[RG]: No one owns content. We just borrow it. The best way to deal with siloing issues to to jointly analyze where you have under-used, or poorly used resources, create new teams that will use them to best advantage, and repurpose people so that everyone is working to full capacity in a collaborative manner, walking hand in had through the different doors of the polyhedron, leading to the hairball of content.

[CH]: What role technical communicators can have in disruption–technology or otherwise?

[RG]: Technical communicators have ALWAYS had a role in disruption-technology. Back in the days when we just wrote manuals, we disrupted the whole development team by uncovering bugs, sometimes very late in the game, that the test team missed entirely.

Today, our role is to shake up the development teams in a different way. Developers think functionally, as a rule. It’s their job to think functionally. We think more in a task-oriented way, the way that users think about the products they interact with. It’s our job to think “out of the box” and give the developers that user-oriented view, make them change their way of thinking. This doesn’t just mean changing the way things are arranged on a screen, or the user interaction model.

It means rethinking what our interactions with technology need to be — should we be using augmented reality? Or simplified reality (using digital technology to provide clear detail of what the user needs to focus on, and stripping away all the rest)? Should we be thinking about how we control the Internet of Things so that it doesn’t get carried away — for example, ordering things from our fridge that we don’t want or need? Who will take responsibility for unwanted products that are ordered by connected objects? How will returns, rejects, defects, be managed for users when most of the process is automatic and without human intervention? Who will tell the machines what they need to watch, what to do when certain events are triggered, and whom to inform? How will they do this?

[CH]: Can you name any companies or brands whom you admire for their content?

[RG]: I think IBM’s intranet is one of the most amazingly rich environments I’ve ever seen. It is full of information of all sorts, including things that you would not consider to be professional. It has its own equivalent of Twitter, known as “Blue Tweet,” and it has a great sense of humour about itself. The findability could be better, but it’s really a WOW experience to dive into it.

[CH]: If you could weave a magic wand only once, what you wish for your current role at work?

[RG]: Lots of gremlins to execute, so I can think, dream, and invent.

Vinish Garg | Products. Experience. Stories. I am a EEES (External Eye Experience Specialist) for startups and their goals, for content, UX, and customer experience.