Nontechnical Phenomena
That Lead to Technical Debt

Even when we deploy carefully designed packages of technical process improvements, those changes cannot address all the effects of nontechnical causes of technical debt. What are those nontechnical phenomena, and why can't technical process design mitigate their effects?

In many organizations, the engineering or IT organizations (the "technologists") are responsible for devising a rational program of technical debt management. And on the surface, allocating that responsibility to them seems reasonable. But the programs they devise can succeed only if the technologists also have the authority necessary to require adjustments in the operations of organizational elements outside their span of control — an inherently paradoxical requirement.

Nontechnical Phenomena that Lead to Technical Debt

A giant wave, like the crest that forms when a tsunami comes ashore. Technical debt is like a tsunami. In the deep ocean, or where the margin for error in steering the enterprise is wide, we hardly notice the wave. But in shallow waters, or when the margin for error in navigation is small, the wave crests, and steering the enterprise away from danger is difficult indeed. When resources are plentiful and market competition is weak, technical debt doesn't matter much. But when resources are dear and market competition strong, technical debt is dangerous.

Although some of the causes of technical debt lie within the technologists' span of control, other causes lie beyond it — some within their span of influence, and still others lie beyond even that. In other words, important phenomena contributing to the formation and persistence of technical debt lie beyond the technologists' ability to influence them. Worse, these phenomena have consequences far beyond the ability of technical processes to mitigate. The result is that technical process improvements intended to achieve rational control of technical debt portfolios often seem to be failures, even though they're actually successful within their domains of potential effectiveness. They appear to fail because they cannot, in principle, address all important causes of technical debt.

This program explores some of these nontechnical phenomena. We outline how they operate; how their presence can lead to the formation and persistence of technical debt; and what is required to mitigate their effects. This set of phenomena isn't exhaustive, but in most organizations, they probably have the most significant consequences. Examples include:

Undervaluing technical debt management
The overall level of technical debt present in enterprise assets is a reflection of the importance the enterprise culture places on rationally managing its technical debt.
Inadequate communication of long-term strategy
To ensure alignment of its long-term strategy with technology planning, senior management must communicate its long-term strategy to enterprise technologists.
Inadequate communication of technology trends
To ensure the feasibility of technical components of enterprise long-term strategy, technologists must clearly communicate the degree of alignment between enterprise technological assets and current and developing technology trends.
Team composition instability
Technical debt can arise when team composition is unstable. Team composition integrity is essential for tracking "clean-up" activity as project reach their objectives. Because the team's understanding of the problems it has solved is clearest at project's end, teams that maintain their integrity have the best chance of recognizing possible improvements based on that understanding.
The Dunning-Kruger effect
The Dunning-Kruger effect causes competence and confidence to be inversely correlated, and it causes us to confuse competence with confidence. As a result, less-technically-competent decision makers might discount the warnings and resource requests of technologists who advocate for rational technical debt management.
Performance management system biases
Performance management systems typically include goal-setting exercises. When we set goals without regard for the consequences for the technical debt portfolio — as they might be, for example, in Sales or Finance — the effects of excellent performance on that portfolio are inevitably harmful.
Knowledge deficits during contract negotiations
When the enterprise expands by acquisition, technical expertise is required to determine the current portfolio of technical debt in the entity to be acquired, and to determine what that portfolio would become post-acquisition. But as debt accumulates, the very people who possess that expertise are likely to become less and less available for contract negotiation support.
Featurism: Unbalanced concern for capability vs. sustainability
Customers and users of enterprise products and services tend not to be aware of the sustainability attributes of the products or services they use. By contrast, they tend to be very much aware of the capabilities of those products and services. It's no surprise, then, that customers and users press for capabilities, but rarely press for sustainability. Some organizations adopt an analogous imbalance, believing — mistakenly — that they're responding to customer needs. This phenomenon is facilitated by an imbalance in the power relationships of some organizational elements.
Unrealistic optimism: the planning fallacy and the n-person prisoner's dilemma
A cognitive bias called the planning fallacy causes project champions to underestimate costs and schedules — and overestimate benefits — for the projects they champion. And when competing with other project champions for scarce enterprise resources, they're caught in a variant of the prisoner's dilemma, which exaggerates their errors.
Organizational psychopathy: career advancement by surfing the debt tsunami
Some decision makers are so ruthless that they're willing to make decisions that greatly expand the organization's technical debt, because they know that the harm they cause will become evident only long after they've departed for their next position. I call this "surfing the debt tsunami."

Learning objectives

The learning objectives of this program include:

  • What technical debt is — and is not
  • How technical debt places enterprise success at risk
  • How technical debt elevates operating costs and extends time-to-market
  • Examples of nontechnical causes of technical debt
  • Why the nontechnical causes of technical debt can overwhelm purely technical process improvement efforts
  • How to mitigate the effects of the most significant nontechnical causes of technical debt

We show that making real progress toward rational control of technical debt is possible only by means of coordinated effort that involves almost everyone in the organization. Our purpose is to help organizations avoid making commitments to technical debt control objectives that might be unrealistic. Effective avoidance strategies depend on your role.

Nontechnical leaders
Nontechnical leaders face a most difficult challenge. Nontechnical leaders include those who lead (or advise those who lead) Marketing, Sales, Financial, Human Resources, and other organization elements beyond Engineering and IT. They must find ways to motivate the people of their organizations to recognize their own contributions to the problem of technical debt, when those contributions are indirect and generally invisible. We show in this program how to demonstrate the importance of these effects, and what kinds of adjustments are necessary to gain control of technical debt.
Technology leaders
Technology leaders are typically the first to sound the alarm regarding technical debt management. And because technical debt is widely — and inaccurately — believed to have purely technical causes, technology leaders are often charged with solving the problem solely within their own organizations. We show in this program that this is a setup for failure. And we provide persuasive arguments to help technology leaders reposition the technical debt management problem as an organizational issue that requires both technical and nontechnical elements in its solutions.

Learning model

We usually think of technical debt management activities as rather technical — free of emotional content. We hold this belief even though we know that our most difficult situations can be highly charged. That's why this program uses a learning model that differs from the one often used for technical content.

Our learning model is partly experiential, which makes the material accessible even during moments of stress. Using a mix of presentation, simulation, group discussion, and metaphorical team problems, we make available to participants the resources they need to make new, more constructive choices even in tense situations.

Target audience

Because anyone in the organization can make choices that lead to incurring technical debt, this program is designed for everyone. We use examples and exercises that show how anyone — absolutely anyone — can contribute to technical debt formation, and therefore anyone can make changes in the way they work that then lead to reductions in the size of the technical debt portfolio.

Program duration

Available formats range from a one-hour survey to a full day. The full-day format provides optimum value as an organizational introduction to technical debt management.

Follow Rick

Send email or subscribe to one of my newsletters Follow me at LinkedIn Follow me at X, or share a tweet Subscribe to RSS feeds Subscribe to RSS feeds
The message of Point Lookout is unique. Help get the message out. Please donate to help keep Point Lookout available for free to everyone.
Technical Debt for Policymakers BlogMy blog, Technical Debt for Policymakers, offers resources, insights, and conversations of interest to policymakers who are concerned with managing technical debt within their organizations. Get the millstone of technical debt off the neck of your organization!
What People Say About Rick's Programs
  • "Rick is a dynamic presenter who thinks on his feet to keep the material relevant to the group."
    — Tina L. Lawson, Technical Project Manager, BankOne (now J.P. Morgan Chase)
  • "Rick truly has his finger on the pulse of teams and their communication."
    — Mark Middleton, Team Lead, SERS
Ebooks, booklets and tip books on project management, conflict, writing email, effective meetings and more.
Comprehensive collection of all e-books and e-bookletsSave a bundle and even more important save time! Order the Combo Package and download all ebooks and tips books at once.
If your teams don't yet consistently achieve state-of-the-art teamwork, check out this catalog. Help is just a few clicks/taps away!