I recently received an email which asked:

Since my career seems to be following a path broadly similar to yours … I’d love to know what your experience was and any lessons learned.

Specifically Mark, who sent the email, asked a few questions:

1. How do you take over as manager for a group of technical writers?
2. How do you get better management buy-in (promise cheaper or faster dox?)?
3. What are the first activities you should do (content audit, benchmarking?)?
4. How soon is *not* too soon to start changing things?

I’ll break each question out into a new post so, without further ado, onto question #1.

How do you take over as manager for a group of technical writers?
Carefully!

Typically if you are joining an established team then it pays dividends to take your time to settle in, understand their working processes and day to day habits. It’s fair to presume that they have a set of processes that work for them and that are tailored for their environment. That’s not to say that those processes couldn’t be improved but avoid being brash and making changes for the sake of it. You got the job, you don’t need to ‘make your mark’ by changing things the minute you get in the door.

I’m not sure if I have a management style per se, but I do try and be as open as possible. If I don’t complete a task I say so, and if I hear something that the team might want to know, I’ll tell them. Beyond that I let them manage their day to day activities and try and make sure that my role only extends as far as pulling everything together into a cohesive view across the entire documentation set. I strongly believe that a good manager is one who removes obstacles and deals with issues, whilst promoting his team at every opportunity. I’ve been lucky that the team I currently have are diligent and motivated, all I really do is guide them when they need it.

As a new manager it’s important to quickly build relationships with everyone with whom you’d like to be involved. I’d suggest that that typically means almost every area of the company. A short introductory meeting with each manager or team lead is usually enough, a quick chat to outline what you are trying to achieve with your team, and how it may benefit them. This is largely the beginnings of managing the expectations of what your team can bring to a company, as well as building some bridges.

Currently I have good ties into Sales, Pre-Sales, Marketing, Training and our project staff. It can be tricky keep everyone up to speed, but the benefits of having a consistent message is an easy one to sell. These introductory meetings also allow you to re-instate the position of your team. Previously it may have been the case that “ohhh we don’t talk to Marketing” but you can use the fact that you are new to break through the socio-political barriers, after all, you don’t know any better, do you?

Gaining buy-in from your team is the main thing that you need to figure out. Taking a soft approach when you first join, making sure that you are learning from the team and not dictating things is important. Ask questions by all means, sometimes a simple question might prompt the team to realise something they had noticed (aka the ‘can’t see the wood for the trees syndrome’) but it makes sure that you are seen as a team player.

Finally you need to understand the business plan. Ultimately part of your job is to make sure that your team is contributing towards the goals of that plan as efficiently as possible. You will have other expectations and agreed deliverables, and understanding the business plan will allow you to make the right decisions both for your team and for the benefit of the company.

Once you understand all of this, your position, and the position of your team in the company, you can start to formulate goals and aims. Setting a high level vision for where you want to take the team can be tricky but if you have spent the time gaining their trust and buy-in, you should be able to collate all of that into a vision that everyone agrees. Once you have that, revisit your colleagues that you introduced yourself to and update them. Set out the expectations for the coming few months and get going!

Where does the ‘documentation manager’ fit in an organisation?

As our company grows and we push ourselves to be better it is envitable that some people will end up in slightly different roles than they envisaged. Thankfully my current company isn’t too bogged down on job titles and org charts, preferring to make sure that roles and responsibilities are defined and allow people to get on with getting things done.

So, I currently find myself conducting a mini content audit, across most of the company, in an effort to find the big gaps that may or may not exist (ok, that definitely do as every company has them) and working with a couple of other people in different areas of the company to make it happen.

It’s a switch away from concentrating on writing and managing the product documentation but it is an area I’ve long since considered something that someone in my position SHOULD be driving forward.

This exercise has given me the opportunity to touch base with most other areas of the company, and it’s telling that very few have a full product view. In fact I’d say it’s fair to say that none of them have (and rightly so) and so I often find myself pointing out that documentA is already in progress by teamB, so teamX doesn’t need to do write their own.

It also means that, once we have finished the audit and written up the missing information, we should have a cohesive and complete story through all the various touching points our customers have with our company. It should make our offering easier to sell, easier to understand and back up the fact that our product is excellent and our staff are a bunch of smart people!

I have a double interest at play here though, as I also have a developer community which I need to feed far more regularly than I have been, so any content is ‘good content’ as far as they are concerned.

An interesting time which, once again, reminds me why I love this profession of ours, after all who else gets to stick their finger in so many pies.

