How To Explain Technical Debt To Executives. Hint: It’s Not Technical.
Every engineer I know has, at one point or another, complained to me about some crazy client or stakeholder who is asking for a feature that the software they lovingly crafted for them was never intended to do.
And every business person I know, whether an entrepreneur or corporate leader, has, at one point or another, complained to me about these stubborn diva engineers who, when asked to implement the tiniest new feature, throw up their hands, and say, “whoah! we’ll have to completely rewrite the system to accommodate your request! That’ll take months.”
From this scenario arises a very basic conflict that is ever-present in technology work. Business people, upon hearing this push-back, start worrying about the potential incompetence — or at least intransigence — of the engineers on their team. And the engineers start thinking of the business people as crazy, irrational toddlers who simply don’t understand how the world works.
What Is Technical Debt?
“Technical Debt” is an emergent condition present in any digitally-enabled business enterprise that has now discovered its technology is too rigid to accommodate new business objectives that have come to light. It is too rigid because of past system design and architecture decisions that were made, usually with the best intentions, based on the engineer’s knowledge of business objectives that were available at the time.
No technology can do everything. In order to design a system for any particular purpose, engineers must make a series of design choices — or trade-offs — along the way that, as a necessary consequence, sacrifice other choices that could have been made at that juncture. Good engineers try as a professional point of pride to keep as many options open as they can in the technology for as long as possible. They know that requirements will change, and they try mightily to preserve flexibility, if for no other reason than to save their own sanity when inevitably requirements change. And change they always do.
But eventually, the system must be optimized for a particular set of business objectives and at the expense of others. In other words, we future-proof, to the best of our ability, but we ain’t got a crystal ball.
Why Is Technical Debt Important?
The only reason to build technology at all is to automate a manual process for some human purpose. While we could include non-profit and public sector examples here, the vast majority of technology is built for profit-seeking businesses. So those processes have a business purpose.
Automating a business process requires knowing everything about the business that is relevant to that particular process. But businesses change. Customers want different things. Competitors come along with new capabilities that we have to copy them in order to keep up (maybe). Partnerships and mergers arise where we need to replace one system with another slightly different system that does more or less the same thing. All of this variation puts pressure on the original design of the system that is automating the business process in question.
Software can be made to be quite flexible to change. But that flexibility comes at a cost. It takes time and care to make a flexible system, and that time is in direct conflict with the pressures from the business to meet customer needs ASAP.
Where Does Technical Debt Come From?
Technical Debt is not actually a technical problem. It manifests as rigidity in a technology system, sure. But it is actually a byproduct of a process and communication problem, which themselves are rooted in culture problems within the organization.
Organizations that are highly siloed, where the developers, product managers, designers, and other functions tend to work in isolation, are much more likely to suffer from technical debt. This is because decisions made by engineers in the code — decisions that are making explicit trade-offs in favor of one direction over another — are so many layers removed from the actual needs of the customer. The customer need is translated through these layers from one hand to another, and in the process the richness and fidelity of the customer need is lost. The engineer then does their best to interpret the needs of the customer, but sometimes gets it wrong.
In addition, work is often removed from its business and strategic context. Leadership makes demands on the product organization based on some mystified business strategy, usually with little in the way of measurable goals. The product managers then have to interpret that strategy into technical requirements, and instruct designers to build experiences that meet those goals. Finally, at the end of the telephone game, engineers get some design mocks and poorly written user stories and have to make sense of them in order to make the product real. Much misinterpretation can occur in this kind of arrangement.
In other words, technical debt occurs more often in businesses where there is a lack of trust and a lack of teamwork and collaboration.
How To Bring Engineering And Business Together.
Given that technical debt arises from human communication problems, and not in fact any technical problem, the first component of the solution is to stop focusing on the software altogether and instead focus on the culture of the organization. Everyone is happier when they have the trust of their peers. And happier teams produce better business outcomes.
We should focus on closing the gap between the engineering and business cultures within the organization. Engineers who have a clear sense of empathy with the customer tend to make better decisions about the technical design of the systems they are building. Business leaders who trust their engineers to make more decisions don’t have to focus on micro-managing the development of features that go into the product. Micromanagement doesn’t serve anyone, and yet it is very hard for management to let go of control if they don’t trust that customers needs will be adequately addressed by engineering teams.
We should put systems in place that enable the engineering teams to have direct contact with customers, and place the different functions (engineering, design, and product management) into dedicated cross-functional teams. Business leaders should specify the business objectives required, but leave the implementation specifics to the team.
Engineering teams should learn to articulate system design decisions in terms of concrete and measurable business impact. If their choice of design pattern or technology doesn’t have a verifiable business outcome tied to it, it should be classified as waste.
Technology leaders should be trained to leverage their bilingual skills between the business leadership culture and the technical engineering culture, and work to create more opportunities for trust-building collaboration and information sharing between the clusters and layers of the organization.
