Drifting Goals

Description

The archetype "Drifting Goals" describes how standards are gradually lowered when the gap between aspiration and reality persists over a longer period. Instead of changing the structure that prevents the desired goal, the organization adapts the target value to current performance. This makes the deviation feel smaller in the short term, while the original aspiration is lost over time.

Feedback Loops

The mechanism is based on two competing balancing loops.

Loop 1, desired: Detect a defect, make a clear correction, and pull actual performance up toward the goal.

Loop 2, goal adjustment: The system reacts slowly or resists the change through delay or policy resistance. Pressure is reduced by lowering the mental picture of the goal: "We are not doing that badly."

The second loop is especially effective because it creates immediate relief: the goal is adjusted, and the perceived gap disappears. Precisely for that reason, the structural cause remains.

Architecture Example

A team aims for a 99.9 percent uptime SLA. In the first quarter it reaches only 99.5 percent. Root-cause analysis is effortful and architecture-wide refactoring would be demanding. Management treats 99.5 percent as sufficient for this legacy module. In the next quarter, uptime drops further. Step by step, an initially ambitious standard becomes a lower normal state without the technical cause being fixed.

Organizational Example

A tribe introduces a zero-bug policy for its sprints. Every bug should be fixed before new features are built. Because the product is unstable, many defects become visible and the sprint slows down significantly. To reduce the pressure, the teams adjust the meaning of bug: some defects are now treated as enhancements, minor disturbances, or known issues. The goal remains formally present, but loses its practical effect.

Diagnostic Questions

1.Have we recently recalibrated company-wide metrics such as DORA, uptime, or security ratings because we could not hit the old goals?

2.Where do we now tolerate waits in the codebase, such as build times above forty minutes, that would have been treated as clear problems a few years ago?

3.Do experienced developers often say, "That is just how things are in this company"?

Diagram

How to Recognize the Pattern in Daily Work

The pattern becomes visible when quality goals are no longer derived from customer needs, risk, or technical necessity, but from recently achieved performance. Goal drift rarely happens in large jumps. It usually happens step by step over longer periods. Systems thinkers therefore do not anchor target states only in historical values, but also in external references such as best practices, industry standards, or clear SLA contracts.

What Distinguishes the Pattern from Similar Dynamics

Drifting Goals is the mirror image of Escalation. In escalation, teams keep raising the level of effort. In Drifting Goals, the target itself is lowered until the gap becomes easier to tolerate. It also overlaps strongly with Eroding Goals, which is often used almost as a synonym.

How to Move from Pattern to Response

Treat goal erosion as a visible architecture topic. If the build pipeline regularly takes longer, that should be discussed early. Anchor quality goals in a traceable way and with external justification. If goals are currently unreachable, name that honestly as a deficiency; then either create a plan for structural improvement or document a deliberate goal change.

First Next Steps

Prevent alert fatigue in your observability stack. If developers only click warnings away because "that always flashes up for a moment," the system has already lowered their internal quality goal.

How to Recognize the Pattern with Confidence

Can we still clearly explain which concrete customer need gave rise to our architecture goals, or have they turned into internal paper targets?

Sources

The Systems Thinker: Drifting Goals

Daniel Kim - Systems Archetypes at a Glance

Wikipedia: System Archetypes