Are we functional (part deux)?

 It’s been over seven years since Windows 7 launched. Inside Microsoft, one of the more controversial elements of that launch was the change Steven Sinofsky made to the Windows organization at the start of that product’s planning and development. Coming over from Office, Steve switched Windows’ structure from having many product unit managers (PUMs running lots of small businesses) to having a functional org structure (separate disciplines reporting to a single cross-disciplinary business leader).

Windows 7 was a huge success, so many big groups at Microsoft were quick to switch to a functional org structure. (We called it, “getting Sinofskied.”) As I wrote back then in Are we functional?, “let’s not get too hasty. Knee-jerk nitwits who act before they think are doomed to repeat old failures in new ways.” Well, it’s been seven years. Was switching to a functional org structure the answer, or are we better off as a loosely coupled collection of individual small businesses? Neither.

Eric Aside

Historians might point out that shortly after Steven Sinofsky shipped Windows 8, he was seeking work outside of Microsoft, as were nearly all his leadership team members following the release of Windows 8.1.

Also, previously Sinofskied organizations (including Windows) are now a mix of functional and product organizations, instead of being purely functional below a single leader. PUMs haven’t returned, but there are combined engineering teams (almost no pure testers), as well as separate groups of program managers (PMs), data scientists, AI folks, and designers. These are interesting data points, but don’t directly speak to the efficacy of a functional org structure.

A blast from the past

Here’s my take on Windows from my column back in 2010: “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.” I rationalized this choice as follows: “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.”

Life in the software industry shifts quickly. Later that same year (2010), I published There’s no place like production, describing how services can release software multiple times a day, using exposure control to test and experiment in production. Today, Windows uses exposure control with preview releases of the operating system. Windows also now ships on Xbox, phone, IoT, server, Hololens, desktop, and tablet, voiding my assertions that Windows is a single business that can’t change plans overnight. Instead, Windows has become an agile business that broadly releases previews every week or two on multiple platforms. It’s a phenomenal change that bodes well for the company, but it also means we must rethink the org structure.

Windows is still a large collection of groups that must plan together and align to do big things. However, each team must stay small to be agile and responsive to the market. At a high level (VPs and directors), we’re coordinated and aligned, and at a low level (feature teams), we’re agile and responsive. The bridge between the two levels is made up of group managers, who run their small businesses aligned to the larger Windows business. It all sounds good in theory, but how are we doing in practice? Meh.

Eric Aside

Even when Steve originally Sinofskied Windows, he had general managers in charge of hardware and Internet Explorer, which were separate businesses from Windows.

What are your overheads?

As I uncover in Span sanity—ideal feature teams, the least expensive and most productive feature team is six people: one PM, one engineering lead, and four engineers. Even if you think feature teams should be a bit larger or smaller, there’s no doubt that they are the focal point of productivity and responsiveness in our new world, where even Windows is a service. They need to make quick decisions daily about the priorities and direction of their shared component within the framework of divisionwide plans and priorities. Self-directed feature teams are the smallest cross-functional unit.

However, even self-directed feature teams need higher-level direction from time to time. People issues, plan changes, and cross-team collaboration often escalate to group managers. How many group managers are needed per feature team to handle these escalations? One engineering manager (EM) should do.

There’s an argument that adding a group program manager (GPM) might be better. The GPM would support and grow the feature team PMs, provide a counterpoint for the EM, and halve the EM’s management responsibilities. Since many EMs have little or no experience growing PMs, and might mishandle or ignore PMs in their charge, the extra GPMs might be worth the $450K per year they each cost. Personally, I’d first try training and upgrading EMs in order to invest the half-million elsewhere.

Unfortunately, most feature teams default to having two or even three group managers supporting them. That’s as much as a million dollars a year of excess overhead per group of feature teams. What’s even worse is the substantial make-work that excessive group managers inevitably cause. We can and should do better.

Eric Aside

For more on group manager escalation, read Escalation acceleration and A manager’s manager.

Get in line

If you decrease the number of group managers, you also reduce the need for even pricier directors and VPs. Naturally, this can be overdone. We need a diverse collection of experienced people to plan, design, and drive our major initiatives and scenarios. They just don’t all need to directly manage feature teams.

The fewer group managers we have, the easier it becomes to gain alignment (fewer cooks, fewer captains). It’s true that unruly group managers might cause the same kinds of trouble that unruly PUMs did years ago, but there are two differences.

• PUMs were often tasked with running a somewhat independent business, even involving business managers and business development. Group managers are tasked with running an aligned business within the direction of their division and Microsoft.
• PUMs added a layer of management between directors and group managers. Reducing group managers drops that layer of indirection, decreasing the game of telephone up and down the org.

There’s a longstanding myth that adding more people increases output. When it comes to feature team size and overhead, the opposite is often true. If you want more results, and better aligned results, it’s frequently best to reduce the number of people involved. Instead, spend that money and those talents empowering additional people and organizations on the planet to achieve more. We certainly have more than enough problems to solve and customers to serve.

Eric Aside

Where do data scientists, AI folks, designers, and specialized testers fit? Just like marketing, business development, artists, content publishers, and other specialized disciplines, not every feature team needs these specialists. Instead, they can report to a group manager, director, or VP, depending on that org’s scale of need.

World of tomorrow

Seven years after the release of Windows 7 and the Microsoft era of being Sinofskied, divisions and groups are beginning to find more nuanced ways of organizing. Many groups have combined development, test, and operations into DevOps teams. Agile development is now a given, instead of a threat. Designers and design are now associated with success. Software is more componentized; open source is more welcome; and data, data scientists, experimentation, and AI are more essential to running our business.

It’s an exciting time to be a software engineer. Streamlining our org structure to reduce levels of hierarchy, drop excess overhead, and right-size agile feature teams is more important than ever to respond quickly to changing markets and technology. Yes, this means moving folks around, but that can expand our reach and enable our customers to achieve more.

With so much change, some longtime leaders and experienced engineers will resist altering how they work and how they are organized. It’s natural to feel uneasy, but holding back can lead to org and execution constipation—nobody wants that. Take a laxative, welcome all these wonderful advances, and embrace the change. Let’s make ourselves better prepared to face a fruitful future.