From 'Always Be Quitting' to 'Always Be Teaching'

Jack McGlone shared Julio Merino's Always Be Quitting with me during a personal development session years ago. The whole team loved it. I've shared it more times than I can count since then—it's probably one of my favorite blog posts. The advice is solid: document your knowledge, train your replacement, make yourself dispensable so you can grow.

But after implementing it multiple times across different teams, I've realised something: following "always be quitting" as an individual practice gets you halfway there. The problem isn't the advice—it's that it stops at the individual level. The real goal isn't making you replaceable. It's building a team that collectively owns knowledge, regardless of who's there.

And that requires a fundamentally different approach: from "always be quitting" to "always be teaching."

The Problem With Documentation As Individual Practice

Producing documents isn't enough. Documentation that isn't usable and actually used is just noise. I learned this the hard way.

Early in my career, I followed Merino's advice religiously. I documented everything—technical decisions, system integrations, architectural patterns, process workflows. I was making myself replaceable, right?

Not quite. I'd just shifted the bottleneck. I was no longer the knowledge holder; I was the knowledge documenter. The team still depended on me—just in a different way. They needed me to write things down, to organise information, to know where everything was. Different problem, same dependency.

The real issue: if you're the only person producing documentation, you haven't built team capability. You've just created a different kind of indispensability.

The Evolution: Three Stages of Team Documentation

Stage 1: Leader Documents Everything

This is where most teams live. You follow "always be quitting." You write everything down. You create templates, establish standards, build the wiki or Confluence space.

The team depends on your documentation instead of depending on your verbal knowledge. It feels like progress. And it is—but it's not the destination.

Stage 2: Team Contributes (And Everything Breaks)

You realise you're still the bottleneck, so you push documentation out to the team. "Everyone should document their work!"

This is where it gets messy. And this is where most attempts fail.

In a previous role, we led a large integration project spanning multiple teams. Everyone followed "always be quitting"—they documented their work diligently. But we hadn't established clear formats or organisation. Information ended up everywhere: scattered across different Confluence spaces, buried in Jira tickets, hidden in Slack threads, duplicated across multiple docs.

Documentation everywhere meant documentation nowhere. You couldn't find what you needed. When you did find something, you couldn't tell if it was current. Multiple sources said different things. The cognitive load of managing the documentation became worse than the original problem of tribal knowledge.

We'd jumped straight to practice—"document your work"—without establishing why it mattered or how it should work. The team was contributing, but without shared understanding of what good documentation looked like or why it existed.

Stage 3: Self-Documenting Culture

The breakthrough came when I stopped thinking about documentation as a task and started thinking about it as culture.

In my previous team, we tried something different. We introduced personal development time with one requirement: contribute a wiki post each month about something you'd learned, and explain why it was valuable or not. No templates initially. No strict formats. Just: share what you're learning.

At first, people struggled. They weren't sure what to write or how to present it. But then something interesting happened: the team started improving each other's work.

Someone would write a solid technical explanation, and a teammate would add better graphics. Another would add links back to "building block" concepts to make it more accessible for newcomers. A colleague wrote extremely verbose prose—nothing wrong with the content, but it was long and rambling. We worked together to cut it down by more than 50% using bullet points and diagrams. It became great.

The team wasn't just adding content. They were collectively curating and improving our institutional knowledge. A few very waterfall approaches to business analysis got flagged as not right for our team. Posts that were unclear or dull were revised. In a world of near-infinite information, curation became as valuable as creation.

I wasn't directing the documentation; I was creating the conditions for the team to own it.

Making It Stick: Building Accountability Into Workflow

The cultural shift was essential, but it wasn't enough on its own. In my current role, we needed more structure.

We rebuilt our Confluence space from scratch with clear organisation. Each integration we own has a dedicated page. When we update an integration, updating Confluence is part of the acceptance criteria—we link the specific page that needs updating, or state that a new page must be created if one doesn't exist.

