Might seem a bit of an odd topic for a tech author who is employed, as opposed to contracted to, a company, but someone made this comment in passing and it kind of struck a nerve as it applies regardless of your current position. We all have something to sell.

It took me sometime to develop enough business-savvy to realise that, despite knowing that doing X instead of Y makes more sense for my users, and my team, business decisions and the drivers behind them don’t always work that way, and sometimes you have to take some pain before getting to where you want to be.

A lot of authors I’ve worked with in the past that share that mentality, are usually now managers, or senior writers or whatever the next step up our career ladder happens to be, so from my limited experience, I’d suggest that it makes sense to understand the business impacts and opportunities available, and how you can sell the services of a technical communications teams to the rest of your organisation.

There are some obvious things to try, and looking at how your marketing department are selling the product is a good place to start. But I’m curious to hear if you have tried anything in this area, and if so, what worked for you?

My ‘other’ site holds brief details on my little side job stuff, which is mainly focussed on web design. I’ve just finished a website (with another on the way) and it’s nice to get that little glow of achievement. I deliberately choose small projects, and it’s fun to take what I learn there into my day job as a technical writer.

Taking the lessons I’ve learned over the past couple of years whilst “running” one man designs, which is in essence a small business, into my dau job has been interesting. Treating a small team of technical writers as a distinct business makes sense on many levels. One I hadn’t really considered in great depth was marketing the services of the team, selling what we do to the rest of the company.

I guess I’d considered it an educational function and, once educated, everyone would (somehow) know to get the technical writers involved with their project, or introduce the latest functionality to them. Of course this is never the case. Now, don’t get me wrong, I knew this but just hadn’t really considered it in great detail before… what with being busy, you know, writing stuff. ;-)

So how do you approach this kind of thing? Do you hold meetings, talk to the other team leads/managers directly? How do you “sell” what you do?

Recently, as part of my induction, I completed a simple questionnaire as part of a Belbin team role analysis exercise. This sounds much grander than it really is, although the simplicity of these things always amazes me. Who would have thought that by taking a few minutes to consider ten different questions, each with eight possible statements, and ‘scoring’ yourself against three (or less) of those statements, you’d be able to see which role you typically take when working in a team environment. And who would have thought that, mostly, the damned things would be so accurate.

It’s the second time I’ve taken this particular test (the other common one is the Myers-Briggs personality test… I used to be an INTJ for that one, but that’ll have changed by now) and it’s proved itself to be accurate on both occasions. This is despite the fact that I’m not the same type of ‘person’ that I was when I first took the test. Impressive stuff.

The Belbin definition of a team role is:

“A tendency to behave, contribute and interrelate with others in a particular way.”

Briefly, during the 1970s Dr. Meredith Belbin ran several experiments to try and determine what types of people, when combined in a team, produced the best results. One of the key principles he found was that every team needs a mixture of roles, and that every team member, as well as bringing a set of strengths to the team dynamic, also brings a set of ‘allowable weaknesses’. The idea being that not everyone is perfect and you need to accept that. Dr. Belbin discovered that every team needs a mix of around nine different types of team role, and that there should be at least four people with a mix of roles (some roles are interchangeable before any of you math heads leap on that).

Based on his findings, he devised a series of questions, the answers to which help to pinpoint your typical team roles, with each person having a primary and secondary role within a team environment. These typically aren’t things you can plan or cheat, they are reflections of your personality, manifest in the workplace, and whilst they will change over time, they can be hard to influence.

Yes, it’s one of those things that, to many, seems obvious and the very fact that a test exists to try and “theorise” about this kind of thing is tantamount to management-wankery. I disagree with that notion though, as it’s only because of the early-thinkers about this are of business (and life) that we have ended up with the idea of teams in the workplace (to a degree).

Obviously every team needs a good mix of the right kind of people. You need someone to provide ideas and excitement at the start, to organise and motivate people, you need people who will take that idea and question it, pull at it and delve further into the roots of the problem, you need people who will help keep things on an even keel, and you need the people who will sit and churn away until the job gets done. Those people are not one in the same.

Me? I was, primarily, a co-ordinator, a chairman, the type of person who gets all excited about new ideas and helps organise and motivate people at the start of a project. Unfortunately, coupled with my secondary role (resource/investigator) my “allowable weakness” amounts to the fact that I tend to drop things after the initial excitement has died down. I wish that weren’t true but it’s an easily identifiable trait. Hell, you need look no further than this website for an example. There are still things I had planned to do here that I haven’t gotten around to, and likely never will.

But what really got me was that, the first time I took this test, the outcome was completely different, but equally as accurate. I was still enthusiastic, still excited about new things but lacked the ability to organise and motivate others. Which would be true as the last time I took the Belbin test I was still very much a team member, not a team lead.

Is Belbin analysis useful? Yes. From a personal point of view, it was a timely reminder of my weaknesses and helped me to focus on them in the past few months. From a team point of view then, again, yes. Knowing that you are working with someone of, say, a similar nature to you allows you to realise, and plan to deal with, the potential conflicts that may arise.

As most technical communicators work with a variety of different people, in different parts of the organisation and almost by definition, those people have widely differing personality and team types, then any information which can help you to tailor your contact methods is surely a good thing.

Without meaning to I seem to have taken some inspiration from this post, whilst I’m not directly offering a counterpoint, it’s worth a read.

~

Every trade or profession has a skill set, a unique set of talents that make one role different from another. For most people in the IT industry we all have some amount of ‘business-led’ skills such as time management, a little project management perhaps, and so on.

