What's wrong with Steve Ballmer? Is it the same as what was wrong with Research in Motion's semi-departed co-CEOs, Mike Lazaridis and Jim Balsillie? Does RIM's new CEO, Thorsten Heins, share the problem? How about Steve Jobs's successor, Tim Cook?
Most important of all, as an IT professional, do you care?
[ Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]
The answers, in order:
1: Lack of vision.
4: It will be very hard to tell.
5. You bet. Steve Ballmer: A lesson in lack of vision
Start with Ballmer. Give the man his due. Under his leadership, Microsoft's software has made enormous strides in quality and security. Nor are the dings about Microsoft's inability to innovate entirely fair -- SharePoint and Lync (and to a lesser extent, Microsoft Live Meeting) are seriously innovative products. From what I'm able to tell, a lot of innovation is still going into Visual Studio, as well as Azure and Kinect.
The innovation is there. The product quality is there. What's missing? In a word, storytelling.
Vision is poorly understood. It isn't about eating a peyote button so that you can wander around admiring the bright colors while saying, "Oh, wow!" under your breath every so often.
It's about storytelling -- creating clear, compelling, easy-to-grasp narratives that answer the most important question anyone has about the products your company has to sell: What's the point?
Take the SharePoint/Lync/Live Meeting combo. It's marvelous technology for 21st-century companies with 21st-century workforces and 21st-century management styles -- companies that need to support informal collaboration among employees who might be anywhere in the world.
Not that you'd know this from anything Microsoft has said about these products. There's lots of information about what they do. What's missing is what they can do for you. That requires the vision to see it and the storytelling skills to explain it.
Microsoft's missing plot point: Methodology
What also requires vision: When IBM introduced the relational database management system, it introduced a design methodology to go with it -- Codd and Date's famous "12" rules of normalization. (There are actually 13 rules, but they were numbered 0 through 12. This is what passed for humor in IT circles back then.)
Whoever in IBM was responsible for DB2 understood the need for a design methodology, to help customers avoid the pitfall of re-creating the current mess -- the then-common ad hoc approach to designing file stores -- within the DB2 technology. But it didn't end with the methodology; they needed the story behind the methodology.