By the late 1990s I’d built up a decade’s worth of half-formed observations, governance moments dressed as technical decisions, authority questions nobody was naming as authority questions, and no framework to hang any of it on. I could see the pattern repeating. I couldn’t yet say what the pattern was.
So I went to study, partly out of frustration with my own inability to explain what I kept seeing. The MBA covered the usual ground, and none of it particularly changed how I thought. Then came the final unit: Services Marketing and Management. It wasn’t the subject I expected to be the pivot. It turned out to be the only one that was.
The core idea is simple enough once you’ve seen it, and almost invisible before you have: a service isn’t a product with some intangible extras attached. It’s a different kind of exchange entirely, built on interactions rather than deliverables, where the quality of the outcome depends on decisions made during the process, not just on what gets handed over at the end. Once I had that distinction, I went back through a decade of projects I’d watched go wrong and realised I’d been diagnosing every one of them incorrectly.
They hadn’t failed because the technology was wrong. The software mostly worked. They’d failed as services, the wrong question asked at the start, the wrong person consulted about a decision that wasn’t theirs to make alone, a handoff between teams that assumed context nobody had actually transferred. None of that shows up on an architecture diagram. All of it shows up, eventually, as a project that technically shipped and organisationally never quite landed. I’d spent years calling these technology failures because that was the vocabulary available to me. They were services design failures the whole time, and services design failures are much harder to see, because nobody puts “who gets consulted, and when” on a project plan.
What struck me most was how consistent the miscoding was.
It wasn’t that people were bad at noticing something had gone wrong, everyone always noticed. It was that the available diagnostic categories, technical failure, scope creep, poor communication, all pointed away from the actual mechanism, which was an authority and sequencing problem wearing a technical costume. Give someone the wrong diagnostic category and they’ll fix the wrong thing extremely competently, forever.
I didn’t leave that unit with a finished theory. I left it with a question that’s shaped everything since: if the thing that’s actually broken is how a decision gets made, who gets asked, and in what order, then most of what gets called a technology problem is really a governance problem that hasn’t been recognised as one yet. That question has followed me through every project, every sector, and every region I’ve worked in since, largely unchanged.
It wasn’t an original insight, even then. Vargo and Lusch’s work on service-dominant logic, a few years later, made the same reframing formally, arguing that value isn’t delivered in a product handoff but co-created through an ongoing process, exchange as service, not exchange as object.
I’d arrived at a rougher version of the same idea from the opposite direction, watching things go wrong rather than reading the theory first. It’s a pattern I’ve noticed about most of what I’ve learned this way: the literature was usually already there. I just met it after the practice, not before.
References:
Vargo, S. L., & Lusch, R. F. (2004). Evolving to a New Dominant Logic for Marketing. Journal of Marketing, 68(1), 1–17. https://doi.org/10.1509/jmkg.68.1.1.24036