Innovation teams have a problem, and it's not the one most of us think.

Most innovation teams were never properly designed. They were assembled when a leader secured headcount, hired a few smart people, allocated a budget, and gave the team a vague mandate.

In contrast, the teams that do work almost always have one thing in common. Someone made the foundational choices early: why this team exists, what role it plays, and how it operates within the constraints of the organization it serves.

When Susie Braam took on the responsibility for leading innovation at the UK Foreign Office, she inherited an innovation lab full of talented technologists building solutions that the organization couldn't absorb. Maturity was low, investment decisions were haphazard, and nothing the team created could get adopted.

So she stopped building entirely and redesigned the team from the ground up. Within eighteen months, the number of employees who could evidence impact through innovation had quadrupled.

This article draws on Susie's framework to walk through three of the most critical decisions in that design process: diagnosing the real job the team was hired to do, choosing whether to build, enable, or architect, and mapping the operating model that makes it all hold together.

From assessing organizational readiness, to picking the right orientation, to pressure-testing the whole thing on a canvas before committing resources, it's the starting point for the innovation leader who wants to build a team that lasts longer than one budget cycle.

The mandate most innovation teams receive is some version of "go do innovation." And now, as organizations race to respond to the AI wave, a growing number of innovation leaders are hearing an equally vague variation: "go build us an AI capability." Both mandates set teams up to fail in the same way, because they default to activity instead of purpose. The organization often doesn't know what it actually needs, and figuring that out is the innovation leader's first job.

Before designing an innovation team, its structure, or its focus areas, the person leading the effort needs to answer three foundational questions honestly. Getting them wrong, or skipping them entirely, is how teams end up stretched thin and struggling to show results.

Susie applies the Jobs to Be Done theory to innovation team design itself. The theory, originally developed by Clayton Christensen to understand why customers choose one product over another, is built on a core insight: people don't buy products for what they are, but for the progress those products help them make. Susie's argument is that the same logic applies internally — organizations "hire" innovation teams the way customers hire solutions, to make progress on a specific outcome. And that outcome has layers: functional, emotional, and social.

The functional job is usually the easiest to articulate: solve a specific problem or seize a specific opportunity. But the functional job is only part of the story. Organizations also hire innovation teams for emotional reasons, even if those go unspoken:

And for social reasons, which shape how the organization presents itself to the outside world:

When an innovation team is only designed around the functional job, and the emotional and social drivers remain unclear, sustained executive support becomes difficult to maintain. Understanding all three layers helps build a team that delivers value on the dimensions leadership actually cares about.

Susie's own career illustrates how dramatically these jobs can differ. Her first Head of Innovation role was at the UK Ministry of Defence, where she set up and led incubators focused on counter-terrorism challenges. The stakes were high, the problems were urgent, and the functional, emotional, and social jobs were deeply intertwined: leadership needed new capability built fast, they needed to feel confident in the decisions being made, and the broader national security community needed to demonstrate that it was responding to the moment.

When Susie moved to her second Head of Innovation role at the Foreign Office a few years later, the jobs were entirely different. The functional job was to focus scattered innovation activity on areas with maximum potential and to stop pet projects. The emotional and social jobs were intertwined: leadership wanted to feel confident the organization was keeping pace with the challenges it faced, and they wanted government stakeholders to see that too.

These were two Head of Innovation roles held by the same person, with completely different mandates. That difference is precisely the point: articulating all three layers of the job to be done, functional, emotional, and social, is the foundation everything else is built on. Without that clarity, even the best-resourced team risks solving the wrong problem.

Innovation teams need certain conditions to succeed. Before designing anything, the innovation leader needs to take an honest look at where the organization stands across a few key dimensions.

These conditions range from the obvious to the easily overlooked. Leadership needs to understand what innovation actually requires, not just say it matters. An executive sponsor needs to be willing to spend political capital, not just lend their name. There need to be real resources for experimentation, not an expectation that the team will deliver on top of everyone's day job. And critically, when something does work, the organization needs to be able to absorb it, rather than letting it die in the handover to business as usual.

