The Three Year Cycle of Tech Debt

 

I’ll admit upfront, this post carries a slightly cynical tone, but it’s grounded firmly in experience. I’ve observed what I call the “Three-Year Cycle of Tech Debt” happening at nearly every major corporate IT organisation I’ve worked at.

What exactly do I mean by this?

In corporate IT, tech debt accumulates primarily due to the incentives and pressures placed on project managers. A project manager’s core objective is simple: deliver assigned projects on time, every time. Their evaluations, career progression, and even jobs/contracts hinge solely on timely project completion, not on long-term system sustainability.

Given these incentives, project managers naturally prioritise immediate results over future maintainability or standards. Consequently, they regularly make compromises, accompanied by familiar justifications such as: “We’ll fix that later,” or “Let’s deploy it now, and we’ll address the issues retroactively.”

But, we all know these promised future fixes rarely materialise. The reason? The subsequent projects, managed by yet another PM under the same constraints, face identical pressures. Thus, the can gets kicked even further down the road.
This process continues unchecked until a significant breakdown or catastrophic system failure forces everyone to finally confront the accumulated technical debt.

Interestingly, there’s often an organisational rhythm to this process, tied closely to executive turnover. High-level tech executives, CTOs or equivalent leaders, frequently rotate about every three years, moving onwards to new opportunities or being recruited to resolve major issues elsewhere.

With each new leader comes fresh motivation and the desire to make a visible impact. Newly appointed executives naturally shine a spotlight on previous inefficiencies or mismanagement. It’s the ideal moment to surface and tackle the accumulated tech debt.

At this time, you’ll often hear cry’s of, “This infrastructure is unacceptable,” or “These issues should’ve been resolved long ago.” Subsequently, radical overhauls and aggressive debt reduction initiatives ensue, reshaping systems “root and branch.”
Yet, deep down, everyone in the organisation seems to understand and implicitly accept this pattern. People grow accustomed to tolerating significant levels of tech debt, comforted by the expectation that sooner or later, the cycle will reset itself with the next executive shuffle.

I still, after 25 years doing this sort of thing, have no idea why people behave like this. Perhaps it’s the relentless focus on short-term outcomes or the cultural insistence that project timelines must never be compromised. Whatever the underlying reasons, the three-year cycle of tech debt is undeniably real and you will find it all over the place.

Recognising this cycle is all fine and everything, but addressing it requires genuine organisational change, aligning incentives not just with immediate results but with sustainable, long-term success, and you as a contractor are not going to be able to do that.

But what you can do, is properly document the true solution as well as a suggested method of getting from the current short term situation to the proper intended solution so that the people that come after you know you did not deliberately leave them with issues and you have helped them as best as you can.

Getting Agile Project Management to work with Fixed Price Goal Based Contracts

 

The integration of goal-based or outcome-driven contracts with agile project management methodologies has become increasingly common, particularly in interactions between large corporations and their vendors.

While this trend may seem like a recent innovation, it’s just a new iteration of a long-standing challenge: balancing flexibility in doing a project (dealing with scope creep, fixing crises, and the like) with the financial certainty that fixed-price contracts provide.

The shift toward goal-based contracts (essentially fixed-price agreements under a new guise ) is primarily finance-driven. The reasons are clear: corporations aim to minimise scope creep and cost overruns.

As project managers, our role involves accommodating these financial constraints while delivering successful outcomes. However, agile methodologies, now the default expectation within many organisations, inherently conflicts with fixed-price agreements (which are better fit to the waterfall methodology).

So how do we reconcile these two seemingly incompatible requirements?

I have found several practical ways to make this work (rather than just saying “Use scaled agile framework (SAFe)” or some other boring reply):

1. Clearly Defined Initial Cost Boundaries
Initially, costs must be explicitly fixed. This non-negotiable stance appeases finance departments, preventing early-stage roadblocks. While we know additional costs might arise later, establishing a firm baseline from the outset is crucial. Once you have got the project started, you can get ready to handle extra costs with separate statement of work agreements, but managers and such can get on with these while real people get on with delivery.

2. Shifting Goal Definitions
A potential (though problematic) solution involves redefining goals as effort-based rather than strictly scope-based, that is, hire a vendor for a defined period of time with a certain number of people to do the job. Although appealing due to its simplicity, this approach may lead to compliance risks (e.g., IR35 concerns 1 ), particularly for smaller vendors, and can diminish vendor motivation as they know they will not be held to account for anything.

3. Breakdown deliveries into Smaller, Goal-Based Items
Another viable approach is segmenting the statement of work into smaller, individually priced items. This method simplifies justification of outcome and billing but can also result in significant administrative overhead and ongoing negotiations.

4. Categorizing Goals by Priority
A beneficial strategy involves dividing goals into mandatory and optional categories. Mandatory goals must be completed first, while optional goals can be adjusted or omitted to accommodate scope creep or unforeseen issues without compromising the fixed-price arrangement.

5. Internal Readiness and Client-Side Accountability
Implementing an internal readiness firewall can protect vendors from being unfairly penalised for client side delays or process inefficiencies. Clearly defined client-side responsibilities and associated SLAs ensure transparency and accountability.
Including explicit provisions for what occurs financially if these SLAs are breached helps maintain fairness.

6. Pre-Approved Contingency (Positive Change Budget)
Creating a “white-listed change budget” of approximately 5-20% of the total cost serves as positive contingency. Unlike traditional contingency funds viewed negatively, this budget is openly acknowledged, pre-approved, and requires minimal paperwork, making it much, much easier and less “finger pointy” to roll with a cost overrun.

