On org structures, goals, and metrics

@marypcbuk brought up an interesting point on Twitter:


I want to explore this a bit.

Organization structures are a good example of the adage all models are flawed, some models are useful.  The structure you pick for an organization will tend to emphasize some behaviors and deemphasize others.  As discussed in my earlier entry on the upcoming Microsoft reorganization, the structure that has been in place since the fall of 2005 was intended to put clear responsibility and authority for each Microsoft customer-centric business in the hands of a business unit President.  In doing so it emphasized the autonomy of the business units and encouraged them to avoid too much cooperation.

Avoid cooperation?  Was that intentional?  Was that an unintended consequence?  Was it wise?  Yes. Yes. Somewhat. Somewhat.

In the fall of 2005 Microsoft was getting ready to exit the Longhorn era, and a lost five years, by shipping Vista.  Part of what made Longhorn so damaging was that it had involved every business in Microsoft in whole or in part.  Longhorn started out with the notion that all of Microsoft would do a coordinated wave of products around a new ground-breaking OS.  It was going to be über cooperation that hadn’t been seen since the days of Windows 95.  Exiting Longhorn few Microsoft executives had any taste for über cooperation.  And every corner of Microsoft found itself having fallen behind the curve as a result of the lost five years.    So an organizational structure that let each business focus on its own rebuild, without the distractions of major cross-organizational cooperative efforts, made sense.

This “lack of cooperation” lead to Windows 7.  This “lack of cooperation” lead to Windows Azure.   This “lack of cooperation” lead to great releases of Windows Server and SQL Server, amongst many other products.  This “lack of cooperation” lead to Office’s rebound from a product that was, in the early 90s,  considered mature and unlikely to grow at greater than the pace of PC sales to the product line that (along with STB) carried the company through otherwise very dark times.  That’s the positive side.  Of course there are many negatives as well.  And not all cooperation was abandoned.  BPOS/Office 365 was a cooperative effort between Microsoft Business Division and STB.  And despite a rough start the SQL Server and Office team have cooperated magnificently in bringing the self-service BI vision to fruition.

The problem is that after the initial rebuilding took place the organizational model that encouraged independence started to become part of the problem rather than part of the solution.  Take Windows Azure as an example.  It initially had few customers, met few requirements for other teams to use it, seemed to have introduced arbitrary incompatibilities with Windows Server, etc.  That one was an easy one to fix and Windows Azure was moved into STB alongside Windows Server.  Look at Azure now and the story is very different.  Some of that is organizational structure.  Some is a change in leadership.  And some is a change in the goals and metrics by which organizations and individuals are measured.

Organizational fixes alone are often not enough of course.  Take Windows Media Center (WMC) as an example.  In an attempt to fix the problem that two organizations had responsibility for the “Living Room”, WMC was pulled out of the Windows organization and put into Entertainment and Devices, the team that owned Xbox.  But despite heroic efforts on the part of a number of people, Joe Belfiore for example, WMC was playing second fiddle to the Xbox as the main strategy for addressing the “third screen”.  Meanwhile it no longer had more than lip service support from its shipping vehicle, Windows.  Well, all models are flawed.

After the shipment of Windows 7 and similarly timed products, and the basic repair of Microsoft’s ability to write and ship software, it became increasingly obvious that cooperation needed to take a stronger role in how Microsoft worked.  The efforts around Windows 8 were forced.  The efforts of the last year reflect general recognition of the need for cooperation by the senior executives.  The coming reorganization is one way that Steve will try to make cooperation the norm rather than the exception.  I’ll make three (and a half) points to support this.

The first is that the organization structure (as rumored) will leave none of the engineering leaders with businesses that can run independent of one another.  A perfect example is that if the Office clients (Word, Excel, Powerpoint, etc.) move to Qi and the Office Servers and Services (SharePoint, Exchange, Office 365, etc.) move to Satya then neither owns the entire business (if they have any business responsibilities at all).  They must cooperate to meet the needs of the Information Worker.  Devices will need the OS, consumer services from Qi, and business services from Satya.  And so on.  Contrast this with how MBD was constructed back in 2005, when all clients, servers, and services deemed necessary to address the Information Worker were placed in the same organization.  Or take Windows, where Hotmail and other consumer services were moved out of Online Services and into Windows (nee, Windows and Windows Live) allowing the Windows business to function independently.

