In the New Year we are instituting a No Talking rule in my office. If anyone has a question, they have to write it down and pass it to a colleague who will then write down their response. This should cut down on the amount of chatter and conversation that, obviously, is having a huge impact on productivity.

There will be no more talking in our office, the conversations will stop!

I am, of course, joking.

What I’m actually pondering is how to extract the casual knowledge that currently exists in the heads of the development team. The little snippets of information that take seconds to utter when prompted by a nearby colleague, but which remain out of the grasp of the product documentation and thus are invisible to anyone not sitting in our office. You know the type of thing:

“Hmmmm, hey Alice, my build failed with error 4932, any idea how to fix it?”

“Ohh sure Lewis, just set property 73 to false and it should run just fine.”

The above names have been changed to protect the innocent.

This kind of conversation happens everyday, across the breadth and depth of our (very large) product and, as we have development teams around the globe, it is a real problem and one we need to solve.

The No Talking rule might sound ridiculous but it may be one way to help people realise just how much information they impart to each other, face to face, that isn’t captured anywhere else. That’s the theory at least.

I work with smart people, they are friendly, helpful and professional. They go the extra mile and genuinely want to do a good job. I’m not just saying this but they are one of the best groups of people I’ve worked with, but that doesn’t change the fact that they way they work is flawed.

Ultimately the challenge will be to change the culture, just enough, to be more info-centric. For example, if the software build system breaks, the developers fix it, yet it seems obvious to me that our information channels are broken and my perception is that they don’t care enough to want to fix it.

How do I get them to invest in this idea? Talking to my girlfriend she rightly suggested that one method that might work would be to pitch it as a time-saver. If every developer was to count the number of questions she was asked over the course of a week, I think they’d all be surprised at the number. Whilst not all of the questions would be something that needs documented, I’d warrant a fair number would be. As I said to a during a discussion with a couple of team leads last week, I’d much rather my team was inundated and overrun with requests to add information to the product documentation, at least that way we’d know the size of the problem.

So maybe I will suggest a no talking day, or maybe there is another mechanism out there that the developers will buy into. Maybe the first step should be to ask them what they think, are they even aware this problem exists (I’m sure they are, it’s just not the most pressing problem in their day to day list).

Regardless, one way or another, it’s something we need to fix, preferably without stopping the conversations.

I don’t know about you but I’m getting fed up trying to make everyone realise the value of what we do. Technical Communicators of the world unite!

Why is it so darn hard? Isn’t it obvious? We live in a so-called “information age” after all, so why is it such a struggle to get the message across?

So, for the meantime, I’ve stopped.

My team currently has a separate stream of work looking at how we get better at PR and whilst that runs its course I’ve decided to deploy a different tactic, one which has fallen into my lap. No more will I go cap in hand to department heads, no more will I try to coax, nudge and cajole others into understanding why product information is so important. I won’t roll out the usual reasons, and I will save my “part of the product life-cycle” spiel.

You see, we’ve been receiving requests from different parts of the organisation, based on some work we did in the past. Lots of people are looking for help. At the moment, all of the team are busy but I’m going to pick one of the requests and find a way to get it actioned. That way we will get a quick win and increase our profile a little (it really is great to be part of such a good team, their work speaks for itself) and it should give us an ‘in’, an opportunity to build a relationship with a different part of the business, learn how they work and in time expand what we do as part of our service to them.

Land and expand. Simple really.

At present I know there are many areas of the company producing content. I also know that many of them would benefit from our input, just as I know we don’t currently have the resource and, without a lot of up front research I’m not sure I would be able to guess at what resource would be required to cover the current requirements. Creating the business case to expand operations would take time, and even then a lot of the effort goes into educating people as to why consistent, reliable, re-usable product information is a “good thing”.

With that in mind, getting a foot in the door (landing) before getting involved and agreeing a level of delivery for the future (expanding) seems the most sensible way forward. It allows us to get a feel for where we can best be involved and over time we can increase our influence, and standing, within the company.

Now, where I can buy some ninja costumes?

The modern day technical writer, in fact I think we’ll go with technical communicator for this on, has a myriad of tools at their disposal. Be they authoring tools, publishing formats, or ways to collaborate, we are spoiled for choice. I can write content and make it available to the world in mere minutes if I so choose (and I do, frequently, you are reading it).

