Respect for people is the Lean principle that's easiest to agree with in a training session and easiest to violate in a system configuration, because it rarely gets violated on purpose. It usually gets violated by two well-intentioned habits: cleaning up your system, and trying to keep everyone informed.

Deleting an idea is not the same as saying no to it

When someone submits an idea that isn't going to result in a change, the instinct is to clean it up: delete it, keep the list tidy. Resist that instinct. If the idea had any real thought behind it, deleting it erases the record that someone engaged with a problem, and it opens the door for a different employee to submit the exact same idea eighteen months later, forcing you to run the same analysis twice.

Worse, deleting sends a quiet message: this wasn't worth acknowledging. Resolving the Item as "No Change" instead sends the opposite one. It tells the person their input mattered enough to get a real response, even if the answer was no. That distinction matters more than it sounds like it should, because it's one of the few places in a CI program where an employee directly experiences whether leadership actually listens or just says it does.

There are genuinely four different reasons an idea might not result in change, and each deserves a different response rather than a delete button:

• It's a bad solution to a real problem. Coach them toward a better one instead of dismissing the problem along with the solution.
• It's not feasible. Resolving it as "No Change" and explaining why creates a record so the next person who has the same idea understands why it didn't happen.
• It's already been done. That's not a wasted submission, it's a signal that your training or communication has a gap somewhere.
• Nothing needs to be done. This should be rare. If it's happening often, that's usually a sign the real issue is upstream of the idea itself.

The only ideas worth actually deleting are test submissions and anything that's genuinely an HR or sensitivity issue. Everything else is data about the health of your improvement culture, including the percentage of ideas that don't result in change, which is a number worth tracking on its own.

Full guidance on when to resolve versus delete is in Why not delete Items resulting in no change?

Respecting people's attention is its own design problem

The other side of respect for people shows up in notification design, and it's less about what you say and more about how much of it you send. KaiNexus can notify quality leaders, finance, safety teams, executives, and every team member on an Item, and it's tempting to configure broad visibility for everyone because more information feels safer. It isn't. A leader who gets pinged on every Item regardless of relevance stops reading notifications at all, which means the one that actually mattered gets buried with the rest.

The better default is notification design by role, not by breadth:

• Quality and process leaders need visibility into new, neglected, and high-impact resolved Items, not every comment.
• Finance needs visibility into financially-impactful resolutions specifically, so ROI reporting stays auditable without burying them in unrelated activity.
• Executives need the short list of Items that touch critical business operations, filtered hard.
• Teams need real-time updates on their own Items, which KaiNexus already handles through Team Role-based notifications by default.

Each group can also set their own Digest and subscription cadence, which matters, because "respect for people's time" includes letting people choose how often they hear from the system, not just what they hear about. Full detail on Digests, subscriptions, and role-based notification setup is in KaiNexus communications.

The tell

If people are muting notifications, ignoring the Digest, or asking "why did I get this" more than "thanks for the heads up," that's not a training problem. That's a configuration problem, and it's worth treating it with the same seriousness you'd give an actual process bottleneck.

Next up: PDCA, and why your configuration deserves the same improvement cycle you're asking everyone else to run.