Second, if my speculation about business responsibilities moving away from the engineering units to a central business organization are true then the business guys will drive cooperation.  Let me speculate on an example.  Today both SQL Server marketing and Office marketing have BI business responsibilities.  Not only are there two organizations, their degrees of freedom are constrained within the business requirements and engineering priorities of their larger products.  While coordination between the teams, in parallel with coordination on the engineering side, has led to some great advances that is a one-off case.  In the new organization it is possible that you’d have a single BI business focus that gave requirements to multiple engineering organizations, own prioritization of requirements across the engineering organizations, own (via one or two levels up the management chain) making business-focused priority tradeoffs between BI and other areas, etc.

By the way, one of the reasons that Microsoft could consider going to a structure now that would have been rejected a few years ago is the move to annual or shorter release cycles.  In the past an area of friction, for example, would be that SQL Server had a ship cycle to meet the needs of database customers and Office had a ship cycle of its own.  If SQL Server had something to ship and missed the Office cycle it had to wait for the next one for them to sync up.  (For those who wonder why Access always struggled with support for newer versions of SQL Server, you now have a significant part of the answer.)  With cycles of 2-3 years that means in a worst case scenario you could wait nearly six  years to ship a cooperative effort.  With no longer than annual release cycles, the worst case scenario is two years to ship a cooperative effort.  Six years to ship something requiring cooperative effort discourages trying to cooperate.  Two years are tolerable, and moreover it is far easier to coordinate annual shipments making even two years a true worst-case scenario.  So the shorter shipment cycles make it far more productive to try to cooperate than the longer cycles of old.

The third point is that many of the reported leaders of the new organizations have a good track record of working with each other.  Satya used to work for Qi and the two appear to maintain an excellent working relationship.  Julie showed a willingness to cooperate that would often be stymied by her then boss.  Terry Myerson is more of a question mark, with many people historically having had a hard time working with him on cooperative efforts.  Though I suspect Terry’s experience being the junior partner in the Windows Phone 8/Windows 8 effort may have given him a new perspective.

Organizational structures are but one way to encourage a cooperative atmosphere.  Organizations also use goals and metrics, at both the organizational unit and individual levels to drive behaviors.  Let me give a hypothetical example.  If you tell your business unit Presidents 70% of their review would be based on meeting business metrics such as revenue targets and contribution margin, 10% on people and organization health  goals, and 20% on shipping specific products on time where is the incentive for them to cooperate?  If you want organizations and people to cooperate you have to measure and reward cooperation.

Microsoft has (at least) two ways to do that.  One is via individual review criteria that Steve establishes with his directs and they then filter down into their subordinate’s reviews (and so on down the chain).  The other is via a set of shared metrics that determine a portion of the compensation for all of Microsoft’s senior leadership.  Outsiders get to see, or fairly easily discover, the organization structure but we don’t get to see anything about  review criteria or shared compensation metrics.  I have heard that over the last few years these have been tweaked to favor cooperation, but I have no knowledge of how far this effort has gone.  Indeed, these interact with the current organization structure in ways that to date may have made them less effective than one would hope.

Let’s be clear, if a Business Unit misses revenue and contribution margin commitments than that is a material event that could cost the President their job, cost Steve his job, and even (in theory) sink the company.  If product A says that organization X failed to cooperate on something product A needed, the impact on the leadership of organization X might range from a slap on the wrist to a severe tongue lashing and, perhaps, a small ding to their compensation.  Lose your job or get a slightly smaller bonus?  I know which I’d pick.

A new organization structure in which the engineering leaders are not responsible for short-term business metrics would allow them to carry review commitments with sufficient weight to truly encourage cooperation.  Let me try a concrete hypothetical example.  It would be easier to seriously hold the engineering leader of Office and the engineering leader of Windows responsible for doing whatever it takes to ship a great set of Metro Office apps ASAP if you aren’t also telling them job #1 is to meet this year’s revenue and contribution margin goals.

