How do you get better management buy-in?

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 docs?)?
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 #2.

How do you get better management buy-in (promise cheaper or faster docs?)?
Management buy-in is key to any team within an organisation. If the management don’t properly understand what the team brings to the organisation, be they hard or soft benefits, then your job will remain a battle.

So, how do you get it?

Firstly I’d suggest not making any promises to do things cheaper or faster. Whilst it is largely the type of thing your boss will want to hear and they are promises you can make later on, the first thing you need to quantify is whether you are producing what is needed or not. That may mean looking at improving the quality of the documentation, or it may mean re-evaluating the type of information that is produced.

How do you do this? Talk to your audience.

A simple statement, and something it everyone will tell you is core to your ability as a technical communicator but which remains one of those things that is very hard. Even if you have direct access to your audience, the customers of your part of the product, it can still be tricky to get useful feedback from them. With that in mind I’d set up a series of one-to-one interviews. They don’t have to be long, nor do they have to be formal (in fact I staged mine over a few casual chats, grabbing 15 minutes of time from some of our SMEs over the space of a couple of weeks) but you must talk to them.

The benefits are two-fold. Firstly it raises the profile of your team and alerts your customers that you are actively engaged and trying to improve things, secondly it should mean you can formulate a plan to take to your boss.

The former should also start to generate some goodwill, you’d be surprised how many people understand the need for good documentation and you may well be able to garner some support from some other parts of your company. Don’t be afraid to ask people to email you and your boss with their thoughts of your new plan, the more evidence she/he sees that you are driving improvements yourself, the more likely he will be to back you.

But ultimately you need, at some point, to present a plan to your boss. One that outlines what you are planning to do, what the benefits are, and how long you think it will take to achieve.

Benefits should be stated in business terms - for most software documentation the main cost benefit is to reduce the time it takes your audience to complete a task using the software - and the more specific you can be the better. Essentially you have to justify why the company is spending money on you and your team, and ultimately you may be asked for a fine grain of detail that you just don’t have. So, if your plan is to reduce Support calls, make sure you have a way of monitoring the stats AND that you can attribute them to the documentation, before suggesting that as a plan!

Buy-in, in my experience, is largely gained by showing a business awareness. Ever boss will want things faster and cheaper but instead of make presumptions, involve your boss in those discussions. During the start of a project, take the initial scope of the documentation that you and your team have planned, prioritise it (using MoSCoW perhaps?) and take that to your boss. Then it’s a simple case of saying “OK, this is what we MUST have in the documentation, this is what we SHOULD have, these are the things we COULD have and there are also some things we WOULD want to have, can you help me narrow this list down as we can’t produce it all”.

That allows your boss, in conversation with you, to make sensible decisions around the production of the documentation, allows a decision on faster or cheaper to be made, and shows that you understand the business reasoning behind what you do.

Be prepared to have discussions where you lose, where that Quick Start guide that you think is a really good idea gets put to one side. Part of gaining the trust of your boss, and his/her buy-in to your plans is showing that you have the bigger picture in mind, and if you can prove that then your boss should happily back you all the way.



Source: onemanwrites.co.uk