Don’t start by asking “What tech debt do we have?” Start by asking “What slows us down or creates risk?”
Most teams talk about tech debt like it’s just old code.
But after 30 years in the field, I’ve learned this: The biggest risks aren’t always just in your codebase.
They’re in your network, your IAM, your CI pipeline—and often in the aging hardware, outdated operating systems, forgotten services, or legacy tools that nobody’s touched or patched in years.
The Real Definition of Tech Debt
If you only look for legacy apps, you’ll miss the systems, configs, and decisions that quietly drain velocity and invite failure.
Tech debt is anything that slows down your ability to deliver value safely and predictably.
That includes:
Orphaned IAM policies
Undocumented route tables
VPNs with overlapping CIDRs
Unmaintained Terraform modules
Manual deployment gates
Unsupported OSes
Shadow IT systems and abandoned toolchains
Outdated, unmonitored network paths
If it creates friction, adds risk, or lacks ownership—it’s debt.
Where It’s Hiding
Not just in your app stack.
Real tech debt lives in:
Networking: flat VPCs, legacy hub-and-spoke designs, stale peering connections, unmanaged NATs, no segmentation, inconsistent tagging, and no visibility into east-west traffic
Security: firewall rules nobody reviews, inconsistent MFA, overprovisioned access, legacy tooling
CI/CD: flaky pipelines, approval bottlenecks, drifted test logic, manual promotion steps
Infrastructure: old servers, unmanaged certs, DNS no one owns, shared storage no one audits
Software: internal tools built 7 years ago by a team that no longer exists, with no documentation, no tests, and dependencies on deprecated libraries
Systems: EOL operating systems, unmaintained tools, forgotten cron jobs and scheduled tasks
So How Do You Find It?
Not with a Jira label. You need a tech debt inventory that spans code, systems, infrastructure, and teams.
Here’s how:
🧭 Step 1: Map the Flow
Start by mapping how a feature moves from idea to production. Use a simple Value Stream Map to expose:
Delays
Handoffs
Manual steps
Ownership gaps
Ask your team: Which systems break when we look at them sideways?
⚙️ Step 2: Inventory the Stack
At each step, document the underlying tech:
Apps: Monoliths, brittle SDKs, shared business logic
Software: Internal tools with no current owner, apps with deprecated libraries, old Java or .NET services still running critical workflows
Infra: Load balancers, storage systems, unmanaged cert chains
Network: VPC layouts, peering, NATs, DNS, firewall zones
Security: IAM roles, expired certs, dormant users, lack of logging
CI/CD: flaky tests, hardcoded secrets
Hardware/OS: Aging On-prem servers, unsupported Linux distros or Windows versions, untracked dependencies
Tag each with:
❌ Unowned
⏱ Causes delay
🚨 Security or audit risk
🛠 Breaks often
🧠 Requires tribal knowledge
📊 Step 3: Score and Prioritize
Rank each item by:
Friction: How often it slows or blocks work
Risk: Security, compliance, uptime exposure
Effort: Cost to remediate
Value: Business impact if improved
This gives you a defendable, fundable backlog.
🔍 Step 4: Visualize It
Don’t hide this in a spreadsheet.
Build a heatmap by system, team, or domain
Annotate your OnPrem or Cloud architecture with risk overlays
Highlight where aging hardware, mismanaged networks, and forgotten processes intersect
Visibility creates urgency.
The Goal
You don’t need zero tech debt. You need zero unowned, invisible, or business-blocking debt—especially the kind buried in your software, infrastructure, tooling, and network.
Final thought:
Tech debt hides in the things that slow you down or make your team nervous. It’s not just code—it’s what everyone avoids.