Devops is a way of working in which the people who build software share responsibility for how it runs once it’s live. It combines a culture of shared ownership with practices such as version control, automated testing, continuous integration, monitoring and fast recovery.
It grew out of a familiar problem. Developers wrote code and handed it over the wall to an operations team, who had to deploy and support something they hadn’t helped design. Developers were rewarded for change and operations for stability, so each side blamed the other when a release failed. The name comes from DevOpsDays, the conference Patrick Debois organised in Ghent in 2009.
Why it matters for content
Content has its own wall. Writers and subject experts create material and hand it over to be published, and then responsibility fades. Nobody owns how the page performs, whether it still matches the service or who updates it when a policy changes. The devops answer is shared responsibility for what happens after publishing, so the people who create content also see how it’s used, how it fails and how it’s maintained. In practice, the writer of a help article might see its search terms and feedback, and join the review when the support team reports that it’s causing calls.
Many people and tools now create, review, translate, publish and update connected material. Yet workflows often rely on documents, memory and favours rather than visible changes and repeatable checks. Devops offers habits that transfer: make small changes, keep versions, review differences, automate routine tests, watch what happens after release and learn from failures without blame. Applied thoughtfully, these habits improve content operations without asking writers to become software engineers.
The comparison has limits. Content involves judgement, meaning and cultural context that tests can’t capture. Borrow the discipline where it helps and keep people responsible for editorial decisions.
How AI changes the picture
For AI-assisted content, these practices become more relevant. Prompts, knowledge sources and evaluation cases can be versioned, tested before release, monitored afterwards and rolled back when quality falls.
Continuous integration can check links and required fields when content changes. Automated accessibility checks cover particular failures, not the whole experience. A documentation team could also test that a changed setup instruction still matches the current product, then investigate failures before releasing it.
The deeper change is cultural. Content, design, technology and operations share ownership of how the system behaves, rather than passing work downstream and hoping for the best.
Questions people ask
- Is devops a job or a practice?
It appears in job titles, but it’s mainly a set of shared practices and responsibilities across teams.
- What can content teams borrow first?
Start by keeping versions and reviewing visible differences before publication. For a small team, that might mean checking one changed instruction against its source and recording who approved it. Then agree who watches each important page after it goes live. Add staging or automated tests when the work warrants them.
- Can content quality be automated?
Parts can be checked automatically. Accuracy, usefulness, ethics and tone still need evidence and judgement.
- Do we need developer tools?
Not always. Start with the practices and choose tools that fit the team’s capability and risk.
Learn more
- DORA’s software delivery performance metrics – the evolving measures of software delivery, with warnings against gaming targets and comparing unlike services; not a ready-made score for editorial quality.
- The Three Ways: The Principles Underpinning DevOps – Gene Kim’s summary of the principles behind devops: flow across the whole system, fast feedback and a culture of experimentation and learning.
- Continuous Integration – Martin Fowler’s detailed guide to the small, frequent changes that make the wider approach possible.