People avoid touching certain areas
Parts of the system become socially dangerous, so engineers avoid them unless forced.
- Where you see this
legacy codecritical data pathspoorly documented services
- Not necessarily a problem when
- the area is intentionally restricted for high-risk operational reasons and ownership is still healthy
- Often mistaken for
- respect for complexity automatically means healthy caution
- Time horizon
- medium-term
- Best placed to act
tech leadengineering manager
The signal
What you would actually notice
Avoidance reduces shared ownership, increases risk concentration, and turns ordinary changes into escalations.
Field observation
Certain modules, services, or workflows are approached reluctantly and only by a small subset of the team.
Also observed
- Nobody wants to touch billing.
- Only Chris edits that part.
- Let us not risk it before release.
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.
- fragile code
- hero dependency
- poor observability
- past negative reinforcement from incidents
Stakes
Why it matters
Avoidance reduces shared ownership, increases risk concentration, and turns ordinary changes into escalations.
Inspection
What to check next
Deliberate steps to confirm or disconfirm the primary reading above. Not a checklist. An order of inspection.
- incident history
- test coverage quality
- observability and rollback capability
- knowledge concentration
Diagnostic questions
Questions to ask the team, or yourself, before concluding anything.
- What are people afraid of exactly?
- Is the fear about complexity, blast radius, or missing knowledge?
- What would make the area safer to touch?
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.
- people warn others away from an area
- refactors are postponed repeatedly
- only one or two people volunteer for changes there
Common root causes
What is usually sitting under the signal.
- painful incident history
- low testability
- weak runbooks
- hero ownership
Likely consequences
What happens if nothing changes.
- stagnation
- localized technical debt growth
- knowledge monopolies
Look-alikes
Not what it looks like
Patterns that can be mistaken for this signal, and 'fix' attempts that make it worse.
- respect for complexity automatically means healthy caution
Anti-patterns when responding
Responses that feel sensible and usually make the underlying pattern worse.
- declaring an area scary instead of improving it
- routing all risk to the same expert
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
- legacy code
- critical data paths
- poorly documented services
Who sees it first
Before it escalates.
- engineers
- team leads
- new joiners
Who can move on it
Not always the same as who notices it.
- tech lead
- engineering manager
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 make people feel bolder temporarily, but without understanding it can also increase risky edits in feared areas.
AI masks
Ways AI tooling tends to hide this signal, so it keeps growing under the surface.
- AI help can hide how weak real ownership still is.
Relationships
Connected signals
Related failure modes, decisions behind the signal, response playbooks, and neighboring red flags.