It’s not the code – it’s the decisions

When technical debt does not feel like a technical problem

Most people who work closely with IT projects know the feeling.

The system works. The release went live. The deadline was met. Yet there is a lingering sense that something has been postponed.

It is not necessarily because the developers did not know better. The risks may have been recognised and raised along the way. But a decision was still made: We will deal with it later.

Technical debt may become visible in the code, but it often begins earlier – in decisions about time, scope, quality and risk.

Leading without formal authority

If you lead without formal authority in an IT project, you are often in a difficult position. You may be responsible for progress, quality and collaboration without having the authority to stop or redirect the project.

You might be a tech lead without line-management responsibility, a senior developer coordinating the work of others, an architect working with multiple stakeholders or a project manager with technical insight but limited decision-making authority.

What these roles have in common is that you may see the consequences of a decision long before they reach the production environment – without being the person who ultimately makes that decision.

“We’ll do it properly later”

Technical debt rarely results from a single major mistake. It often accumulates through a series of decisions that appear reasonable at the time:

• “This solution will be good enough for the first release.”
• “It’s only temporary.”
• “We just don’t have time right now.”
• “The business needs something now.”

Each decision may be rational in isolation. Together, however, they can create a system that is harder to change, harder to explain and harder to maintain.

Not all technical debt is deliberate. It may also arise because requirements change, knowledge is incomplete or the consequences of a design choice only become apparent later. The important question is how the organisation responds once the debt becomes visible.

The problem is not compromise – but unowned consequences

Compromises are unavoidable in IT projects. The problem arises when their consequences remain invisible or nobody is responsible for revisiting them.

If technical debt is not documented, prioritised and discussed in language that both technical and non-technical stakeholders understand, it can disappear from view – until it becomes critical.

This can leave you in a difficult position when you lead without formal authority: You understand the risk but do not have a clear mandate to address it.

When technical debt becomes a leadership issue

Many technical compromises are never recorded as explicit decisions. They simply become part of the system.

That is how technical debt can grow unnoticed.

Eventually, it stops being solely a technical concern and becomes a leadership issue. This happens when:

• changes take disproportionately long to implement
• fixing defects requires extensive coordination
• the team loses clarity and motivation
• new requirements encounter unexpected resistance in the system

At this point, it becomes clear that past decisions are limiting the organisation’s current options.

This is why leading without formal authority can make a real difference. You may not be the person who makes the final decision, but you can make sure that risks and consequences are understood before the decision is made.

How to put shared concerns into words

You are unlikely to eliminate technical debt on your own. But you can make it visible and help the organisation make more informed choices.

1. Translate technical consequences into organisational risks

Instead of focusing only on refactoring, dependencies and complexity, explain what they mean in practice: longer delivery times, a higher risk of defects, more coordination and less flexibility later.

When the consequences are understandable to people without a technical background, they are easier to consider alongside deadlines and business priorities.

2. Make implicit trade-offs explicit

Many decisions are made quickly and are never described as actual choices. Make the trade-off clear:

“We are accepting this limitation for now to meet the deadline, but it will make future changes more difficult.”

The purpose is not necessarily to stop the decision. It is to ensure that the decision is made with a clear understanding of its consequences.

Where possible, record the consequence, assign an owner and agree on when the decision should be reviewed.

3. Ask the questions that might otherwise be missed

What will this solution mean six months from now? Who owns the consequence when the system needs to change? What becomes harder if we choose the fastest solution today?

The technical answers may already exist. What is often missing is someone willing to ask the questions at the right time.

4. Create a shared language for quality, time and consequences

If quality is discussed only in technical terms while time is discussed only as a deadline, stakeholders may talk past one another.

When you lead without formal authority, you can help connect these perspectives. Quality, speed and long-term consequences should be treated as related decision criteria rather than opposing interests.

The aim is not to reject every compromise. It is to make choices with a clear view of what they will cost later.

It is not about perfect code – but better decisions

Technical debt is difficult to avoid entirely, and its presence does not necessarily mean that a project has failed.

But there is an important difference between:

• debt that has been identified and consciously accepted
• debt that is discovered only when it begins to restrict the organisation

That difference is not found only in the code. It is also found in the decisions made along the way.

And that is where leading without formal authority can make a real difference.