Assessing an Organization's Capabilities: Resources, Processes, Priorities

The most crucial thing in innovation is trial and error. You need enough resources to experiment cheaply, and keep at it until something works.

Let's keep looking at "disruptive innovation" from an organizational angle. The case here is Nypro. The background:

Nypro wanted to adopt an innovative molding technology. It made mold changes in the production process much easier and gave far more capacity for flexible manufacturing — short cycles, small batches — though it certainly wasn't as precise as the old technology. At this point Nypro faced three options:

1. Build a factory that uses only the new technology, overseen personally by the CEO;

2. Install 2–3 of the new machines in each of its 21 existing factories around the world;

3. Put it into one of the factories, focus on making it succeed there, then replicate it in the others.

On the organizational question of innovation:

Many companies' innovations fail not because of some fatal technical flaw, nor because no market exists yet. They fail because the innovative business wasn't entrusted to a fitting organization. The very DNA that made an organization successful may be exactly what blocks its path to innovation. I really like the RPP model. It helps you understand what an organization is, what it can do and what it can't — and, more importantly, when a new technology or new business comes in, it lets us re-examine where in the organization the "existing capabilities" and the "disabilities" lie.

When we talk about "capabilities," we can break them down into three elements:

Resources

Processes

Priorities

That's the RPP model.

Resources: the most tangible — people, equipment, technology, product designs, brands, information, cash, even relationships with suppliers, distributors and customers.

Resources are visible and flexible; they can usually be measured, hired, bought, sold and transferred across organizations.

Processes: an organization creates value by transforming inputs of resources into products and services of greater worth. The patterns of interaction, coordination, communication and decision-making it goes through along the way are its processes — including how it develops and manufactures, and the methods it uses for procurement, market research, developing employees, allocating resources and so on.

Some processes are "formal": clearly defined, codified and documented. Others are "informal": routines or ways of working that have formed over time, some of which have even become part of the organization's culture.

Processes emerge in response to specific recurring tasks. They are set up to help employees perform recurring tasks consistently and well, time after time, without intensive managerial oversight. In organizations whose targets shift, this tends to work well. But in a flexible, fast-changing business, a process that is effective for one task can become an obstacle to another.

When analysing whether a process is a capability or a disability, what matters most is not the obvious value-adding processes in logistics, development, manufacturing and service, but the underlying processes that support investment decisions: the habitual ways market research is done, how analysis is translated into financial projections, how plans and budgets are negotiated, how that data is delivered, the types of goals management is held accountable for, KPIs and so on. An organization's most serious disabilities in building disruptive growth businesses are most likely to come from these processes.

Whether a process is a capability or a disability for a new business is hard to judge. But one question you can ask is: has this organization faced a similar task before? If it has handled this kind of business repeatedly, it has very likely formed a particular process. That's when you need to take care to build a more suitable process, or managers will instinctively follow the old one.

Priorities: team members at every level have a ranking of priorities. Management decides how to allocate funds to new products, services and processes; salespeople decide which customers to call, which products to push and which to de-emphasise; engineers choosing design options and production schedulers sequencing orders all work from an order of priorities.

Let members at every level make priority decisions autonomously, in line with the company's business and profit model. Every member must prioritise "the things that help the company make money the way it should and ensure it survives and thrives."

Resources and processes tend to define what a company "can do," while priorities define what an organization "cannot do." For example, if a company's overhead structure requires it to achieve 40% gross margins, then its decision rule is that no decision below a 40% gross margin can be proposed or approved — vs. another company whose business model has a different cost structure, which might pursue that same decision urgently and as a priority.

A successful company's priorities can shift along two dimensions:

Rising gross margins. As companies upgrade their products and services to compete in higher-end markets, they tend to add overhead, so margins that once looked attractive may no longer appeal. What a company can put at the top of its priorities may change as it moves upmarket. Declining appeal of small opportunities. As successful companies grow larger, they need bigger absolute revenue gains to sustain the same high growth rate. So they cannot deploy resources against markets that are very small today but will be very large tomorrow — their already-changed priorities don't allow it.

This is also why mergers and acquisitions are so hard. After two already-huge companies merge, they think they've saved costs and strengthened their resources, but what the resulting company should treat as its priorities requires enormous care. Their organizations are so vast that they often have no appetite for small opportunities. Unless it keeps dividing itself into smaller units, sheer size becomes a very real disability.

Startups should pay attention to RPP too

In the early stage, a company relies mainly on resources: a few key people joining or leaving, the success of a patented technology and so on. Over time, organizational capability migrates towards processes and priorities. As people successfully tackle recurring tasks together, processes get defined; as the business model succeeds, it becomes clear which businesses should be given the highest importance.

Many startup teams lose their shine after their initial success, and one very important reason is that the original resource — the founding team — failed to establish the processes and priorities that would keep the company's growth momentum going.

