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:
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.
]]>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:
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!
]]>Whilst we all may use different tools and approaches to our work, we all feel under the same constraints of time and resource. However the results do through up a couple of issues and, as one of the participants of the survey, I thought I’d expand a little on one of those.
The survey hints at two issues:
I don’t think the first is a contentious statement but what interests me is the phrasing. The implication is that technical writing teams are seen as (or see themselves as?) content consumers, areas of the company into which content is lost to proprietary tooling. Obviously we publish a lot of content but perhaps we are a little too guarded of the information we collate?
I’ve never had an issue sharing information, regardless of state, as long as the appropriate caveats are in place. Information is meant to be shared, so the more of it we do, the better. In my opinion.
More interesting is the second point around the lack of evidence of company-wide information management. This is something I’ve been working on with key members of other areas of our company, and from previous experience it’s usually the technical writing team that takes a lead here as we gain the most benefit from having a good information management solution in place.
That may boil down to a document management system (from ad-hoc to access controlled repositories), or even a content management system, but ultimately the benefits are applicable across entire organisations. I’m lucky in that there are a couple of people who see the benefits and so it’s much easier to drive adoption and cooperation across the organisation, but even if that weren’t the case, and in the current climate, it may be something you should look into and start to drive forward yourself.
The survey results are, like any survey, a thin sample of our profession in the UK, but it’s great to have that information available. I’ve already spotted a few things that I can use in discussions within my own company, and there are plenty of common themes and ideas that can be carried forward to help improve our team.
So, well done Cherryleaf, I’m sure it wasn’t an easy process but I certainly think it was well worthwhile.
* A coverall title that encompasses anyone responsible for a team of technical writers.
]]>A recent comment on that post suggested that it’s not just DITA that is lacking, it’s the working realities of single source that is flawed.
Well, that and the fact that I keep referring to single source when I am actually meaning content reuse (for you can have one source for everything but not reuse the content anywhere).
You can read the full comment yourself but the relevant bits are:
I have never seen single sourcing work. Maybe a single author who knows the topics thoroughly enough to reuse, or a tightly knit group of writers synched up at the same level.
…
The only place we are going to reuse content is in web mashups using semantic markup once the content is in the cloud.
It’s an interesting view and one which touches on something that has been on my mind these past couple of weeks as we are in mid-migration towards our single source solution.
Just how do you coordinate a team of writers, working in discrete areas of the documentation, with a large number (3000+) topics?
There are a number of ways we are tackling this and only time will tell if they are successful. Firstly we spent some time discussing how best to structure the source topics. Do we group them by product area? By topic type? Or some other arbitrary method?
We decided to group at the highest level (the top level folder) by user persona, and below that we grouped topics in accordance to how they are viewed from the product, so development kit wide ‘Events’ are stored in single folder, where as topics for a specific piece of functionality in the development kit are stored in their own folder. Your system will be different, of course, but this method suits our needs.
After that we need some way of knowing both what type of information a topic contains, as well as where that topic is used. We are not authoring in a DITA specific environment but decided to model our topic types on the DITA model to future proof us as much as possible (we are using Author-it which will export to DITA XML should we need it in the future). We have different templates for each type of topic (Concept, Procedure, Reference and so on), primarily to allow us to identify a topic (by default, Author-it shows which template a topic is using).
That leaves the final piece of our puzzle. How do know where a topic is used? This is more than just a list of which deliverables the topic will appear in, it also has to hint at the context of how the topic is being used.
Does any of this mean that we are more likely to reuse content? Not necessarily but it should give us a fighting chance, and once we’ve updated the content plans for all of our deliverables we will start to really see the benefits. Those content plans were the very things that suggested we could reuse content across multiple deliverables and I’m certain that, with a bit more analysis, we’ll get further gains.
Can single source and content reuse work? Of course it can. There are plenty of good examples out there and they all share one thing in common, something that isn’t really broadcast by the vendors; content reuse from a single source takes a lot of hard work.
But it is possible.
]]>Thanks Katja for organising this, I’m looking forward to it as it’s always informative and interesting to meet fellow professionals. As my career progresses (or perhaps just because I’m getting older) I start to understand the true benefits of, what has now come to be known as, networking.
It’s the same reason I joined the ISTC, and also why this blog exists. I’ve been blogging, on a personal basis, for several years and have made some good friends so I have my own proof that blogging works as a way to network, to communicate.
It’s not that hard to quantify either. Directly because of this blog I realised how enthusiastic I am about my line of work, which made me want to get more involved which prompted the writing of a monthly column for the ISTC Newsletter and which also lead to my invitation to speak at the TICAD conference. I’ve swapped emails with technical writers from around the world and, quite genuinely, can say that through the blogs I follow I learn something new, if not every day, at least every week.
It can be hard to find the time to write posts, it can be hard to find something that I can write about (I try to steer clear of company specific issues), but it is rewarding and, I hope, of some use to others.
Networking isn’t easy. In a way I’m lucky as I have an outgoing personality, but the internet makes it so much easier. In saying that, it still doesn’t beat face to face communications so, if you are in the Glasgow area this evening, please come along.
]]>