Friday, 27 February 2009

The best place for a tech writer

I have spent most of my tech writing career working with product development teams in software and other hi-tech industries. It is what I enjoy doing. It's what I do best. And I have come to the conclusion that it's not the best place to be.

That conclusion may surprise other tech writers, and it did surprise me a little as well. Usually the discussions are about whether the tech writers should report to marketing, or to customer services, or to development. The general consensus is that being part of the development team is best because daily contact with engineers and developers helps tech writers understand the product features they need to explain. It's also a good place to be because the end-user documentation, like the product itself, is usually seen as a deliverable item.

Let's look at this question from a slightly different angle. Where do shared interests lie? Marketing are interested in pre-sales - getting new customers in. Customer services are interested in post-sales - keeping existing customers happy. Development are interested in engineering and in code.

Did you notice the subtle difference there? Development aren't really interested in customers. Of course, in general terms they want the company to have customers because they know that's where the money to pay their salaries comes from, but their day-to-day focus is not on customers. The tech writers' focus is on customers, or at least it should be. That's why we share so much affinity with usability and user experience people, and with training people. That's why we try to write end-user documentation that is about tasks people have to do, rather than about features the product can offer. That's why we don't really fit in to a development team.

Where would the ideal place for tech writers be? I'd say that we are part of the team that looks at customer needs and how they are met. That would be a team with a slightly wider viewpoint than the development team, and I would call them the product management team. (I know that "product management" in many organisations is a marketing function.) Product management would have the responsibility for delivering useful tools to customers, and those tools include products, task-based documentation, training, and support. Where this kind of product management team doesn't exist sticking around the development team is clearly the preferred option, but I'd say it's not ideal.

8 comments:

Katja said...

I agree. I've worked as a tech writer in development teams in the past but now work in a product management team. I find that this tends to mean you get exposed to much more information about how any particular project you're working on fits in with wider goals. The shift in focus from delivering a product to delivering what customers need might seem small but makes a big difference. Of course, this doesn't mean you should isolate yourself from the developers: getting your direction from product management but interacting with developers on a daily basis seems like a good mix.

Alice Jane said...

Great post! Where to put tech comms peeps always seems fraught, somehow.

I've always thought that the best place for the tech comms peeps to reside is with the technical support team.

In those I have worked with (and that have worked best), developers work on the support side. We tech comms peeps exchange information with them, and keep in touch with end users. In the best place I worked that used that model, I responded to tech support calls as well, which meant that I had first access to some of the problems end users faced. A good place to be.

Maybe this is sticking with the developers, but it is not the same as working embedded in the dev team. It is so much better!

Gordon said...

Hmmm sounds like you've been working in badly focussed (run?) development teams. If they aren't building to meet business requirements (as outlined by... guess who.. customers!) then why are they building what they are building?

It's one thing receiving direction from product management, quite another to work in a development team that has lost sight of the customer.

FARfetched said...

Today is my last day being part of the product management team… as of Monday, it's back to the tech services group with me.

Working in that group had some advantages, in that I had a line into upcoming projects (and thus could mentally prepare for them). But I agree with Alice Jane, tech support gives you a connection to customers and the problems they're having, which can give you the opportunity to head off those problems in the documentation.

Lois Wakeman said...

I agree - but in some ways if you can be even more divorced from 'insiders', you can better place yourself in the shoes of the 'outsider' - the end user. Not practical in most bigger organisations of course but having gone, over my career, from the very large (ICL's customer publications centre - a dedicated tech writing organisation reporting to both marketing and development) to the very small (freelance writer), it's easier to be user-centric as an outsider. Of course that doesn't always translate into having the power to do what one thinks best.

Ellen said...

David -- Product Marketing -- that's where I ended up at my company and where I felt most at home. Ellen

Sarah Maddox said...

Great post! I've worked in large and small organisations, sometimes in dedicated training/documentation areas and other times as part of the development team. At the moment, I'm in a technical writing team and we are part of the Engineering (i.e. development) department. This is working well.

I think the answer depends partly on the kind of documentation you are writing and on your audience. We write a lot of developer-focused documentation as well as end-user docs. So our SMEs act as a good model for our audience and actually form part of our audience too!

In the past, I have found that outsiders (people not in the engineering department) do not receive the same amount of respect and attention from developers. A technical writer is a highly technical being, but it can be difficult to convince developers of this fact. Being part of "Engineering" or "Development" gives you that extra bit of clout.

Marilyn_Rogers said...

I believe the best approach is for Information Developers to be members of the development team. They should take a leadership role to assist the Developers in understanding the users' perspectives. In modern systems, embedded user assistance should be developed in parallel with the code that the Developers write and user assistance should be considered a necessary part of the product. Information Developers should work closely with Product Managers so they can educate the development team about the business value of the features. They can enhance software design by being savvy in usability and by being deeply involved in design meetings and decisions. Functioning outside of the development team leaves the Information Developers isolated from the daily design decisions that are so important for the usability of the product.