Commentary: Microsoft job cuts - part of a bigger problem? Part II – perspective.

(The following are based on my opinions and conclusions based on my observations while working at Microsoft. I've done my best to avoid revealing any confidential information, and attempted to steer clear of ad-hominem attacks on anyone who has worked there, past or present.)

So how is this relevant to what's going on?

Layoff handling and H-1B issues aside, there’s a problem I’ve observed brewing in my time at Microsoft. And it appears that since I’ve left, the problems are not only still there, and not only have they apparently existed in most groups, but that it’s growing, and infesting its way into the management and executive teams.

It's a belief that one can code one’s way around any problem, and that all should be grateful for the solution. That is, any issue can be resolved technically. It's an almost Western frontier attitude - ' We have the biggest most powerful guns, and can draw faster than any other hombre!' It's as if they think they can out-gun or out-code any competitor into submission.

To put simply -

innovation=coding

But having the smartest people, and the best software coding resources doesn't always translate to a best solution, or the most profitable. Microsoft has trying to compete with other companies in a number of areas on a laregly technical basis when others clearly are more established and successful. It's one thing if the plan is succeeding and one gains success. It's another when it only helps the competition. Granted some things take time (5 years, 10 years, beyond, etc). And perhaps because of the Internet and the Software/IT business itself, such things are more compressed. But being in business more than 10 years and still trying to out-code the competion in the face of the latter's increasing dominance is not the mark of resiliance, but a lack of executive vision, a failed business plan and poor management.

This arrogant attitude is what I think fosters the perception of Microsoft. And it causes people (regardess of how smart they are) to be truly blind to what's happening. And when you have such thinking infiltrate the upper levels of the product planning, it makes for a failed set of long-term business strategy, and eventually decline.

Yes code is important and is part of innovation, but how one arrives at that point, and where it goes from there are far more important.

I've met a lot of people there with this singular 'innovation=coding' attitude, and it's not restricted to just one group, like developers. Imagine now, that such individuals move up and become leads, managers, directors, even VPs, and still foster this thinking.

What many teams at Microsoft have largely apparently never been able to understand is –

1. That the customer’s experience with the product or service (not the just code that generates it) it is what matters.


2. Products and services should not be emerge in their entirety solely in silos. Eventually, one has to see how it fits in its surroundings, and how it interacts with others to really understand how it's going to be used. This has to be tied to a business strategy and vision.


3. Software Testing is a function of your overall plan for success. Your project or product leaders need to understand that testing software is a 'honest broker' service to the project.

 I think I've covered 1. and 2. somewhat. Regarding 3 ...

I've observed that Microsoft for some time has been eliminating actual testing jobs in favor of SDETs who are treated largely as 2nd-class employees. They spend more time creating tools, rather than actual testing. It’s no wonder many of them eventually move to being SDEs because that’s what the software testing has become there: a stepping stone to software development. Indeed, I've observed this in all three groups I worked in. It's almost as if software and software development are one in the same.

Yes software quality assurance (SQA) involves assessing the process in which the product is created, in addition to verifying requirements, logging bugs, and verifying defect fixes. And yes, Software Quality Management (SQM) involves being tied to business strategy, short- medium- and long-term product planning, usability and marketing research, integration with other products, partnering with other product teams to determine interoperability, release management, quality improvement, and so on.

But those things take time, and really only work once you have a coherent product evolution strategy in place, along with a tremendous thrust for moving the product foward. And this should always go hand-in-hand with always knowing what your customer experiences.

And that's the key point there -  it should be tied to what the customer actually experiences, and works to improve both it and the product’s quality. One must never lose sight of that. And while some teams make the effort to do some of these things, I never observed anyone doing all of those things.

And quality improvement should go hand-in-hand with Innovation. Indeed, that's one of the founding principles of any Defect Prevention strategy (ironically, this is from a book that came from Microsoft. It's unfortunate that many teams there don't apparently read much of their best literature). But again, preventing defects, and analysing them should never be considered a replacement of actual testing. They go together and are linked.

To me, true long-lasting innovation involves thinking, planning, strategizing, and smart design on an idea, in addition to coding (development), testing and support. And in this day and age, one has to always think about implications along short-, medium-, and long-term. Of course, everyone in this day and age wants something now and yesterday and last week. The pressures of being first-to-market seem to be increasing on an almost daily basis (The number one term I repeatedly kept hearing in my final days was 'market-share'.) Everything becomes a competition. After awhile, internal teams start fighting amongst themselves. Meetings to review software issues are termed 'war rooms', as if everyone should bring their armor and armament and be ready to do battle.

And yes, I see the importance in being first in a market.

But being first under this 'build it first' approach doesn't always lead to it being the best in market, or the most successful. Indeed, Google Search wasn't the first web search engine out there. I've heard some comment that the solutions for Microsoft should be to just 'let the developers have control, again'. I think people say that because they believe that developers are the most creative people at Micrsoft. While it's true that many of the designs on how to implement an idea might be skillfully acheived, it's largely useless without any foresight.

Successful leadership in such times require vision, planning, and execution. What's missing at Microsoft these days from that is a sense of vision and direction. Oh they execute. But usually quite badly without the first two. And usually what also tends to get missed when not doing those things is a plan for quality. Without those things, such calls revert back to the innovation=coding mantra, which when unchecked and allowed to grow and fester, I think will lead to the very same problems they now face.

I'm not saying innovation should be stifled by process. Rather, I think when one has an idea, they should think it through and plan for it to be successful, instead of heading to their machine and banging out code to improve it later. Innovation only works when coupled with an intelligent vision, strategy, planning and execution. This includes things like planning, strategy, quality.

Till Microsoft realizes this, and works to change these attitudes, I don’t think you’ll see much improvement in the situations currently unfolding. Indeed, these layoffs are just the beginning.