Several years ago I attended a management training course. It was largely a series of scenarios throughout which you had to apply the rules of the particular branch of management methodology to which we had ascribed.

It’s been a long time since I revisited those rules but by and large I’ve adapted them to match my personality and my own beliefs as to how a technical communications team should work. They are, as I’m sure you’ve probably realised, largely based around common sense and the knowledge that you are working with professionals. If you are not you are either working for the wrong company, or you hired the wrong people.

So, how do you hire the right person?

A quick search on the internet will return many thousands of results, featuring articles, training courses, recommendations and strategies. I’m not suggesting that my approach is better or worse than any but it’s worked well for me.

My guiding principle is not to treat an interview as an interrogation. It may sound obvious but I’ve been for interviews where you get sat across a desk from three or four interviewers who take turns in asking you very specific questions. This is fine for some roles but, particularly for technical communications, removes a lot of the value of the interview.

An interview is a conversation, during which you are trying to ascertain personality fit to your corporate culture and their abilities to fulfill the requirements of the job. The latter includes how they learn, how they communicate, how they think and plan what they are writing, as well as how they deal with challenges and adversity, and if they like pizza (an important factor in any software development office!).

That said, there is a structure that I follow and which I explain to the interviewee at the beginning.

Hiring new staff is fraught, and rightly so, as it’s likely to be the biggest ‘purchase’ you make for your company. I’ve conducted enough interviews that I’m fairly comfortable with the process, and have a good feel for when to press for more information and when to sit back and let the candidate sell themselves.

I may post more on how I conduct interviews later (anyone interested?) but as I am hiring right now I’ve started to think about the whole induction process, and how we can best get a new technical writer into the team and up to speed.

First of all there is the timing of these things. Rarely do you get the luxury of being able to streamline a new team member into the start of a release lifecycle, so you need to consider what they will be working and, possibly, whether you keep them out of the main stream of work until a new cycle begins. Like most departments we have a slew of ongoing tasks that are not directly related to new product development, and one of my favourite items to get a new start to tackle is the installation guide.

Typically, unless you are writing documentation for a very simple application, the initial setup and configuration of a product can be confusing. You may need to consider underlying platform choices, supporting applications, databases, connection protocols and so on, all of which the customer controls and which mean there isn’t often a common set of instructions.

There may be some initial configuration required before you can run the setup routine, and the choices made available may then impact what options are available later on in the process.

Ultimately it’s the trickiest thing to get right so my view is that a fresh set of eyes, belonging to someone who has yet to be inflicted with the curse of knowledge (that is, they don’t know anything about the product so don’t presume the audience will either), is ideal for reviewing and updating an installation guide.

Beyond that there are matters of tooling and procedures to be learned, as well as the general culture to be communicated and encouraged. I firmly believe the latter is the more important, tools and procedures can be learned over time, but fitting someone into an established culture, into the way we think and the way we tackle our work is far more important.

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.

How do you do it?

I’ve conducted a fair number of interviews over the past few years, not a huge amount but definitely into double figures. Some have been good, some not so good, and some just embarassing.

I recently read about an interview that was more like a planning meeting, outlining the job in terms of the issue that was being addressed, discussing requirements and asking for ideas. As a way to evaluate how a prospective employee works, and how they would fit into your organisation or team, it makes some sense. I’d still use the more traditional question and response session as well, but this has gotten me thinking.

Are there other, better ways, to conduct an interview?

Just for kicks, here is my typical interview routine:

1. Meet and greet with a firm handshake and set the tone with a friendly enquiry. Check that the formalities have been dealt with (interviewee has signed in and has a pass).
2. Take them to the location of the interview, usually one of our meeting rooms.
3. Outline the interview process to them.
4. Give them a tour of the building, and talk a little about the history of the company, and point out some ‘how we work’ stuff.
5. Back to the interview room, offer them a drink (coffee, tea and water will already be there).
6. Then chat with them through their CV, asking them to explain and expand on certain points. I do ask for examples of work as well.
7. I’ll then expand a little on the role they are interviewing for, and go over some of the employment terms.
8. Then it’s final questions and we’re done.

It’s point 7 that could be expanded to be more of a scenario based discussion, and whilst I do use that approach on a small scale when I’m asking them questions, it might be interesting to outline a larger scenario and see how they handle that.

I’m always looking for better ways to do these things, as interviews can be hit or miss for both participants, so anything that would help keep it interesting and engaging would be beneficial.

Do you interview when hiring new staff? Any favoured approaches?