From Tribal Knowledge to a Living Operating Guide

As Delta's content operation evolved, so did the knowledge required to operate it.

Processes changed. New technologies and design systems were introduced. New standards emerged around SEO, accessibility, localization, AI readiness, and content safety. The team adopted a new sprint-based operating model and developed new procedures for crisis communications and other specialized work.

The information existed — but it was increasingly distributed across people, process documents, conversations, and an aging internal Content Guide.

I saw an opportunity to turn that collection of information into something more useful:

A living operating guide for the entire content operation.

The Challenge

The original Content Guide was primarily a reference for the website's content components.

It explained how to use the individual building blocks — images, charts, cards, links, banners, and other components — that content editors assembled to create pages.

There was an elegant quality to the original approach: the Guide itself was built using the components it documented. A page explaining how to use a particular component could actually contain examples of that component in use.

Over time, however, the Guide expanded beyond component documentation.

It began accumulating information about SEO, links, image specifications, localization, translations, authoring practices, and other aspects of the content operation.

Meanwhile, the underlying digital experience was changing.

The organization had moved through multiple design systems, with the latest transition underway. Much of the existing documentation had not been substantially reviewed in four or five years.

The result was a resource that contained a great deal of valuable information but was becoming increasingly difficult to maintain as a reliable source of truth.

At the same time, the content operation itself had become considerably more complex.

The team had established a new sprint process. Crisis communications required documented procedures. AI readiness had become a new consideration. New SEO and emerging GEO practices needed to be understood. New components and authoring standards were being developed.

The Guide needed to evolve 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, I was increasingly responsible for communicating processes, documenting procedures, and helping people understand work that they did not perform every day.

That role played directly to one of my strengths: taking complicated processes and explaining them simply enough that someone unfamiliar with the process can successfully perform the work.

My approach is to start with the people who know the process best.

I interview the people who perform the work regularly. I ask them to explain 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 technical knowledge from the perspective of someone who doesn't live in the process every day.

That creates an important bridge between subject-matter expertise and practical usability.

The goal isn't to eliminate the technical detail.

It's to make the detail accessible.

From Existing Site to New Information Architecture

I began by taking the entire existing Guide and using Kiro to analyze its structure and content.

Rather than simply updating pages in place, I reconsidered how the information should be organized and how someone would naturally expect to find it.

The new structure expanded well beyond 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 resulting Guide contains 68 pages organized into a structured site rather than a collection of disconnected documents.

The goal throughout was simple:

If someone needs to know how something works, there should be a logical place for them to find that information.

Validating the Knowledge

Reorganizing the information was only part of the challenge.

A documentation system is only useful if its information is accurate.

I reviewed the existing Guide page by page and identified subject-matter experts who owned different areas of the operation.

Rather than assuming the existing documentation was still correct, I contacted those owners directly.

For example, the existing translations documentation was reviewed with the person responsible for that area and its relationship with the translation partner. Other subject-matter experts were asked to review the material relevant to their areas and identify what had changed.

I maintained a log of the people I needed to contact and the status of each review.

As feedback came in, I incorporated it into the new Guide.

This created a process of distributed knowledge validation rather than relying on a single person to determine whether everything was accurate.

It also established relationships between the Guide and the people who own the processes it documents.

Building Outside the Authoring System

One of the most important decisions I made was to separate the Guide's information architecture from the content-authoring components it documents.

The existing Guide had been built using the same components it was explaining.

That approach worked well when the Guide was primarily a component reference. But I didn't want the new Guide's usability to be constrained by which production components happened to be available.

The organization's current design system was still being developed. Not every component needed for the Guide was available, and some of the information I needed to present didn't naturally fit into those components anyway.

So I used Kiro to build the new Guide as a standalone site while incorporating the organization's current visual standards.

The Guide follows the current design system's typography, colors, spacing, and overall visual language without being dependent on the production authoring components themselves.

That gave me the freedom to design the information experience around how people need to find and understand information, rather than around the limitations of the authoring system.

A Living System, Not a Finished Document

I set an aggressive deadline for the rebuild.

I began the work at the end of June and targeted July 31 for the new Guide to be operational.

That required coordinating reviews, rewriting outdated material, restructuring the information architecture, and building the new site simultaneously.

But the launch wasn't the end of the project.

It established a new philosophy for how the Guide should be maintained.

When new information emerges, one of my first questions is:

Does this belong in the Guide?

As new components are developed, I stay connected to those conversations and incorporate the relevant information as it becomes sufficiently established.

As processes change, the documentation changes with them.

As new standards emerge, they can become part of the shared reference system.

The Guide therefore isn't intended to be a document that is periodically rewritten from scratch.

It is intended to evolve with the operation.

Making Knowledge Findable

The value of documentation isn't simply that 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 have and provides a consistent structure for navigating between related areas.

It also allows the same information to serve different audiences.

A content editor can use it to understand how to perform a task.

A new team member can use it to learn how the operation works.

A manager can use it to understand a process they don't perform themselves.

A stakeholder can be directed to a specific reference page without needing to understand the broader content operation.

That ability to communicate complex information at different levels of depth is one of the central goals of the system.

Measuring How the Knowledge Is Used

The next step is to understand how the Guide is actually being used.

I'm working on analytics that will show which pages receive the most internal traffic and which areas of the Guide are most frequently referenced.

That creates another feedback loop:

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

The same philosophy that drives the team's broader process-maturity work applies to knowledge management as well.

The Guide shouldn't simply be considered "done."

Its usage can provide evidence about what information people need most — and where additional documentation or refinement may be valuable.

Impact at a Glance

The Result

The new Content Operations Team Process Guide transformed an aging component reference into a much broader operational knowledge system.

It provides a centralized, structured place for the team to find information about how the content operation works, not simply how individual website components work.

It captures knowledge that might otherwise remain distributed among subject-matter experts, process documents, meetings, and individual experience.

It provides a common reference point for editors, managers, stakeholders, and new team members.

And because it is designed as a living system, it can evolve as the organization, its technology, and its processes evolve.

The result is more than documentation.

It is 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 accumulate knowledge constantly.

The challenge isn't simply capturing it.

The challenge is making it understandable, findable, maintainable, and useful.

That's what I wanted the new Guide to accomplish.

The people closest to a process will always know more about its technical details than someone coming to it for the first time. My role is to bridge that gap — to listen to the experts, understand the complexity, determine what other people actually need to know, and turn that knowledge into something they can use.

The Content Operations Team Process Guide is the clearest expression of that approach.

It takes the complexity of a large digital content operation and creates a shared layer of clarity around it.

Not just documentation. A living system for how the team works.

Tools & Technologies