Building Cross-Functional Teams for Digital Transformation

The Meeting That Changed Everything

Three weeks into my role as Executive Director of Global Web Strategy at Novartis, I made a decision that confused everyone on my team.

I invited Legal to our kickoff meeting.

Not just Legal. Regulatory. Compliance. Medical Affairs. Patient Services. Every stakeholder who traditionally shows up at the end of a project to tell you everything you built needs to change.

My team looked at me like I'd lost my mind. "We haven't even defined the requirements yet," my lead architect said. "Why would we bring in the people who are going to slow us down?"

I understood the concern. In most organizations, compliance functions operate as gatekeepers. You build something, submit it for review, wait weeks for feedback, then rebuild half of it. The process is adversarial by design. Digital teams learn to avoid these conversations as long as possible, hoping to present a finished product that's harder to reject.

But I'd spent fifteen years watching that approach fail. Projects that looked 80% complete would get kicked back at the final review, requiring months of rework. Timelines would double. Budgets would explode. And everyone would blame the compliance team for being "difficult" when the real problem was bringing them in too late to do anything but say no.

So I tried something different.

The 90-Country Problem

Here's what we were facing at Novartis: a web ecosystem that had grown organically across 90 countries over two decades. More than 1,200 websites, many of them unmanaged, operating under different technology platforms, design standards, and content governance models.

The business case for consolidation was obvious. We were spending millions annually on redundant infrastructure. Brand consistency was impossible to maintain. And from a regulatory perspective, we had significant exposure. Pharmaceutical websites have strict compliance requirements that vary by country. With 1,200 properties, nobody could say with certainty that we were meeting all of them.

Leadership wanted a unified platform strategy. One architecture that could serve all 90 countries while allowing appropriate local customization. A system that would reduce costs, improve brand consistency, and eliminate regulatory risk.

Simple to describe. Extraordinarily difficult to execute.

The conventional approach would be to assign this to IT, let them build a technical solution, then socialize it with stakeholders for approval. That's how most enterprise digital projects work. Technical teams build, business teams review, compliance teams approve (or don't).

I knew that approach would fail. Not because the technical team couldn't build a good platform, but because they'd build the wrong one. They'd optimize for technical elegance without understanding the regulatory constraints that would ultimately determine what was possible. They'd create workflows that made sense to engineers but violated Medical Affairs protocols. They'd design user experiences that Legal would reject for liability reasons.

By the time those issues surfaced, we'd have invested months and millions into an architecture that couldn't be deployed.

So instead of building first and asking permission later, I restructured the entire project around early stakeholder integration.

The Bi-Weekly Coalition

Every two weeks, I convened what I called the "Coalition" meeting. Representatives from IT, UX, Content Strategy, Regional Marketing, Legal, Regulatory, Compliance, Medical Affairs, and Patient Services. All in one room (or one video call), reviewing progress and surfacing concerns together.

The first few meetings were awkward. These groups weren't used to collaborating. They were used to reviewing each other's work and finding problems with it. The dynamic was inherently adversarial.

But something shifted around month two. Instead of waiting to be asked for approval, the compliance stakeholders started offering input proactively. "If you're going to build that feature, here's how to structure it so it won't trigger a regulatory review in Germany." "The way you're describing this patient resource will create issues in France. Here's alternative language that accomplishes the same goal."

They stopped being gatekeepers and started being collaborators. Not because their standards changed, but because their role changed. They weren't reviewing finished work looking for problems. They were shaping work-in-progress to prevent problems from occurring.

The results were dramatic.

We projected a 52% reduction in development and maintenance costs compared to the existing fragmented ecosystem. Our implementation timeline came in 40% faster than any comparable initiative at Novartis. And perhaps most importantly, we had zero late-stage compliance rejections. Not one.



Every regulatory requirement was baked into the architecture from the beginning because the people who understood those requirements were in the room when we designed it.

What Most Companies Get Wrong

After Novartis, I've led cross-functional initiatives at organizations ranging from startups to Fortune 500 enterprises. The pattern I see repeatedly is the same one I disrupted at Novartis: teams treat compliance, legal, and regulatory functions as obstacles to navigate rather than expertise to integrate.

This creates a predictable failure mode.

Phase 1: Digital team builds something they're proud of, optimizing for user experience and technical architecture.

Phase 2: Legal/Compliance review reveals issues that require significant rework.

Phase 3: Rework delays launch, increases costs, and creates friction between teams.

Phase 4: Everyone blames the "slow" compliance process, reinforcing the belief that these stakeholders should be avoided as long as possible.

Phase 5: Next project repeats the same cycle.

The dysfunction is self-reinforcing. Each failed handoff makes teams more likely to delay stakeholder engagement, which makes late-stage rejections more likely, which makes teams more resentful, which makes them delay engagement even further.

Breaking this cycle requires structural change, not just cultural goodwill. You can't ask teams to "collaborate better" without changing the systems that incentivize them to work in isolation.

A Framework for Cross-Functional Integration

Based on my experience at Novartis and subsequent client work, here's the framework I use for building cross-functional teams that actually function:

1. Identify Your "Veto Stakeholders" Before You Start

Every project has stakeholders who can kill it at the end. In regulated industries, these are typically Legal, Compliance, and Regulatory. In other contexts, they might be Security, Finance, or Operations.

List every person or function that could reject your finished work. These are the people you need in the room from day one, not day ninety.

At Novartis, my veto stakeholder list included: Global Legal, Regional Legal (for key markets), Regulatory Affairs, Medical Affairs, Patient Services, IT Security, and Data Privacy. Eight distinct functions, each with the power to derail the project at the finish line.