At the Foreign Office, Susie found that maturity was low across nearly every one of these dimensions. Leadership understanding was minimal, investment decisions were haphazard, and the team she'd inherited kept running into the same blocker: they could innovate, but nothing could get adopted. The organization simply wasn't set up to absorb what they produced. That assessment drove her decision to pivot the team away from building entirely and toward raising innovation maturity across the organization.

Most organizations have tried innovation in some form, even if they don't call it that. The innovation leader's job is to find out what happened, what worked, what failed, and why, then assess what's changed since. Susie calls this "innovation archaeology": the practice of digging into past innovation attempts before launching new ones.

The answers shape what needs to be different this time: stronger sponsorship if past efforts lacked executive support, better clarity on the mandate if that was unclear, someone credible with the core business if the last team was too isolated, or a hard look at what blocked scaling if early success couldn't sustain itself.

At the Foreign Office, Susie's "archaeology" surfaced a pattern she recognized immediately: sporadic efforts, no coordination, leadership disengagement. This was an organization that had tried innovation before and hadn't built the conditions for it to take hold. The team she'd inherited, a group of talented technologists, was the wrong team for this moment, not because of their skills, but because the organization wasn't ready for what they were doing.

That gap between what the team could do and what the organization could absorb forces the question that shapes everything that follows: if the organization isn't ready for creating new solutions yet, what does it need instead?

Susie proposes that innovation teams generally operate in one of three orientations, or primary roles, each serving a fundamentally different purpose. The diagnostic work from the previous section, understanding the jobs to be done and the organization's readiness, feeds directly into this choice. For any innovation leader designing or redesigning a team, this is the critical first decision.

Architects design innovation systems and strategy. They build the frameworks, governance structures, and processes that enable innovation to happen systematically across an organization, rather than in scattered pockets.

For example, a mid-sized media company found itself in exactly this situation. The digital team was experimenting with AI, product development was launching new offerings, and operations was finding workarounds for outdated solutions, all independently. There was no coordination, no shared pipeline, and teams competed for the same resources without being able to articulate how their work connected to strategy. The company didn't need more people building things — it needed someone to design the system around them. So a two-person innovation team spent the following year working as Architects, partnering with newly created lines of business to develop innovation strategies, build pipelines, and create stage-gate processes for investment decisions.

Signals that an Architect orientation may be the right fit:

Builders execute innovation projects and create new solutions, whether that's a product, service, process, or business model.

For instance, a social housing association in the UK was struggling with a specific operational challenge: it was becoming increasingly difficult to gain access to tenant properties for scheduled maintenance visits. The problem was well-defined, executive sponsorship was in place, and budget had been ring-fenced. Because the challenge required dedicated focus and specialist skills, the association assembled a small, focused builder team consisting of a service designer, a data analyst, and a housing specialist. Over six months, this team tested twelve different interventions and scaled three that showed measurable improvement in access rates.

Signals that a Builder orientation may be the right fit:

Enablers support others across the organization to innovate within their own roles. They build innovation capability through training, coaching, and cultural development, rather than delivering innovation projects directly.

This was the orientation Susie chose for her team at the Foreign Office, and it required a hard conversation.

She had inherited a team of technologists and coders who were builders by training, by temperament, and by job description — and she was about to tell them the team's mission was changing entirely.

In practice, she moved the existing builders into other roles where their skills were needed, including cloud technology projects and similar work elsewhere in the organization. Nobody was made redundant, but the innovation team as they'd known it ceased to exist.

In the existing team's place, Susie created a role that had never existed anywhere in UK government: Head of Profession for Entrepreneurship. She hired someone she had seen shift innovation skills and culture in another organization, and together they built a training program and skills framework from scratch, created an internal coaching and peer learning network, and worked with HR to align recognition systems with innovation behaviors. Within eighteen months, the number of employees who could evidence impact through innovation had quadrupled, from a small base of early adopters to a broad network spanning multiple business units. And leadership, which had previously been a barrier, was increasingly championing and supporting innovation efforts across the organization.

