I was chatting to a new colleague, an experienced technical architect, the other day to give him an overview of my team and what we produce. He asked what type of information we provided, was it the “clicky clicky” type or something more useful that explains how our product works.
I assured him that we covered more of the latter type of information, but also provided “clicky clicky” (procedural) information when appropriate. For his type of role, that audience persona (experienced and highly technical), that form of information is exactly what he wants. For other parts of our product, used by inexperienced staff often with a high turnover, we try and help keep the costs of training down by providing more of the “clicky clicky”.
It’s all about the audience after all, right?
Thing is, as I walked away from that conversation, there was something in the back of my mind that wasn’t sitting right, something was irking me and it wasn’t until a couple of days later I realised what it was.
Within the team, there is one question we try and answer, one question that we find useful when trying to understand the latest greatest features of our product. Why?
We ask it of technical architects, product managers, software engineers and business analysts. We ask customers and our professional services staff. Hell if we can we’ll ask our Chief Technical Officer.
- Why are we building this?
- Why did we build it this way?
- Why didn’t we build it that way?
- Why should our customers use it?
- Why should I use it this way and not that?
The list goes on…
And yet, walking away from that conversation I started to realise the one place we don’t ask it often enough. Within the team, of ourselves, we need to be asking one question more often; Why are we writing this piece of content? It’s a simple question but should allow us to follow on with further reasoning.
- Who asked for this?
- Who will use it?
- Why am I WRITING this, would it be better as a video?
- Does this piece of functionality even need any supporting information?
As the team continues to grow, and we start to take on more work from other parts of the organisation, we will need to keep these internal challenges in our minds.
This notion also fits, loosely, to a general theme that has been in my head since TCUK12 the idea of lifting your head, getting out of the default position of “write content” that many of us fall into. Whilst that’s a good default to have, as the world of Technical Communications continues to change it will benefit us all to spend a little bit more time asking why.
Challenging presumptions and changing attitudes towards our profession is not easy, but asking why can help.
Our profession is largely focussed on product, we understand that there are users of the product, we understand that those users vary in skill level and knowledge. Asking those why questions tells everyone else that we are thinking at a higher level, that we are trying to do better, that we want to contribute value to our organisation, this is particularly of value when you bear in mind that we tend to have a different view of our products from many of our counterparts.
As a technical writer, we touch all levels of a product, from the conceptual information all the way through to the technical detail of the implementation itself. We understand the business requirements, the use cases, and the end functionality. Not many other departments share that view so when we ask why, we can ask it from a position of knowledge and, increasingly, authority.
Too often I hear people say that they feel frustrated, that they don’t get the information they need, or struggle to get people to understand what value they bring to a company. Maybe the questions we are asking are partly to blame? Asking why is a soft way of challenging, of gently nudging people to a different view, if you are persistent and consistent the people you work with will start to anticipate your questions, raising their game to meet yours and that’s where the value lies. Not only does asking why get you more of the information you need, allowing you to make better decisions about your work, it’s also provide a link between parts of your organisation.
So be that person, be the central resource that asks why. It may take some time but stick at it and, along the way, you’ll have opportunities to promote what you do and others will start to place more value on the information you produce and the value you provide to the company.
And that, to me, is a perfect example of a win-win situation.