Of course, there is more to our job than the tools of our trade, so much more that at times I think we can forget that our value lies elsewhere and if we are forgetting that, can we really blame others for losing sight of it too? We are more than our knowledge of Microsoft Word, but I fear that’s not always apparent.

Working in a software company, I hear talk of the ‘quality of the code’ frequently, thankfully I hear similar comments about the product documentation, so where does the disconnect occur, how do our fellow professionals move from “those are the people who produce good quality product information” to “anyone can write product information” and, more importantly, how do we change that notion?

Part of the problem is that anyone can easily create and share information, better than that, they can collaborate with the author on that content. The people using the information can ask questions of the author directly, add their comments and even edit the content if it’s not correct. This is not new, Wikis have offered similar functionality for many years, yet somewhere along the line the value placed on information shifted from the quality of the content, to the functionality surrounding it.

• Can I access it easily?
• Can I leave a comment?
• Can I send it to someone else?
• Can I port it to another platform?

Some argue that information as a commodity raises the bar for us all, that by placing a value on information it allows us to be part of discussions we’ve struggled to gain access to in the past. Whilst that may be partly true, somewhere along the line we missed a grand opportunity.

Treating information as a commodity hides the real value and, worse, it places the high quality information we create into the same jumbled marketplace of content that we are all all too familiar with. As a commodity we have become just another coffee maker. Some people will seek out the best of such things, but the majority will not, they will seek the lowest cost and presume that, as it comes in a box that says ‘coffee maker’, it will meet their needs.

How do we change this?

The short answer is, we can’t. The horse has flown the cowshed (?!), the battle is lost.

However, that’s not to say the war is lost.

Good quality information will bubble to the top of the pile eventually. If your information is in a small pool, this will happen sooner rather than later. If you are concerned only with an internal audience you can help this happen by reaching out to other parts of your organisation to make them aware of what you are doing. If your information is in a larger pool, and you have to contend with other ‘google-able’ sources then you will need to do some leg work, some P.R.

This is not a new scenario and the very things that give us flexibility and power are also the things waiting to plot our downfall.

Information is a commodity. There is no escaping that fact.

But we are craftswomen, craftsmen of the highest order, and our knowledge and approach to information gives us an advantage that we shouldn’t be afraid to push home. Yes, all that other information is good, yes I’m sure it comes in handy now and then, but our information is something you can rely on, something that you can trust. It is honed, refined and delivered by experts.

Our information is not a commodity. It is a differentiator.

The sooner we all understand, and believe that, the better for us all.

In the past I’ve held the following positions:

• Technical Administrator
• Technical Writer
• Documentation Specialist
• Technical Communications Manager
• Publications Team Leader

The first three have similarities as they were all grounded in the production of technical documentation. The latter two are essentially the same thing, leading a team of technical writers producing technical information. None of the job titles I had limited me, by my thinking, in what I could and couldn’t do.

My current job title, as confirmed on my new business cards which handily arrived just AFTER I’d been to TCUK12, is Product Information Manager. I didn’t choose this but, whilst talking through my role and responsibilities recently, I realised it’s pretty accurate.

The team I’m part of does a lot more than write technical documentation. We create many different types of information, mostly recently writing more chatty article style content, and we get involved in all manner of product related discussions. We’ve also driven the creation of a developer community website, and we continue to look for new ways to improve our offering to the product and the company.

As the onus and value of information shifts, largely influenced by the web, it’s been something that we’ve actively pushed. Whilst our work is still mostly based around the production of information (albeit in increasingly different styles and formats) we are also pushing into the area of user experience.

Having to step back to explain my roles and responsibilities was something I don’t do often enough. It’s sometimes easy to forget how far things have changed and improved, and it made me realise that my new job title is more accurate than I’d realised. My team is a product focussed team.

The realisation matters not, however, and we will continue to push to improve, try new things and if those things aren’t of benefit to us we will try others. Above all we try and keep in mind that we are working on a product, and that makes it all the easier for us to have conversations with other parts of the company.

