When our team brings an operational failure to the Issues List, we almost always default to blaming an individual rather than diagnosing the underlying system breakdown. How do we use IDS to separate personal performance from structural root causes?

Question

Tyler Smith · Accepted Answer

When operational breakdowns occur, leadership teams naturally point fingers at whoever touched the failure last. Scapegoating feels productive in the moment, but firing or reprimanding an employee without fixing the underlying process ensures the exact same mistake happens again with a different person.

In IDS, the Identify step requires peeling back symptoms until you reach the root cause. When an issue hits the table, the team must ask one fundamental diagnostic question before discussing any solution: Is this a people issue, or is this a process issue?

- A process issue means the system is broken, vague, or nonexistent. The person acted reasonably given the lack of clear guidelines, broken software, or conflicting incentives. If the process is missing or flawed, you do not reprimand the person. You assign a To-Do or a Rock to build or simplify the core process using the 20/80 rule.

- A people issue means the process was documented, trained, and clear, but the individual either does not get it, want it, or have the capacity to do it (GWC), or their behavior violates your Core Values. If the individual lacks GWC, no amount of workflow optimization or process documentation will fix the breakdown.

By forcing the team to categorize the issue as structural or behavioral before entering the Discuss phase, you eliminate personal defensiveness. You focus the entire leadership team on repairing systems rather than attacking colleagues.