Introduction to DocOps
Catherine Heath | July 13, 2021
We’re shining a spotlight on the term “DocOps” in this post. Whether you love it or hate it, DocOps is a growing trend within enterprise content management and is modelled after DevOps.
What is DocOps
Here's a definition of DocOps from Write the Docs:
“a set of practices that works to automate and integrate the process of developing documentation across engineering, product, support, and, of course, technical writing teams.”
The term DocOps was introduced to the world by Jim Turcotte, an executive at CA Technologies. He talks about creating a Content Supply Chain so that documentation can be quickly and continuously iterated upon.
Here are the top three features of DocOps:
Breaking down silos
Rapid customer feedback
The key idea behind DocOps is to remove the silos between teams so there can be a closer relationship between operations and other important parts of the business. Just like DevOps is a fusion between Development and Operations, DocOps is Documentation and Operations managed by the same team.
In DocOps development, content is developed alongside the software project lifecycle and reflects a move away from traditional print publications. As such, DocOps is closely related to the Agile method of software development and in some ways has emerged out of the trend for technical writing in Agile.
DocOps is always customer-centric. Once your documentation has been published, there needs to be an easy mechanism for customers to feed back their experiences and comments.
Why do we need DocOps
The question is, do we need another term to describe documentation processes? Supporters of DocOps would definitely answer yes.
It’s a reaction to the habit of many teams to forming silos in which no one really knows what anyone else is working on. By creating a DocOps team you will have professional documentation delivered in a way that is delightfully productive and agile.
Of course, it’s not necessary to have a DocOps team just for the sake of it. If DocOps doesn’t suit your business then you could form alternative teams, or find other ways of breaking down the walls that exist within an organization.
You could also have an unofficial DocOps team in which relevant team members meet regularly to discuss documentation needs and collaboratively produce documentation. Here at KnowledgeOwl, Documentation Champion Deborah is mainly responsible for writing our documentation, but she collaborates with the rest of the team for accuracy.
You could say that the whole company buys into the concept of DocOps, and we are working to have a stronger DocOps culture.
The ideal DocOps platform
DocOps is closely tied to the platforms you’re using but there are no particular tools that are strictly necessary for it to work. The definition of DocOps is that documentation is centralized and it can be version controlled, you can embed images and diagrams, and iterate on your documentation anywhere, anytime.
It’s likely you will all be working centrally from the same platform like a cloud-based wiki or a knowledge base, which helps you keep track of edits and avoid duplication. After your product is released, you can go back and update the documentation easily. Having your documentation centralized means customers will never be troubled by duplicate content since theoretically your whole team is singing from the same hymn book.
For example, you could use a product like our own KnowledgeOwl to publish your documentation. KnowledgeOwl is knowledge base software and you can purchase a specific number of users for your platform.
Once you’re inside the system, creating a new page is as easy as clicking a few buttons and the knowledge base layouts have already been designed for you. You can have more than one site within your KnowledgeOwl account so if you’re managing multiple buckets of documentation you will never get them confused.
Some other popular DocOps tools include Atlassian’s Confluence, GitHub, and Jekyll to name just a few.
Arguments against DocOps
Some people don’t like the idea of DocOps or DevOps. They may view it as unnecessarily complicating the matter or reinventing the wheel. It may be hard to implement a DocOps team if you have people who are already used to working a certain way. Some team members may not see the point in collaborating on documentation and instead view it as getting in the way of their “real” job.
One of the reasons that DocOps has grown out of the Agile movement is because documentation has traditionally been a low priority for these sorts of teams. This is because they value working software over comprehensive documentation, which has led many people down the path of regarding all documentation as a waste of time. It will be hard to convince some types of people that DocOps is worthwhile.
All things considered, DocOps probably works best in a development environment that is already used to being agile.
Benefits of DocOps
We’ve already talked a lot about the benefits of DocOps. Borrowing techniques from software development, DocOps is a central part of the overall development process. Working in an agile manner means that writers can keep pace with the code being produced and have their work prioritized within the software lifecycle.
One of the key benefits to this workflow is that your documentation writers end up being a bit like beta testers. Product & Customer Champion, Resident Cheesemonger Kate’s former coworkers used to only half-jokingly call this "documentation-driven testing", but it's true: if you're writing feature documentation as development is wrapping up a feature, you often surface bugs or behavior questions that made it past other QA processes. It can help you ship less buggy code (and what developer doesn't like that!).
It can also help shape product management and prioritization conversations, which helps keep your entire agile methodology propelling forward. Writers can surface the kinds of questions that users will surface, too--and while you still have time to make tweaks to things.
We like DocOps because of its innate focus on the user. The way this works is that content is produced and published, customers use the documentation and submit “bug fixes” which then takes the content back to the development team. Changes are made directly and published immediately.
DocOps makes documentation producing teams more efficient and encourages brevity in the content.
Docs at KnowledgeOwl
Kate says, "Here at KnowledgeOwl, we don't practice a formal type of DocOps. Our documentation is primarily written by two people--Deborah and me. At the moment, the breakdown on that workload is that Deborah works on larger projects, I work on release-related documentation creation and updates, and we both handle doc updates based on feedback from customers. We leverage KnowledgeOwl's built-in versioning feature for many updates, though small edits are made directly to live published versions.
"Importantly, no bug fix or feature release is marked "complete" until documentation has been created or updated for it. We take the "Docs or it didn't happen" mantra to heart. :)
"In our case, QA and documentation often happen simultaneously, since I do both QA and release-related documentation, which provides a very tight feedback loop between our docs team and our developers. (Asking questions that come up as I think about how to write about a new feature often surfaces new ways to test that feature, too!)"
DocOps is all about working collaboratively and breaking down organizational silos. It has a focus on Voice of the Customer which means that the customer is the center of all the work you do. The concept of a Content Supply Chain is interesting because it presents the idea that content is being continuously developed. Customer feedback is viewed as inseparable from writing the actual content.
Documentation has a history of borrowing terms from the development world and adapting them. DocOps may just be a flash in the pan as just another buzzword, but we think it’s here to stay.