2. Create a Recurring Forum with Decision Rights

Ad-hoc collaboration doesn't work. You need a structured forum with a regular cadence and clear decision-making authority.

At Novartis, our bi-weekly Coalition meetings weren't status updates. They were working sessions where we made real decisions. Each function had a representative empowered to speak for their department. When we reached consensus in the room, it stuck.

This requires executive sponsorship. Someone with enough authority needs to mandate that functional representatives actually attend and actually have decision rights. Otherwise, you get "I need to check with my boss" on every issue, which defeats the purpose.

3. Design Workflows Around Constraint Identification

Most project workflows are designed to produce deliverables. Requirements, wireframes, prototypes, code, content. The assumption is that if you produce good deliverables, approval will follow.

Flip this model. Design workflows around identifying constraints early rather than producing deliverables that might violate them.

In our Novartis Coalition meetings, we spent the first thirty minutes of each session on "constraint surfacing." Each function would share upcoming regulatory changes, policy updates, or concerns about the current direction. Only after mapping the constraint landscape would we discuss deliverables.

This front-loaded the difficult conversations. Issues that would typically surface at final review came up in week three instead of month nine.

4. Make Compliance Expertise Accessible, Not Just Reviewable

Most organizations treat compliance as a review function. You submit work, they review it, they tell you what's wrong. This positions them as judges rather than collaborators.

Create mechanisms for your build team to access compliance expertise informally and continuously. At Novartis, I established "office hours" where developers and designers could bring questions to our Legal and Regulatory representatives without formal review processes.

A UX designer wondering about cookie consent could get a fifteen-minute answer instead of submitting a formal review request and waiting two weeks. This dramatically accelerated decision-making at the working level.

5. Measure Time-to-Compliance, Not Just Time-to-Launch

Traditional project metrics focus on delivery milestones. Did we ship on time? Did we hit the feature target?

These metrics incentivize teams to delay compliance engagement because it appears to slow down delivery. But the real metric that matters is time from project start to fully-compliant deployment.



At Novartis, we tracked both. Our raw development time was slightly longer than previous projects because we were doing more upfront work with stakeholders. But our total time-to-compliant-deployment was 40% faster because we eliminated the rework cycles that typically followed "completed" projects.

The RACI Trap (And How to Avoid It)

Every consultant loves a RACI matrix. Responsible, Accountable, Consulted, Informed. It's a clean way to document who does what.

The problem is that RACI matrices often reinforce the sequential handoff model that kills cross-functional collaboration. If Legal is "Consulted" on technical architecture, they get asked for input but aren't responsible for the outcome. This lets the technical team ignore their input without consequence.

I use a modified approach I call RACI+V, where V stands for "Veto." Any stakeholder with veto power over the final deliverable gets elevated beyond "Consulted" to an explicit acknowledgment that their approval is required for success.

This changes the dynamic. When the technical architecture lead knows that Legal has explicit veto power documented in the project charter, they're more likely to integrate Legal's input rather than treating it as optional feedback.

Why This Works in Regulated Industries (And Everywhere Else)

I've applied this framework most extensively in pharmaceutical and healthcare contexts, where regulatory complexity makes early stakeholder integration especially valuable. But the principles apply broadly.

At a B2B SaaS company called INRIX, I used a similar approach to align marketing, sales, and product around a lead nurturing initiative. By bringing Sales into the process during campaign design rather than just handing them "marketing qualified leads," we tripled conversion rates. Sales understood what the leads had seen and engaged with. Marketing understood what Sales needed to close. The handoff became a collaboration.

At Nielsen, integrating the sales team into our Salesforce and Marketo implementation from the beginning meant the system was designed around how they actually worked, not how we assumed they worked. The result was 23% higher close rates because adoption was built into the architecture.

The pattern is consistent: early integration of downstream stakeholders produces better outcomes than sequential handoffs, regardless of industry.

The Validation That Mattered Most

Here's something I don't mention often: I left Novartis before the platform we designed was fully built.

The strategy, architecture, and governance model were complete. Implementation was underway. But the multi-year build-out happened after my departure.

And it worked.

The team I left behind continued executing the strategy we'd developed together. The platform launched successfully across the 90-country footprint. The projected cost savings materialized. The compliance framework held.

That's the real test of a cross-functional approach. It's not whether the leader who designed it can hold things together through sheer force of will. It's whether the structure itself is robust enough to survive leadership transitions.

The bi-weekly Coalition meetings continued without me. The constraint-surfacing workflow continued without me. The relationships between technical teams and compliance functions continued without me.

That's what sustainable cross-functional collaboration looks like. Not a charismatic leader bringing people together, but a system that makes collaboration the default even when specific individuals change.

Building Your Cross-Functional Foundation

If you're leading a digital transformation initiative, especially in a regulated industry, here's where to start:

• This week: List every stakeholder who could veto your project at the end. Be comprehensive. Include anyone whose rejection would require significant rework.
• This month: Establish a recurring forum that includes those veto stakeholders. Give it a regular cadence and clear decision rights. Get executive sponsorship to ensure attendance and authority.
• This quarter: Redesign your project workflows around early constraint identification. Front-load the difficult conversations. Create informal channels for your build team to access compliance expertise without formal review processes.
• Ongoing: Measure time-to-compliant-deployment, not just time-to-delivery. Hold yourself accountable for the metric that actually matters.

The organizations that master this approach don't just deliver projects faster. They build institutional capability for navigating complexity. Each successful cross-functional initiative makes the next one easier because relationships exist, trust has been established, and patterns are understood.

That's the real competitive advantage. Not a single successful project, but a system that produces successful projects repeatedly.