Eroding Goals

Description

The archetype "Eroding Goals", often treated as overlapping with *Drifting Goals*, emphasizes the melting away of long-term vision. It usually appears when the hard work required to fix a fundamental problem in the IT landscape, such as breaking apart a legacy monolith, would take too many years. Management or the architecture group cannot tolerate that long stretch of tension psychologically. Instead of pushing the mammoth effort forward, they let the vision of the golden state quietly dissolve into a merely good-enough state that effectively cements the broken reality.

Feedback Loops

The behavior emerges from a balancing loop that tries to close the gap between ideal and reality. But the corrective action, structural refactoring, has such a brutal delay, or is blocked by budget pressure, that the gap remains open for a long time. That cognitive dissonance, the feeling of always failing, is toxic for developers. Human psychology closes the gap instantly through a second balancing loop: we simply declare the messy reality to be the new official architecture standard.

Architecture Example

A bank launches a two-year initiative to introduce strict hexagonal architecture in all backend services. After six months, feature teams notice that the hard separation costs too much time for simple CRUD flows. The architecture committee softens the rule slightly: for read access, direct database calls are allowed. The goal erodes for the first time. By month twelve one team opts out completely: this critical, highly complex logic will bypass the model entirely. The architecture committee approves it. At the end of the two years the architecture is more fragmented and broken than before, but the presentation still celebrates the successful flexibilization of the system.

Organizational Example

A DevOps transformation program starts with the noble goal: you build it, you run it. Teams should own twenty-four-seven on-call responsibility. The teams protest that they still lack real CI/CD automation. Instead of investing for months in CI/CD improvements, the painful root-cause path, management gives way. It keeps a central dedicated night-shift Ops team that will step in during emergencies. The goal of developer responsibility erodes away, and DevOps degrades into a buzzword under which the old behavior simply continues.

Diagnostic Questions

1.Have we launched grand architecture goals as lighthouse projects that are now quietly fading into the sand and getting sold as partial successes?

2.Have clear exception rules become the real new architecture standard in our company?

3.Does our C-level or tech leadership allow teams to lower the bar whenever they complain loudly enough instead of actually helping them clean things up?

Diagram

How to Recognize the Pattern in Daily Work

Eroding Goals never comes from bad intent. It grows out of exhaustion. Technological transformations extract a heavy price from people who often still have to deliver day-to-day feature work in parallel. Blurring the vision becomes a survival instinct. Real architects have to act as an uncomfortable north star. Tactics may change, but the strategy and the quality goal must not be watered down for the sake of convenience.

What Distinguishes the Pattern from Similar Dynamics

In systems work, *Eroding Goals* is often tightly coupled with *Fixes That Fail*. Because the ambitious quality target erodes, people start throwing workarounds around the landscape, which make the real problem far worse over time.

How to Move from Pattern to Response

Tie architecture visions to external imperatives, especially customer pain, rather than internal vanity. If uptime goals erode, stop the internal metric theater and bring developers into direct contact with furious customers. External reality acts like a hard reset on the system. It tears apart the softened goal and restores the legitimacy of the original, harder target.

First Next Steps

Hold the line. Architecture principles are not mere guidelines. They must cost something, otherwise they do not change systems.

How to Recognize the Pattern with Confidence

Would our architecture vision survive the litmus test of delaying the go-live of a major feature if that feature violates the core standard?

Sources

The Systems Thinker: Drifting Goals

Peter Senge - The Fifth Discipline, ch. 6

Daniel Kim - Systems Archetypes at a Glance