Changes always touch too many places
Even ordinary changes require edits across many files, layers, or services.
- Where you see this
service-oriented systemslayer-heavy monolithsschema-and-contract-driven platforms
- Not necessarily a problem when
- the change is genuinely cross-cutting by nature
- Often mistaken for
- complex business domain automatically requires broad code fan-out
- Time horizon
- near-to-medium-term
- Best placed to act
architecttech lead
The signal
What you would actually notice
Broad change surface increases risk, slows delivery, and makes ownership murky.
Field observation
Simple requests require multiple coordinated changes across layers that should have been more local.
Also observed
- It is just a small change, but it touches six services.
- We need three teams for this simple rule update.
Primary reading
What it usually indicates
Most likely underlying patterns when this signal shows up. Not a diagnosis, a starting hypothesis.
Usually indicates
Most likely underlying patterns when this signal shows up.
- tight coupling
- leaky abstractions
- premature layering
- missing vertical ownership
Stakes
Why it matters
Broad change surface increases risk, slows delivery, and makes ownership murky.
Inspection
What to check next
Deliberate steps to confirm or disconfirm the primary reading above. Not a checklist. An order of inspection.
- dependency graph
- change hotspot analysis
- service or module boundaries
Diagnostic questions
Questions to ask the team, or yourself, before concluding anything.
- Why is this change not local?
- Which dependency makes the fan-out unavoidable?
- Are we paying for technical coupling or organizational coupling?
Progression
Under the signal
Where this pattern tends to come from, what's holding it up, and where it goes if nothing changes.
Leading indicators
What tends to show up first.
- ordinary features get framed as system-wide work
- review size grows faster than value delivered
- teams ask for coordination meetings before small changes
Common root causes
What is usually sitting under the signal.
- boundary decay
- shared schemas
- centralized business rules
- no clear product slices
Likely consequences
What happens if nothing changes.
- slower delivery
- more regressions
- coordination overload
- invisible deadlines
Look-alikes
Not what it looks like
Patterns that can be mistaken for this signal, and 'fix' attempts that make it worse.
- complex business domain automatically requires broad code fan-out
Anti-patterns when responding
Responses that feel sensible and usually make the underlying pattern worse.
- celebrating cross-team coordination as proof of maturity when it is often compensating for bad structure
- accepting fan-out as normal
Context
Context and ownership
Where this signal surfaces, who sees it first, who can actually act, and how much runway there usually is before escalation.
Where it shows up
- service-oriented systems
- layer-heavy monoliths
- schema-and-contract-driven platforms
Who sees it first
Before it escalates.
- developers
- tech leads
- engineering managers
Who can move on it
Not always the same as who notices it.
- architect
- tech lead
near-to-medium-term
How much runway there usually is before the signal hardens into the underlying pattern.
AI impact
AI effects on this signal
How AI-assisted and AI-driven workflows tend to amplify or hide this signal.
AI amplifies
Ways AI tooling tends to make this signal louder or more common.
- AI can speed up multi-place edits, reducing friction while preserving the underlying architectural problem.
AI masks
Ways AI tooling tends to hide this signal, so it keeps growing under the surface.
- Generated cross-repo changes can make fan-out feel operationally normal.
Relationships
Connected signals
Related failure modes, decisions behind the signal, response playbooks, and neighboring red flags.