Your technology team reports 80% completion. Your project tracking dashboard is nearly all green. Your quarterly demos are well-attended. Everyone feels like progress is being made. And yet your strategic initiatives are wasting millions of dollars.
This isn’t fiction. It’s a scenario that I’ve seen play out many times at Fortune 500 companies, mid-market enterprises, and startups alike. Teams are working hard, hitting their milestones, and delivering exactly what was asked of them. The problem is that what they were asked to accomplish had nothing to do with creating business value.
Mark Twain (or Samuel Clemens if you prefer) once said, “Never mistake motion for progress.” In today’s enterprise technology landscape, that wisdom has never been more relevant, or more frequently ignored.
In this article, we’ll cover:
- The four warning signs that your technology initiatives are creating motion, not progress
- Why a SaaS transformation that hit every technical milestone still destroyed the business model
- The organizational dysfunctions that cause teams to optimize for looking busy instead of creating value
- Five questions to ask now that separate value-creating initiatives from budget-burning progress theater
The warning signs: When progress becomes theater
CEOs should be alarmed when they see these patterns emerge in their technology initiatives:
Teams report completion metrics without business outcomes
Your project dashboard shows “80% complete” or “on schedule,” but when you press your CTO or VP of Engineering on what business capability will exist at 100% in production, you get vague answers about “improved this and that” or “modernized something.”
Meanwhile, the business metrics you actually care about – customer retention, time to market, revenue funnel, operational costs – remain unchanged or in the worst case, even degrade.
Technology choices drive business decisions
Your initiatives are defined by technology implementation: “Migrate to microservices architecture,” “Implement AI capabilities,” “Deploy the new monitoring platform across all systems.”
Rather than business outcomes: “Reduce customer-impacting outages by 40%,” “Launch new products in two weeks instead of six months,” “Decrease customer service costs by 30% while maintaining satisfaction.”
Demos show features, not value
You attend regular demonstrations of technical progress – new dashboards, deployed services, completed integrations. But these demonstrations never answer the fundamental question: “What can we do now that we couldn’t do before?”
Your stakeholders leave satisfied that they’ve seen “work happening”, not realizing they have not seen any value creation.
Budget gets consumed without a clear path to ROI
You’ve invested millions in “strategic initiatives” that started with compelling business cases, but as the project progresses, that original business justification is nowhere to be found in the technical implementation goals. The technology has become the goal for all intents and purposes.
Your teams celebrate completing work that was never actually tied to measurable outcomes.
The common thread? Organizations confuse activity with achievement. Your teams are busy and your dashboards show progress but your business isn’t getting stronger.
The DevOps transformation that improves nothing
Let me start illustrating this idea with a hypothetical. Imagine you’re a Fortune 500 company launching a major DevOps transformation initiative. You’ve got a clear and important goal: accelerate time-to-market for new features and reduce production incidents. You’re going to invest multiple millions over 18 months.
Here’s how you should approach it:
First, identify the specific bottlenecks in your development and deployment process that actually slow down business outcomes. Is it that your deployment process takes three weeks when it should take three days? Is it that 40% of your production incidents come from one particular service or integration point? Is it that your best developers spend 60% of their time on operational tasks instead of building new capabilities?
For each bottleneck, instrument the metrics that matter: deployment frequency, lead time for changes, time to restore service, change failure rate. Then implement automation and process changes specifically targeted at these constraints. Measure improvement in business outcomes: how much faster can you respond to market opportunities? How much more reliable is the customer experience?
That’s the approach that creates actual business value.
Here’s what you don’t do:
Launch a DevOps transformation without first identifying which parts of your development and deployment process are actually constraining business outcomes. Instead, you deploy infrastructure, monitoring, and automation tools across all teams without understanding what problems this solves for them. You track progress by “percentage of teams migrated to the new toolchain” and celebrate each team that adopts the tools.
You can report steady progress: “15 of 40 teams migrated,” “30 of 40 teams migrated.” Leadership sees numbers trending toward 100%. Everyone can see that work is happening, that the initiative is advancing.
But eighteen months and several million dollars later, time-to-market hasn’t improved. Production incidents haven’t decreased. Costs have actually gone up because you’ve automated processes that were already efficient while ignoring the real constraints. Teams are using new tools to deploy software at the same speed, with the same error rates, at higher operational cost.
Motion? Absolutely. Progress? None. Value? Zero.
I wish I was making this up, but the pattern repeats across industries and company sizes…
The SaaS transformation that made the economics worse
A real example now: A software company was attempting a fundamental business transformation: from selling enterprise software on CDs for installation in customer data centers to becoming a SaaS company. This should have unlocked entirely new economics and capabilities. The board was excited. Investors were watching. This was the future of the business.
Here’s how they should have approached it:
The fundamental economics of SaaS depend on multi-tenancy – the ability to use one set of infrastructure to serve needed the ability to use one set of infrastructure to serve 10, 50, 500 or 10,000 customers. That’s what makes SaaS profitable and scalable. Without multi-tenancy, you’re just hosting software for customers instead of letting them host it themselves. The entire business model depends on this architectural shift.
Here’s what they did instead:
They modified their installer so it could deploy into Amazon Web Services. They successfully moved their infrastructure to the cloud. Technically, they achieved “cloud deployment.” From a project management perspective, everything looked great. They were hitting milestones. Demos showed the application running in AWS. Leadership could see the progress on every dashboard. Progress! (Or is it?)
But in fact, they still ran everything exactly as it would have run at the customer site, just in the cloud. Every customer still had their own dedicated servers. For every new customer, they had to provision a complete set in infrastructure – three or four servers minimum. Their cost structure was actually higher than the old model.
The breaking point came when they had to stop selling to new customers. It was literally costing them more money to provision and run each customer than they received from the recurring revenue. Despite “making progress” with cloud deployment – and hitting every technical milestone – they’d actually made their business economics worse.
The technology team had delivered exactly what was asked: move the infrastructure to the cloud. They’d completed the project successfully. But nobody had asked whether the cloud migration would enable the fundamental business model transformation that SaaS requires. The initiative was defined by a technology goal (cloud deployment) rather than a business outcome (SaaS economics).
The mobile app that had to built twice
Another true story: During the mobile-first stampede of the 2010s, a mid-market SaaS company decided they needed a mobile app. Not because they’d identified specific business value. Not because customers were demanding it. But because every competitor was building one, every conference speaker was talking about mobile-first strategy, and the market seemed to demand it.
Here’s how they should have approached it:
Start by understanding the business outcome you’re trying to achieve. Will mobile access increase customer engagement? Reduce churn? Enable a new use case that drives revenue? Then identify which specific features or workflows would actually create value in a mobile context – not just port desktop features to a smaller screen. Define success metrics: if this works, what specific business numbers will improve, by how much, and by when?
What they did instead:
The CEO personally designed the app “to look pretty.” There was no user research, no analysis of what features would drive revenue on mobile. No hypothesis about how mobile access would change customer behaviour. They hired a development company and spent significant money building it. The application was successfully delivered on time and on budget. They had something to show at the next board meeting, something to announce to customers, something to put in marketing materials. Progress!
Unfortunately, they soon discovered the app was completely useless. The CEO had designed it without understanding who would use it or what users actually needed. And guess what? It didn’t do what their users needed. They had to rebuild the entire application from scratch with a different vendor. They essentially doubled their investment to get something that worked – something that actually created business value instead of just checking a box.
Today I see echoes of this story as companies rush to implement AI capabilities, adopt cloud-native architectures, or build streaming data platforms without connecting these initiatives to concrete business outcomes. The technology changes, but the pattern of “progress without value” remains the same.
If you can’t explain to your board exactly what business outcomes you’re creating and how you’ll measure success, you’re not ready to start.
The repeating anti-pattern
This is how progress becomes theater. Teams can report completion percentages – 14 of 30 systems instrumented, 25 of 40 teams migrated, 80% of infrastructure in the cloud. Leadership sees numbers trending toward 100%. Everyone can see that people are busy, that work is happening, that projects are advancing.
It’s like a brick layer telling you his percent complete based on how many bricks he’s laid today. That tells you nothing about when your house is going to be livable, it just tells you that the brick layer was busy today.
There is an anti-pattern at work here. It can be summed up with:
- Technology initiatives started without clear business outcomes.
- Implementation plans not tied to any delivered business value.
- Teams celebrated completing technical work.
- Leadership accepted “progress” without demanding value.
- Substantial capital wasted.
And more importantly: time lost in competitive markets where your competitors may have gained advantage while you were busy looking busy.
Why this keeps happening
Understanding why this pattern persists requires looking at some deep organizational dysfunctions.
Engineers aren’t given business context
In most industries, you let experts determine implementation. If you go to a restaurant and order chicken noodle soup, you don’t tell the chef what ingredients to use, how long to cook it, when to stir it. You say “I would like chicken noodle soup,” and the chef makes it.
Technology is uniquely different. Customers don’t come to the engineering team and say “I want chicken noodle soup.” They say “I want you to get a chicken, and I want you to get some noodles, and I want you to get some stock, and I want you to mix it all together.”
They don’t actually say it should taste good – that’s just implied – but if it doesn’t taste good, they will let you know.
“Well, I used the chicken you told me to use.”
“Well, you should know better.”
The historical belief that engineers aren’t real people
I think this started with the notion that engineers aren’t real people and they’re not capable of understanding the business side of things. So you have to be very specific with them and break things down into very technical terms. Once you do that, you’re treading into the design space, into the engineering space. You’re telling them how to do their job.
But if there’s anything the world should have learned over the last 30 years, it’s that not only are engineers people too, but if you give them the context for what you’re trying to do and the reason for it, they will actually be a hugely valuable partner in the process.
The three worlds problem
Think of it this way: Out in customer land, in sales, in the business, you have the World of Desire – people who want things. Then, standing apart from that, you have the World of Possibility – where engineers are. These two worlds are in different places in space and they speak completely different languages. They can’t really talk to each other.
So there’s a third world that sits between them: the World of Choice. This is where business analysts and product managers sit. When this is all working well, the World of Possibility has as much to say as the World of Desire. Engineers contribute to what gets built, not just how it gets built.
When it breaks down, that translation layer becomes a specification layer. Engineers become order-takers. And you get expensive implementations of bad specifications.
False confidence from democratized information
These days, anyone can ask ChatGPT or Claude for a system architecture. You can take that architecture, hire a developer off Guru, and say “Build me this.” They will build you exactly that, and you’ll probably be unhappy with it.
But if you went to that same developer and said “Look, I need to build a personal CRM. I want you to partner with me. I’ll tell you what I want. You build it. I don’t care how you build it, as long as it does what I want,” you’d get a much better product.
The difference is that in the second scenario you’re ceding control over how it gets done. For whatever reason, people don’t like to do that, especially with intangible things like software.
How to escape the progress illusion
The fix isn’t complicated, but it requires discipline.
Identify your critical business processes
List the three to five processes that directly generate revenue or mitigate existential risk. For financial services: loan origination, loan closing, loan servicing. For SaaS: customer acquisition, onboarding, retention. For retail: inventory management, point of sale, fulfillment.
These are your investment priorities. Technology initiatives should focus here first.
Define success in business terms
No: “Deploy observability platform across all systems.”
Yes: “Reduce customer-impacting outages by 40% within 12 months.”
No: “Migrate to cloud infrastructure.”
Yes: “Enable launching new products in two weeks instead of six months.”
No: “Implement AI capabilities.”
Yes: “Reduce customer service costs by 30% while maintaining satisfaction scores.”
Apply theory of constraints thinking
Within your critical processes, where do failures actually occur? If historical data shows 40% of your outages come from the e-signing service, that’s where you start. Not with comprehensive rollout across everything.
Orient work around outcomes, not activities
Work descriptions must state the benefits created, not just mechanical tasks that have to be completed. Engineers need business context if they’re going to be effective partners. Allow them autonomy over how things get implemented. And then judge the results by business metrics, not completion percentages.
Demand value demonstrations
Regular demos should answer: “What can we do now that we couldn’t before?” Not “Look at this dashboard we built,” but “Here’s how this dashboard enabled us to detect and fix an issue before customers noticed.”
The questions to ask tomorrow
Whether you’re evaluating a new technology initiative or checking on existing ones, these questions will tell you if you’re creating value or just creating motion.
For Every Technology Initiative (New or Existing):
- “If this project completes successfully, what will our business be able to do that it cannot do today?” If the answer is vague or technology-focused, that’s a red flag.
- “What specific business metric improves, by how much, and by when?” If there’s no clear metric or timeline, that’s a red flag.
- “Which critical business process does this address, and why is it a priority over others?” If the answer is “all of them” or references technology standards rather than business priorities, that’s a red flag.
- “Have we given the engineering team the business context and autonomy to determine implementation?” If engineers are executing detailed specifications from the business side, that’s a red flag.
- “When you demo progress, do you show business value or technical completion?” If demos focus on features built rather than capabilities enabled, that’s a red flag.
If any initiative triggers multiple red flags, it’s time for a hard conversation about whether to continue, pivot, or shut it down.
Progress is easy, value is hard
It’s easy to look busy. It’s easy to report completion percentages. It’s easy to demonstrate technical work.
It’s hard to connect technology to business outcomes. It’s hard to measure real value. It’s hard to admit when initiatives aren’t delivering.
Your competitors face the same challenges. The ones who solve them gain sustainable advantage.
The difference comes down to CEOs who demand that every dollar spent on technology must deliver measurable business value. Your role isn’t to understand the technology. Your role is to ensure technology serves business strategy, not the reverse.
Start tomorrow by asking the questions above. The answers will tell you which initiatives are delivering value and which are burning money while looking productive.
Because at the end of the day, if you don’t have the ability to do something you didn’t have the ability to do before, you haven’t transformed anything. You’ve just upgraded your tools. And expensive tool upgrades don’t create competitive advantage.
Can you confidently answer the five questions in this article for every technology initiative in your organization? If not, Ten Mile Square’s technology assessment can help you separate the projects creating real business value from the ones creating expensive theater. Learn about our assessment approach.