Early in the healthcare data platform program I led, I remember sitting in a room with a clinical lead, a government program director, and a vendor engineering lead, and realizing that all three of them were right — and that being right wasn't going to get us anywhere. The clinical lead was right that patient data required careful handling. The government lead was right that funding decisions couldn't wait indefinitely. The engineering lead was right that the registries genuinely didn't fit together cleanly. Nobody was wrong. Nobody, on their own, could move the program forward either.
That's the situation I think about most when people ask what's actually hard about large cross-functional programs. It's rarely a lack of expertise in the room. It's the absence of a shared decision-making structure that lets legitimately different priorities get resolved into a single plan.
Structure the ambiguity before you touch the technology
My instinct in that first meeting could have been to jump straight to a technical design — pick a data architecture, propose an integration approach, move fast. I've learned that's usually a mistake. The more useful first move is almost boring: get precise about what decisions leadership actually needs to make, on what timeline, with what level of confidence in the underlying data. Once that's clear, the technical priorities mostly fall out of it — which registries matter first, what "good enough" data quality looks like for each decision, and where you can afford to move slower.
Governance is not a formality — it's the actual mechanism of alignment
I used to think of steering committees and QBRs as overhead — necessary, but not where the real work happened. Running this program changed my mind. A shared metadata and governance catalog, for instance, did more to build trust between clinical and government stakeholders than any dashboard we built, because it gave everyone a common, honest reference point for what a given dataset actually meant and how current it was. The cadence of bringing clinical, government, and engineering leads into the same room regularly meant decisions got made once, together — instead of being quietly renegotiated by each group afterward, which is how programs slowly drift apart without anyone noticing until it's a crisis.
Build the foundation, not just the deliverable
One choice I'm glad we made was treating the initial platform as a foundation rather than a finished deliverable. When additional provincial and national reporting requirements came later, we weren't starting from zero on governance and trust — we extended a model that already worked instead of re-litigating the basic rules of engagement each time. That's a slower way to start and a much faster way to scale.
Staying close to execution as a strategy-level leader
It would have been easy, at a program-lead level, to stay one layer removed from the details — reviewing status reports rather than understanding the actual data quality issues underneath them. I don't think that would have worked here. The clinical and technical judgment calls in the details were exactly where the plan could have quietly failed, and staying close enough to understand them was part of what let me make the governance structure actually useful rather than symbolic.
When a cross-functional program feels stuck, resist the urge to add more technical detail to the plan. Check first whether the real problem is a decision-rights problem — unclear ownership, unresolved trade-offs, or no shared forum where priorities actually get settled. Fixing that usually unblocks more than any amount of additional analysis.