Signals that an Enabler orientation may be the right fit:

Choosing the right orientation doesn't mean committing to one forever. But starting with a primary focus matters. Susie explains how to choose that starting point using two dimensions that together form a simple matrix.

The matrix has two dimensions: organizational readiness (how strong are the foundations?) and primary need (is the challenge about changing culture and systems, or delivering specific projects and products?).

Once the orientation is chosen, it's worth pressure-testing it before committing:

In practice, many innovation teams blend orientations, and that can work. But trouble starts when teams try to do all three at once without being clear about which one is primary. A team of one or two people simply cannot design governance systems, create new products, and run training programs simultaneously. Even larger teams benefit from explicit clarity about who is doing what.

Once your team's orientation is clear, the next step is designing how the team actually operates. The key mindset shift here: the team's operating model is a hypothesis, not a permanent structure. Just as startups rarely get their business model right the first time, innovation teams should expect to test, learn, and iterate on how they're set up. The structure that gets designed on day one is almost never the one that eventually works.

To make that design process structured rather than ad hoc, Susie adapted Strategyzer's Business Model Canvas into an Innovation Team Model Canvas. The canvas works like any startup's business model canvas, but the lens is turned inward: the "customers" are internal stakeholders and business units, the "product" is the value the innovation team provides, and the "revenue" is the business impact that justifies the team's existence.

The canvas has eleven sections. On the right-hand side, the part visible to the team's internal "customers":

On the left-hand side, the operational infrastructure behind the scenes:

The most important constraint in the canvas is that the left side has to fit within the budget. The cost of key activities, resources, and partnerships cannot exceed what's actually available. Rather than designing an ideal model and then lobbying for more funding, the canvas forces innovation leaders to work within their constraints and find creative ways to deliver value, whether that means reducing scope, partnering instead of building internally, or focusing on fewer early adopters.

The canvas is a living document, not a one-time exercise.

When Susie's Foreign Office team first shifted to an enablement orientation (focusing on training, coaching, and raising innovation capability rather than building technology), they built and delivered all their innovation training programs in-house, drawing on the subject matter expertise they already had. But as the team developed relationships with external partners, Susie realized something: the team's real value wasn't in delivering training content. It was in coaching and advisory work that required deep understanding of the Foreign Office's business context, something no external partner could replicate. 

Upon this realization, they shifted the model: external partners, such as consultancies and specialist training providers, took over delivering the structured training programs, while the internal team redeployed toward higher-value work, such as one-to-one coaching with leaders and co-designing innovation strategies with individual business units. The mission stayed the same, but the operating model changed to play to the team's actual strengths.

Back at the Foreign Office, Susie's deliberate progression showed how the framework plays out over time. The enablement work raised organizational maturity. Leaders who had previously been blockers started to engage. And that opened the door to innovation strategy and governance: innovation pipelines, portfolio strategy, investment decision frameworks, working with individual lines of business to figure out what they wanted in their portfolios and how ambitious they were willing to be.

Then came the deep systems work: getting finance, legal, and compliance to nominate someone in their area as an innovation point of contact. Whenever the innovation team came up against a blocker in one of those functions, the conversation shifted from "that's not how we do things" to "right, we need to redesign this process for innovation".

And toward the end of her time there, as COVID disrupted every process across the organization, the team started to build again — not the disconnected pet projects she'd inherited, but focused projects shaped by the strategy, governance, and organizational capability that now existed.

Each transition was a deliberate response to what the organization was ready for, not what the team wished it was ready for. The enablement phase took eighteen months before the strategy and governance work could begin. That kind of patience is rare in innovation, where the pressure to show results fast is relentless. But it's also what separates teams that last from teams that produce one impressive quarter and then get cut.

Susie's team didn't transform innovation capability across the organization by working harder or hiring more people. They did it by making the call most innovation leaders resist: designing the team around what the organization actually needed, not what it said it wanted. That meant stopping before building, enabling before architecting, and waiting eighteen months before the work they're now known for could even begin.