Am I a “Product Information Manager”, not quite yet I don’t think. Whilst my team do offer various types of information about the product, we don’t yet have a hooked up strategy for the entire product, and that’s where content strategy comes to play.

Regardless, it is the first time I’ve really felt like my job description represents what I actually do and, more importantly, that is suggests that there is more to come.

What’s your job title? Is it a good representation of what you do? If you could, what would you change it to?

It’s a common question during interviews, “Where do you see yourself five years from now?”.
At that point some people will talk of how they want to have progressed in their career, have learned and expand their role, be able to look back with a sense of achievement and look forward in a clear direction.

The smart people will simply say they don’t know, but that they know that their natural ambition and drive will have moved their careers forward.

I was recently asked the reverse question by an interviewee, “Where do you see the team being in five years time?”.

My response was honest.

“I don’t know”.

And I truly don’t. I know what we have in front of us for the next six months or so, and where our main efforts will be focused in the coming year or two, but beyond that I have no clue.

I do know that we will continue to try and expand the level of services we offer the business (increasing our value), and that our unique knowledge of the product is becoming increasingly useful. I do know that we will continue to improve, and that in the past (almost) 6 years I’ve been with the company we’ve targetted the right thing at the right time. We started by focusing our efforts on the quality of the content we were providing, and currently we are turning more and more towards concerns over the structure and findability of the information. We’ve expanded the type of information we create from task-based content to articles and pre-sales information, and gotten involved in on-screen text and usability issues.

So what does the future hold? Possibly something to do with personalisation of content, definitely further enhancements and development of our taxonomy, and beyond that? I really don’t know. It would be foolhardy to pretend otherwise. I do know that I work with some very smart people and that whatever we do, whatever direction the team takes, it will be the right one for the time.

If pushed, I guess I could answer the question of where the team will be in five years time, I’d say ”still trying to making the right decisions at the right time”.

The big picture is coming together. Development teams in seven different locations round the world, contracted technical writers in some locations, none in others and a product line that is merging… why that all sounds like a challenge!

I’m still in discussion about how we will gather information from disparate teams using different processes (some use SCRUM, we use a blend of waterfall and ‘Agile’), still trying to figure out what our deliverables will be and how they will be delivered so whilst it’s been a few weeks now, it doesn’t feel like things have changed all that much, apart from now knowing that bar one technical writer in Ireland, my team are THE team.

By my reckoning that makes us Global something or other so we are getting new business cards printed…

The realities of how we will manage the information gathering process are my main focus at the moment, I’m reaching out to team leads and managers in as many places as I can to get a better view of where we fit and where we can offer the best value. Over the past few years we’ve built the team to be more ‘service’ focussed, and whilst the bulk of that offering is centred around our product releases, we do also help out our PreSales teams and project delivery information where we can. We also work closely with our Support Team, and monitor incoming calls to understand the product usage that develops and where people trip up.

The end goal is to replicate what we do across the different sites round the globe.

The challenge will be making it happen.

What happens when one company acquires another? How do you merge departments, working practices, content? That’s the challenge that lies ahead for me as my company was recently acquired by Kana Software.

We are still in the midst of integration planning, figuring out how to take the best parts of both product sets forward, and I’ve started to look over the documentation created by our counterparts across the water. It’s immediately obvious that we will need to make some compromises. Firstly in tooling, we use Author-it they use FrameMaker, and then in style (both writing and content delivery).

We’ve been moving to a more article type deliverable, focussing on explaining the reasoning and thinking behind a product feature and only providing How To style information when needed. From what I’ve seen our counterparts, whilst they have a good mixture of information, they have a lot more in the way of How To style information.

We had already kicked off, shortly before the acquisition was announced, started an entire overhaul of the structure of our product documentation. The early results are looking good and should make the entire product information set much easier to use, and it’s been timely as it will allow us to be confident that the information we are taking forward is the best we have, is logically structured, well researched and written.

First things first though, and I’m setting up some calls to talk to them, to understand how they work day to day, why they made the decisions they’ve made and to explain the same from our side of things. Somewhere in the middle lies the future, the path forward to a combined set of product information.

It won’t be easy, we both come to these discussions with a large amount of information, but I know we are all up for the challenge!