Making the Invisible Visible

Making the Invisible Visible

Technical debt lives in the invisible realm. Making it visible is the first step to addressing it.

Why Debt Is Invisible

Technical debt is invisible because:

- It lives in code, which non-engineers don't see

- Its costs are diffuse (slowdowns, not discrete failures)

- It often manifests as "engineering is slow" without clear cause

- Teams absorb the pain rather than surfacing it

Visualization Strategies

Debt inventories: Maintain a list of known debt with estimated impact:

Heat maps: Show where in the codebase debt concentrates. Areas with high change frequency + high complexity = burning debt.

Time tracking: Track how much time goes to debt-related work vs. new development. "We spent 30% of last quarter on workarounds and fixes."

Incident correlation: Link incidents to underlying debt. "This system caused 40% of our on-call pages."

Communicating to Leadership

Translate visibility into business terms:

- "Our velocity is 30% lower than it should be because of X"

- "We can't build feature Y without first addressing Z"

- "This debt contributed to N incidents last quarter, each costing..."

- "New engineers take X weeks longer to ramp up because..."

The Debt Report

Consider a regular (quarterly?) debt report:

1. Current major debt items

2. Impact on velocity, incidents, satisfaction

3. What's been paid down since last report

4. What's new or growing

5. Recommended priorities

This makes debt a regular part of business discussion, not an occasional crisis.

When Visibility Backfires

Caution: visibility can backfire if:

- Leadership sees debt and demands it be fixed immediately (unrealistic)

- Teams feel blamed for debt they didn't create

- The inventory becomes overwhelming

- Focus shifts to "reducing the debt count" over actual impact

Visibility is a tool. Use it thoughtfully.