Traditionally updating content on websites has been handled by developers, and the development team of companies. This would seem to be the obvious choice when you think about how developers would have the technical skills to update the content (the HTML, CSS, look & feel, etc.). But there is one obvious problem with this. Developers typically are not technical writers, nor want to be. Most developers will grumble when asked to write documentation, and when they do, they often assume knowledge and write over the audience’s head, making the documentation too technical for the end-user. Not to say there aren’t developers who can also write. There are. But most developers would rather develop than write documentation. And then there are additional fundamental differences, such as workflow and the type of requests that come in that further differentiate the fields.
If knowledge management is not development, let’s talk about who should be handing content and knowledge management, and some of the reasons why.
Ideal People for Content & Knowledge Management
So when you are managing content in a smaller organization or project, or managing knowledge in a larger organization, the ideal people who should be updating content are technical writers; people with writing skills, who also have the technical skills to update the website. Depending on the platform you are using, ideal skill sets include:
- Good writing skills
- Good editing & proofreading skills (English majors make great editors)
- Good researcher
- Being able to explain complex topics in a simple, yet accurate way
- Able to understand the technical processes, software and/or hardware to be documented
- Basic technical and/or development skills (HTML, CSS, wiki formatting, etc. depending on your platform)
- Able to manage and prioritize hundreds of change requests (potentially more depending on size of company)
- Able to properly vet and verify the accuracy of information submitted by others
- Able to work in a team environment and interface with multiple departments and management
- Able to work with the development team to coordinate efforts
Are Technical Writers Developers?
Once you have the right team members for content or knowledge management, then the question comes up as to whether they are just a specialized developer, or of they are something else. In my experience, they are completely separate fields with completely separate workflows and demands. Managing a technical writer as if they are a specialized developer often diminishes some of the benefits of having technical writers.
Some of the reasons why technical writers are not developers include:
Developers Answer to Management Only; Technical Writers Answer to the Whole Organization
In most organizations, developers answer directly to management and must work on what management thinks are the priorities. This means that anything suggested by anyone other than management, no matter how brilliant or easy to implement, is either swept under the rug, or postponed under the development team gets around to it. While this makes complete sense when dealing with development projects that have a lot of inter-dependencies, where individual features often cannot be worked on in isolation, it does not make sense with a knowledge management team.
While technical writers ultimately answer to management for their priorities and marching orders, to be fully effective and responsive to the organization, they must have their ear to the ground, and be able to promptly respond to requests from various departments and groups within the company. If technical writers only concentrate on what upper management thinks is the priority, then the various departments suffer. Upper Management created departments and teams for a reason. It is a technical writer’s and knowledge management team’s job to interface with all those departments and teams and find out what is needed. This frees up Upper Management to focus on the big things, and not constantly be bothered by department heads asking for documentation. If the departments are bothering upper management about their documentation needs, the knowledge management team is not doing its job properly.
Developers Work on Projects, Software Versions and Interdependent Code; Technical Writers Work on Individual Requests
One of the huge differences between developer project management and technical writer project management is the type of requests they have to deal with. Developers usually have the benefit of self-organizing projects. And by that I mean since there are so many dependencies between tasks, it makes it super easy to lump everything together into a nice project, SCRUM sprint, or software version. Technical writers do not always have that luxury. While some things can be grouped into projects and/or subdivided into smaller tasks, a mass majority of change requests include stuff that is not related to each other, making it really hard to group together.
Since requests that are received are not typically dependent on other requests, there is no need to bundle requests together before starting work. For organization’s sake, and your own sanity, it is smart to group like tasks together in a project management system (when possible; it is not always possible). But there is no need to wait until a SCRUM sprint, or until we get to a certain section of the knowledge base to start work. If it is something simple to do, do it now. And then schedule time for things that take more time and research so they get done as well.
This also means that a technical writer’s work is more like thousands of minor tweaks rather than major feature releases with a ton of new stuff at once. The order of requests is less important to technical writers, because in the end, every minor change adds up to a major change. If a technical writer waited until minor changes were important enough to do, then they would never get done.
Technical Writers Deal with Urgent Individual Tasks, Developers Deal with Urgent Projects
While related to the previous item, it bears mentioning that technical writers deal with far more urgent requests that are not part of an overall project than developers.
For example, let’s say that the company is launching a product and upper management notices something that needs to be changed. A good development project manager will inform the manager that he can have his urgent request now, but there is a cost associated with it, which is the delay of the other project that management has asked them to work on. It then gets lumped into a SCRUM sprint, or a project, or in the timeline somehow based on the priority given to the task. For a technical writer, if upper management comes and asks us to change an article immediately, since there are no dependencies and it can be updated with minimal work, it is harder to postpone the request. This radically changes how you deal with incoming requests and priorities.
Also, since the knowledge management team must be responsive to the entire organization, technical writers have to deal with conflicting priorities between departments.
Developers & Technical Writers Have a Completely Different Workflow
Another giant difference is the fact that their workflows are different to the point of not being compatible. While on the surface, they may seem similar, they are actually quite different. For developers, management and product owners direct them to work on certain things, and they show their work to the people who requested it to get approval.
For technical writers, requests can come from anywhere, from front-line staff all the way up to upper management and the company’s general counsel, even including requests from customers. This poses a unique workflow issue. Unlike developers, the person who requested the change is probably not the person who would vet or verify its accuracy, or approve it, if approval is required. The technical writer and editors may not be qualified to vet a particular piece of content. This means that people throughout the organization will become involved into the process of creating the article beyond the technical writer and the person who requested it. The workflow has to deal with this eventuality.
On top of that, the terminology is completely different, and there are different tasks that need to be done, such as vetting content, proofreading, editing, formatting, etc. And add the fact that technical writers deal with hundreds of individual often unrelated requests, while developers usually can focus on one project at a time, what works for developers usually does not work for knowledge management.
While on the surface, content & knowledge management and development may seem to be similar, they are actually very different fields that are best handled as separate teams.