What this note helps with

Use this note to make the repeated decisions behind content operations visible enough that the team can improve them.

What this feels like in the work

This feels like the team knows how things work until someone new joins, someone is out, or volume spikes. Then we realize the process lived in memory, not in the system.

The problem

Many L&D teams run on memory. People know how things work because they have been around long enough. That breaks when volume grows or people leave.

The system move

Start with a minimum viable playbook: intake rules, naming standards, review steps, publish criteria, maintenance cadence, and where decisions are documented.

What to inspect

Look for repeated decisions that are answered differently depending on who is asked.

Use this when
  • People answer the same publishing, naming, review, and maintenance questions differently
  • Content operations depend on memory and informal handoffs
  • New team members cannot tell how work moves from request to published resource
Diagnostic questions
  • Which decisions does the team repeat every week?
  • Where are naming, review, publishing, and maintenance rules documented?
  • What breaks when one experienced person is unavailable?
What to watch for
  • Questions the team answers differently depending on who is available
  • Publishing steps that happen because one person remembers them
  • Naming, review, QA, and maintenance rules that show up only after something goes wrong
What this can look like
  • Order-taking intake The requester names the asset first, but cannot name the behavior, audience, workflow, or evidence standard.
  • Invisible capacity We know the team is busy, but we cannot show request volume, active work, blocked work, or tradeoffs.
  • Governance by memory The same request gets different answers depending on who is asked or who remembers the last decision.
What we can try first
  • Start with the five repeated decisions that create the most rework
  • Document intake rules, review steps, publish criteria, and maintenance cadence
  • Treat the playbook as a living operating artifact, not a policy binder
Small experiment

Pick one repeated decision and write the current answer in plain language. Then add where that decision lives, who owns it, and when we revisit it.

Three ways we can respond
  • No technology Run a 15-minute request triage with four questions: what task is failing, who performs it, where does it fail, and what evidence would show improvement.
  • Microsoft 365 or Google Workspace Use Microsoft Lists, Excel, Google Sheets, or Forms to capture request type, audience, status, priority, owner, due date, and decision notes.
  • AI-assisted Ask AI to classify requests into training, workflow, documentation, manager support, tool, or measurement issues, then have a human confirm the category before work starts.
Sources