How Microsoft Works

People often look at Microsoft and scratch their heads.  One of the things I want do with this blog is to give people a peek behind the curtains so you understand how things really work.  My hope is that once you understand some of this, our actions and attitudes will be a little less befuddling.

One of the things you need to understand about Microsoft is that we spend > $7 Billion a year in R&D.  Now couple that with the fact that everyone here works super hard on their stuff and you see why teams find it virtually impossible to keep up with with what is going on with various technologies. 

Many of those investments are platform investments which means that teams have a steady stream of people knocking on their doors telling them that they should/must support this or that technology.  What is a team to do?  There are too many people knocking on their doors and people got hurt when some of those big bets didn’t pan out (think Hailstorm and WinFS).  It is natural and healthy for teams to take a "wait and see" approach to supporting new technology.  This is one of the reasons why you didn’t get universal command line coverage simultaneous with the release of PowerShell V1.0.  Sure PowerShell SOUNDS good but so did WinFS!

So now when I knock on people’s doors to talk to them about supporting PowerShell, I’ll often try to hold the meeting in my office.  At some point in the conversation, they notice the Tower of Power and the conversation usually goes pretty well after that.  People still have schedules and timing issues but they are all interested.

Now that said, there is hype and there is value.  You could have a mountain of books but if the technology doesn’t deliver the goods – it isn’t going to get off the ground.  (I like to tell the team, "Focus on delivering the right value because if you get that right, even your worst enemy will use your technology.  Get that wrong and even your best friend will abandon you.")

I was super pleased a while back when a team whose door I had been knocking on for a couple of years finally put a dev on the task of prototyping some cmdlets.  It was a short while afterwards that I was forwarded an excited email articulating all the things that customers could do with their technology using PowerShell.  There were examples after examples and the note ended with the key point:  Here is how much code I had to write to get this (and there was a small section of code). 

It was at that point that they were able to see the "real deal" of the PowerShell value proposition:  small amount of code yields huge customer advantage.  I had been telling them that for years but the reality is that everyone that knocks on their door tells a variation of that story.  When they understood it for themselves they were hooked.

As a side note, that team then went on to do one of the best jobs I’ve seen a team do in terms of understanding how customers use their technology and how to model it in PowerShell.  I can’t give you the details because it is their news to tell but it’s awesome.

Cheers!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx