For technologists who spend much of their time eyes-deep in the tools, platforms, and architectural drivers that great solutions require, it can be easy to feel isolated from the surrounding business. The business goals of the project and the financial context that surrounds and constrains it become, through the necessary processes of business analysis and project planning, several layers removed from the technology team’s internal representation of the project. Components to be built, system and application architectures, UML diagrams, task tickets, and burn down lists may be necessary constructs to run a development project, but they retain little to no understanding of the business context.
Just as the syntax of programming languages by and large lacks the ability to communicate the system architecture, the artifacts of project management and development planning lack the crucial ability to communicate the business context.
This is why the business and technology teams so often feel like separate factions, each harboring gripes about how the other lacks the context to understand the decisions that need to be made. (One beautiful and refreshing aspect of Ai’s culture is that it has the opposite character: we are pretty cozy here, despite our spacious office, and our size helps us to manage and minimize these divides.)
And here’s one big reason why “technical debt” has become a hot topic: it’s a concept that can do wonders to bridge the communication gap that often develops between technology and business teams over the course of a project.
This gap is itself a project risk, and as with all risks, we need to find the right tools to understand and mitigate it. Thus the (justified) popularity of “technical debt”.
But just as “technical debt” is a useful term for mitigating this risk, other terms can broaden or enforce the border around an IT team. One, a term more pervasive in larger organizations, is “the business”. This is how IT project managers often refer to that shadowy side of the organization that issues commands from its isolated realm, dictates that the IT group must translate into actions and project plans.
“The business” will place constraints of budget, schedule, platform on the project. (All too often, these get delivered to us via another unfortunate neologism: “the ask”. “Ask” is a verb. It just is. It’s a verb. When someone drops “the ask” on the meeting table, they’re presenting a hard object with no creator: “the ask” has arrived, ineluctable and undebatable.)
“The business” will make midstream decisions seemingly ignorant of implications to the project’s technological commitments. “The business” also, of course, writes the checks, so we feel we have no absolute leverage.
It is in dealing with these constraints from “the business” that we regularly incur technical debt: to meet a deadline, or to facilitate a sudden change in requirements, we commit to compromises in the code or architecture that we know we’ll need to fix someday. (“Someday”: as with financial debt, technical debt is a tool at your disposal; but you have to fix a date to this payment to keep your debt from ballooning.)
The key lesson here is that we can’t conceive of these decisions as technology decisions. As Steve McConnell notes, “At the end of the day, all [technical] decisions made in this context are business decisions.” The business and technology teams are partners in the success of a project. Business decisions must take technology into account, and vice versa.
We can take it a step further, in fact: there is no “the business”. Each one of us is The Business.
Considering ourselves, the technologists, to be The Business means internalizing that each line of code we write, each component we build, each compromise we make affects the business context of the project, and ultimately the success of the wider organization. What’s the business value of documenting this code? What’s the business value of building this test script? There’s no reason why QA engineers and developers should labor in the absence of this notion of business value. Knowing the business context helps us make intelligent decisions, spend our time and energy wisely to focus on value, not problems or minutiae.
If we erase this construct of a separate “business”, we give the project a huge leg up: now, project direction needs to include business and technological context. Now, we are forced to have cross-disciplinary conversation around difficult decisions. Now, when a high-value and very difficult requirement becomes an architectural driver for the technology team, we can understand and plan around this big hurdle in the context of its overall importance.
The interest in recent years in managing technical debt is just this: an increasing interest in fostering common understanding around difficult technical decisions, and in providing institutional memory of debt incurred so that the organization can agree, and remember, to pay down that debt in the future.