Technology is a means, not a strategy: start with the outcome, then test the ecosystem

A technology proposal can become hard to question surprisingly early. Once it has a name, a champion, a budget estimate and a polished demonstration from a vendor, the conversation tends to move from whether this is the right thing to do to how quickly it can be done. At that point, the tool has started to become the goal.

A business does not need artificial intelligence because it exists, automation because competitors are automating, or a new system because the current one is old. Any of these may turn out to be a good investment, but only after the business has defined the outcome it wants, found what is actually stopping it, compared the realistic alternatives and understood what the technology will change around it. The risk is not just choosing a poor technology. It is letting technology set the direction of the business.

This article sets out a two-step approach. First, test whether technology is the right means at all, by defining the outcome without naming any tool, finding the real constraint and comparing alternatives, including doing nothing. Second, if it is, test whether the preferred option can actually be adopted, because the technology with the best specification does not always become the one that customers, suppliers, skills and money organise around.

When the means becomes the end

Sociologist Stephan Lorenz, writing in 2017, questioned the assumption that more technology automatically means progress. He was concerned about a pattern in which the tools keep multiplying while the purposes they are meant to serve receive less and less scrutiny. The argument came from a debate about environmental limits, but it applies directly to business decisions.

Inside most businesses there is an imbalance. A technology project has visible advocates: a sponsor, a vendor, a budget, a plan and something to show. The alternative of not adding another system, simplifying a process or improving how people decide usually has no advocate at all. Over time, this produces businesses with more systems, more data and more automation, but no matching improvement in customer value, decision quality or productivity.

Three common misreadings

Technical capability is mistaken for business capability. A business can have advanced analytics without improving any important decision. It can automate a weak process and simply produce errors faster. It can install collaboration software while leaving unclear who is responsible for what.

Technology is assumed to be passive. It is not. It changes workflows, skills, incentives, the information people pay attention to and sometimes what counts as good performance. Automation can remove routine work while concentrating what remains into fewer, harder exceptions. A self-service channel can shift effort from staff to customers.

Adoption is measured instead of value. Licences activated, users logged in, workflows automated and models deployed are measures of implementation. They do not show that the business is better off.

Separate four things

Before committing to a technology, separate four things that often blur together:

• The end: the outcome that matters.
• The means: the intervention chosen to influence it.
• The mechanism: why that intervention should produce the outcome.
• The evidence: what would confirm or challenge that belief.

If any of these is unclear, confidence in the investment should be lower.

Step one: is technology the right means?

Define the outcome without naming the technology

Write the outcome so that it would still make sense if the preferred technology disappeared tomorrow.

• Weak: “Implement AI across customer service.”
• Stronger: “Reduce the time to resolve routine enquiries while keeping service quality, records and escalation of complex cases.”

The stronger version leaves room for other ways of getting there.

Find the constraint

What is actually stopping the outcome now? It might be staff capacity, inconsistent processes, poor information, unclear responsibilities, slow approvals, scarce skills or physical throughput. Technology aimed at something that is not the real constraint can produce a local improvement without changing overall performance.

Compare credible alternatives

At minimum, compare:

• redesigning the process;
• changing a policy or approval rule;
• training or developing people;
• technology that assists people;
• automation that replaces a task;
• outsourcing or partnering;
• deliberately doing nothing for now.

Compare them on value, time to benefit, reversibility, disruption, new dependencies and how much they keep future options open.

State the mechanism

Write down why the chosen means should produce the outcome, in a form that can be tested. For example: “Automating data entry will free about six hours a week of the coordinator’s time, which will be used to follow up unpaid invoices.” If that freed time is absorbed elsewhere, the expected benefit will not appear, and the business will know why.

Decide what people will keep judging

Specify what the technology may decide on its own, what it may recommend, what needs human approval and what independent checking remains. The higher the consequence of a mistake, the more important this boundary is.

Technology can also displace capability as well as add it. When people stop doing a task because a system does it, the business may lose the experience that helped it notice exceptions. That does not mean keeping inefficient manual work. It means deciding which human skills remain important, which may be different skills from before: fewer people doing routine work, but people who can question results, interpret anomalies and recognise when the system is wrong. The adopting AI: start with the work article looks at this for AI tools specifically.

Agree stop and review conditions

Before implementation, agree what evidence would cause the business to pause, redesign or stop. Without that, delivery momentum becomes evidence in its own favour.

Some choices are hard to reverse

A small trial with a limited set of data is easy to stop. A core business system, a proprietary platform, automation built deeply into operations or a standard adopted across all equipment is much harder to reverse. The purchase can commit the business to migration costs, specialist skills, vendor relationships and ways of working that last for years.

The harder a decision is to reverse, the stronger the evidence should be before committing. Ask not only whether the technology works but which future options it closes. A platform may improve efficiency while reducing flexibility with suppliers. Automation may reduce routine labour while increasing dependence on a scarce specialist. A cloud service may improve access while changing security and continuity risks. Every technology comes with a new set of risks.

Step two: can this option actually be adopted?

If technology is the right means, the next question is which option. It is tempting to treat this as a contest of specifications, scoring performance and features. But technologies that depend on an ecosystem succeed only when people fund them, operators learn them, suppliers support them, standards accommodate them, customers trust them and regulators permit them.

A 2017 study by van de Kaa, Kamp and Rezaei examined competing biomass energy technologies in the Netherlands. Technical superiority received the highest weight in their model, but they identified twelve factors in total, including the financial strength of the technology’s backers, compatibility, flexibility, price, distribution, the existing installed base, regulation and networks of supporting organisations. The specific ranking belongs to its time and market. The lesson is that choosing a technology is choosing an adoption system, not just a product.

An ecosystem check