7. Streamlined Escalation Pathways
Setting up non-confrontational, rapid escalation channels reduces friction. Both vendor and client teams should have clearly defined pathways for quickly addressing blockers without resorting to finger-pointing or aggressive tactics; this lets you behave far more in an agile way but within a waterfall-style contract.

8. Positive Incentives Rather than Penalties
Contracts should ideally balance penalties with positive incentives, rewarding early deliveries, high test pass rates, and other performance-enhancing milestones. This approach helps collaboration and productivity rather than defensiveness.

9. Separate Internal and External Retrospectives
Conducting internal retrospectives independently from vendor-involved sprint retrospectives can significantly reduce vendor frustration at fixing someone else’s issues while on a tight timeline and enhance internal process improvements. It allows teams to critically evaluate and address internal inefficiencies without placing undue burden on external partners.

10. Be Transparent
Finally, treating a Statement of Work (SoW) as an “outer fence” while operating internally through agile backlog management, fixed team capacities, and friendly releases helps prevent defensiveness, promoting clear, blame-free visibility of progress.

  1. This is a form of UK-based disguised employee legislation []

Delivering: Abstract Project verses Business Product

In the realm of project management, there’s a recurring tension between delivering a project as a neatly packaged entity (basically a number of signed-off documents from a project manager’s perspective) and delivering a project as a truly useful feature for the business.

Now on one side, pure project managers often focus on precise documentation, formal ownership, and clear boundaries. This approach can streamline budgeting, clarify responsibilities, and minimise risk, particularly helpful if something goes wrong.

On the other side, managers with a business or operational background tend to prioritise tangible outcomes that meet real-world needs, even if this requires a less orderly process. This style, while potentially more chaotic, can often produce better, more enduring results for the business.

Both approaches have clear benefits and drawbacks. A strict adherence to process and paperwork can ensure compliance, financial clarity, and an “adequate” solution that meets requirements; this gives you a sound basis to claim payment against goal-based contracts.

However, it may not fully address real business needs.

Conversely, focusing purely on delivering the best business outcome can lead to scope creep, cost overruns, and never getting a sign-off on the project, but it might also generate a more valuable end product that truly benefits the organisation.
In truth, I like a bit of column A and a bit of column B on this. You try to be as flexible to the business needs as you can while staying within your remit, and to this end, if you are honest with the business and say: “Look, we were made to sign this contract with these deliverables by our mutual bosses, and if we don’t do that, we won’t get paid. So please, can we do those first and then come back to the extra and different stuff you want?” it’s very often a good place to try balancing from.

Corporate term: “Busking for Time”

Definition:

Busking for time is the period of waffle or nonsense people, (normally politicians) talk in the hope that a solution or idea will come to them.

Explanation:

While this is mainly a journalistic term used when talking about political discussion, it works just as well for corporate conference calls.
When taken off guard or when concentrating on something else, we all fumble for the right words for an answer but when we are unwilling to admit this and try and fill that gap with nonsense, then we are “busking for time”.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

 

Working Well with Your Corporate Peers: The Basics for Beginners

 

This post is because not only is my own son solidly working his way up the corporate ladder, but I have been lucky enough to recently do work experience with some new starters in the corporate world, and felt that the tips I gave them would work well written down.
Ever notice how some people treat their coworkers like one-dimensional obstacles rather than human beings on the same team? It’s more common than you’d think.
Yet, in most professional settings, you need the help of peers, managers, and subject-matter experts to get things done. Here are a few foundational tips to ensure you build strong, collaborative relationships with those around you, without resorting to office politics or generally being unprofessional.

1. Don’t Build Empires

What does “empire-building” look like? It’s when someone hoards responsibilities, people, and power to climb the corporate ladder at any cost. Sure, it might seem like a fast track to the top, but it usually backfires in the long run.
Why avoid it? People will notice if you’re grabbing for power or credit, and they’ll start throwing up roadblocks. A lot of energy that should go toward delivering results ends up wasted on infighting.
Better approach: Show that you’re there to deliver on your tasks and goals, not to trample others. Collaboration is more sustainable and garners respect.

2. Publicly Acknowledge Help

Why is this important? When you’re working across departments, you’ll rely on others for information, extra resources, or simply the benefit of their expertise. If someone helps you, be vocal about it.
How to do it: At the next team meeting, in reports, or in a conversation with your manager, highlight the support you received. This makes your colleagues feel valued and more likely to help again.
Bonus benefit: You won’t come across as someone who takes all the credit. Instead, you’ll earn a reputation as a team player who appreciates contributions from others.

3. Keep a Fair Tally of Favors

In some places (like in England), there’s a social custom of buying rounds of drinks instead of everyone just buying their own. People mentally keep track of whose turn it is. The same principle applies in the workplace when it comes to favors.
What this means: If you receive help, be prepared to return the favor down the line.
Why it matters: No one likes a freeloader. If you only take and never give, you’ll quickly gain a reputation for being self-serving, and people will be less inclined to support you in the future.

Final Thoughts

Working effectively with your peers isn’t just about delivering projects on time; it’s about fostering an environment where people genuinely want to help each other succeed. By avoiding empire-building, openly acknowledging the help you receive, and keeping fair tabs on favors,
you’ll cultivate relationships that propel everyone forward. At the end of the day, its wins all round.