X
Business

How Steven Sinofsky changed Microsoft, for better and for worse

When Steven Sinofsky moved to the Windows division in 2006, it was fundamentally broken. He leaves behind an engineering process that runs smoothly. But he also leaves a legacy of cutthroat politics and feuding between divisions.
Written by Ed Bott, Senior Contributing Editor
Sinofsky-200

Today’s tech news will be filled with speculation about why Steven Sinofsky left Microsoft and why the decision was so seemingly sudden.

Why now? I’ve heard this decision has been in the works for weeks, if not months. Ex-Microsoftie Hal Berenson agrees:

[A] friend had told me months ago that Steven would be gone soon after Windows 8 launched.  The claim was that he had alienated most of Microsoft’s senior leadership, if not the bulk of the executive staff.

Longtime Microsoft watcher Mary Jo Foley agrees, citing the reasons behind the move as politics, not products:

Sinofsky is known inside and outside the company as a guy who got things done and done his way. Rumors regularly reappeared about Sinofsky angling to take over more business units. And until recently, it seemed like Microsoft's own senior leadership team, as well as Ballmer himself, had capitulated….

But more recently, something seemingly changed, including the rhetoric. Ballmer's note to the troops about Sinofsky's departure emphasized the ability of his successor Larson-Green's "proven ability to effectively collaborate and drive a cross company agenda." I smell a reorg....

There is no question that Sinofsky is a polarizing figure. I know key Microsoft engineers who moved out of the Windows division specifically because they couldn’t abide his management style. I know others who left the company rather than remain in what they perceived as a frustrating environment.

But there are plenty of people inside and outside the company who are fans of Sinofsky’s style and, more importantly, the substance of what he accomplished.

Sinofsky moved to the Windows division in 2006 as Windows Vista was about to crash into the market. At the time, the Windows engineering process was, to put it bluntly, broken. The fact that Windows 7 shipped on time and addressed every substantive complaint about Vista is a remarkable testament to Sinofsky's ability to fix things.

Those epic blog posts from Sinofsky and his team members during the development of Windows 7 and Windows 8 were an indication of just how much Microsoft’s culture had changed. The amount of detail that the development team shared was staggering, even if only a handful of people (me, for one) actually read every word.

Count Microsoft’s Dare Obasanjo as a member of Team Steven:

The way things get done in Steven’s organizations is so straightforward it hurts. You spend some time thinking about what you want to build, you write it down so the entire team has a shared vision of what they’re going to build and then you build it. The part where things become contentious is that getting things done (aka shipping) requires discipline. This means not changing your mind unless you have a good reason to after you’ve decided on what to build and knowing when to cut loses if things are coming in late or over budget.

It’s a good read. Dare also links to this 2008 post from Larry Osterman on the Building Windows 7 blog. (Osterman has been at Microsoft longer than just about anyone I know, except Steve Ballmer.)

The process of building 7 has also been dramatically more transparent – even sitting at the bottom of the stack, I feel that I’ve got a good idea about how decisions are being made. And that increased transparency in turn means that as an individual contributor I’m able to make better decisions about scheduling. This transparency is actually a direct fallout of management’s decision to let the various feature teams make their own decisions – by letting the feature teams deeper inside the planning process, the teams naturally make better decisions.

As a Microsoft customer (and as a member of the press who talks to those customers about Microsoft products like Windows and Office), I think that the organization Sinofsky has left behind is strong. In fact, had he stayed around, as my ZDNet colleague Mary Jo Foley notes, he probably would have been an impediment to the collaboration and “cross-company agenda” that the new Microsoft is pushing for.

Hal Berenson tallies the pluses and minuses of the move:

Microsoft has lost one of its few executives with a proven ability to ship major products and ship them on time.   On the other hand, it is also losing an executive who was tearing the company apart from the inside.  I have no doubt that a key reason Steven was unable to gain control of Windows Phone and the Developer Division is that most of the top 2-3 levels of leadership in those organizations would have quit.   So would senior leaders in other organizations….  It was becoming Steven against the rest of the company leadership, and no company can survive that situation for long.

So although the public release of the news might have been surprising in its suddenness, the timing certainly shouldn’t be. Windows 8 and the Surface have shipped. Planning for the next release of Windows (and maybe future Surface devices) is still in the early stages. It is the right time to make a management change.

Julie Larson-Green now runs Windows software and hardware engineering. Her big challenge is to keep that organizational discipline in the Windows team and restore that group’s ability to play well with others. That’s a tall order in a very large company where the company culture is defined by cutthroat politics and feuding between divisions.

I suspect this is only the first of several big moves over the next few weeks and months.

Update 14-Nov: In a comment at Hal Berenson's blog, Steven Sinofsky denies the assertion that he was trying to expand the scope of his organization:

I never initiated any discussions to bring together the organizations/products you describe and no one ever approached me to manage them as part of Windows 7 or 8.  Basic organization theory as described by @teyc would support the current state as a practical working model.

If we had worked together you would know that historically, very few things moved into teams I managed as (you’ve no doubt seen in internal blogs) and when they did I usually pushed back hard looking for a cross-group way to achieve the goal (in other words, decide open issues rather than force an org change to subsequently decide something).  it is far better to collaborate with the org in place and avoid the disruption unless it is on a product cycle boundary and far better to plan and execute together than just organize together.

Editorial standards