If the centre of gravity of the original innovative capability successfully shifts from R to PP, then who is assigned to which project starts to matter less. The classic example is McKinsey: roughly as many people join each year as leave, yet that doesn't stop them delivering high-quality work. That is a textbook case of not depending on resources.

The initial Ps are validated by being right time after time. Once members of an organization adopt certain PPs as a matter of course, without needing rational judgement, those PPs become the company's culture. As a company grows from a handful of employees to hundreds and thousands, culture lets members act autonomously while staying aligned on goals. When the most powerful factor defining an organization's capabilities has moved from resources to processes and priorities, and finally into corporate culture, it also becomes extremely hard to change.

The best innovation is creating new businesses while the company's mainstream business is still healthy, but that requires different processes and models. So while forming new processes and priorities, management also has to maintain the existing processes and priorities that make the core business succeed. This kind of ambidexterity is quite subtle and hard to master.

An innovative business must have matching organizational processes. We can divide teams into four types:

Functional teams: organizational boundaries are drawn around departments — finance, marketing, manufacturing, engineering and so on — divided by professional skill. Different functional departments work independently; once one department finishes its task, the work moves on to another.

Lightweight teams: when one department might hinder or affect the timing, manner or process by which another department gets its work done, you need a lightweight team, because the people/departments involved in the project have predictable interdependencies. So you need a coordinating, lightweight project manager who shuttles across departments to make sure the work fits together in time and space. But the main work and responsibility stay within the departments. At meetings, each department can send a representative to make sure each department's independent work is on schedule and links up correctly. Many amoeba and matrix organizations are lightweight. Heavyweight teams: when a product's and process's architecture needs to change, unpredictable interdependencies arise — you can't clearly foresee and specify who needs to interact with whom — and resolving these problems often means sacrificing one department's interests in exchange for another's. That's when you need a heavyweight team. For example, optimizing the product architecture may require developing a new component and swapping out others.

Every department with key influence on the project must send someone to join this team, and each member must not keep thinking about "representing" their department's interests; instead, everyone's goal is to jointly work out a better way to coordinate and optimize product performance, quality, cost, customer convenience and so on. All members must work in the same location and be led by a manager with significant clout — someone with a big-picture view who is able to make decisions beyond their own professional expertise.

A heavyweight team is a tool for creating new processes and new ways of collaborating; lightweight and functional teams are tools for exploiting existing processes. However, once a product's and process's framework has been defined and the departments have been set up, keeping a heavyweight team creates a lot of unnecessary overhead. So heavyweight and lightweight teams may be temporary mechanisms, while autonomous teams may be a more lasting organizational form.

Autonomous teams: when facing disruptive innovation, and the company's existing processes cannot rank it ahead of other investments, this is the type of team you need.

What does autonomy mean? Not geographical location, nor ownership structure — a disruptive venture can be wholly owned by the parent company. The key to autonomy lies in processes and priorities: the freedom to create new processes and a new cost structure, so that it can be profitable even when making and selling its first products, and to be allowed to compete with sister divisions — even to cannibalise the existing market.

No organizational unit can effectively accommodate two completely different cost structures or business models at the same time. When managers forcibly merge two units in the name of "saving costs," one or even both will be destroyed. When facing disruptive innovation, an organization needs to create a new organization with a new cost structure in order to develop "the capability to put innovation at the top of its priorities."

In any case, we should remember:

An organization cannot disrupt itself.

Judging at which level of the organizational structure each project should be embedded is a question the CEO must think through when developing new businesses and new processes. Creating new capabilities? — Build or buy. On acquisitions

Build-or-buy is usually about "resources": develop a component or buy it, develop a technology or license it, and so on. But "processes" can also be built or bought — take Toyota.

Toyota regularly compiles manuals based on design problems it has solved. Every time it develops a new platform through a heavyweight team, it puts huge effort into codifying the knowledge of the architecture and interfaces, so that it doesn't need to set up heavyweight teams for subsequent product designs. A great deal of interaction information is recorded in "lessons learned" books, so that Toyota's approach turns one-off experience into processes. Some teams are always gaining experience but never build processes from it. Codifying experience into processes lets you earn compound interest on time.

When acquiring, the question to ask is:

What is the acquired company's core value? Resources or processes?

If it's "resources," then integrating it into the parent makes a lot of sense: plug the acquired people, products, technology and customers into the parent's processes to leverage the parent's existing capabilities.

If it's "processes," then the last thing it should do is fully integrate it into the parent. If processes and the profit model are the key, it's best to keep it independent and have the parent inject resources.

On building

When facing innovation and change, first determine whether you have the "resources" you need, and then you must think through the following questions independently:

• Are the work processes people in the organization are used to suited to solving the new problem?

• Will the organization's business model allow the innovation to be given priority?

It's fine if the answer is "no" — understanding a problem is the most crucial step in solving it.

In addition,

• When attempting innovation, the choice of customers is one of the key points of leverage.

• Strategy can be top-down and "deliberate," or bottom-up and "emergent"; an organization can formulate strategy through its resource allocation process.