Citizen CMS: From Deadlines to DocOps

[#1]

I once worked for a company that released a new product every day - around 8pm. A few hotfixes followed before midnight. Most work started that same morning, and it wasn’t unusual to change the scope mid-day. But one rule was sacred: the release must happen. No delays. No exceptions.

And we never failed.

It was extreme Agile - except this wasn’t a startup or a tech company. It was a daily newspaper.

As my late mentor Boris Latta said: “The sun may skip a morning, but the paper never does.”

(continues below the image :) )

Agile before agile

This was the early 2000s. Our newsroom was fully computerized and online, but it was still the time of dial-up connections, no 3G, dumbphones, and CD burners being luxury items.

Every newsroom ritual had its modern-day Agile equivalent: standups, planning, retros, last-minute pivots, and full-scale chaos. Natural disasters, wars, protests, or a politician voicing a reasonable opinion - all could throw your entire plan into disarray.

There were no reverts. Once the paper was out to print, it was out. You couldn’t delay. You could redo for a second edition, you could not retract the first. But you still had to ship on time. So we did Agile - because there was no other way.

CMS made a radio star

Whether in newspapers or later at the BBC World Service (from 2002), everything ultimately funneled through a CMS. The BBC’s CMS was robust, interconnected, and purpose-built for large-scale content workflows. That’s where I got my first taste of requirement analysis - translating the needs of writers and producers into language engineers could act on.

That experience taught me four foundational truths:

• Everyone must work within a single, integrated system.

• Workflows and processes must wired into the system.

• People need tools suited to their roles - connected to a central system.

• CMS limitations are the result of missing input from actual users.

I had ideas. For features, of course. But also for concepts of what you need to bring together to make your CMS work.

BYO… CMS

So when I joined the startup World Business Press Online, I had an amazing opportunity - work on designing our own CMS. Collaborating with Milan Piskla, Norbert Korny, and a small dev team, we built a lean, powerful system in a matter of weeks.

It was end-to-end: editor, workflow tool, content lifecycle manager, and publisher all-in-one. WYSIWYG. Drag and drop. No nonsense. Exactly what we needed.

That CMS wasn't just a tool - it was as small-scale a blueprint for how content systems should work.

From newsrooms to mainframes

At CA Technologies, I helped migrate a vast library of product documentation - some of it dating back 50 years - into Confluence. This is where DocOps emerged: embedding documentation into product development workflows. 

I worked on CA MICS documentation to support continuous delivery of the giant mainframe software suite. Coming from news media, my first thought was: Of course it should be this way. A shared system where docs, code, QA, and devs live on the same page? Obvious. Natural. Powerful.

The migration surfaced many pain points - and countless opportunities. I had ideas (Thanks Pavel Skopik for bringing some ideas to code!). Some of them became patents and patent applications.

My first encounter with the patent review board full of ‘senior distinguished architects’ was humbling. My ideas were not coming across:

“Do you have a working prototype?”

“No. I’m not a developer, but I thought it’s not a condition to submit the idea for a review.”

“That’s fine. You don’t need a working prototype. But you need to be able to describe your idea in such a way that a developer can code it or an engineer can build it.”

That was a turning point. Working under tuition of one of the board members, I learned how to break down a concept, connect the why with the how, and express it in technical terms. I didn’t need to write code - I needed to write clearly and think like a builder.

It cured my fear of complexity. It confirmed I could document both the products and the concepts - as long as I understood it and could work closely with those who built it.

Backbones and blueprints

What we used or built in newsrooms? It was the original DevOps and DocOps. Shared goals. Shared systems. Shared workflows. Tools both shared and specific but connected where and when they needed to. The newsroom CMS was a backbone - and that’s how I approach Confluence, its platform, and the wider Atlassian ecosystem.

That’s why the transition from media to tech writing to CMS design felt so natural. I had lived it before. I always worked in a context (pun intended) where workflows, processes, tasks, and content were integrated within a single environment.

That same mindset shaped my experience at Emplifi, where I led initiatives that unified documentation and product release cycles across teams, redesigned Atlassian app usage to improve efficiency.

Those efforts earned us Atlassian’s Team ’24 Award for “Working Differently, Together” and made me the central subject of customer success stories by both Atlassian and K15t. Because, at the end of the day, the tools are only as powerful as the clarity and connection they enable. And what you enable… that’s up to you.