Every CI leader knows how to run a PDCA cycle on someone else's process. Plan a change, do it, study the result, adjust. Ask the same leader when they last ran that cycle on their own process or platform configuration, and most will admit the honest answer is never. It was designed once, at implementation, and hasn't been deliberately revisited since, even as the organization's needs changed underneath it.

That's the same failure mode you'd flag in any other part of the business: a process that was right for the conditions it was built under and never got checked against the conditions it's running in now.

Engagement data is a diagnostic, not a scoreboard

The User Engagement Summary Report gets used most often to answer "who's active and who isn't," which is useful, but it's a shallow read of what the report is actually capable of telling you. The same data that shows who's disengaged also shows you where your configuration itself is failing to earn engagement.

If a specific location or team has consistently low usage despite comparable staffing and leadership attention elsewhere, don't jump straight to a people problem. Check whether their workflow is heavier than everyone else's, whether their templates ask for more than other teams', or whether they were never properly onboarded to a Board structure that makes sense for how they actually work. Sometimes "low engagement" is really "this configuration doesn't fit this team," and no amount of coaching fixes a tool that's the wrong shape for the job.

What a quarterly config audit actually looks for

You don't need a formal project to do this. A short recurring review, ideally quarterly, tied to a simple checklist, catches most of what matters:

• Unused templates. Pull usage counts. A template nobody's touched in two quarters is either genuinely obsolete or a sign the team using it went around it. Either way, it's worth a conversation, not a deletion by default.
• Fields nobody fills in. A required field with a high blank or garbage-value rate isn't being ignored out of laziness, it's usually a field that doesn't map to how the work actually happens. That's a Poka-Yoke problem as much as a data quality one: the form should make the correct answer the easy one, not just the mandatory one.
• Workflow steps that exist out of habit. If a "Just Do It" template still routes through three levels of approval because that's how it was built four years ago, ask whether that approval chain still matches the risk level of what's actually being approved. Removing an unnecessary sign-off is the same move as removing waste from any other process, it's just easier to overlook because it's buried in a workflow config screen instead of a shop floor.
• Notification fatigue. Revisit this alongside the audit rather than waiting for complaints. If nobody's cleared their notifications, that's a signal worth acting on before someone tells you they've filtered emails from the platform out of their inbox entirely.

Build the feedback loop in

The most durable version of this isn't a leader remembering to run an audit, it's a standing mechanism for it. Some organizations purchase a dedicated "System Feedback" template where users can flag friction in the configuration itself, the same way they'd flag friction in any other process. Others incorporate a question about configuration into their Gemba Walks or Daily Management routines. Both of these turn configuration improvement into an ongoing, bottom-up input instead of something that only happens when a CI leader happens to notice a problem.

The standard you're already holding everyone else to

None of this is a new discipline. It's the same PDCA cycle, standard work audit, and root cause thinking you already expect from every team you coach. The only shift is pointing it at your own system instead of theirs. If your platform configuration hasn't changed in two years and your organization has, that's not a sign it's stable. It's a sign it's overdue.

Next up: what happens when part of this coaching habit gets built directly into the tool.