Have you ever heard this before? “I just need a small change to this feature.” Or perhaps: “How hard could it be to add this one thing?” These seemingly innocent requests often trigger weeks of delays, mounting costs and growing frustration across your organization.
What appears as a simple technology hiccup might actually be a warning sign of deeper problems threatening your company’s ability to compete, grow and adapt to changing market conditions.
At Ten Mile Square, we call the process of matching technology problems with their root causes “Technology Pathology.” Understanding the underlying causes – not just treating the symptoms – is critical for any business leader seeking sustainable growth.
Oh, and a toilet plunger can also help…
When simple changes aren’t simple: the warning signs
Why is everything so hard? This is a common refrain I hear from executives when talking about their tech teams: I asked for a simple change and it created all these other problems and issues. You change one thing and something else breaks.
This is the kind of thing you might be seeing:
- Changes that unexpectedly break seemingly unrelated features;
- Problems that are “fixed” temporarily only to reappear later;
- Constant workarounds rather than permanent solutions;
- Features promised to customers that continually slip past deadlines.
The business impact of these symptoms is substantial. When technology teams can’t respond efficiently to business needs the consequences cascade throughout the organization. The downstream effect is that the company loses confidence in its ability to deliver products and the company starts rotting from within.
This loss of confidence can be ruinous:
- Customers grow frustrated with unreliable systems and unresolved issues;
- Sales teams lose faith in the product and start making promises that can’t be kept;
- Product managers hesitate to commit to roadmaps;
- Competitors with more responsive technology organizations gain market advantage;
- Innovation stalls as resources are consumed by maintenance and firefighting.
Technology pathology: understanding the root causes
So now we’ve identified the symptoms and talked about what happens if they’re left unchecked, let’s dig a little deeper and look for the potential underlying causes. We almost always find that they have less to do with technology itself than they do with the organizational patterns that created the technology. (This is an expression of Conway’s Law, which states that the structure of a software system reflects the communication structure of the organization that developed it – in other words, the way your teams are organized and interact with each other shapes the design and architecture of the technology they build.)
Here’s what could be lurking under the surface:
1. Product management issues
It might be that the company changes direction frequently, causing the tech team to thrash around in response to shifting priorities. When product roadmaps are unclear or constantly changing, engineers struggle to build systems that can accommodate these shifts.
I’ve seen cases where the sales team, lacking confidence in the product, makes promises to potential clients: “Yes, that feature is on our roadmap. It’s coming in the next release.” They put it in the contract, but the engineering team learns about it only during the implementation kickoff. “We don’t do this”, they say. “But it’s on your roadmap”, replies the client. The check has been written, now it has to be cashed.
These might only be small changes but the need for the tech team to repeatedly switch between different initiatives can significantly slow down progress.
2. Inflexible and inefficient development practices
Technology releases have fixed costs associated with them in terms of building, testing, deployment, rollback planning, and changing operational procedures. The more inflexible and inefficient your software development practices, the higher these fixed costs will be.
And every change, no matter how small, is subject to this same drag. Without automation and a streamlined release process, even trivial changes require the same heavy process – with all the attendant costs in terms of time and money – as major features.
3. Technical debt accumulation
What technologists call “technical debt” is similar to financial debt – it accrues interest over time, making everything more expensive and time-consuming.
A product is made up of many constantly-evolving components and the rate of change across all these components is high. Problems with one component, left unchecked, cause knock-on effects in other components. Eventually you get to the point where one version just doesn’t work the same as the previous one and you’ve got a job on your hands to figure out why.
This reactive approach is high risk. You don’t know when the big problems are coming, how disastrous they’re going to be to the user experience, how much it’s going to cost to fix them and how long it will take.
When product managers are over-incentivized to add new features to the product rather than address non-functional requirements, technical debt grows. If you don’t budget for maintaining and updating your technology – typically around 20% of your overall technology budget – this accumulating debt slows everything to a standstill.
4. Environment complexity
The environment in which your software runs should be well understood. You should be able to tear it down and rebuild it again in an automated fashion. If that’s not the case, it tells you there are things you don’t know about your systems. This is common in complex setups and is one of the things that leads to high fixed release costs.
I’ve worked with clients who didn’t even have the source code for important components of their systems. Without the ability to understand, document and automate your environment, small changes become high-risk endeavors.
Diagnosing your organization: questions CEOs should ask
So how do you determine if your organization is suffering from these underlying pathologies? Here are the key questions to ask your technology and product leaders:
- Tell me how you build and release our product. Walk me through the steps.
- What parts of this process are automated? What parts are manual?
- Why are the manual parts not automated? Are they repeatable? Are they documented?
- How do you test changes before releasing them?
- How do you prioritize maintenance versus new features?
- Do we have a documented product roadmap with clear business justification?
The answers will reveal a lot about your organization’s technology health. Listen for these warning signs:
- Documentation for the build, test, release, and rollback is not up to date, or missing;
Engineers describe systems as “fragile” or “brittle”; - Reluctance to make changes for fear of breaking things;
- Heavy reliance on specific individuals who are the only ones who understand certain components;
- Lack of automation for key processes (build, test, release, rollback);
- Failed releases with manual rollback;
- Frequent post-release emergencies;
- Sales and support teams creating their own workarounds.
You want to see a progression from manual processes to documented, repeatable processes and finally to automated processes. You go from the “hero” state, where it takes a specific human to do it, to a repeatable process, where it’s documented and somebody knowledgeable could do it, to automated, where it’s run exactly the same way each time.
Building transparency and trust
A fundamental challenge underlying many technology problems is trust. As the late John Sidgmore, former UUnet/WorldCom CEO (and one of the first great CEOs of the internet era) used to say: “Engineers always lie. It always takes longer. It always costs more than they say and it never delivers what they promise.”
While harsh, this perspective reflects a common breakdown in understanding and expectation-setting between business and technology organizations.
I often tell clients that transparency is a benefit for both the people driving the business and for the people who are driving product. But what does transparency look like in practice?
A product plan that supports the business plan
The product plan has to be in sync with the business goals. That means addressing in the business plan promises regarding non-functional requirements. These include retiring technical debt, refactoring old code, cybersecurity, reliability, performance, flexibility, scalability, capacity, and cost, among others.
These non-functional requirements then have to flow into the product plan. Set aside a budget for retiring technical debt, expressed as a percentage of work, so that everybody knows how to prioritize these tasks in relation to new features.
Regular demonstrations of progress
One of the most important rituals of Agile software development is the product demo. Being able to do this proves that you’re able to deliver something of value in a period of work. It doesn’t always have to be a visually impressive user-interface demo – it could be a developer working in an IDE, illustrating how a transaction runs end-to-end – just something that gives stakeholders confidence that progress is being made.
When they can see regular progress, even if it’s not complete, they start to trust in the team’s ability to deliver.
Clear documentation and communication
A good product roadmap should clearly communicate the sequence of work and the business needs being addressed. What good looks like is when someone says…
“So let’s see, last quarter we had this on our product roadmap; these are the things that were delivered; this wasn’t delivered. Why was that?”
And you go back through the documentation you maintain and you find out. When stakeholders understand the relative priorities of the technology initiatives, and how they’re tied to business goals and milestones, you don’t end up with “surprise parties” where deliveries are late and fail to meet expectations.
The plunger story: a practical example
Let me share a practical example that demonstrates the importance of clear communication and transparency. This is from a company that was struggling with technology problems. The company was losing clients, losing money and had been acquired by a private equity investor. We came in to help turn things around.
One of the key issues was the constant interruption of development work by urgent problems. People would walk up to developers throughout the day with issues: “There’s an outage.” “There’s a problem.” “This isn’t working.” These interruptions were killing productivity for the whole technology team.
This was our solution: We went to the store and bought a toilet plunger. Whoever was responsible for dealing with the problems that came up that week had the plunger on their desk. Anyone with an issue could see who had the plunger and go talk to that person. Meanwhile, the other engineers could focus on fixing problems.
Sounds stupid, but it did two things: first, it streamlined the process so there weren’t as many distractions; and second, it gave people confidence they could always go talk to somebody. You’d hear people on the phone saying, “I’ll go talk to my guy who’s on duty. I’ll find out what’s going on and we’ll get back to you.”
This simple visual management approach had an outsized impact by making small change requests and issue resolution easier and more transparent.
The path forward: strategic actions for CEOs
Addressing the underlying causes of slow technology delivery requires a structured approach to assessment and planning. Here’s how to conduct an effective technical assessment that drives business results:
1. Define your current technical state
Begin with a comprehensive evaluation of your technology landscape. This isn’t just an inventory of systems, but a deep analysis of how they function together and the capabilities of the whole:
-
- Document your current architecture, development processes, and release management;
- Evaluate the actual state of your codebase through direct inspection (not just reports);
- Understand operational metrics: deployment frequency, change failure rate, and recovery time;
- Identify areas of high manual intervention that could benefit from automation;
- Assess knowledge distribution within your team (are critical systems understood by only one person?)
2. Analyze the gaps between the business plan and technology
With a clear understanding of your technical capabilities, you can identify where they fall short of business requirements:
-
- Compare growth targets against system scalability limitations;
- Evaluate how quickly your technology organization can respond to market changes;
- Assess whether current architecture can support planned product innovations;
- Identify where technology constraints are limiting revenue or operational efficiency;
- Determine if data capabilities align with business intelligence needs.
Is there a misalignment between business goals and technology capabilities? For instance, a business plan might assume the ability to rapidly test new features with customers, but the current technology state can’t deliver changes quickly enough.
3. Diagnose the underlying causes – the pathologies
Look beyond the symptoms to identify the organizational patterns creating technology problems:
-
- Analyze how product decisions are made and communicated to engineering;
- Examine how technical debt is tracked, prioritized, and addressed;
- Assess team structure and whether it matches the architecture needs;
- Evaluate leadership communication patterns between business and technology teams;
- Identify skill gaps that may be contributing to quality or delivery issues.
These pathologies often follow predictable patterns: unclear product direction leading to constant pivots, insufficient attention to maintenance needs, or communication barriers between business and technology teams. You’ve got to understand these patterns if you want to intervene effectively.
4. Create a plan to address the pathologies
Develop a prioritized roadmap that addresses fundamental issues rather than just symptoms:
-
- Establish a balanced approach between new features and foundational improvements;
- Apply tools such a Theory of Constraints to identify and remediate bottlenecks;
- Create clear governance for technology decisions with business input;
- Implement incremental architectural changes that deliver immediate business value;
- Define metrics to track progress on both technical health and business outcomes;
- Set realistic timelines that acknowledge the complexity of each initiative.
Quick wins build confidence while strategic initiatives address fundamental issues. To keep everyone on board throughout implementation, you need to be transparent about trade-offs and expected outcomes.
5. Define the skills and experience gaps between the plan and the current product and technology team
Finally, assess whether your team has the capabilities needed to execute the plan:
-
- Identify critical skill gaps in both technical and leadership capabilities;
- Determine whether to build, hire, or partner to address these gaps;
- Create development plans for team members with potential to grow into needed roles;
- Establish mentoring relationships to transfer knowledge effectively;
- Consider interim leadership to bridge gaps while building internal capabilities.
This skills assessment should be honest but not punitive. Many teams have the potential to rise to challenges when given clear direction, appropriate support, and the right technical foundation.
A well-executed technical assessment provides the clarity needed to make informed decisions about technology investments. When you understand both the current state and the underlying pathologies, you can build a technology capability that truly enables your business strategy.
Technology debt is business debt
The inability to make small changes quickly is rarely “just a technology problem.” It’s a business problem with technology symptoms. When I conduct assessments, I often identify multiple root causes spanning product management, development processes, technical architecture and organizational dynamics.
The key is recognizing that these problems won’t solve themselves. In fact, they tend to compound over time just like financial debt. A small investment now in diagnosing and addressing the underlying causes will save enormous costs later.
As we found at one company, a simple thing like a plunger – which let people know in a very immediate way how to behave – increased confidence. That increased confidence led to improved product delivery, which led to more satisfied customers and eventually a successful acquisition.
The journey begins with an honest, structured assessment of where you stand today. Remember, symptoms are what you see, but causes are why you see them. By focusing on the causes – not just treating the symptoms – you can turn your technology organization into a reliable engine for business growth rather than a block on innovation.