There's a quote attributed to Bill Gurley that I return to regularly: “Uber is an operations business, not a technology one.” It's a fascinating lens through which to view the entire objective of building a tool or a system or a ‘platform’. Uber's platform is, at its heart, a technology-enabled operations orchestrator — facilitating thousands of micro-interactions on both sides of the value chain. But the measure of success is stubbornly physical: did the taxi arrive in less than five minutes?
I think about this a lot, because the technology world forgets it with alarming regularity. Software gets revered for its own sake — its elegance, its architecture, its abstraction — and somewhere along the way the connection to the physical world loosens. But any system worth building must eventually land somewhere real, where certain events complete: cloud spend decreases, PPE arrives at a hospital, a contractor gets onboarded, an invoice gets paid. When technology loses its connection to these kinds of outcomes, it tends to float upwards into the realm of conceptual slide decks and boxes filled with adjectives. I've sat through enough of those to know.
This conviction — that technology is only as good as the operational outcomes it enables — is central to how we work as a consultancy at reidworks. But it didn't arrive fully formed. It came from years of fumbling around in the gap between what gets built and what actually gets used.
A Winding Path Into Tech
I was late to the tech world, joining the insurtech Amplify Health at around 28 as a product manager. As a corporate joint venture between two large insurers, Amplify was in the business of conceptualising, building and selling software solutions to health insurance companies. I was quickly tagged as a ‘business’ employee. For context, in most health insurers there's a notional bifurcation between ‘business’ employees (actuaries, sales, product) and ‘technology’ employees (engineers, DevOps, data scientists, testers). In terms of power, actuaries sit at the top of the decision-making mountain, and tech employees are typically subservient.
Amplify was a confusing mix — it was a technology business that employed several actuaries, with no plans to directly underwrite risk — but the inherited traditional schism was strong all the same given its genesis. Also, I was on the outside of the technology employees in an org that was in the business of developing and selling technology. This bothered me. Wasn't everybody supposed to be in the ‘technology team’? Why did we carry these legacy-insurer department structures into a nascent startup?
Nine months in, I grew impatient with all the presentations and asked to join the technology team. I ended up with an operations-related role and remember the sting of those first few months, excluded from every major decision-making forum. To solve a fast-scaling problem, I ended up building lists of contractor names and laptop serial numbers in various Excel sheets. Visibility into the direction of the business had vanished.
“I had no idea where to start. There was no way I was going to learn JavaScript or Python to any reasonable level at this age, and this was a pre-AI code-editor era.”
So I decided to start where my previous career as a banker had left off: in Microsoft Excel. Being self-directed and able to read the common language of what our senior leadership ultimately cared about — namely revenue and costs — I took to exploring the two biggest cost items in our budget: people spend (salaries, what they worked on) and cloud cost optimisation (Azure spend).
It proved to be a good bet. I quickly reached the limits of Excel as a single, large, flat table, and the notion of a database — sets of related tables linked through primary and foreign keys — became self-evident. An image emerged of constellations of related tables, ever growing and expanding. My confidence deepened as I realised that given all the fancy-minded discussion of technical terms and languages, my foothold into the technology world was firmer than I'd assumed. Most things related back to structured data in tabular formats, and years of manually constructing company valuation models in investment banking had prepared me for this more than I knew.
From Dashboards to Logic Boxes
I taught myself SQL to fetch data and picked up Power BI, a fairly intuitive program that could sit on top of many traditional data sources (including Excel). It could display aggregations, spread data across time-series values and allow for low-latency filtering. After the high of merging a few disparate data sources and publishing my first dashboards, I grew hungry for more.
But I noticed something. I grew interested in how people actually interacted with what I'd published. One was a dashboard on contractor costs, which were expanding rapidly. Several senior product leads wrote some questions, but most people took a look once a month and moved off once they'd got what they needed — usually to win an argument with finance. They cut the data quickly using the filters and switches I'd designed, but there were very limited actions they could take as cost centre owners. They couldn't make a request, or raise an objection, or ask for a candidate to be fast-tracked. All of that went offline and into email, or a copy-paste Excel job — the standard default tools.
To address this, I took up learning Power Automate, another of Microsoft's intermediate tools for people like me. It let me daisy-chain a few actions together in different directions depending on inputs. A user could submit request data through a form, which generated a unique requisition number and was sent to the relevant lead for approval. Once approved, it auto-moved to the next department over email and Teams, where further actions passed it onwards. At the end, a new employee was onboarded or cloud spend for a new cluster was approved. Teams needed these things, so they used my systems.
The mini-processes built in complexity over time — eight in total, eventually — and provided a centralised repository of requests, approvals, and actions across multiple teams. I created simplified error logging and ensured auditability on who approved what, when. I routed myself in bcc on the approval chains and built a reputation as someone who knew where each process was stuck, which had been a significant pain point previously. People started calling it a ‘system.’
Where the Logic Box Breaks
Even as I tinkered with and improved my mini-operational system, the gaps between my simple logic boxes and a proper software system grew stark. I discovered intimately where my system sucked — users often had to correct or amend information, and forms didn't save interim inputs, so they'd frequently have to start again. Related tables of vendor rates contained confidential information that needed to be hidden from select users. Access roles were limited to SharePoint's basic admins, owners, and users, and people frequently complained about form access issues. In short, operating an org-wide approval and onboarding management system for our two biggest cost drivers was quickly growing out of SharePoint's capabilities, in the same way I had grown out of Excel.
Let me rewind a bit for some context. A few years earlier, during COVID-19, I'd had a fairly unique experience as a relatively junior banker. Whilst the country went into lockdown, I was seconded from my corporate finance team to a cross-corporate healthcare initiative alongside the likes of McKinsey, PwC, Bain, Discovery and Netcare. Our task was to procure PPE from abroad using money raised in the private sector for the public sector, at a time when global prices were skyrocketing.
During that experience, I got the privilege of working with a true rockstar application developer from Naspers, the South African company with a large stake in Tencent. Over two or so weeks, this developer took the prior three months' work of twenty-odd extremely well-paid consultants — massive sets of Excel files — and effectively ingested it into a live, real-time marketplace where buyers and sellers of PPE could congregate, bid, purchase, and transact. It supported real-time auctions, connected to government company registration databases, and had reasonably robust fraud detection.
“That experience was deeply revealing. It showed me what a capable single source of truth could actually do.”
It introduced me to the elegance of fine-grained role-based access controls (RBAC) and broader user management principles — the mechanics that allowed thousands of users, loosely organised into groups with very different incentives, to interact with a platform simultaneously and for real decisions (including money spent) to be made. More foundationally, it showed me that screens rendered in a UI were simply digital ‘cardboard’ until they were arranged sequentially — a tunnel metaphor seems to help — locked via conditional validations, connected to related user tunnels, and imbued with empathy for how a typical user actually experiences the thing.
Back at Amplify, I had a new pitch: help me build Iceberg, an integrated contract, contractor, vendor, and billing management platform for the entire company, with external and internal users. It was ambitious but achievable — I'd been thinking about the problems for months and had mapped the challenges intimately. We built Iceberg in record time.
The Harder Problem
Building Iceberg was the comparatively easy part. The harder work — the work that most technology teams underestimate or ignore entirely — was everything that came after: getting people to actually change how they worked.
New technology always lands inside existing human processes, and those processes are tangled up with habits, incentives, egos, and institutional memory. Someone has been running onboarding through email chains for three years and has a system that works for them, even if it's opaque to everyone else. A vendor relationship manager has a personal spreadsheet containing rates they're not keen to share. A finance lead has approval authority routed through a process they designed, and replacing it feels like a demotion. These aren't irrational responses. They're human ones.
Personal change is hard
Collective change is harder still
The most capable system goes unused if people don’t trust it
This is where we spend a disproportionate amount of our time, and where we think the real value lies. Not just in the build, but in the layers of work around it — communication, incentive alignment, documentation, training, operating alongside teams during the transition, and transferring ownership carefully. We don't build for build's sake. We've seen too many projects that were technically sound and operationally irrelevant.
The Loop Is Shrinking
There's always been a gap between two distinct phases of any technology project: the pre-launch development phase, where you're building against assumptions — your best guesses about how people will behave, what they'll need, where things will break — and the post-launch phase, where you're finally measuring against reality. Did the contractor actually get onboarded faster? Did the cloud spend actually come down? Did the PPE actually arrive?
Historically, this feedback loop was slow and expensive. You'd spend months building, launch, discover the gaps through painful user feedback, then spend months iterating. Each cycle carried the full weight of development costs, retraining, and organisational patience. I've watched projects run out of goodwill before they ran out of bugs — the technology was improving, but the people around it had already moved on, emotionally if not formally.
AI has compressed this loop dramatically. We can now build functional prototypes in days rather than months, put them in front of users, observe what actually happens, and iterate before institutional fatigue sets in. The distance between “here's what we think you need” and “here's what's actually working” has shrunk from quarters to weeks. This matters not because speed is inherently good — plenty of fast work is bad work — but because it tightens the measurement of the physical changes we're trying to create.
“When people can see and touch a working version of the thing within the first fortnight — when they can break it, complain about it, point out that the approval flow doesn't match how they actually work — their relationship to the project shifts. They become participants rather than recipients.”
I think back to my Power Automate days and how much of the adoption came from the fact that I was there, in bcc, watching the process break and fixing it in near real-time. AI lets us do something similar at a much larger scale: build, observe, adjust, repeat — before the window of organisational willingness closes.
What We Carry Forward
The arc from Excel to Power Automate to Iceberg taught me something that has shaped everything we do: technology is a means, not an end. The value isn't in the system — it's in whether cloud spend actually drops, whether the contractor actually gets onboarded, whether the PPE actually arrives. The path from ‘built’ to ‘operational’ always runs through people, and AI has given us a way to walk that path faster and with more confidence — tightening the loop between what we build and what the real world tells us is working.
We've learned this through doing, not theorising. We've sat in the messy middle where processes break and users resist and data doesn't flow the way the architecture diagram said it would. That experience — across health insurance, marketplace platforms, and enterprise operations — is what we bring to every engagement.
If you're thinking about a technology build or an operational transformation, we'd be happy to talk.
>_ Written By
James Reid