Empowering Teams Through Metrics at Apple

TCGen is trusted by
these brands and organizations

Workday Logo
Workday Logo

Apple is an iconic brand noted for disruptive innovation. In the heat of the digital revolution that it helped spark, Apple’s products became a portfolio of increasingly complex and diverse offerings. At a crucial point in its growth, the company had to reign in its exuberance and created a disciplined, cross-company product development process.

Apple Logo

The challenge: the lack of a consistent process meant that each team reinvented the wheel. Worse, teams were unaware that they were interdependent on one another. The direction and decisions of one team might conflict with those of another. Conflicts over features and schedules loomed especially on the software side. Decisions made by one software team would have implications in the OS that would crash the work of another team. Cowboy teams acting in isolation also tend to cause conflicts over suppliers and over functional resources.

The most important side effect of the lack of a common product development process was that it inhibited the company’s ability to scale. Teams became inefficient, which weighed heavily on managers. Managerial inefficiency, their inability to transcend day-to-day fire-fighting in order to manage new activities, constrained the firm’s growth and scale-up.

One Bite of the Apple at a Time

Four times Apple tried and failed to adopt a consistent product development process. When I became involved, with my colleague Jeanne Bradford then at Apple, we were determined to vault over this hurdle. Trying to do too much, too soon, was a flaw of earlier efforts. We took a targeted approach. First, we conducted a general assessment and then used its findings to pinpoint a small number of improvement levers. Organizational changes were teased apart and divided into incremental improvements. We chose the most effective levers, and then sequenced and prioritized them.

For each of these key improvement levers, we established a target metric with the aim of seeding the changes within the organization so that they took root. Only when our metrics indicated that an improvement was taking hold did we move on to the next transformation.  Our focus, sequencing of improvements, and its measurability separated this program from earlier efforts.

Empowering Teams with Boundary Conditions

One of the most important transformations was to establish what we call Boundary Conditions accompanied by the Out-of-Bounds process. Boundary conditions are a contract between the teams and management. At the start of each project, the team and management negotiate a contract around approximately five dimensions of a project, usually product cost, features, schedule, quality, or reliability. These boundary conditions identify the big, bold aspirations that the team has for its project. The team and management then agree on quantitative thresholds for each of the boundary conditions, for example a target cost for the product at retail, or a “no later than” date for delivery, tied to an important trade show. It is all-important to the success of the boundary conditions process that each of the dimensions of the project is defined by a quantitative metric.

Boundary Conditions Diagram
Figure 1: Sample Boundary Conditions for Three Dimensions, Quality, Schedule and Features

As long as the team expects to remain within its pre-defined boundary conditions, upper management leaves the team alone. If the team perceives that it is going to cross a boundary (we call this a boundary break) then it has a clear escalation process that we call the Out of Bounds review, a way for teams and management to solve problems and make decisions quickly and cooperatively.

In the case of a boundary break, there are two solution paths. In the first, the team, by prior agreement, simply sends an e-mail proposing to management a solution to the boundary break. If management agrees to the team’s solution, then no meeting is necessary. A new quantitative threshold is agreed upon and the team proceeds as before, with the new threshold as its target.

If management cannot agree with the team’s solution to the boundary break, then a meeting is held to discuss alternatives. Once management and the team have come to an agreement and a conclusion has been reached, a new boundary is made, a new quantitative metric is established, and the team moves forward based on its new remit. After the Out-of-Bounds review is complete, the team starts a new day with new boundary conditions. This approach is immensely liberating for teams and management because it puts them on the same side of the game. Management need not micromanage, while the teams have a clear escalation path and a way to come clean if projects begin to go awry.

Out-of-bounds diagram
Figure 2: Out of Bounds Review Process Flow

A Cultural Hurdle

Some of the biggest barriers to adoption came from the hearts and minds of management. Convincing management to empower the teams was a major challenge. For example, asking managers to let go of weekly status meetings, as a control measure, proved difficult. But if a team is working with known, pre-established boundary conditions there is no need for status meetings. If the project is in-bounds, then the team doesn’t need to waste an hour explaining to management why it’s not in trouble. If the team is running into trouble, then it has a clear process for addressing its dilemmas.

Details in the implementation of the project also proved challenging, for example, agreeing on what subset of management was to oversee projects. The process champions also had to define who gets informed when there is a boundary break. Further negotiations involved the precise nature of a boundary break as well as the question of how soon teams should inform management of a potential break. The teams also had to be convinced that they were obligated to provide a solution in the case of a break. They also had to be trained to hold the discipline of maintaining a single escalation path that went through their Project Manager.

Once buy-in was achieved and the process defined, the implementation began with a trial. We tested our operating assumptions with several teams and key executives. Then we piloted the process in all its details with particular teams. This was largely a learning exercise to understand the specifics of implementation. Having tested the veracity of the method and its implementation, we then ran a training program, in the form of workshops, for all relevant stakeholders.

We phased in the process by first requiring only a subset of teams to follow it. New teams adopted the process as they formed, and we offered retraining at that time. We then attached compliance metrics (“% of teams that have Boundary Conditions”) with a clear goal on the order of 95% compliance within three months.

The Results?

Through focus, starting small, building incrementally, and garnering buy-in from key players, we succeeded in transforming Apple’s new product development environment. A head of product marketing claimed that Apple began to make better decisions faster. The long-term impact of the new process at Apple is clear. The new process was a vital piece in enabling the company to scale. The newly empowered teams, with boundary conditions in place, consumed less of management’s time. There was far less flailing when a project team strayed, because teams and management had a system for making decisions together. The new process slashed waste while it also improved the relationship between the teams and management.

Apple’s case argues for the continued relevance of milestone processes. The ability of companies to scale depends on achieving an appropriate level of product development process maturity. Empowered teams, within the tight, measured framework of the boundary conditions process, liberate managerial time and energy that enables a company to scale. Companies that do not have consistent product development processes will be left behind as they grow, unless they can meet the challenges Apple faced when teams, acting as if they were autonomous, put downward pressure on scalability.

There is a maturity path for new product development organizations. First, move to stabilize the process; then open it up to greater levels of sophistication for example, nesting Agile-style sprints within a milestone process. But companies must crawl and then walk before they can run the marathon.