Are we functional?

When Steven Sinofsky and Jon DeVaan took on joint management of Windows® 7, they made several significant changes to the entire organization. Two profound changes were creating a single centralized plan and switching to a functional organizational structure. Given the success of Windows 7, some Microsoft® engineers are asking, “If my PUM is a bum—is it time to throw the bums out?”

Maybe, but let’s not get too hasty. Knee-jerk nitwits who act before they think are doomed to repeat old failures in new ways. Everything has its own purpose and place. Before you throw the bums out, consider the role that product unit managers (PUMs) play and how best to balance product and functional demands. Forgotten? Never understood them in the first place? I’ll remind you.

I’m PUMed

PUMs are multidisciplinary managers responsible for the strategic and operational decisions needed to engineer a Microsoft product or major component—at least in theory. In practice, PUMs are often dysfunctional—marginalized from above by their general manager (GM) or from below by their discipline managers. However, when used properly PUMs give small innovative products agility in their market by handling business and execution decisions like a startup-sized team.

PUMs typically appear toward the bottom of product organizations and don’t appear at all in functional organizations. Functional and product organizational structures aren’t new—modern versions of both have been around since the 1970s. Is there a “right” choice? Let’s break it down.

What’s your function?

Functional organizations, like Windows now, are organized by disciplines. The division president has a director of each discipline reporting to her (such as a director of development or a director of testing). There are no multidisciplinary managers within the division.

Product organizations, like Windows Server®, are organized by products. The division VP has a set of GMs reporting to him who each own a set of related products. Each GM has a set of PUMs who in turn own a specific product. Each PUM has discipline managers for each discipline reporting to her. Basically, a product organization becomes a functional organization at the PUM level.

In either case, to get the product built engineers need to work across disciplines, typically in feature teams. Thus, both organizational variations are “matrix organizations”—people working together across functional boundaries (silos).

Based on this description, you could and should be thinking, “Wait, every company I know starts at the top as a product organization and switches into a functional organization somewhere down the chain.” Exactly. Even new-age, hip, cool, out-there companies start at the top as product organizations and switch to functional organizations at the bottom. The only issue is when you switch. Windows now switches at the division president level, Office switches at the GM level, and Windows Server switches at the PUM level.

Make the switch

At what level should an organization switch from a product structure to a functional structure? Idealistic neophytes would say companies should be flat—functional from the top, or better yet, have a product structure with one boss and interchangeable people underneath like a crowd-sourced project. Admittedly, that’s a beautiful dream where people share the wealth, award each other, and live in peace, harmony, and prosperity forever. Naturally, it’s not sustainable.

The problem is a lack of alignment around business direction. Once you get to projects that require orchestrating more than 150 people, you must create structural mechanisms to keep everyone headed toward the same goals and timelines. Some companies, like Gore (makers of Gore-Tex), are specifically designed around not building anything that requires more than 150 people. However, you need large groups to build the integrated capability of an operating system (OS), a suite of applications, or an end-to-end set of services.

Every product needs a clear business direction, a vision, which lays out the goals for the upcoming release (themes and scenarios), the basic principles behind it (tenets), and the timeframe by which it must be delivered (high-level schedule). It also helps to have a shared understanding of how this direction was reached and where it hopes to go. Ideally, everyone in the organization should be part of forming this direction, but one person owns it for both coherence and accountability. That person is the business owner.

Below the business owner, you want everyone to follow the vision. You don’t want more business owners—you want people who can align the organization around executing the plan. At what level should an organization switch from a product structure to a functional structure? At the business owner. Windows is a single business—we don’t sell the product in pieces. It makes sense to be functional below Sinofsky. Office sells its products in several pieces. It makes sense to have GMs own those pieces and be functional below the GMs.

You can go your own way

Why not have sub-business owners below the business owner? Because you don’t need multiple business plans—you want a single vision. Business owners can’t help themselves. They want to set direction, to make plans, to make business decisions. After all, they’ve got no other responsibility besides pure people management.

Does this mean there’s no room for innovation and autonomy under a single vision for a product? Oh please! I hear this whine so much it makes me ill. A product vision is not a feature spec or a design document. If it were, the entire Microsoft engineering staff would be about 125 people and a ton of vendors.

There are millions of ways to achieve the themes and scenarios laid out in the vision that meet the tenets and the schedule. The vision provides intent—there’s plenty of room for inspiration. Perhaps a scenario can be met with a new approach, removing complexity and time. Perhaps a tenet can be achieved in ways that save billions of dollars over the next few years. Or perhaps, there’s just a simple change based on customer feedback that will delight a whole category of users. A change that others missed or didn’t have the courage to champion.

It’s true that functional organizations share one business plan, so large functional organizations can’t radically change their business plans overnight. That’s prudent for a large product like Windows, but may not make sense for rapidly changing areas. You pick the model that best fits your business and market.

The one thing you do have at Microsoft, regardless of your organization’s structure, is the autonomy to make your own choices and guide your own work. Not everyone takes full advantage of that autonomy. People confuse alignment and constraints with shackles. As I’ve said before, artists, architects, and creative minds do their best work when provided constraints. It’s the challenge of building something new within the confines of the existing world.

Finding the right mix

To run successful large projects, you need leadership and decision making around both product and function. The balance determines success. Too much function focus and you lack a cohesive product. Too much product focus and you lack consistency, efficiency, and resource flexibility.

An approach that works well for engineering organizations is to switch from a product structure to a functional structure at the level where product direction is set and aligns the functional organization. Division leadership should determine that level based on their business strategy.

PUMs might make sense for the Windows organization if we sold Windows in lots of pieces. However, Windows would cease to be the integrated platform for thousands of solutions our partners create and our customers rely upon. So we sell Windows as a single platform, and Windows has a functional organizational structure.

Should your group adopt the Windows model? That depends on your business and your market. Who should be accountable for business decisions? At what level should those decisions be made? You need to match your organizational structure to your business strategy. If yours doesn’t match, perhaps it is time to throw the bums out.