Most organizations assume that simply hiring an innovation team will drive results.
The mandate comes down from leadership as a vague directive; "We need to be more innovative." A team is assembled, a lab is built, or an accelerator is launched. Months or years later, frustration sets in. The team is busy, yet the organization sees no tangible outcomes.
The issue is a fundamental misalignment between team design and the actual job the organization needs that team to do.
Susie Braam, Innovation Strategy Advisor, applies the "Jobs To Be Done" theory to organizational design. The approach clarifies team purpose and reveals whether you need Builders, Enablers, or Architects based on organizational maturity and readiness.
To check the full session recording, upgrade to Premium
The "Jobs To Be Done" of an Innovation Team
Diagnose the real problem before hiring the solution
The "Jobs to Be Done" methodology typically helps understand customer needs. We ask, "Why is a customer hiring this product?" Clay Christensen famously explained that people don't just buy a milkshake; they "hire" it to do a job—perhaps to stave off hunger during a commute or to provide a moment of comfort.
This lens must turn inward. When an organization hires an innovation team, what is the job they are hiring that team to do? It is rarely as simple as "make new things."
Just like consumer products, an innovation function has three distinct types of jobs to be done:
Functional Jobs: What is the practical outcome the organization needs? Is it to share data more quickly across departments? Is it to stop "pet projects" and focus resources on high-potential ideas? Is it to gain market share?
Emotional Jobs: How does leadership need to feel? Do they need to feel confident in their decision-making? Do they need to feel safe that the organization isn't being left behind?
Social Jobs: How does the organization want to be perceived by others? Does it need to signal to investors, government stakeholders, or the public that it is cutting-edge and responding to modern challenges?
Applying this lens reveals hidden motivations. Susie shares a personal example from her time setting up counter-terrorism incubators in the UK. The functional job was clear: share data across the national security community to keep the country safe. However, the emotional job was just as critical: senior leaders needed to sleep at night feeling confident in the decisions they were making to close or pursue investigations. The social job was to show the government and the public that, following a series of attacks, the agency was actively responding to the challenge.
Innovation leaders must look beyond the functional request. If a CEO says, "I want to drive innovation," you have to ask "Why?" until you uncover the root cause. Are they seeing a drop in market share? Are they worried about a specific competitor? Or is it an emotional need to feel relevant in a changing market?
The Three Types of Innovation Teams
Match your team design to the job you're actually hired to do
Once you understand the job to be done, you can determine what type of team you actually need. Teams often blend these roles in practice, yet understanding the primary orientation is crucial for alignment.
1. Builders
Create new products, services, and ventures
These are the teams most people imagine when they hear "innovation." They focus on creating new solutions, products, and ventures.
Focus: Building new products, services, or corporate ventures.
Examples: Corporate venture labs, R&D units, or incubators building specific solutions (like the counter-terrorism tools Susie mentioned).
The Trap: Organizations often default to this model without the necessary infrastructure to scale what is built.
2. Enablers
Raise innovation capability across the entire organization
Enablers do not build the product themselves; they support the rest of the organization to innovate.
Focus: Providing training, coaching, and resources.
Activities: Running innovation training programs, coaching leadership, scouting for startups, or facilitating workshops.
The Goal: To raise the overall capability of the organization so that innovation can happen anywhere.
3. Architects
Design the systems and governance that allow innovation to survive
Architects focus on the deep systems of the organization. They design the strategy and governance that allow innovation to survive.
Focus: Designing innovation systems, strategy, and governance.
Activities: Formulating innovation strategy, designing the end-to-end pipeline, deciding how ideas enter the funnel, and determining how funding and "defunding" decisions are made.
The Gap: This is often the most under-represented role, yet it is essential for long-term transformation. The polling data confirms this critical function remains underutilized despite its importance.
Not enough Architects?
Innovation leaders across industries report the following distribution of current functions:
40% supporting others' innovation efforts (Enablers)
30% combination of multiple functions
20% building new products and services (Builders)
10% designing strategy/governance (Architects)
Given today’s pressure to adapt quickly and reinvent processes, structures, and organizational mindsets, the architect role should be more prevalent. The low representation reveals the core challenge: organizing for change and transformation is exceptionally complicated for larger companies. This might be why most innovation functions fail.
The Team Orientation Matrix
Position your team based on maturity and focus
One of the biggest pitfalls is small teams trying to do everything at once. A team of five people with a limited budget cannot be Builders, Enablers, and Architects simultaneously—at least effectively.
Susie introduces a matrix to help leaders situate their team based on two factors:
Organizational Readiness (Y-Axis): How mature is the organization regarding innovation? Is leadership bought in? Is there a shared language and understanding?
Focus of Change (X-Axis): Is the primary need to change culture and systems, or is it to produce specific projects and products?
If Maturity is Low: Start with enablement or guerrilla building
You cannot jump straight to being an Architect or a large-scale Builder.
You must start with Enablement. Your job is to run a campaign to raise leadership awareness, build a shared taxonomy, and develop basic skills.
Alternatively, if you must build, you start very small. You act as a "guerrilla" innovator—piloting one clearly defined problem to prove value and tell a story that builds buy-in.
If Maturity is High: Earn the right to design deep systems
You earn the right to move into the Architect space. You can start designing deep systems, governance, and portfolios because the organization understands the need for them.
You can execute large-scale Building projects because there is a reception path for the solutions you create.
Team Orientation Is Not Static
Constantly reassess and adapt your team's primary function
As the organization's maturity changes, the team's function must evolve.
Susie illustrates this with her experience at the Foreign Office. She inherited a team of Builders—technologists and coders working on disconnected projects. However, she diagnosed that the organization's maturity was low; the business units didn't understand innovation, and the solutions being built had nowhere to land.
Susie made a deliberate strategic pivot. She shifted the team's primary function from Building to Enabling. She had to change the team composition, moving technologists to other roles and bringing in people who could design skills, frameworks and training programs. This was difficult and unpopular with the existing team, yet necessary to meet the organization where it actually was.
She created a brand new role that never before existed in the UK government. The job was literally to develop a skills framework and training program so people even understood what innovation was, what the methodology was, and how to do it.
Eighteen months later, as maturity rose, the team evolved again. They began to take on Architect roles—helping business units write strategies and manage pipelines—and eventually moved back into some targeted Building.
The key lesson: You must constantly assess: "What is the primary function of my team today? Is that the right focus given our current maturity? And do we have the right skills to execute that specific function?"
You need to meet the organization where it is, not where you want it to be. Success requires patience with the pace of change.
Innovation management is about building the capacity to solve problems. By understanding the job you are hired to do, and aligning your team's orientation to the organization's reality, you stop fighting the system and start transforming it.
