I build enablement functions — end to end.

Every enablement request arrives as a solution: "We need a course on X." My first move is to refuse the request as stated and re-open the underlying problem. Most "course" requests are actually documentation gaps, process gaps, or hiring gaps in disguise — and a course will not fix any of those.

• Question 1 — What outcome would tell us this worked?
• Question 2 — Who specifically is failing at that outcome today?
• Question 3 — Is the gap knowledge, skill, system, or motivation?
• Question 4 — If we built nothing, what's the actual cost?

Content has a half-life. Treating every article and course as permanent is how knowledge bases rot into liability. I sort everything I author into three tiers, each with its own review cadence and retirement criteria.

Enablement teams get measured on completion rates, which measures the wrong thing. Completion proves people clicked. I track three layers, and I make leadership choose which one a project is being judged on before the project starts.

• Activity — Did the learning happen? (Completions, engagement.)
• Capability — Can people now do the thing? (Assessments, observation.)
• Outcome — Did the business result move? (Ramp time, ticket deflection, CSAT.)

The framework forces the conversation up the stack. If a stakeholder won't commit to a capability or outcome metric, that's a signal the project shouldn't be built.

A help center is not a content library — it's a feedback system. Every search with no result, every article with high views and low ratings, every ticket that quotes an article back is data. I run a weekly triage on three signals:

• Zero-result searches → content gaps to fill.
• Low-rated high-traffic articles → rewrites in priority order.
• Recurring ticket themes → new articles or product feedback.