Installed base and compatibility matter

A large existing user base brings skills, spare parts, reference customers, add-on products and a sense of safety. That can make a widely used technology hard to displace even when a challenger performs better. Compatibility with existing systems shortens the time to benefit. The best core capability can be outweighed by the cost, delay and risk of converting everything around it.

This is not an argument for always choosing the incumbent. It is an argument for making the full adoption case visible. Sometimes the right answer is to use the established option for production now while funding a small, separate trial of an emerging one to learn and keep the option open. The proving a new technology is ready to depend on article covers how to test whether a new option is ready.

Technology competes for more than money

Technology projects consume scarce change capacity: management attention, specialist time, training time, data work, security review and staff tolerance for disruption. Several individually attractive projects can still be a poor combination if they rely on the same people or change the same processes at the same time.

Before approving a technology project, ask: if we fund this, what will be delayed, not funded or poorly absorbed because of it? If nobody can answer, the real cost is not being counted.

A worked example

This is an illustration. A plumbing and gas fitting business with 28 staff is frustrated by missed appointments and slow job completion. A vendor demonstrates a field service platform with AI scheduling, and the operations manager is keen.

The owner works through step one:

• Outcome without naming the technology: reduce missed appointments, currently about 9% of bookings, and shorten the time from a customer’s request to job completion.
• Constraint: reviewing two months of jobs shows the main problem is not scheduling logic. It is incomplete information at booking: wrong addresses, missing access details and no description of the problem, so plumbers arrive unprepared or cannot get in. The single dispatcher is also overloaded on Mondays.
• Alternatives: a structured booking script and checklist; a simpler scheduling tool that sends customer confirmations; a second dispatcher at about $75,000 a year; the full platform with AI scheduling.
• Mechanism: complete booking information and automatic customer confirmations should reduce missed appointments and wasted trips, whatever scheduling method is used.

The owner chooses the booking script and a scheduling tool with automatic confirmations, and defers the AI scheduling module. The stop condition: if missed appointments have not fallen below 6% within four months, revisit the dispatcher and AI options.

For step two, the owner compares two scheduling tools:

Platform A is technically stronger, but Platform B fits the business’s existing systems, has local support and a large user base, and costs less than half as much in the first year. The owner chooses Platform B and notes that AI scheduling can be trialled later if the constraint shifts to scheduling logic.

Four months later, missed appointments have fallen to about 5%. The dispatcher’s Monday overload has eased because customers confirm or reschedule automatically. The business has solved the problem it had, not the problem the demonstration suggested.

How this applies to a small Australian business

Small businesses are frequent targets for technology sales, and often lack the time to evaluate options deeply. Practical steps:

• Write the outcome without naming any technology.
• Find the real constraint before choosing a solution.
• Compare alternatives, including process changes and doing nothing.
• State the mechanism and how you will know it worked.
• Decide what people will keep judging, especially for consequential decisions.
• Agree stop conditions before implementation.
• Check the ecosystem: compatibility, local support, user base, supplier strength and transition cost.
• Count the capacity cost: what will be delayed because of this project?
• Check privacy, security and data obligations where the technology handles customer or staff information.

Signals worth watching

• Technology initiatives described by features rather than outcomes.
• Adoption figures used as the main measure of success.
• Benefits with no owner in the business.
• Problems caused by earlier technology being solved with more technology.
• Staff less able to question what a system tells them.
• Projects continuing because of money already spent.
• Leaders able to explain what is being implemented more clearly than why.

Common mistakes

• Starting with a tool instead of an outcome.
• Automating a weak process.
• Ignoring non-technology alternatives.
• Measuring adoption instead of value.
• Choosing on specifications alone, ignoring the ecosystem.
• Underestimating transition costs and lock-in.
• Running several technology changes at once with the same people.

Frequently asked questions

Does this mean we should be sceptical of all new technology? No. It means being clear about the outcome first. Many technology investments are excellent. The discipline simply makes the good ones easier to identify and the weak ones easier to stop.

How do we compare options when a vendor’s demonstration is impressive? Ask the vendor to demonstrate using your own data and situations, ask for local references from businesses like yours and include integration, training and support in the comparison.

What if the technically better option has a small user base? Consider using the established option now and trialling the emerging one separately, so the business can learn without depending on it.

How do we measure value rather than adoption? Measure the outcome you defined at the start, such as missed appointments, time to invoice or customer complaints, before and after, and keep measuring for some months after go-live.

What is a reasonable stop condition? A specific result by a specific date, for example a defined improvement in the outcome measure within four months. If it is not achieved, the business reviews the approach rather than adding more technology.

Questions to ask

• What outcome are we pursuing that would still matter if this technology did not exist?
• What is the real constraint, and how do we know this technology acts on it?
• Which alternatives did we seriously consider?
• What new dependencies and hard-to-reverse commitments will this create?
• Which human skills must remain strong afterwards?
• What would make us stop?
• What will be delayed because this project uses the same people?

Bringing it together

Technology is neither the enemy nor the strategy. Start with the outcome, find the real constraint, compare credible alternatives including doing nothing, state why the chosen means should work, decide what people will keep judging and agree when to stop. Then test whether the preferred option can actually be adopted: compatibility, supplier strength, local ecosystem, transition cost and learning trajectory. A good technology decision makes the business better at producing outcomes that matter while keeping future choices open. A weak one adds capability without purpose and relies on momentum to justify itself.

---

Source: KEVOS notes, drawing on S. Lorenz (2017) on the means and ends of technology, Journal of Cleaner Production, and G. van de Kaa, L. Kamp and J. Rezaei (2017) on factors in technology selection, Journal of Cleaner Production. Examples and figures in this article are illustrations.