The great divide: Separating operations and innovation

This article was co-authored by Duke Dyksterhouse, an Associate at Metis Strategy.

After transforming their organization’s operating model, realigning teams to products rather than to projects, CIOs we consult arrive at an inevitable question: “What next?” Of the many possible answers, some of our clients elect to carry the transformation further by separating their employees into two groups: those responsible for operations and those responsible for innovation.

By operations, we mean work that fixes or hones the processes and tools already employed in an organization. You might know it by one of its aliases: sustain, keep-the-lights-on, run-the-business, or support. By innovation we mean transformational work, the construction of new processes and products, often of the sort that generate revenue, improve experiences, or pivot the enterprise.

In many organizations, the same group, team, or even individual handles both responsibilities, which is fine. But by assigning these responsibilities to different resources, some organizations can drive focus, sharpen capacity calculations, and simplify strategic planning, especially amid a product-led operating model, which can make such a division more attractive for several reasons.

First, it’s a straightforward proposition whose end state is relatively easy to envision and measure, making it a nice palate cleanser for those still wrapping their heads around the broader operating model shift. Second, because product teams are permanent, unlike temporary project teams, product-led operating models are more amenable to a division of responsibility that is more methodical and longer-standing. And finally, separating the two roles within product teams can give individuals more clarity and focus, primarily by reducing multitasking.

Splitting these responsibilities without a clear vision and careful plan, however, can spell disaster, reversing the progress begotten by a new operating model. If you’re considering separating operations and innovation responsibilities in your own organization, weigh the following trade-offs before deciding. And if you proceed with the split, let the principles below guide your moves.

Trade-offs

Advantages

Focus: Enhanced focus is perhaps the greatest benefit teams stand to gain from a division of responsibilities. That focus can streamline operations and bring much-needed structure to the time spent exploring new ideas, vital to a company’s long-term success. Employees responsible for both innovation and operations too often are forced (usually by their own managers and technology leaders) to sacrifice the former in favor of the latter. Dividing the labor by work type helps guard against this.

Streamlined capacity management and resource planning: Capacity management becomes easier when it’s split into smaller pieces, especially when the split is by type of work. Operations will always take priority over innovation whenever there’s a fire. The problem is that there’s always a problem: a server to be restored, a computer to be fixed, a security flaw to be patched. If the resources responsible for keeping things up and running are the same as those responsible for transforming the company, it stands to reason that the company’s innovative activities will stall, and its capacity calculations will prove an unreliable input to its strategy and budget. For those considering outsourcing or offshoring key functions of IT, the split can shine light on which capabilities are commoditized and which are differentiating. 

Clearer strategic planning: Splitting operations and innovation doesn’t erase each one’s dependencies on the other, but the split can make those dependencies easier to coordinate, in part due to the clarity gained through streamlined capacity management and budgeting. Road-mapping and transformations also become easier as each group can undertake the work that will most affect its assigned success metrics. When operations and innovation activities reside under the same umbrella, those metrics might be at odds, such as measures of reliability and stability versus those of experimentation.

Disadvantages

Navigating the divide: The biggest downside to separating responsibilities is that doing so introduces an explicit divide that teams and their leaders must navigate. Their failure to do so can create work silos and dilute responsibility. Innovation teams, once they’ve developed a viable product, must resist the temptation to “throw their work over the wall” to the ops team. That temptation runs counter to the spirit of today’s best product-oriented operating models, and giving in to it will return the organization to square one. Establishing norms that specify how long a new product will be owned by innovation, what performance measures must be met before it is transitioned, and the knowledge transfer process is critical for organizations that successfully navigate the divide.

Relationship Management: In product teams where there is no formal split between responsibilities, teammates will often come to some tacit agreement of who’s responsible for what. In part, this is because they are held accountable as a team. But where there is a formal split, that agreement may dissolve and thus introduce a need for deliberate coordination. If that need exists, address it. Instate a manager to oversee both parties. Or instate procedures or cadences that keep them aligned. Whatever the solution, it must make unmistakably clear who is responsible for what.

Operations Burnout: While many will love focusing on ops, there will be others that despise it and view it as a career-limiting move. Have discussions with your teams. See what moves make sense for individuals’ career aspirations. Consider the idea of rotational programs to provide the option or requirement to work in different domains to develop a “full-stack” skill set.

Key principles and considerations

Splitting responsibilities should not be taken lightly. Doing so can destroy the gains made in the shift to a product-focused operating model, with the consequences reverberating across every part of the organization. If you do decide to draw the line, keep these principles top of mind to help ensure the split preserves momentum and delivers value.

Create a “One IT” mindset: Splitting responsibilities should not equate to splitting the team, at least in spirit. A sports analogy might be appropriate here. While the players on a sports team have different responsibilities, they play as a single unit. Similarly, an ops-innovation divided team must play as a single unit, chasing the same objectives, attending the same strategic meetings, and anticipating the consequences of each other’s moves.

Determine the appropriate level for the split: You needn’t split the responsibilities of all teams identically; often they can be split at multiple levels in an operating model. Consider a model in which product teams are loosely grouped by links in the value chain. For one link, say Marketing & Sales, you may decide it’s appropriate to divide operations and innovation at the broadest level of that link, sharing the operations resources across all product teams that compose Marketing & Sales. But for another link, such as Corporate Financials, you might split responsibilities at a more granular level, perhaps by individual product teams. In that case, operations resources are not shared across the link but dedicated to a specific team. The consideration here is the same as all centralization-decentralization trade-offs: standardization versus customization.

Take the time to clearly define operations versus innovation work: Define precisely what qualifies as operations and what as innovation; ambiguity will lead to chaos and strain. A client of ours in the healthcare industry worked closely with its engineers to classify work right down to the ticket type.

Stay focused on agility and business value: The goals and tempos of the two groups will vary, but that’s no excuse to operate in isolation. Teams must be coordinated in their moves. Two effective means of engendering that coordination are: one, align teams to the same business objectives. If the teams’ work don’t eventually translate to customer value, then it’s moot. And two, if the teams follow different Agile methodologies, align their key elements: their release schedules, their PI planning, perhaps even their retrospectives. These ceremonies are like the beats in a song; they will keep teams in sync even if they dance to different melodies.    

Have impeccable ITSM: If you split responsibilities and one side of the division struggles, the other side will absorb the load, and you’ll lose the benefits of the split while still incurring its costs. So, before you split things, hone your ITSM. Hire resources with the right skills, arm them with the right tools, and lay tight escalation paths that they can follow when they do, in fact, need help from the innovation teams.

Embrace APIs and microservices: After splitting operations and innovation, there will be a constant and ever-evolving need to align the systems and processes that govern the two groups. A robust catalog of APIs and microservices can alleviate many of these pressures by empowering teams to navigate this split for themselves, rather than having the coordination handed down to them from the top.

Dividing resources by the type of work they’re responsible for, operations versus innovation, can amplify the benefits of a product-oriented model. But it’s a move that requires precision. Articulating what qualifies for each type of work, dividing at the right level of the op model, coordinating teams to move as a unit—these are but a few of the variables that can squelch an op models’ benefits if handled nonchalantly. Also, to divide responsibilities is not categorically better, even when it’s done right. Whether such a split is silly or sage depends on the idiosyncrasies of the organization. If your gut urges you to keep teams together, listen to it. We’ve laid out the advice that we have simply to say: if you do decide to split things, split them like you mean it.