The truth is that the metrics you choose to measure are what really drives behavior, not organization structure.  Sales management really understands this as the metrics have long been directly tied to the sales compensation structure.  But it applies in other disciplines as well.  If you want a product to perform well you need to drive it to a set of performance metrics.  If you want a product to be reliable you need to drive it to a set of reliability metrics.  If you want programmers to be productive, you need some set of metrics for that as well (as controversial as these usually are).  If you want people to cooperate you need metrics for assists and saves, not just points and wins.

Until we see the actual structure of Microsoft we won’t know how much of what I’ve described really applies.  All information so far does point to a reorganization that favors cooperation far more than Microsoft’s current business unit structure.  Now we wait for the actual reorganization to be announced and the details to settle down, and then it will be more obvious to what extent I’m right and to what extent I’m full of excrement.


This entry was posted in Microsoft and tagged , , . Bookmark the permalink.

7 Responses to On org structures, goals, and metrics

  1. It will be interesting to see any sort of cooperative regime foisted upon a workforce that’s evolved for a decade and a half to slit the throat of they guy in the next office come review time. While waiting for details, I note that the entire Pink Floyd catalogue has been released on Spotify. Come in dear boy. Have a cigar. You’re going to go far. You’re going to fly high…

    • Brian says:

      I was there for 12 years (albeit in services, and in the field, not Redmond). Yes, you competed against your teammates at review time, and if “Bob, next door” had a blowout year, there was a chance that your review might get lowered to pay for an outsized bonus for Bob.

      However, I *never* felt that that influenced behavior during the year. The teams I worked on thrived on cooperation.

      Because of the nature of the MSFT review process (at least in the org I was in), there wasn’t very much inter-group or inter-org competition relative to “review time”. Each org has to be balanced in “the model” without regards to other groups. Individual contributors are rewarded for their individual contributions, not for those of their team (for better or worse). However, I have absolutely no idea what it’s like when you move up the food chain.

  2. SpragueD says:

    I’m surprised that, in your analysis of past structural (dis)incentives for cooperation between product groups, there is no mention of antitrust oversight. As a customer, I had always assumed that one of the reasons more products weren’t integrated was fear of the appearance of tying. But that seems not to have entered the equation at all.

    • halberenson says:

      I didn’t approach this as an analysis of all disincentives for cooperation, but rather from the standpoint of what the impact of a reorg should be compared to previous disincentives. However, since you bring it up…

      Antitrust considerations really fall into two categories with regards to the impact on cooperation. The first is the overhead associated with ensuring you were avoiding antitrust pitfalls. So during much of the “lost five years” you pretty much couldn’t talk to another team without a lawyer in the room. And then there were the things you’d say “wouldn’t it be great for customers if we did X” and the lawyers would say “maybe, but the DoJ or EU won’t like it” if not “that’s not allowed” and that would be that. Actually the worst is when they tell you “it’s technically ok but competitor X will make a big stink and that will force antitrust authorities to butt in”. But the things that lawyers would actually prevent are pretty small, and once you understand the rules you don’t invest a heck of a lot of effort in things that won’t pass muster. Over time the types of meetings that lawyers had to be present for shrunk and the culture incorporated a sense of when you were on thin ice and when you’d best make sure the lawyers took a closer look. For the last few years I don’t think that antitrust concerns have been a disincentive for cooperation, but I could point to dozens of things where people go “why didn’t Microsoft do X” and tell you that it was because of (real or imagined) antitrust concerns and not a lack of desire to cooperate across teams.

      • SpragueD says:

        Interesting. I’ve often wondered about the subtle effects of “internalized” oversight that you indicate — self-editing by managers — and its implications in corporate culture and decision making. That alone would make an interesting chapter in the History of Microsoft. Irony: I’m writing this as news breaks about Apple getting its own first dose of oversight 🙂

    • Tim says:

      Good point. But I wonder if that isn’t the case anymore these days. It seems to me that the big players are all trying hard to intentionally create that integration/tying…i.e. the best ecosystem. It would seem that Microsoft, Apple and Google all want and need to give the appearance to customers that they have a well-rounded, all-encompassing digital world in which to live.

Comments are closed.