The orientation matrix, the canvas, and the diagnostic questions in this article are the same tools that shaped those decisions. The only question left is what your team would look like if someone actually designed it.

Most innovation work needs different functional teams to move together.

As such, it runs straight into the reality of how most organizations operate: in silos, each with its own priorities, its own reporting lines, its own definition of success. What's missing is the hardest part: a way to actually work together across those (imaganery) lines.

That's exactly the layer that needs building after team design. Not just how the innovation team operates internally, but how it aligns and collaborates with the functions around it.

Mary Catherine Plunkett, Vice President Customer Success Design at Autodesk, spent thirteen years watching cross-functional work play out the same way: energy, good intentions, then a slow death by handoff. When a CEO-backed mandate to rethink innovation inside customer success landed on her desk, she built a way to pull people out of their silos and into the same room, borrowing a concept from product and engineering.

The structure she landed on? The pod model. A small, standing cross-functional team built around a single problem, with shared goals and a weekly rhythm.

Six months post-launch, 8 pods with 60 people are running across customer success, shipping work that had been stuck for over a year. Here's how this model works.

Every pod starts with a problem that already has multiple functions talking past each other. That problem becomes the pod's mission. The roles needed to solve it end to end determine who's in the pod. At Autodesk, that means a service line manager, service designer, product/tech lead, and field team members pulled from their respective functions into a single working unit. The service line manager acts as champion and strategy holder, but everyone contributes to the agenda.

The composition will arguably look different across organizations. What matters is that the pod owns an outcome, not just a set of activities. For example, one of MC's pods owns the entire digital support experience. Another is building a zero-to-one data product for technology managers.

Before setting up a pod, pressure-test whether the problem warrants one:

If you said “yes” to more than three, you can safely bring the problem into the pod.

Here's a scene many innovation leaders will recognize: a cross-functional meeting where every function shows up with its own data, calculated differently, tied to different targets. Product optimizes for one thing, the field team for another, and the meeting becomes a translation exercise rather than a working session. Nothing is technically wrong, but the teams aren't solving the same problem.

MC makes shared goals the entry price for every pod. These replace the competing functional targets that create silos in the first place. In practice, that means:

As simple as it sounds, this is the single biggest unlock. The energy that goes into prioritization arguments now goes into the work instead.

Here's another familiar trap: a new cross-functional team launches and spends its entire first quarter designing how to collaborate. RACIs, process maps, meeting cadences. By the time the operating model is "ready," the momentum is gone.

The fix is a ratio: spend 80% of energy on actual work, 20% on process. Here's what that looks like:

The deliverables keep pods aligned, while the freedom keeps them moving.

Cross-functional pods don't build shared culture by accident, especially when members still report into different functions. Four rituals are weaved into its operating rhythm:

Individually, these are small moves. Together, they give the pod a shared heartbeat.

How Beca turned a values clash in a new ventures team into a shared operating agreement.

About six years ago, Jeannine Walsh was asked to set up the new ventures team at Beca, a century-old professional services engineering firm headquartered in New Zealand.

The very first project she launched was a twelve-week internal bootcamp with four teams. Each team combined entrepreneurial operators from her new innovation unit with domain experts from the core business, the idea being that a venture team needed both the agility to experiment and the technical depth to build something Beca could actually ship. Jeannine knew mixing the two groups would create friction but that was the whole point.

By the end of the first week, she could see the seams. People who were meant to be collaborators were sitting across tables like polite strangers, each wondering what the other had been brought in to do.

The biggest fracture Jeannine noticed was over how differently individuals were treating failure. For the entrepreneurs, failure was a learning opportunity, a necessary step toward something new. For the engineers, it meant something closer to negligence. Their day jobs involved designing infrastructure that could not fail; they were paid, quite literally, not to fail.

This bootcamp was built on entrepreneurial principles, which meant that by design it was asking the engineers to treat failure as learning. For them, that wasn't just a small mindset adjustment. It was a challenge to the professional identity that had earned them their seat at the table.

