From Tribal Knowledge to a Living Operating Guide

As Delta's content operation grew up, the knowledge needed to run it grew with it. Processes shifted, new technologies and design systems arrived, and fresh standards took hold around SEO, accessibility, localization, AI readiness, and content safety. The team moved to a sprint-based operating model and wrote new procedures for crisis communications and other specialized work. All of that knowledge existed, but it was scattered across people, process documents, conversations, and an aging internal Content Guide. I saw a chance to pull it into something more useful: a living operating guide for the whole content operation.

The Challenge

The original Content Guide was mostly a reference for the website's content components. It explained how to use the individual building blocks (images, charts, cards, links, banners, and the rest) that editors assembled into pages. There was something elegant about the original approach, because the Guide was built out of the very components it documented, so a page explaining a component could show that component in use. Over time, though, the Guide outgrew that. It started collecting information about SEO, links, image specs, localization, translations, authoring practices, and other parts of the operation. Meanwhile the digital experience underneath it kept changing. The organization had worked through several design systems, with the latest transition still underway, and much of the documentation hadn't been seriously reviewed in four or five years. The Guide held a lot of valuable information and was getting harder and harder to trust as a single source of truth.

The operation itself had gotten more complex at the same time. The team had a new sprint process. Crisis communications needed documented procedures. AI readiness was suddenly a consideration, new SEO and emerging GEO practices had to be understood, and new components and authoring standards were in development. The Guide needed to grow from a component reference into a knowledge system for how the operation actually works.

Rethinking the Guide

As Communications Lead for the Sprint Management team, more and more of my job was communicating processes, documenting procedures, and helping people understand work they didn't do every day. That plays straight to something I'm good at: taking a complicated process and explaining it plainly enough that someone unfamiliar with it can still do the work. My approach starts with the people who know the process best. I interview the ones who do the work regularly and ask them to walk me through what they do, why they do it, what decisions they make, and what someone else would need to know to perform the task. Then I translate that from the point of view of a person who doesn't live inside the process. That's the bridge between subject-matter expertise and everyday usability. The goal isn't to strip out the technical detail. It's to make the detail accessible.

From Existing Site to New Information Architecture

I started by taking the whole existing Guide and using Kiro to analyze its structure and content. Rather than patch pages in place, I rethought how the information should be organized and where someone would naturally expect to find it. The new structure reached well past the original component reference. It now includes sections for:

• Getting Started
• Content Strategy
• Reference Materials
• Service Levels
• Tools & Software
• Authoring Guidelines
• Accessibility
• AI Readiness
• Content Safety
• SEO
• Localization and Translations
• Components and Templates
• Placements & Campaigns
• Sprint Management
• Crisis Communications
• Internal References

The result is a 68-page Guide organized as a structured site rather than a pile of disconnected documents. The goal the whole way through was simple. If someone needs to know how something works, there should be a logical place to find it.

Validating the Knowledge

Reorganizing the information was only half the job, because a documentation system is only worth anything if the information is right. I went through the existing Guide page by page and identified the subject-matter experts who owned each area of the operation. Instead of assuming the old documentation still held, I went to those owners directly. The translations material, for instance, got reviewed with the person who owns that area and the relationship with our translation partner, and other experts reviewed the material for their areas and flagged what had changed. I kept a log of who I needed to reach and where each review stood, and folded the feedback into the new Guide as it came in. That turned accuracy into a distributed effort rather than one person deciding whether everything was correct, and it built real relationships between the Guide and the people who own the processes it describes.

Building Outside the Authoring System

One of the most important calls I made was to separate the Guide's information architecture from the content-authoring components it documents. The old Guide had been built from the same components it explained, which worked beautifully when it was mainly a component reference. But I didn't want the new Guide's usability held hostage to whichever production components happened to exist that week. The current design system was still being built, not every component I needed was ready, and some of what I had to present didn't fit cleanly into those components anyway. So I used Kiro to build the new Guide as a standalone site that still follows the current design system's typography, colors, spacing, and overall visual language without depending on the production authoring components. That freed me to design the experience around how people actually need to find and understand information instead of around the limits of the authoring tools.

A Living System, Not a Finished Document

I set an aggressive deadline. I started at the end of June and aimed to have the new Guide operational by July 31, which meant coordinating reviews, rewriting outdated material, restructuring the architecture, and building the site all at once. The launch wasn't the finish line, though. It set a new philosophy for how the Guide gets maintained. When new information shows up, one of my first questions is: does this belong in the Guide? I stay close to the conversations where new components are being developed and bring the relevant details in once they're settled enough. As processes change, the documentation changes with them, and as new standards emerge, they join the shared reference. The Guide isn't meant to be rewritten from scratch every so often. It's meant to evolve alongside the operation.

Making Knowledge Findable

Documentation isn't valuable just because it exists. People have to be able to find it when they need it. The new Guide is organized around the questions people are likely to bring to it, with a consistent structure for moving between related areas, and the same information can serve very different readers. A content editor uses it to figure out how to do a task. A new teammate uses it to learn how the operation works. A manager uses it to understand a process they don't run themselves, and a stakeholder can be pointed to one reference page without needing to grasp the whole content operation. Communicating complex information at whatever depth the reader needs is one of the central goals of the system.

Measuring How the Knowledge Is Used

The next step is understanding how the Guide actually gets used. I'm building analytics to show which pages draw the most internal traffic and which areas get referenced most often, which creates another feedback loop:

Document → publish → observe usage → identify gaps → improve → document again

The same thinking behind the team's broader process-maturity work applies here. The Guide is never simply "done." How people use it tells me what information they need most and where more documentation or refinement would help.

Impact at a Glance

The Result

The new Content Operations Team Process Guide turned an aging component reference into a much broader operational knowledge system. It's a centralized, structured place to find out how the content operation works, not just how individual website components work, and it captures knowledge that would otherwise stay locked up in subject-matter experts, process documents, meetings, and individual experience. Editors, managers, stakeholders, and new teammates all share it as a reference point. Because it's a living system, it evolves as the organization, its technology, and its processes evolve. The result is more than documentation. It's institutional memory made accessible.

What This Demonstrates

Knowledge Management

Turning distributed expertise and organizational knowledge into a structured, searchable system.

Process Documentation

Translating complex operational processes into clear, usable instructions for people who don't perform those processes every day.

Information Architecture

Reorganizing a large body of information around how people actually need to find and use it.

Governance & Maintenance

Establishing a living documentation model in which process owners validate information and new knowledge is continuously incorporated.

Change Enablement

Supporting a rapidly changing content operation by keeping its shared knowledge aligned with evolving processes, standards, and technology.

AI-Assisted Development

Using Kiro to analyze the existing Guide, rethink its structure, build the new experience, and accelerate the integration of new and revised content.

Stakeholder Enablement

Making specialized operational knowledge accessible to people with different levels of familiarity with the content operation.

The Bigger Lesson

Organizations pile up knowledge constantly, and capturing it isn't the hard part. The hard part is making it understandable, findable, maintainable, and useful. That's what I wanted the new Guide to do. The people closest to a process will always know its technical details better than someone meeting it for the first time, and my job is to bridge that gap: listen to the experts, understand the complexity, work out what everyone else actually needs to know, and turn it into something they can use. The Content Operations Team Process Guide is the clearest version of that I've built. It takes the complexity of a large digital content operation and wraps a shared layer of clarity around it. Not just documentation, but a living system for how the team works.

Tools & Technologies