Category: Work

I dropped Tom an email about Writer River last week, and he alluded to some of the issues he mentions in his post in his reply. Little did I know that Writer River was soon to be hacked!

I love the idea behind the website though, so it’s good to see Tom is still keen on pushing things forward. If you previously registered I’d urge you to go back and register on the new version of the website. The premise is the same, a website which will collate the best Technical Communications stories and blog posts.

Head over to Writer River, the more people who sign up and join in, the better it will become.

Having been off work for a few days (a bad cold, I’ll live), and when not sleeping, sneezing or blowing my nose, I’ve been thinking about this blog and if I can commit to a more regular schedule of posting.

The recent posts on Consideration Layers were, I hoped, designed to prompt comment and discussion, two things that I can’t seem to make much headway into here. I have pretty good RSS reading figures but this remains a small blog, with a low numbers of readers.

Whilst I do try and keep a reserve of possible topics, I still tend to react to things when posting here but hopefully the coming months will change that.

For one, we are getting close to starting our journey towards single source at work, so I’d imagine there will be plenty of things there that will spark some blog posts here. I’m also hoping to get to a couple of conferences later in the year and they are always good for getting the creative juices following, and stirring up some enthusiasm.

Until then I’ll just take things as they come. Unless anyone has any suggestions, questions or comments?

I had planned to write more about this idea but as yet I’ve not had the time to properly flesh out my ideas. I’m also taking the lack of comment on this as a good thing (everyone agrees) rather than a bad thing (no-one is reading). So, to try and briefly summarise what it is I’m blithering on about, I thought I’d try a different tact.

Namely, a diagram:

There are multiple paths down through the layers, with each layer and each consideration being linked to one another. There are some things I’m still ironing out but it fits the way MY brain thinks. What about yours?

As a technical writer, every decision you make is influenced by several discrete things, considerations for either the audience of the information, the process you’ll need to follow to collate and verify the information, and so on. Every decision requires such considerations but is it possible to model these?

Some background first; I don’t revisit my old posts nearly as often as I should and, as there are certain topics that I tackle with the vague idea of covering in greater detail at some point later on, it’s handy when someone else gives me a nudge about an old post (namely, The tool is not important).

That said, such topics are typically the hardest ones to consider, the big picture things that end up with my brain reeling as I try to narrow down this wonderful profession into something digestable without generalising (genericising?) so much that it becomes worthless. Still, that’s never stopped me trying, so I’ll bash on and see what falls out of my head.

My post about how the tool is not important looks at the other areas that need to be consider if you are investigating upgrading or changing your main authoring tool, and was largely prompted by our upcoming move from FrameMaker to Author-it. The post is focussed on tools (obviously) but looking back it only mentions a rather large consideration in passing, namely “focussing discussions on the audience, the expectations”.

Such is the way of things when it comes to Technical Communications, anytime you take a step back you realise that there are many things to consider, all of which impact on one another even though they are distinctly different. The audience requires to have information delivered in a particular format (technical consideration), and in a particular voice (writing theory). They’d also like it structured a certain way (information design) and of course they’d quite like it to be accurate and up-to-date (working practice).

As a manager of a technical communications team, all of these things feature in my thinking almost every day. Anytime something new lands on my desk or a new issue is discovered that needs to be corrected my brain runs through the gamut of considerations trying to figure out how best to tackle the work. The more often this happens the more I look for a model of how best to tackle such things and, as I’ve not really found one, I thought I’d take a bash at creating something myself.

This is a first draft, it is still very crude and is missing a lot of detail but as a starting point I think it might work. The premise is simple enough, for each piece of work undertaken by a typical software technical writer (yes, I’m making some assumptions), there are various items that need to be taken into consideration and these can be broadly broken down into four layers – Audience, Content, Theory, and Tools – and within each layer there are a number categories of consideration.

Rather than try and tackle the entire thing, I’m going to focus on the big pieces first.

The following layers are the broadsweep of the model, and I think most technical communication considerations can be allocated to one of the following;

• Audience – be it preferences for format and media, scenarios for which they require information, through to a detailed understanding of how they work.
• Content – the main output needs to be considerate of audience, and as such will be provided in different forms (written, graphical and so on). It also needs to be sourced properly, written, reviewed and published.
• Theory – depending on where you are on the IPMM, this layer may be thin but it will still exist and covers working practice as well as in-house guidelines. It also covers larger view methodologies such as single source, minimalism in writing and so on.
• Tools – the lowest layer as it is furthest removed from the user but still has a significant impact as it is directly tied in to the writing process itself.

So, does any of this make sense to anyone? Or is it just me? Over the next few posts I’m aiming to delve a little deeper into each layer, presuming I’ve gotten them correct and we’ll see what lies within.

Consider this very much a work in progress, and feel free to point out my errors. Comments are welcomed.

I love making mistakes. Really I do. Sure they can be painful, costly and time consuming but let’s look at the positives here, every time you make a mistake you can learn something new. How great is that!

As part of our release cycle, we conduct a series of retrospective meetings, one per team, in which we focus in on the things that went well (with the aim of continuing them) and things that didn’t go so well (so we can improve them). I faciliated some of the last round of these and this time round I get to do them all.

So for the coming week I have two, two hour long meetings a day, helping the teams discuss and formulate actions for the next release cycle. It’s a fascinating process and I’m quite looking forward to it.

The technical writers in my team are embedded within the development teams so they take part in the relavent retrospective meeting, but I’m currently wondering if we need our own mini-retrospective process.

Technical writing is such a spread of disciplines that, whilst we are well hooked into the development process, there are still some things that we do that are unique to the role and deliverables we produce. I have a few things that I noticed during the release that I’d like to discuss, some of which are under my control, some of which aren’t, but all are things that can be handled better in the future.

Making mistakes isn’t ever fun, we all have great pride in our work and do our utmost to be professional and dedicated. However a lot of mistakes come about through bad processes (or lack of them) and those are the ones that it is easier to tackle first.

So go ahead and make mistakes, it’s ok, everyone does. Just make sure you learn from them and figure out ways to stop them happening again in the future.