From Tribal Knowledge to Living Procedures: Using Claude to Organize What I Learned Along the Way
I needed to deploy a containerized application to my org’s Kubernetes environment. The documentation existed — scattered across dozens of Confluence pages, Slack threads, and the heads of people who were too busy to walk me through it. So I let Claude help me assemble the puzzle, and what came out the other side was more useful than any single document had ever been.
The Problem Every Newcomer Faces
Here’s the reality of deploying an application in a mature enterprise environment. It’s not just “write a Dockerfile and push.” The actual path looks something like this:
- Local development and containerization
- GitHub CI/CD pipeline configuration
- Container registry configuration
- GitOps deployment tooling
- Kubernetes namespace access and RBAC
- Secrets management
- Environment protection rules
- And a handful of organizational dependencies that require requests to IT, DevOps, and platform teams at specific stages
No single document covered this end-to-end. No single person had time to sit down and walk through the whole thing. The information existed — the DevOps team had built solid infrastructure and documented individual pieces — but it was distributed across Confluence in bits and pieces, each page assuming you already knew the context from three other pages.
Veterans in the org had all the tribal knowledge. They’d done it enough times that the process was muscle memory. But for a newcomer, this was going to be a process with friction. That’s expected in any complex environment. The question was whether that friction had to be repeated for every new team and every new application.
Building the Guide Along the Way
Instead of trying to read all the docs upfront and assemble a mental model, I took a different approach: I started the deployment and captured lessons learned in Claude guidance as I went.
Every time I hit a wall — a missing prerequisite, an undocumented step, a config value that only existed in someone’s Slack message — I’d solve it and then feed the solution back into Claude’s guidance. Claude helped me organize it as I went, so I wasn’t just taking notes; I was building a structured, usable reference in real time.
The process looked like this:
- Start the next step based on what documentation I could find.
- Hit a gap — something wasn’t documented, or the docs assumed prior knowledge I didn’t have.
- Solve it — ask a teammate, dig through Slack, find the right Confluence page, or figure it out through trial and error.
- Feed it back to Claude — “Add this to the deployment guide: before you can create the namespace, you need to submit a request to the platform team with these specific details.”
- Claude organizes it — integrating the new information into the right place in the growing guide, maintaining the logical flow.
By the time I finished the deployment, I didn’t just have a running application. I had a comprehensive, step-by-step guide that covered the entire process — including the organizational dependencies that no technical doc would ever capture.
What Came Out the Other Side
The result was a templatized repository containing:
- Org-specific templates — Dockerfiles, CI/CD configs, GitOps manifests, all pre-configured with the org’s conventions and requirements.
- Step-by-step documentation — not generic “how to deploy to Kubernetes” docs, but specific instructions for this org’s infrastructure, with this org’s tooling.
- Dependency checkpoints — clear callouts for when you need to engage another team: “Ask IT for this specific access at this stage,” “Submit a DevOps request before proceeding,” “Configure GitHub environment protection rules like this.”
- Best practices — lessons learned from the deployment, common pitfalls, and the “I wish someone had told me this” items.
Claude could then use this repository to rapidly guide future deployments. Not just generating code, but walking a human user step by step through requesting access, navigating approvals, and handling the organizational friction that’s inherent in enterprise environments.
From 5-8 Weeks to 1 Week
The original process — from idea to deployed application — was taking newcomers 4-6 weeks (for a simple application). Not because the technical work was that complex, but because of the discovery process: figuring out what you need, who to ask, what to request, and in what order.
With the templatized repository and Claude guidance in place, that dropped to about a week. The technical steps that used to require research and tribal knowledge are now spelled out. The organizational dependencies that used to surprise people mid-process are called out upfront. The templates that used to require copying from an existing project and hoping you got the right version are now maintained in one place.
Credit Where It’s Due
I want to be clear about something: this works because a talented DevOps team built solid infrastructure. The CI/CD pipelines, the GitOps tooling, the Kubernetes clusters, the secrets management — all of that was already in place and well-engineered. Claude didn’t replace any of that work. What it did was make that infrastructure accessible to more people.
There’s a real gap in most orgs between “the infrastructure exists” and “people can actually use it.” DevOps teams build platforms; Claude helps bridge the gap between the platform and the people who need to use it.
That’s a force multiplier, not a replacement. The DevOps team’s work becomes more valuable when more teams can take advantage of it without requiring hand-holding through every deployment.
Living Documents vs. Static Documentation
The key insight here is the difference between documentation and living procedures.
Traditional documentation:
- Written once, maintained reluctantly
- Gets stale as infrastructure evolves
- Lives in a wiki that people search when they’re already stuck
- Assumes a level of context the reader may not have
Living procedures (Claude guidance):
- Updated continuously as new lessons are learned
- Actively used during the process, not just referenced
- Contextual — Claude adapts the guidance to where you are in the process
- Shareable via git — version controlled, reviewable, and collaborative
When someone on the team hits a new edge case or discovers a changed process, they update the guidance. The next person benefits automatically. The documentation doesn’t just describe what you should do — it actively guides you through doing it.
The Bigger Picture
This pattern isn’t specific to Kubernetes deployments. Any complex organizational process with scattered documentation and tribal knowledge is a candidate:
- Onboarding new team members — not just “here’s the wiki,” but active guidance through setting up their environment, getting access, and understanding the codebase.
- Incident response procedures — living runbooks that adapt based on the type of incident and what you’ve found so far.
- Compliance and audit processes — step-by-step guidance through what evidence to gather, where it lives, and how to present it.
The common thread is taking knowledge that’s distributed across people and systems and encoding it in a form that’s both human-readable and AI-usable. Not to replace the experts, but to make their expertise available at scale.