Response to Mini-MSFT on cutting Microsoft sales force

Mini-Microsoft is a blog dedicated to reducing Microsoft employee headcount: "Let's slim down Microsoft into a lean, mean, efficient customer pleasing profit making machine! Mini-Microsoft, Mini-Microsoft, lean-and-mean!"

 

I wanted to give my personal view on some of the thoughts and ideas posted in the post: Mini-MSFT: Employee Growth Chart

Quote: "I'd also be really interested if we have awful products that require a greater amount of support / effort to sell and market, especially considering what's the comparable investment of that effort given the products' profits (or lack there-of)."

 

My Response (see Disclaimer)

I'll answer the question of whether Microsoft should be micro-sized in another post. Instead I'll specifically address why I think our sales force should not be cut.

 

I used to work as a Developer Evangelist in the Microsoft Mid-Atlantic district where I was responsible for evangelizing the .NET vision and our developer tools story. Our group was responsible for commercial (aka non-government) sales for Maryland, Virginia, West Virginia and Washington DC. For those of you who may not know, The greater Washington, DC area has a very large tech base, consisting of large telecom/ISP companies (America Online), huge tech consulting/outsourcing companies (Booz Allen Hamilton, Computer Science Corporation, BAE Systems), government-assisted corporations (Amtrack, Fannie Mae, Freddie Mac), banks (Capital One, InterAmerican Development Bank, World Bank, International Monetary Fund, NASDAQ, T. Rowe Price), retail companies (Circuit City, Crutchfield), organizations (AARP, Red Cross), media companies (Gannett/USA Today, Discovery Channel, National Geographic, PBS) and many, many others (Celera Genomics, Marriott, Microstrategy, Philip Morris/Altria, etc).

 

Our goal was to meet with these organizations, understand their needs and evangelize how our technology will help provide the best solution possible. This involves everything from providing your typical "What is .NET" overview talk to CxO's to discussing more obscure topics like creating section 508 compliant web pages using ASP.NET or creating working prototypes of actual solutions. So how many Microsoft employees do you think we had covering developers and architects for all of the companies in our district and all of our MSDN events? Would you believe three people, two of which were technical? David Goodhand, a Microsoft legend as the Microsoft Outlook Product Planner (circa Outlook '97) and a great mentor was the Architect Evangelist, I was the Developer Evangelist and we had a sales manager who took care of actually closing the deal, licensing, etc. We were (and probably still are) understaffed in addressing direct customer relations. In deals where we actually got to meet with the customer, and tell them our story, our success rate was incredibly high. If we show up, we win, it's was that easy. Frankly, there are some customers I never met with, and others I only met with once a year. Would you spend your ever-dwindling IT budget on a vendor you meet for two hours a year or with the person who's always there for you, and who has spent the time to study and understand your business needs? I can't tell you how many meetings I went to where it was the first time they had ever met someone from Microsoft. In fact my role as a developer evengelist didn’t exist until around 2001. Selling to an enterprise, and I'm referring to getting the big wins, is not easy.

 

Enterprise Sales Process

• Long Sales Cycle: Selling to an enterprise is a tough process with a sales cycle that can be longer then 18 months.
• Long implementation cycle: Complex applications can take several years to implement.
• Complex Needs: Large enterprises have complex software needs. Deploying SAP to run your line of business applications is not trivial and requires expert advice to do it right. So does architecting any mission critical application. Throwing a product out on the market and assuming it will sell just won't work.
• Approval: Some enterprises have architect councils which standardize application development across the organization or subsidiary. Before a line of code is written, you need to convince this group the value of having your technology be an approved standard. Your product may be better then sliced bread, but if it's not approved, it's not happening.
• Skin in the Game: Customers expect a joint investment in a solution. This is an area where IBM truly excels. IBM is more interested in being a trusted advisor and is willing to put “skin in the game” by investing money in a customer’s solution. For big name companies, IBM is willing to invest (or comp) software, services, support and infrastructure to ensure the customer is successful. It’s piece of mind, customers know that IBM is going to do what it takes to make sure everything’s working. Contrast that with the Microsoft approach where you are just selling a product, oh and you don’t get free support. The marketplace has already decided which mechanism works for enterprise software.
• History/Relationship: We have customers who have been IBM purchasing products from IBM for 25+ years. They have a personal relationship with the salesperson, who has been working for the account all those years. Approximately ~70% of their IT budget goes to IBM, 5% of it goes to Microsoft.
• Politics and Bias: There are also plenty of other issues, ranging from geo-political policy to only use open source in Europe and Asia to out-and-out technology bigots. While you can at best contain the latter, the former requires much more effort. This also ties back to my approval point above, but imagines if Microsoft technology couldn’t even be considered by government agencies because it wasn’t open source. That’s bad for us and our customers.

Moral of the story: While I agree that one should measure the ROI of a sales force or any investment for that matter, implying that our sales force should be cut shows an ignorance of the enterprise software sales process. Microsoft can't be considered a trusted advisor in an enterprise without a significant investment in time, money, resources, and people.

Comments

• Anonymous
  January 12, 2005
  The comment has been removed

• Anonymous
  September 26, 2006
  The comment has been removed

• Anonymous
  February 27, 2008
  Kudos to Ariel Stallings , Microsoft employee and author the Microspotting blog (one of my favorite new

• Anonymous
  February 27, 2008
  Kudos to Ariel Stallings , Microsoft employee and author the Microspotting blog (one of my favorite new

• Anonymous
  February 27, 2008
  PingBack from http://msdnrss.thecoderblogs.com/2008/02/27/microspotting-lands-an-interview-with-mini-microsoft/