As a profession, Technical Communications covers a wide range of skills and some people, depending on their role or the company the work for, can end up being a jack of all trades (master of some?). However, there are some skills that are easily identifiable as being part of our core job and apply to most, if not all, technical writing positions, for example:

• Writing
• Editing
• Indexing

After that we can look to other areas in which some technical writers dabble, either because of company need or personal curiosity, such as:

• Graphic design
• QA/Testing
• Coding
• Usability
• Information Architecture

All of these skills are professions in their own right, and whilst I would never suggest that a technical writer could replace like for like, we do tend to inherit a few additional skills as we bumble along. The specifics and amount vary from person to person, situation to situation, and whilst that means that no two jobs are the same it does present a small quandary.

How do we come up with a generic job description for our profession?

Even if I was to limit the scope of that question to my own personal experience, having worked in 5 different software companies with each having a slightly different view of what my role should be (and with each role being developed in a different way once I had joined the company), it’s still hard to get a single, generic, job description.

This all sparks another question, why do we need a generic job description for our profession?

Well put it this way. A software developer will have a set of skills, but I’d warrant that their list of core skills far outweights the list of their secondary skills. There is an understanding that a software developer will know certain things, and that list is far longer than that of a technical writer yet we have the potential to bring so much more than ‘just writing’ to a company.

To help publicise our capabilities, and the benefits of having a dedicated technical writing team within your company, a generic job description is an ideal starting point to make sure the hiring managers of the world know what we CAN do, if given half a chance.

I know that a generic job description will never match any one role, but I imagine it like a pie chart, with each slice (skill) growing or shrinking to meet the job specification. But before we can bake that pie we need a full list of ingredients.

So, what have I missed? What other roles and skills do you bring with you to a company? Let us build our generic technical writer, we can call her Tina… (or maybe not)

Just about finished at this years conference and, as ever, I feel fired up to get back to the office and get things moving. Overall the main theme of the conference was preparation, preparation, preparation, mainly focussed around gathering requirements before kicking off a project. Nothing special there but if you are considering moving towards a single source environment, there is a LOT of preparatory work you’ll need to consider.

I’ll amend this post tomorrow with some notes and thoughts from some of the sessions, but overall I’d highly recommend you visit X-Pubs next year. What follows is largely compiled from scribbled notes and random thoughts, but hopefully may be of interest. I’m not sure if copies of all the slides will be available on the X-Pubs website at any point, I certainly hope so.

Like most people, I ‘fell’ into the world of Technical Communications. I didn’t choose this career, and like many I didn’t study anything that remotely involved writing. But then, who really knows what they want to be when they are choosing what to study at university.

So, after spending a few years learning about Electronic and Electrical Engineering, and largely finding the entire experience boring, I packed that in and somehow found myself working as a Technical Administrator for a small local software firm. My Mother had spotted the job advert in the local paper and the rest, as they say, has passed under the bridge…

Having spent some time helping out at a local community centre, creating flyers and brochures for local charities and organisations, starting work as a Technical Author was a departure into a new ‘technical’ world. I learned a lot of things in that first job but the most important things can be easily summarised and stated that as “how NOT to be a good Technical Author”. Still, no-one can say I don’t learn from my mistakes.

Fast forward many years and I find myself in the position of knowing enough about my profession to understand how it can best help the company for which I’m currently working, and being comfortable enough about the processes involved with being a Technical Author that I don’t need to worry about them on a daily basis. I can quite happily paddle along, with nary a ripple cast in my wake. Of course I strive keep up-to-date with the latest fads and fashions in the world of information access and creation, technologies and methods which are constantly on the move, but the changes to the prevalent methodologies within the Technical Communications industry (the draft and review process for example) evolve rather slowly, and I have to admit that the lack of speed of progress in these areas is a concern.

Anyone involved with the software industry will have felt the varying effects of the internet, good and bad, as it has ripped across many different areas of technology, massively changing how people think about information. We, as Technical Authors/Writers/Communicators now work with a commodity which continues to rise in value as more and more people create and manipulate, publish and expose it for everyone to use. It’s no revelation to state that the internet has brought about an ‘information boom’ and this boom means that, for those of us working in the software industry, we need to rise and meet one simple expectation.

I want it now. No, I don’t want to look it up. No, I don’t want to have to read anything. No, I’m not that interested in anything else other than solving my current problem. Now. Please. Thank You.

Not even 10 years ago the expectation was different. The expectation had some built-in tolerance, an acceptance that information may need to be found, or at least filtered, from at least one source. Maybe that expectation was taken advantage of, maybe that expectation gave us an excuse to produce a level of product documentation that was ‘good enough’, as opposed to ‘better than expected’. Maybe not.

The field of Technical Communications prides itself on making information usable. Yes, there is a focus on making sure that information is complete, and accurate, but after that there is little point in having information if what the reader wants to find is hidden away behind some weird structure or methodology with which they are unfamiliar. There are a number of ways to presenting information to the user, and some consistent methods such as a Table of Contents, or an Index being the most common. However these all require some effort and in the age of instant access I’d humbly suggest that there is one growing universal truth by which all information must abide: If I can’t Google for it, why would I bother?

Of course it’s not all bad, one technological advantage of the “Google-age” is the relative lack of work required to make your information available to the mighty search engine. Put your PDFs, web pages, or even Word documents on a website and Google will find it. Simple enough.

However, to fully leverage the advantage and properly embrace the webcentric view so many people now have of the information world, we, as a profession, need to add another string to our bow, we need to master the skill of search engine optimisation (SEO). This is no small task but, naturally, the internet is brimming with information that can help, with plenty of hints and tips to get you started.

The world of information, both creation and usage, continues to change, I wonder what other skills we will need to develop?