Technical Debt on Alfero Chingono

Technical Debt Is a Capital Allocation Decision

Thu, 07 Dec 2023 09:00:00 +0000

By the time technical debt is obvious, the engineering argument is usually no longer the hard part.

People can see the outages. They can see the missed commitments. They can see the manual work, the duplicated effort, the slow onboarding, the operational fragility.

The harder part is helping the business interpret what it is seeing.

Is this just a run of unfortunate IT costs?

Or is it a sign that the company needs to reallocate capital toward the platform underneath the business?

I think the second framing is usually the correct one.

Technical debt is not only a code smell

One reason these conversations go sideways is that technical debt is still too often described as if it lives mostly in source code.

Sometimes it does.

But in practice, the more expensive debt usually spans:

code and schema variation
outdated libraries and protocols
manual deployment behavior
undocumented custom features
weak monitoring and recovery capability
poor separation of configuration and secrets
process models that rely on individuals more than systems

That matters because the remediation strategy changes depending on the frame.

If leadership hears “developers want to clean up code,” the work sounds optional.

If leadership hears “the current operating model is reducing delivery capacity, increasing risk, and slowing revenue growth,” the conversation becomes more honest.

Some remediation costs are avoidable. Some are not

I think this distinction is useful, especially for leadership and finance conversations.

There are costs the business should absolutely try to eliminate.

Things like:

repeated manual intervention on unstable components
professional services spent compensating for poor operational control
paying for underperforming service providers without getting the contracted value
troubleshooting time caused by undocumented variance
support volume created by preventable deployment mistakes

Those are avoidable costs, or at least reducible ones.

But there are also costs that are simply part of maturing a software business.

Things like:

replacing deprecated dependencies
redesigning deployment paths
introducing monitoring and alerting
centralizing source control and environment management
modernizing critical parts of the architecture
training teams to work in a safer, more scalable way

Those are not accidental expenses.

They are the price of remaining operable as the company grows.

Treating them as surprising overhead is how organizations stay trapped.

The most expensive choice is often delay

This is the part I think many businesses discover too late.

When leaders postpone remediation because the spending feels large, they are still making an investment decision. They are investing in continued fragility.

Delay has a return profile too.

It buys:

more downtime risk
more customer frustration
more operational labor
more difficulty launching strategic work
more reluctance inside the team to make changes confidently

In other words, inaction is not free.

It is just financed through slower delivery, preventable incidents, and missed opportunity.

Why phased remediation works better than heroic transformation

I am skeptical of remediation plans that read like one dramatic act.

The better pattern is usually phased, especially in risk-sensitive organizations.

Small steps. High value. Deliberate sequencing. Maximum de-risking.

That sounds conservative. In practice, it is what allows momentum to survive.

I would rather see a company do five grounded things well than announce one total reinvention and spend a year deepening confusion.

For older systems, the practical sequence is often something like:

make the current state more visible
centralize source and dependency management
reduce environmental variance
create safer development and staging loops
automate the repeatable paths
modernize the architecture in bounded slices

That sequence is not exciting, but it respects reality.

Leadership has to fund the future, not just the present

There is a mindset shift here that matters.

If leadership sees modernization only as cost containment, the ambition will usually be too small.

The stronger framing is that remediation buys capacity.

It buys the ability to:

keep commitments more reliably
onboard customers with less operational stress
release with less fear
reduce reliance on hard-to-replace tribal knowledge
give product and revenue work a healthier platform underneath it

That is not just maintenance.

That is business enablement.

The IT treadmill is real

There is one more uncomfortable truth here.

Even after a serious remediation program, the work is not over forever.

Protocols change. Vendors deprecate features. Libraries age out. Security expectations rise. Operating systems move on.

This is normal.

I think organizations get into trouble when they keep treating updates as exceptional disruptions instead of ongoing budget realities. A healthy platform budget should assume that some amount of modernization is continuous.

Not because the team failed.

Because software lives in a moving environment.

My takeaway

Technical debt remediation should not be sold as housekeeping.

It is a capital allocation decision about what kind of business the company wants to be able to run two years from now.

If the current platform is constraining delivery, trust, and growth, then remediation is not a side project competing with the business. It is part of the business finally funding the conditions it needs to keep scaling.

That is the real argument.

Not “we should clean this up someday.”

But “we need to invest in a platform that stops charging us interest on every move.”

This is the last post in the series. The first two were When Product Velocity Becomes a Growth Tax and Why Manual Deployments Keep Legacy Teams Stuck.

When Product Velocity Becomes a Growth Tax

Tue, 05 Dec 2023 09:00:00 +0000

One of the more expensive patterns in software is this: a company grows because it moves quickly, then later struggles because it kept moving the same way for too long.

