Long before I had any language for governance, I had a hunch about it, and the hunch arrived, of all places, inside a Microsoft Solutions Framework certification in the mid-1990s.
At the time I was doing the kind of work that doesn’t photograph well: moving data across refineries and power stations, standing in the gap between technical teams and the customers who had to live with what got built.
I’d learned, mostly the hard way, that the problems everyone called “technical” usually weren’t. The technology tended to work fine. It was the decisions around it, who got asked, who got skipped, when someone finally said yes…that caused the damage.
The Microsoft Solutions Framework (MSF) certification wasn’t sold to me as a governance course. It was a project methodology, decision rights, versioned releases, the structured trade-off between authority and delivery momentum. But somewhere in the middle of it, something clicked that I didn’t have a name for yet: this was a governance methodology, dressed as a technical one.
It was teaching, explicitly, that certain decisions had to be settled, and settled by the right person, before the technical work was allowed to proceed. Not because process demanded it. Because the work would eventually surface the decision anyway, at a worse time, at a higher cost, with less room to get it right.
I didn’t walk out of that course able to explain what I’d learned. I just started noticing it everywhere.
Projects that skipped the authority question didn’t fail cleanly, they failed slowly, months later, in a change request nobody could approve or a handover nobody was accountable for. The pattern was consistent enough that I started treating it as a kind of rule, long before I had any research behind it: governance precedes delivery, and if it doesn’t, delivery pays for it later.
It would be another three decades, through a services-marketing pivot that reframed “technical failures” as design failures, a stint in uniform that gave me a second, harder-won vocabulary for authority and initiative, and a run of infrastructure and network projects on three continents, before I’d end up studying this properly, in the one region where I’ve watched the pattern play out with the least room to hide from it.
Pacific digital and data programmes have a way of putting the authority question front and centre, whether anyone planned for that or not. I’m not sure yet how much of what I noticed in the 1990s survives contact with formal research. That’s rather the point of doing the research.
But the recognition itself, that governance is a precondition dressed as a technical detail, not an overlay applied afterward, is where this whole line of thinking started, and it seemed like the right place to start writing too.
The instinct isn’t original to me.
Decision-rights frameworks in IT governance, Weill and Ross’s (2004) work is the standard reference, have been making a version of this same argument for two decades: that the organisations getting real value from technology investment are the ones who worked out who decides what before they worked out what to build.
I arrived at the same intuition from the factory floor rather than the literature. It’s taken me a while to find out they were describing the same thing.
References:
P. Weill and J. W. Ross, “IT Governance: How Top Performers Manage IT Decision Rights for Superior Results,” Harvard Business School Press, 2004.