i

Description

A Sears department store

Source

Nyttend · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Local optimization (“end of the chain”)

When each link improves its own metric, the chain as a whole can perform worse.

In brief

• What: improving one's own part (team, batch, metric) without measuring the effect on the overall outcome.
• Why: everyone sees and is judged on their own scope; the whole belongs to no one.
• Detect: teams with green metrics while the product is late; queues between teams.
• Avoid: measure end-to-end flow, find the constraint, set shared goals, make links in the chain work together.

On this page

1. Definition
2. How it works
3. Where you encounter it
   1. In project management
   2. In management
4. Famous cases
   1. Sears: units competing with each other 2005-2018
   2. Development versus operations: the Flickr example 2009
5. Detection signals
6. Avoidance reflexes
7. With AI: detect, fix, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to integrate into your practices
   5. How to integrate them
   6. Precautions
8. Limits
9. Sources and verification
10. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Fictitious illustration

Local optimization (or sub-optimization) means improving one part of a system without asking whether it improves the whole. In an organization, each team, each batch, each department tries to do better according to its own metrics, and the sum of these improvements is not an improvement of the whole: it can even make it worse. Decision literature has referred to “sub-optimization” since Charles Hitch (1950s); the idea was popularized in management by Eliyahu Goldratt, in the novel The Goal (The Goal, 1984) and the theory of constraints.

Goldratt's principle is simple: in a chain, throughput is that of the slowest link, the constraint. Speeding up another link only piles up waiting work in front of the constraint. An hour gained elsewhere is worth nothing; an hour lost on the constraint is lost for the whole system.

The bias is both cognitive and organizational: we judge what we can see (our scope) and we are rewarded for what we measure (our local metrics). It aligns with the Goodhart's law: when a metric becomes a target, it gets optimized for itself.

How it works#

