The other day, I had a board meeting to attend in Wellington. Without even thinking about it, as I landed at Wellington Airport, I took out my phone, opened the Uber app, and summoned a car. I did not need to make a phone call, take out my wallet, or do any of the things we used to take for granted. I was effortlessly dropped off at my destination without missing a beat.
We have truly begun to take for granted how much technology has facilitated the less exciting parts of our lives. Uber is one of the best examples of this. It seamlessly integrates cloud technologies, real-time data, artificial intelligence, machine learning, and API integration to deliver an incredible service.
I was reflecting on Uber the other day as I attended a meeting for an organization I am involved with. It does not really matter which organization, but suffice it to say that it manages a large fleet of vehicles deployed to multiple locations at different times. The added complexity comes from the fact that no one knows in advance where these vehicles will be needed. With hundreds of vehicles distributed across the country, this is a perfect case for how modern technologies could be integrated to optimize outcomes.
Instead, what we got was an example of failure. It demonstrated what happens when those responsible for finding solutions do not understand best practices or the fundamentals of the technology landscape. In this case, the decision was as suboptimal as it was surprising. It involved hard-coding fixed data into a database to calculate travel times between multiple, randomly occurring destinations. It is difficult to think of a scenario where cloud technologies would be better suited, yet they were not used.
This got me thinking about the best way to deliver technology solutions to business problems. Time and time again, I have seen technologists gather in a room, wave their arms excitedly, and talk about paradigms, databases, cloud computing, real-time data, and all the other buzzwords. On the other hand, I have also seen business users discuss potential solutions without any awareness of architectural norms or best practices.
There is, however, another approach. To misquote former UK Prime Minister Tony Blair, this is an area where we need a “Third Way.” The key is to bring together smart business users who understand technology to some extent and smart technologists who grasp business fundamentals. By putting them in the same room and allowing them to collaborate, they can find the best solution.
The best solution may not use the latest and flashiest technologies, but it will be grounded in best practices and designed for optimal results. Unfortunately, I have seen too many examples where the opportunity to drive fantastic outcomes was lost, and this was one of them.
I am not a technologist, nor have I ever led a large business unit or organization. But I have spent time working at the intersection of technology and business, and this experience has given me a useful lens to analyze problems from both perspectives.
Achieving this so-called “holy grail” is not actually that difficult. It is about bringing the right people together, fostering open collaboration, and embracing curiosity and a willingness to explore. As we enter a world where artificial intelligence and cloud technologies are not only changing solutions but also redefining the nature of problems, these kinds of cross-functional collaborations will become essential for business success.
Meanwhile, I will jump on my flight and head to my next destination. And when I do, I will rest easy knowing that Uber, despite its flaws in culture and conduct, has absolutely mastered the application of technology to a real-world problem.

The phenomenon you’re describing can be explained by several corporate behaviours I’ve observed over the years:
(1) Cost pressure: Senior IT leaders are told to reduce costs as a priority to “sweat the assets”. This often translates into short-termism expressed as avoiding expense on maintaining existing systems, applying “quick fixes” rather than addressing underlying architectural issues, and using existing installed systems to do things they weren’t designed to do. All of this builds technical debt, and the chickens eventually come home to roost.
(2) Risk aversion: Using something you and your staff know well (the devil you know) is often seen to be less risky than using something you don’t know well (the devil you don’t know) even when the thing you know is well past its best-by date. In-house IT professionals are rarely rewarded for taking risks, even when they’re sensible ones. And there seems to be little appreciation for the fact that taking small managed risks is almost always less risky than trying to avoid risk entirely.
(3) Lack of transparency: Corporate IT managers do not like external scrutiny. Yeah, it’s ugly, but there are reasons. Some are rightfully embarrassed by the state of what they’re meant to be managing on insufficient budget.
There are a few people around who are both actual technologists and actual business people, but our message that companies need to reinvest in their depreciating IT systems, be transparent, and take managed risks is not a popular one.
And when the brown material hits the whirling apparatus, they call in Deloitte who use a couple of juniors to deliver the bad news.