Why Better Technology Decisions Start Before Technology

Technology decisions often appear to begin with technology. An aging system needs to be replaced. Someone wants a new platform. There's pressure to do something with AI, or a vendor has shown up with a product that looks promising.

Before long, demos are being scheduled, architecture is being discussed, estimates are being prepared, and someone wants to know how quickly the initiative can get started. All of that is perfectly normal.

Except sometimes nobody has really agreed on what they're trying to make better.

The technology conversation has taken off before the problem has caught up.

When the Solution Shows Up First

"We need a new CRM." "We need to move to the cloud." "We need an AI assistant." "We need to replace the legacy platform."

We hear statements like these all the time. They sound like problems, but they're actually proposed solutions.

Take the CRM example. Sales may be struggling to understand the complete relationship with a customer. Support doesn't know what sales has promised. Finance organizes customer information differently. Meanwhile, customers are getting annoyed because they keep having to tell the company things it should already know.

Everyone agrees something isn't working. That doesn't mean everyone agrees on what's wrong.

Once "new CRM" becomes the initiative, however, things start moving. Which vendors should we look at? What features do we need? How much will it cost? How long will implementation take? Those are all reasonable questions, but it's possible to become remarkably precise about the solution while remaining surprisingly vague about the problem.

The differences usually surface later. An executive expected the investment to improve customer retention. Operations expected less manual work. Employees wanted better access to information. Technology saw an opportunity to retire aging systems. Finance expected lower operating costs. The customer just wanted the company to stop asking the same questions every time they called.

None of those expectations is unreasonable, but they aren't the same. As the initiative moves forward, the differences tend to get buried inside requirements, priorities, schedules and design decisions. Eventually, a lot of smart people can be working very hard on the same project without actually trying to achieve the same thing.

Assumptions Get More Expensive With Time

Every technology initiative starts with assumptions. We make judgments about what people need, how they work, what customers value, which constraints are real and what will happen once a new capability becomes available. We have to; nobody gets perfect information before making a decision.

The interesting part is what happens to those assumptions as the initiative moves forward.

Early on, challenging one might change a conversation or a few slides. Six months later, the same assumption may be sitting inside a contract, an architecture, several integrations and a pile of code. By then, nobody may remember that it started as an assumption. It's simply part of what the system is supposed to do.

This is one reason technology initiatives can be successfully delivered and still disappoint the people they were intended to help. The vendor may have delivered what was purchased. The architecture may be sound, the engineering good, the system stable and the project on schedule. On paper, everything looks fine.

Then people start saying, "This didn't really solve our problem."

Nobody necessarily did bad work. The organization may simply have executed the wrong decision extremely well. By the time that becomes obvious, changing the decision is considerably more expensive than questioning it would have been at the beginning.

The consequences can also last much longer than the project itself. A platform selected for one initiative influences future integrations. A vendor chosen because it made sense today can become a dependency that lasts for years. Information designed around one application ends up being needed somewhere nobody originally anticipated, and small implementation shortcuts have a habit of sticking around much longer than expected.

AI makes this particularly visible. A decision made around today's models may have to survive a technology landscape that looks quite different a few years from now.

Of course, nobody can predict all of that. Trying to future-proof every decision against every imaginable possibility is a good way to never make a decision at all. But there's a difference between accepting that the future is uncertain and only thinking as far ahead as go-live.

The organization is going to live with the decision longer than the project.

Starting With a Better Understanding

When this is handled well, the technology conversation becomes more useful.

Vendor demonstrations are easier to evaluate because there's a clearer understanding of what the organization is evaluating them against. Instead of being impressed by everything a product can do, people can focus on whether those capabilities matter to what they're trying to accomplish.

Engineering teams have more than a list of requirements; they understand why the important ones matter. Stakeholders may still disagree, but those disagreements surface while there's still room to do something about them. Tradeoffs don't disappear either, but people have a better idea of what they're trading and why.

Eventually, when the technology goes into use, the organization also has a more meaningful way to judge success. The question isn't limited to whether the system was delivered, whether it works, or whether the project met its milestones. It can return to the reason the initiative existed in the first place: did the thing we were trying to make better actually get better?

None of this guarantees the right decision. Circumstances change, technology changes, and sometimes perfectly reasonable assumptions turn out to be wrong. There is, however, a significant difference between taking a calculated risk and discovering two years later that people were solving different problems from the start.

By the time an initiative reaches vendor selection, architecture or engineering, a surprising number of choices shaping its eventual outcome may already have been made. Some of the best opportunities to influence that outcome happen earlier, while there's still room to challenge what the organization thinks it needs and before assumptions become expensive commitments.

Technology absolutely matters. But choosing the right technology for the wrong problem doesn't get you very far.

Better technology decisions don't begin with choosing better technology. They begin with a better understanding of what needs to become better.