To bridge the gap, Jeannine introduced an activity called Above the Line / Below the Line. The activity starts with Beca's corporate values. "Those values aren't just a poster on the wall, they actually get felt and seen and heard through the decisions that the company makes," Jeannine says. Two of them, tenacity and enjoyment, mattered most for venture work. Everyone in the room already shared them in principle. What they didn't share was a common picture of what those values looked like in practice, in the uncertain, unfamiliar work of building something new.

This is what the activity builds together. For each value, the four bootcamp teams define what behaviors live up to it (above the line) and what behaviors work against it (below the line). It runs in five steps. Everyone is brought together and the activity is introduced. A large sheet of paper goes up somewhere visible, and people add to it individually over a week; Jeannine wanted the quieter people in the room to have time to think. She then consolidates the contributions into a draft, which goes back up for another week so people can push back if they want.

Finally, there is a ceremony. Jeannine uses the word on purpose: it signals that this is a moment to mark, not a meeting to run through. Everyone meets again, looks at the document together, and signs it. It's a public commitment to the behaviors on the page, and to giving and receiving feedback when someone lives them out or falls short.

A few weeks into the bootcamp, the document got its first real test. One of the teams had just delivered an investment pitch. They'd secured the investment, but the committee had been confused, and one voice on the panel had been sharply critical of their work.

The debrief started out as retrospectives do, calm enough, and then began to slide. Frustration fed frustration. The room got stuck on what had gone wrong and who had said what, unable to reach for what they could learn. Jeannine let it run; people needed to feel heard. But she was watching something she recognized, and when it became unmistakable she quietly named it: the team was falling below the line. They were staying stuck on what had gone wrong and feeding off each other's negativity, both behaviors they'd agreed weeks earlier to call out. The above-the-line alternative, accepting the outcome and learning from it, had slipped out of reach.

Jeannine didn’t tell them off. She simply pointed at something they had written themselves and signed their names to. As the standard came from the team, nobody got defensive, and they could agree to step away and come back to it another day.

At the end of the twelve weeks, with a few of the teams deciding to carry on past the bootcamp, the cohort met again to look at the document and decided the behaviors still held. This time, instead of adding their signatures, they pressed their fingerprints onto the same page.

Twelve weeks earlier, these were people whose values had collided on the first day. Now, they were standing around a values agreement they had sealed with their own fingerprints.

The activity didn't stay in that bootcamp. In the six or seven years since, every new venture team Jeannine has launched at Beca has started the same way, with the same sheet of paper and the same ceremony. The gap between how engineers and entrepreneurs see failure never fully closed, but the team learned to call it out when it was costing them. In the pitch debrief, it had taken Jeannine naming it to break the spiral; a few weeks later, teammates were doing it for each other.

The document made its way into their monthly meetings as a prompt, a way of opening conversations across silos that wouldn't otherwise happen, and people who had been uncomfortable giving feedback at the start were giving it fluently by the end. The clash wasn't resolved so much as named, out loud, in each other's company, every month.

The signatures said: we agree to these behaviors. The fingerprints, twelve weeks later, said something harder. They said: we agree with each other.

That's what Above the Line / Below the Line actually produces. This was not just a document, but an agreement between people who had no reason to trust each other on day one, and every reason to by week twelve.

You can design a team, you can run its internal rhythms with discipline, and you will still run into the same question Jeannine did in week one: how do people from different corners of the company work together without talking past each other?

The answer, she suggests, isn't a process. It's a page, written in their own words, signed in their own hands.

That’s it for today.

Hope you enjoyed this sixth edition of the Compass. Next time, we’ll explore a new way to measure innovation, offering a common language to connect risk and exprimentation to value.

Hans Balmaekers
Founder, the Compass and Chief @ Innov8rs

PS- best to move this newsletter to your primary inbox, or ‘whitelist’ our domain, to ensure we don’t end up in your promo or spam dungeons…

PPS- feel free to forward this newsletter to all the intrapreneurs in your company and network. Sharing is… indeed!