@marypcbuk brought up an interesting point on Twitter:

So my question about the Microsoft re-org; how much does it do to *incentivize* the co-operation Ms orgs so badly need? cc @halberenson

— Mary Branscombe (@marypcbuk) July 9, 2013

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.