When Optimization Backfires: The Psychology of Departmental Metrics

In the first post of this series, we established that all KPIs are wrong—and that's the point. The Define phase of DMAIC is about interrogating metrics, not selecting them.

But there's a deeper problem. When different teams own different wrong metrics, the system doesn't just degrade. It breeds organizational dysfunction.

The Hidden Cost of Local Optimization

Here's a pattern I've seen in manufacturing organizations:

The coating department reduces thickness variation. Their yield metric improves. They celebrate.

Downstream, machining sees increased tool wear. Quality sees more dimensional rejects. Assembly sees fit issues. Customer service sees premature failure returns.

Each department reports "their" metric is fine. The system is degrading. And everyone is confused about why.

The coating team isn't wrong—they hit their target. The machining team isn't wrong—they're struggling with inputs they can't control. Quality isn't wrong—they're catching problems.

What's wrong is the measurement model.

The Psychology of Metric Ownership

When a team "owns" a metric, something happens psychologically. The metric becomes part of their identity.

"We hit 97% yield this quarter" becomes "we had a great quarter." Defending the metric becomes defending the team's worth. When someone suggests the metric might be misleading, it doesn't feel like a technical discussion. It feels like an attack.

This is why metric changes feel like personal attacks. This is why cross-functional conversations about measurement get tense. The problem isn't the people—it's the ownership model.

Counter: Shared Metrics at Handoff Points

What gets passed between teams should have shared ownership.

"Yield at the machining input" isn't a coating metric anymore. It's a coating + machining metric. Both teams are invested. Both teams see the upstream/downstream connection.

In software: "Deployment success rate" isn't a DevOps metric. It's a DevOps + Security + Product metric. When deployment frequency goes up but success rate drops, the conversation isn't "DevOps is failing." It's "the system is degrading, let's understand why."

Information Asymmetry and Trust

Department A can't see what Department B is optimizing for. Each assumes the other is "being unreasonable."

• "Why are they sending us parts with this much coating thickness variation?"
• "We're meeting spec, they just can't handle it."
• "Why does QA keep rejecting parts that passed our inspection?"
• "We're catching the defects they're letting through."

Both are right from their frame. Both are wrong from the system view.

The system looks broken from every angle, but no one sees the whole.

Counter: Upstream/Downstream Visibility

Every team should see the metrics of the teams they affect.

Not just their own metric in isolation. A dashboard that shows: "Our metric" + "Impact on downstream team A" + "Impact on downstream team B."

This doesn't solve the problem. But it makes the problem visible. And visibility is the first step toward shared understanding.

Gaming Metrics Is Rational Behavior

Here's an uncomfortable truth: if you're measured on X, you'll optimize X—even at the expense of Y. This isn't "bad actors." This is incentive design.

The same person would behave differently under different metrics. The coating supervisor optimizing yield isn't trying to hurt machining. They're responding rationally to the measurement model they live under.

The problem isn't individual behavior. The problem is the system of incentives.

Counter: Align Incentives with System-Level Outcomes

Part of each team's performance evaluation should tie to system-level outcomes. Not just "did we hit our metric?" but "did the system improve?"

This breaks the "not my problem" psychological barrier. When your bonus depends on downstream success, you start asking questions about what happens after your handoff.

Problem-Solving Constructs Shape Solutions

How you frame the problem determines what solutions you can see.

"Improve yield" frames the problem as local. The solution space is: reduce defects in coating.

"Reduce total cost of quality" frames it as systemic. The solution space includes: what happens in machining? What happens in assembly? What happens at the customer?

Same organization. Same data. Different frame. Different solutions.

The DMAIC Define phase should include: whose perspective is this problem framed from? What would it look like from each handoff point? What metrics conflict are we assuming away?

The Blame Game vs. The System Game

When metrics conflict, teams blame each other. It's natural. It's also counterproductive.

"They keep sending us bad parts."

"We're meeting spec, they just can't handle it."

"QA is too strict."

"Engineering gave us a bad design."

Each statement is true from that team's perspective. Each statement is false from the system's perspective.

The way out isn't to assign blame. It's to recognize that the measurement model creates the conflict. Then redesign the measurement model.

Counter: Shared Problem Statements and Joint Root Cause Analysis

When something goes wrong, don't ask "who's responsible?" Ask "what system behavior produced this outcome?"

This requires:

• Cross-functional problem statements (not "machining yield dropped" but "system yield degraded at the coating-machining handoff")
• Joint root cause analysis with representatives from each affected function
• Shared ownership of the fix

Software Has the Same Problem

This isn't a manufacturing problem. Software organizations have identical dynamics.

DevOps optimizes for deployment frequency. Security sees more vulnerabilities. Platform sees more incidents. Product sees more half-baked features. Customers see more bugs.

Each team's metrics look fine. The system is degrading.

The solution is the same:

• Shared metrics at handoffs (deployment success rate, not just deployment frequency)
• Cross-functional visibility (each team sees downstream impacts)
• System-level KPIs (part of everyone's evaluation ties to overall system health)
• Define phase includes perspective mapping

What DMAIC Done Right Looks Like

The first post covered metric interrogation. This post covers organizational psychology. The third—system dynamics—is implicit in both.

The three are inseparable. You can't fix the measurement model without understanding who owns what and why they defend it. You can't redesign incentives without understanding system dynamics. You can't improve the system without interrogating metrics and understanding psychology.

DMAIC done right includes all three:

• Define: What are we measuring, what are we missing, whose perspective is this framed from?
• Measure: What does the data actually tell us, and what does it hide?
• Analyze: What are the root causes, and how do organizational dynamics contribute?
• Improve: What systemic changes would address root causes, not just symptoms?
• Control: How do we sustain improvement without creating new dysfunction?

The Point

Local optimization creates global suboptimization. But the mechanism isn't just mathematical—it's social and psychological.

Teams defend their metrics because their metrics are their identity. Information asymmetry creates mistrust. Gaming metrics is rational under bad incentive design. Problem frames determine solution spaces. Blame feels natural; system thinking requires deliberate effort.

The fixes are structural:

• Shared metrics at handoff points
• Upstream/downstream visibility
• System-level KPIs tied to performance
• Define phase includes perspective mapping
• Joint root cause analysis, not finger-pointing

The organizations that get this right don't have better people. They have better measurement models—and the psychological safety to question them.

---

Next in this series: Blameless Postmortems and the Psychology of Honest Measurement—why "no blame" requires "no individual metric ownership."