Tag: New Manager

New Manager: How soon is *not* too soon to start changing things?

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 #4.

How soon is *not* too soon to start changing things?
The compulsion to change or fix things that, from your point of view seem wrong or broken is natural. You wouldn’t be in the position you were in if you didn’t have that kind of mindset. However you must resist these initial urges!

A common suggestion, that I’ve seen elsewhere, is to wait at least 3-4 weeks before making any changes. That sounds like a sensible timeframe to me, providing that you use that time appropriately (see the rest of my posts in this series).

The first few weeks in any new job sets out your stall for the coming years. It can be very hard to change initial reactions so use the time wisely, tread carefully and make sure you set a level of expectation that you can manage. Communicate your ideas and thoughts, making sure to state that you are still getting to grips with things, make sure everyone knows that you MAY change things but that you are taking a measured and professional approach.

And, to be honest, that’s all I have to offer. Hopefully some of the things I’ve suggested over this series of posts is of some use. Many of them can be embellished and taken further, others might only be applicable in my own circumstance, but my belief is that as the manager of a technical communications team you are responsible for letting them do what they do best, whilst managing everything else around them. Technical Communications is still a widely misunderstood field, so a lot of your initial work will be educational, making sure everyone else in the company knows what your team has to offer, whilst proving you understand the restrictions and limitations within which they must work.

So, thanks to Mark for emailing me with the initial set of questions. If anyone else wants to chip in, the comments are open.

New Manager: What are the first activities you should do?

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 #3.

What are the first activities you should do (content audit, benchmarking?)?
First things first, make yourself a coffee. In all seriousness, fitting into the culture of your office and colleagues is crucial, and one of the best places to get a handle on that is the approach to coffee/drinks breaks.

Then all you need to worry about is understanding the process that your company and team follow. Are you based in a waterfall type system? Are you Agile? And regardless of the underlying methodologies, how do things actually happen? Simple, right? Well it can take a little investigation but it certainly shouldn’t be difficult.

Briefly I’d tackle things in the following order:

  1. Talk to the members of your team
  2. Talk to the people who set the expectations for your team
  3. Audit your content (high level for now)
  4. Manage expectations

If you are joining an existing team of writers, then I’d suggest that the one of the first activites should be to sit down with them, one by one, and try and understand how they work, what issues they are facing and what expectations they have of you, and of their colleagues on a day to day basis. From this you should get an understanding of their process, how they go about creating the information, how editorial and technical reviews are handled, and how that information is published. Collate all of the responses, you’ll revisit them later, although I would take any personal or specific issues to one side and deal with them accordingly.

Next up I’d get a handle on the expectations being set on your team, which will include talking to other departments, and a good understanding of why that expectation is in place. There is a chance that there are unknown expectations on your team so make sure you understand what they are and if they are valid.

Then I would certainly tackle a high-level content audit. Understanding the content you have and learning what the audience of that content requires goes a long way to helping you understand the working practises and decisions made in the past. It should allow you to see if writing style guides are being followed, and whether an editorial review process is working. It won’t help with the technical review phase though but there are things you can do in that respect as well.

To me, a high-level content audit asks the big questions, why does the document exist? Why is the content of the document structured the way it is? Look at the content

So far you’ve talked to the people in your team who create the content, you’ve understood the expectations they have and the expectations on them. You know what type of content is being produced, why it exists, and have a good idea of what it contains and how it is produced.

Now the tricky bit.

Does the process that the rest of the company thinks you are following (their expectations) match up with the process your team is following? If it does then great. If it doesn’t then this is the first thing you need to address with your team.

Rather than try and fix things yourself, get your team together in a room and tell them what you’ve discovered. This is not an exercise in ‘why aren’t you…. ‘ this is the beginning of a collaborative venture, so make sure you pitch it accordingly. What you need to get from your team is the real reasons why the expectations don’t match. From their side it may be that they were unaware of some of those external expectations, or it may be that whilst the expectation is valid the team haven’t been able to progress that part of the process as they would like.

Once you have completed that exercise, and understand the position of your team and (and this is important) your TEAM has a common and understood position and process, you can then revisit the expectations being placed on your team. It may ultimately mean you need one meeting with representatives of both your team and those from the other areas of the company, but this will allow everyone to understand any issues, resolve them and move forward with a process that everyone understands.

Everything else to that is largely secondary. Yes using the right tools makes a difference, yes better knowledge of your audience is crucial, yes there may be improvements to specific areas of the content that could be made but all of those should start to filter to the top of your pile naturally. However, if the expectations both on your team and from your team are not manageable then you are only setting yourself up for a lot more pain in the future.

New Manager: 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.

New Manager: How do you take over as manager for a group of technical writers?

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!