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.