I have seen this most clearly in older product companies that were built by smart, determined people making rational decisions under pressure. A founder writes the first version. Customers arrive. Custom features get added. A few shortcuts are taken because the business needs momentum more than elegance. Then the team grows, the customer base grows, the environments multiply, and the operational model quietly stops scaling.

That does not usually look like a strategy problem at first.

It looks like missed deadlines. It looks like frustrated leadership. It looks like a team that supposedly needs to estimate better.

But very often the deeper issue is simpler: the organization is still trying to buy velocity using methods that now create drag.

The original shortcuts were often reasonable

I think this matters, because teams are too quick to moralize technical debt.

Many of the decisions that later become expensive started as good business decisions.

If you are a growing software company in the early years, shipping quickly is not optional. You need customers. You need proof. You need cash flow. You need the product to keep moving.

That usually leads to choices like:

customer-specific customizations
infrastructure built one environment at a time
manual deployment habits that rely on trusted individuals
configuration embedded too close to code
process light enough not to slow urgent work down

That can work for a while.

The problem is that those decisions compound. And once they compound far enough, the organization stops getting speed from them.

It starts paying interest instead.

The warning sign is usually operational, not architectural

When a company says, “we are struggling to keep commitments,” the instinct is often to inspect planning first.

Sometimes that is correct.

But if the team is supporting product issues, customer-funded custom work, roadmap initiatives, and modernization efforts all at the same time, planning is only one layer of the problem. If every environment is a little different, if releases are manual, if production fixes depend on tribal knowledge, and if custom features are poorly mapped, then the delivery system is already carrying too much hidden variance.

That kind of variance does not show up neatly in a sprint board.

It shows up as:

longer troubleshooting cycles
defensive estimation
support interruptions destroying planned work
leadership hearing commitments that were never structurally realistic

This is one reason I do not believe an agile coach, by themselves, can solve a system like that.

Agile can improve visibility. It can improve flow. It can improve conversations.

But it cannot cancel out environment drift.

Growth gets harder when every customer becomes a partial fork

One of the hardest scaling traps for older products is customer-specific drift.

At first, it feels like responsiveness.

You say yes to an enterprise request. You implement something valuable. You help close or retain revenue. That can be exactly the right choice.

But if the implementation model becomes “add one more custom behavior, one more schema difference, one more environment-specific deployment path,” then eventually the product stops behaving like a product and starts behaving like a family of loosely related installations.

That changes everything.

Testing gets harder because you are not really testing one system anymore.

Releases get harder because every change has to survive a wider, murkier set of permutations.

Onboarding gets harder because new engineers are learning not just a codebase, but a historical record of customer-by-customer divergence.

At that point, the company may still be calling itself fast. But it is doing fast-looking work on top of a slow-moving substrate.

The team is not slow. The system is expensive

This is the sentence I wish more leaders were willing to say out loud.

When a development team looks inconsistent, the cause is not always capability. Sometimes the system they are operating inside is charging them too much for every change.

If developers are working across environments that do not match, touching production-like systems to understand basic behavior, or spending days reconciling code and database mismatches, that is not a motivation problem.

It is a cost-of-change problem.

The same is true when direct server access is part of the normal workflow.

That setup may look faster because it removes ceremony. In reality, it pushes quality control, traceability, and operational safety back onto individual memory and caution. That trade gets worse as the business grows.

The real ceiling is not technical. It is commercial

What makes this pattern serious is that it does not stay inside engineering.

Eventually it reaches the commercial edge of the company.

Customers who were used to frequent updates start feeling instability. Custom work takes longer to deliver. Roadmap work competes with support work more aggressively. Expansion into new markets slows because the platform underneath the business is too fragile to carry more load confidently.

That is when technical debt stops being a developer complaint and becomes a growth constraint.

I think that is the frame leaders need most.

Not “the code is old.”

Not “the team needs to work differently.”

But: “the current operating model is now taxing every future move the business wants to make.”

What I would focus on first

If a company finds itself here, I would resist the urge to start with a grand rewrite story.

The first job is to reduce variance and recover control.

That usually means:

understanding how environments actually differ
centralizing source control and deployment logic
separating configuration and secrets from code
limiting direct production changes
making customer-specific differences more explicit than accidental

Those are not glamorous steps.

They are foundational ones.

You do not modernize a delivery system by declaring a new architecture and hoping the old operational mess becomes irrelevant. You modernize it by making the current system more knowable, more repeatable, and less dependent on memory.

My takeaway

Velocity is one of the best things a young software business can have.

It is also one of the easiest things to counterfeit.

If speed comes from undocumented variation, manual heroics, and an ever-growing number of exceptions, that speed has an expiry date. Eventually it becomes a tax on the very growth it once enabled.

That is the trap.

The goal is not to regret the early decisions forever. The goal is to recognize when the business has outgrown them and to invest accordingly.

This is the first post in a short series. The next one is more operational: Why Manual Deployments Keep Legacy Teams Stuck.