• A limited horizon. Everyone knows their own batch and constraints well, and others' poorly. We optimize what we understand (see The curse of knowledge for the misunderstanding this creates at the boundary).
• Department-level metrics. Utilization rate, number of tickets closed, coverage rate, cost per line: each measures one team. No one is judged on end-to-end lead time.
• Conflicting objectives. Some are judged on change (ship fast), others on stability (don't break anything); each protects their own metric at the expense of shared flow.
• Group identity. Teams see themselves as camps: they defend their scope against “them” (see In-group bias).
• The “end of the chain.” Each link hands off to the next what meets its own definition of “done,” without caring what the next team will do with it.

Where you encounter it#

In project management#

• Batch breakdown: each batch is optimized (cost, timeline, vendor scope), but integration, which belongs to no batch, is discovered late and is expensive.
• Development and operations: the development team is judged on the number of changes delivered, operations on stability. The “wall of confusion” between them slows everything down, for an outcome neither side wants (see the Flickr case below).
• Layer-specialized teams: one database team, one interface team, one testing team; a feature goes through all three queues and waits at each handoff.
• Utilization rate: keeping everyone 100% busy seems efficient, but creates queues and lengthens delivery time.
• Delivering “your part”: a team declares its batch done according to its own definition, without system-wide testing; the next team discovers the gaps.
• Lowest-bid outsourcing: the price of each batch is minimized, while total cost, including integration and rework, increases.

In management#

• Departmental goals: sales wins orders production cannot fulfill; production cuts costs by refusing small runs the customer expects.
• Siloed budgets: one department will not fund an improvement that benefits another, even if it reduces total cost.
• Individual evaluation: each person is judged on their own performance; helping a colleague does not count.
• Reorganization into autonomous units: each unit maximizes its own result, sometimes against the others (see the Sears case).

Famous cases#

Detection signals#

• All team metrics are green, yet the product is late or the customer is unhappy.
• Queues between teams: waiting tickets, work that is “ready but not integrated.”
• “That's not my scope” at the boundary between two teams or two batches.
• An improvement announced by one department whose effect no one else can see.
• Teams argue for their metrics rather than for product outcomes.
• Integration, acceptance testing, or production release are always the surprise point in the schedule.
• Time is gained on one step, and total lead time does not change.

Avoidance reflexes#

1. Measure end-to-end flow. The lead time between the idea (or request) and its use in production, more than each team's activity rate. A value stream map shows where work is waiting.
2. Find the constraint. Apply Goldratt's five steps: identify the constraint, exploit it fully, subordinate everything else to it, elevate it, then start again. Don't improve what isn't the constraint.
3. Shared objectives. At least one indicator shared by the teams in the same chain (lead time, quality at delivery, end-customer satisfaction).
4. Appoint an owner for the whole. For each product or each flow, someone is accountable for the overall result, with the necessary authority.
5. End-to-end teams. When possible, bring together in one team the skills needed for delivery (development, testing, operations) rather than chaining queues.
6. Limit work in progress. A maximum number of items per stage (Kanban board) reveals the constraint instead of hiding it.
7. Define “done” on the consumer side. A batch is delivered when the next team can use it, not when the producer has finished.
8. Integrate early and often. Interfaces between batches are tested from the beginning, before each batch is “finished.”

With AI: detect, fix, mitigate#

Prompts to integrate into your practices#

1. Find the constraint in a chain. With an export of tickets or a process description, anonymized.

Here is the description of a delivery chain with its stages, teams, and if possible durations or waiting lines: [text or export].
1. List the stages in order and indicate, for each one, what makes it wait or what it is waiting for.
2. Say where, based on this data, work accumulates the most, and what data would be missing to confirm it.
3. For three possible local improvements, indicate whether they would reduce overall lead time or not, and why.
Do not make up any data: flag each assumption as such.

2. Local objectives vs. shared objective. To prepare a workshop between two teams whose objectives conflict.

Here are Team A's objectives and indicators: [list] and Team B's: [list]. Both teams work on the same product.
1. Describe, for each indicator, the behavior it encourages and what this causes for the other team.
2. Identify objective conflicts between A and B.
3. Propose two or three shared indicators, with one possible perverse effect for each.
4. Write ten open-ended questions for a joint workshop, phrased without blame.

How to integrate them#

• At the start of an initiative: prompt 1 helps map the flow before deciding what to improve.
• In team workshops: prompt 2 is a discussion aid, not a verdict.
• For follow-up: measure end-to-end lead time, before and after each improvement.

Precautions#

• AI does not know your organization: its answers remain hypotheses to validate with teams.
• Do not draw any individual conclusions from ticket exports: the subject is flow, not people.
• A shared indicator can also be gamed: review perverse effects with the teams.
• Anonymize exports and do not paste confidential data into an unauthorized tool.

Limits#

• Specializing, measuring by team, and delegating are necessary: no one can manage a large system without breaking it down. The flaw is failing to also manage the whole.
• Not every local improvement is useless: one that targets the constraint, or reduces a risk, improves the whole. The criterion is its effect on global flow, not its size.
• Theory of constraints simplifies: in design work, the constraint shifts, and multiple links can be limiting at the same time.
• The Sears case is a journalistic reading based on testimonies; the group's decline has several causes.
• Trying to optimize everything globally leads to paralysis: you need clear local responsibilities and global arbitration.

Sources and verification#

• Goldratt & Cox (1984), The Goal: A Process of Ongoing Improvement, North River Press (French translation: Le But).
• Hitch & McKean (1960), The Economics of Defense in the Nuclear Age, Harvard University Press — origin of the term “sub-optimization.”
• Kimes (2013), “At Sears, Eddie Lampert's Warring Divisions Model Adds to the Troubles,”Bloomberg Businessweek, July 11, 2013
• Bloomberg, “Sears Goes Bankrupt, Mired in Debt and Deserted by Shoppers” (October 15, 2018)
• Allspaw & Hammond (2009), “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr,” O'Reilly Velocity conference.
• Forsgren, Humble & Kim (2018), Accelerate: The Science of Lean Software and DevOps, IT Revolution Press.
• Kim, Behr & Spafford (2013), The Phoenix Project, IT Revolution Press — novel, useful for teaching more than as evidence.

See also#