Technical debt usually starts when the engineering implications of a product decision are ignored, not when engineers are lazy. Deferring work is fine. Pretending the downstream consequences do not exist is what gets expensive.
One of the biggest misconceptions in software is that technical debt comes from lazy engineers.
In my experience, it usually comes from something much more subtle.
It starts when engineering information never actually enters the decision.
Engineering isn’t just implementation
People often think software engineering is about writing code.
It isn’t.
A large part of the job is explaining what today’s decision implies tomorrow.
When I say:
“If we do it this way, we’ll also need to think about persistence, permissions, synchronization, and edge cases.”
I’m not trying to make the project bigger.
I’m trying to describe the decision surface.
The implementation isn’t larger because I want it to be.
It’s larger because the product now has more states.
Ignoring those states doesn’t eliminate them.
It simply means they’ll reappear later as bugs.
Every feature expands the decision surface
Take something that sounds simple:
“Let’s let users rename folders.”
Seems straightforward.
Except it isn’t.
Questions immediately appear:
- What happens to links that reference the old name?
- Does renaming affect shared folders?
- Do notifications display the new name immediately?
- Is the change synchronized across every logged-in device?
- What happens if two people rename the same folder at once?
- Can users rename system folders?
None of these questions are “extra engineering.”
They’re part of the feature.
The dangerous conversation
The conversation often goes like this.
Engineer:
“If we do X, we’ll also have to decide A, B, and C.”
Product manager:
“Let’s just do X.”
A week later:
“Why did everyone’s bookmarks stop working?”
Or:
“Why do I still see the old folder name on my phone?”
Or:
“Why did one user’s rename overwrite another’s?”
Nothing new happened.
The consequences simply arrived.
Deferring is good. Ignoring is expensive.
This is the important distinction.
I love deferring work.
Shipping smaller products is almost always the correct decision.
But that’s different from pretending a decision has no downstream consequences.
A good engineering discussion looks like:
“Yes, those implications exist.
We understand them.
We’re intentionally accepting that debt until V2.”
That’s excellent engineering.
The bad version is:
“Let’s not think about those right now.”
Eventually, reality thinks about them for you.
Technical debt is often communication debt
Many software projects accumulate technical debt long before anyone writes bad code.
The debt begins when engineering constraints never become part of the product discussion.
The engineer isn’t trying to make the software more complicated.
They’re trying to make the invisible parts of the decision visible.
Ignoring those implications doesn’t keep the product simple.
It just postpones the conversation until production.