This discipline has stuck because it's built into our workflow, not bolted on afterward. Documentation isn't a separate activity; it's part of how we define "done."

We also use AI to help maintain consistency. When someone writes documentation, AI helps format it according to our standards and flags potential gaps. Sometimes it asks questions that genuinely improve the docs. Sometimes it guesses wrong and fills in blanks incorrectly—I've learned to be vigilant about technical accuracy, especially when I've provided outdated context that sets the AI down the wrong path.

Documentation is work, and it needs to be managed as work. We make it visible, we track it, we hold ourselves accountable for it.

For technically complex or large areas, I ask the developers who worked on that integration to peer review for accuracy. Format is usually solid when I've given good context. Technical correctness requires domain expertise.

Coaching, Not Commanding

My role has fundamentally shifted. I'm no longer the person who documents everything. I'm the person who coaches others to document well.

When someone writes a ten-page technical deep-dive, I help them think about their audience. Who needs this? What do they need to know? We often compromise: keep the main document short and visual, move the deep technical elements to linked subpages for those who need that level of detail.

Short, concise, well-structured docs with diagrams get used. Verbose text blocks don't. Avoiding repetition across multiple docs is crucial—every time you duplicate information, you create maintenance burden and version control problems.

I'm not telling people what to write, I'm asking questions that help them figure out what's valuable and how to present it clearly.

From Individual to Team: The Real "Always Be Quitting"

"Always be quitting" as individual practice isn't wrong—it's necessary. But it's not sufficient. It's the foundation, not the destination.

If you stop there, you've made yourself replaceable but haven't built team capability. The team still depends on someone to be the documenter, the knowledge keeper, the person who knows where everything is.

Cognitive load doesn't disappear when you document—you just transfer it. If one person holds all the documentation responsibility, you've just moved the cognitive load from "tribal knowledge" to "documentation management."

The real goal: build a team where knowledge is collectively owned, continuously updated, and actually used—whether you're there or not.

I'm still the person with the best understanding of how different systems connect in our current project. I've made most of the design choices. But I'm actively working to distribute that knowledge. We've established product ownership over different streams, giving others both knowledge and accountability. I review their work to maintain quality, but I'm not writing it all myself.

When I share "Always Be Quitting" now—and I still share it with everyone I work with—I follow it up with the harder question: How do we build a culture where this is how the whole team operates, not just you?

The Practical Path Forward

If you're trying to move from individual documentation practice to team capability, here's what's worked for me:

Start with low-stakes contribution. Personal development time, learning posts, "share what you discovered this week." Make it about learning, not compliance. People need to see why documentation matters before they'll engage with how to do it well.

Let patterns emerge before standardising. Don't create templates on day one. See what people naturally create, then identify what works. Standards that come from observed practice stick better than standards imposed from above.

Build accountability into workflow. Acceptance criteria, definition of done, whatever your team uses to define completion. Documentation can't be optional; it has to be part of how you work.

Use tools to reduce friction. AI for consistency, templates for common patterns, clear organisation so people know where things go. Make it easy to do the right thing.

Stay close enough to maintain quality. You're not abdicating responsibility. You're still responsible for the quality of your team's output. But you're coaching, not commanding. Reviewing, not writing.

Measure what matters. Not "how many docs did we write" but "can new team members find what they need?" and "are people actually using this?"

Always Be Teaching

When people first hear "always be quitting," there's usually a moment of shock at the title. Then they get it, and they get on with it. It's memorable advice that changes how people think about their work.

But individual practice is just the beginning. The real transformation happens when you shift from "I need to make myself replaceable" to "I need to build a team that owns knowledge collectively."

That's the shift from always be quitting to always be teaching.

I still love Merino's original post. I still share it constantly. But now I understand it as the foundation for something larger: building teams that don't just survive when someone leaves—they thrive because knowledge is truly shared, not just documented.