Guide: Setting up a 'champions' program without burning out your top performers.

Your point about **formalizing the commitment** is exactly right, but in my experience the "protected time" agreement is often the first part to collapse under delivery pressure. That 4-hour block gets cannibalized for firefights unless it's defended with data.

We solved this by tying it directly to our sprint metrics. The champion's weekly allocation became a non-negotiable ticket in the backlog, with completion tracked like any other story. This made the time commitment visible to product and prevented it from being silently deprioritized.

You also need a clear off-ramp. A champion's term should be defined, say 6 months, with a documented handover process. Otherwise you risk institutional knowledge dependency and the burnout loop you described.

Love the idea of tracking it as a backlog ticket. We've done something similar by linking a portion of the champion's quarterly goals directly to the program's success metrics. Makes it tangible for performance reviews.

But a 6-month off-ramp feels too rigid sometimes. If someone's still energized and the knowledge transfer is documented, why force a handover? I've seen continuity get lost in the shuffle.

What happens when a champion's term ends but there's no natural successor ready?

Totally agree with the bounded scope. I learned this the hard way when our first CRM champion program asked folks to "own adoption" for a whole suite - it became a second, invisible job.

The protected time is key, but it's only half the battle. You also have to give them real authority to make small decisions about their domain, like tweaking a training or approving a use case. Otherwise they're just glorified help desk tickets.

And you're spot on about the career recognition. We finally got it right when champion contributions became a formal, weighted line item in our promotion rubric. Suddenly it wasn't "extra," it was a core path to the next level. Without that, the best people will quietly opt out.

You're right about the bounded scope, but I've found the granularity matters. Defining a "specific tool" can still be too broad if the tool is complex. For instance, "our new feature flag platform" could include rollout, documentation, triage, and training. A champion will burn out trying to cover all of it.

The scope should be an atomic activity. Something like "owning the first-line triage and documentation for feature flag usage" is a bounded service. "Driving adoption of the test suite" is not. This atomic focus makes the **protected time** calculation far more accurate and defensible. You can't realistically estimate the time for "advocacy," but you can for "holding two office hours slots and reviewing five pull requests per week."

The concept of "formalizing the commitment" is solid, but you're missing the audit trail. If that commitment isn't auditable, it's just a verbal promise that evaporates during crunch time. Protected time in a plan means nothing if there's no mechanism to flag when it's being violated. Management needs to sign off on the time allocation with the explicit understanding that missing it is a compliance deviation for the program itself. Without that, you're just documenting a wish.

You've nailed the core failure mode: treating it as unpaid, unrecognized work. But without a concrete enforcement mechanism, that "formalized commitment" is just paperwork.

If the champion's 4 hours gets consumed by their main project work, who flags it? What's the escalation path? The commitment needs an owner outside the champion's direct management chain. Otherwise, their manager will always prioritize delivery over champion duties when push comes to shove.

Exactly, and I've seen that "owner outside the chain" role fail too if it's just another senior engineer. They need real organizational clout. We solved this by making our Head of Engineering the direct sponsor. Their quarterly report to leadership included a simple red/amber/green status for each champion program's protected time adherence. When it went red, it was a leadership-level problem, not a quiet negotiation between a champion and their stressed-out line manager. That external accountability changed everything.

Your point about the escalation path is crucial. Ours was baked into the program charter: a missed commitment two weeks in a row triggered an automatic review meeting with the sponsor and the relevant engineering manager. It stopped being personal and became a process issue to fix.

You're right that a fixed term can feel rigid, but the alternative is a silent, permanent assignment. The handover isn't just about the champion's energy, it's about preventing a single point of failure.

We use a "co-champion" model for the last 2 months of a term. The primary champions start shadowing their successors on tasks. If no natural successor is ready when the term ends, the program itself is flagged as "at risk" in our ops review, because that means we've failed at knowledge distribution.

> why force a handover
Because if you don't, you're just creating a permanent, unpaid maintenance role with a fancy title. The process forces the org to deal with succession, which is the whole point.

The co-champion model for succession sounds smart. How do you structure the selection for the co-champion role? Is it a nomination, a volunteer process, or is it more of a draft based on team needs? I'm worried that without clear criteria, you could end up with someone who isn't interested, which just delays the burnout problem.

I also like the idea of flagging the program as 'at risk' if there's no successor. It turns a people problem into a visible process metric. But doesn't that put a lot of pressure on the outgoing champion to basically recruit their own replacement? Where does the responsibility for succession planning ultimately land?

Spot on with the need for **protected time** and **career recognition**. It's the foundation. But I've seen that foundation crack if the recognition isn't tied to a *visible output*.

In our case, we paired the quarterly goal with a public, lightweight "champion log." It wasn't a detailed report, just a shared page listing things like "hosted 3 office hours sessions" or "reviewed 2 proposed use cases." This turned their commitment into a trackable artifact that both their manager *and* their sponsor could reference. It made the abstract "career growth" concrete for performance reviews.

You mentioned equipping them to scale - is the log something you'd see as part of that toolkit, or does it feel like more admin work?

That's a great addition. The log solves a real problem: making the work visible for recognition. But I've seen the same tool become a source of friction if it's not integrated into existing workflows.

The key is to anchor it to something they're already doing. For example, if they're hosting office hours, the log entry should be a one-click action from that calendar event, not a separate manual entry in a new system. Otherwise, you're right, it just becomes admin work.

In our case, we linked the lightweight log directly to the project management board they used for their main work. That way, moving a "champion task" to "done" auto-populated the log. It became a byproduct of the work, not an extra step. Did you find a way to automate the data capture, or was the manual entry manageable?

Automating the log is the only way it scales. Your approach of linking it to the task board is solid, as it turns compliance into a side effect.

The risk is over-indexing on automation and losing narrative context. A completed task on a board tells you "what" but not the "so what" that matters for career recognition. If a champion reviews a pull request, did they just click approve, or did they provide a critical insight that shaped the implementation? The latter is what gets them promoted.

We solved this by keeping the log entry as a simple link to the evidence - the merged PR, the meeting notes, the Slack thread. The champion adds a single sentence of context only when the outcome was significant. This keeps the admin minimal but preserves the qualitative impact. Without that, the log is just a timecard.

The link-to-evidence model is good, but it only works if your sponsor reviews it. Otherwise it's a black box.

You need a scheduled metric pull. We have a script that parses the log's linked PRs and meetings, then counts them in a weekly Prometheus gauge labeled by champion. That gauge is our "protection time utilization" metric. If it flatlines for two weeks, it auto-opens a ticket for the sponsor.

Without a quantifiable SLA attached to the log, it's just documentation for documentation's sake.

Great question. On the successor issue, we put the responsibility squarely on the team manager, not the outgoing champion. The champion can suggest names, of course, but the manager owns ensuring there's a pipeline of interested people.

For selection, we've had success with a light "expression of interest" process. We advertise the role internally for a week, describing the commitment and the skills it builds. Anyone can put their name forward. Then the manager and the current champion review the volunteers together and make a recommendation. This weeds out the totally uninterested while still giving people a choice.

That 'at risk' flag is actually on the manager's operational scorecard, not the champion's. It forces management to think ahead about growth paths. If no one volunteers, that's a sign the program's perceived value is low, and that's a program design problem to fix.