Technology has never been more accessible.
Cloud platforms can be provisioned in minutes. AI tools are evolving rapidly. Modern frameworks make application development faster. Analytics platforms can provide enormous amounts of data. Almost every business problem appears to have a technology solution waiting for it.
But there is a question I believe technology leaders should ask before choosing the technology:
What business problem are we actually trying to solve?
It sounds obvious. Yet in many technology projects, the conversation starts somewhere else.
“We need an app.” “We should move this to the cloud.” “We need AI.” “We should automate this.” “We need a new platform.”
These may all be good ideas. But they are solutions, not problems.
And starting with the solution can sometimes lead us toward building something impressive without necessarily solving what the business actually needs.
The technology-first trap
I have seen this pattern repeatedly during my technology career.
A new technology becomes popular. The business hears about it. The technology team explores it. A proposal is prepared. A project starts.
And only later do we ask:
What outcome are we expecting from this?
Technology projects require investment — people, time, infrastructure, vendors, licenses, maintenance and operational support. If we cannot clearly explain what business outcome the investment is expected to create, it becomes difficult to measure whether the project was successful.
The technology may work perfectly. The project may technically be delivered on time. The users may even like it.
But if it doesn't solve the underlying business problem, was it really a successful project?
Start with “why”
Before discussing technology, I prefer to understand the business context.
What is happening today? Where is the problem? Who is experiencing it? How frequently does it occur? What is the business impact? What happens if we don't solve it?
And most importantly:
What would success look like after the problem is solved?
These questions often change the solution completely.
A business team may initially ask for a new system because an existing process is slow. But after understanding the process, we may discover that the real problem isn't the application.
- A manual approval process
- Duplicate data entry
- Poor integration between systems
- Lack of visibility
- Unclear ownership
- An inefficient business process
Building another application may simply put a modern interface on top of an inefficient process. The better solution may be to simplify the process first.
Technology should enable the outcome
I see technology as an enabler. The business outcome should remain at the centre.
Depending on the problem, technology might help us increase revenue, improve customer experience, reduce operational effort and errors, improve decision-making, reduce risk, improve scalability, improve employee productivity or create new digital channels.
The technology itself is not the final objective. The outcome is.
A technically elegant solution is not automatically the best business solution. Sometimes the simpler solution wins. Sometimes an existing platform can be configured rather than building something new. Sometimes automation is better than application development. Sometimes the biggest improvement comes from changing the process rather than changing the technology.
Don't start with the architecture diagram
Technology teams naturally think in terms of architecture: cloud, APIs, microservices, databases, containers, event-driven architecture, security, scalability and performance.
All of these are important. But they should come after we understand the problem.
I have learned that starting with architecture too early can make us solve the wrong problem very efficiently.
The better sequence is:
Business problem → Desired outcome → Requirements → Options → Technology → Architecture → Delivery → Measurement
Not:
Technology → Architecture → Development → Then find a business use case.
Ask what success looks like
One of the most useful conversations a technology leader can have with a business stakeholder is:
“How will we know this project has succeeded?”
The answer should ideally be measurable.
If the problem is long customer waiting time, success might mean reducing the average waiting time. If the problem is manual effort, success might mean reducing the number of manual steps or hours spent on the process. If the problem is poor digital conversion, success might mean improving the conversion rate. If the problem is lack of visibility, success might mean providing timely and reliable information to decision-makers.
Instead of saying “We delivered the application,” we can ask: “Did the application create the expected outcome?”
That is a much stronger definition of success.
Technology leaders need to speak both languages
One of the most important skills for technology leadership is the ability to understand both technology and business.
The business may talk about revenue, customers, operations, experience, risk, cost and growth. The technology team may talk about APIs, infrastructure, architecture, performance, security, code and integrations.
A technology leader needs to connect these two worlds.
“We need to improve API performance” is a technology statement.
“Customers are experiencing delays during the booking process, and improving API response time will help us reduce that friction.”
The second conversation explains why the technology work matters.
Sometimes the right answer is not to build
Technology teams are often measured by what they build. But good technology leadership should also ask:
“Do we actually need to build this?”
Before starting a new project, we should consider whether an existing system can solve the requirement, whether we can configure something we already have, whether we can simplify the process, integrate existing systems, automate the repetitive part, or eliminate an unnecessary step altogether.
Every application we build creates a future responsibility. It needs maintenance, security updates, infrastructure, monitoring and support.
So not building something unnecessary can sometimes be a very good technology decision.
Business problems don't always fit neatly into IT projects
Real business problems rarely belong to one department.
A customer journey may involve marketing, operations, finance, technology and customer service. An internal process may involve HR, finance, IT and management. A digital platform may involve multiple teams, vendors and systems.
If technology looks only at its own part of the problem, we may optimise one component while leaving the overall experience unchanged.
This is why understanding the end-to-end journey matters. Sometimes the biggest technology opportunity is not inside the application. It is at the boundaries between systems, teams and processes.
The role of technology leadership
As technology leaders, our job is not simply to bring the latest technology into the organisation. It is to help the organisation make better technology decisions.
That means asking difficult questions: Is this really the problem? What outcome are we expecting? Who benefits? How will we measure success? What happens if we don't do it? Can we solve it without building something new? What are the long-term operational implications?
And perhaps the most important:
Are we solving the problem the business actually has, or the problem we know how to solve?
That last question can be uncomfortable. But it can save significant time, money and effort.
Technology should create business value
Digital transformation is sometimes described as a technology transformation. I don't see it that way.
Technology changes rapidly. Business value is the constant. The tools, architectures, platforms and ways we build software will change. AI will change many things we currently take for granted.
But the fundamental question remains:
What business outcome are we trying to create?
If we keep that question at the centre, technology becomes much more meaningful. We stop adopting technology because it is fashionable. We start choosing technology because it is useful. We stop measuring projects only by delivery. We start measuring outcomes.
And we create technology platforms that are not just technically sound, but valuable to the organisation they serve.
What I believe today
After working across enterprise applications, digital platforms and transformation initiatives, I have become increasingly convinced that the best technology decisions are often made before the first line of code is written.
They happen when business and technology teams sit together and agree on the problem. They happen when we challenge assumptions. They happen when we define the desired outcome. They happen when we decide what not to build.
And they happen when technology teams understand that their ultimate responsibility is not simply to deliver systems. It is to create business value through technology.
So before starting the next technology project, perhaps the most useful question is not:
“Which technology should we use?”
Instead, start with:
“What problem are we trying to solve, and what will success look like when we solve it?”
The technology decision becomes much clearer after that.
← BACK TO LEADERSHIP INSIGHTS