Android Flash

Innovation and Execution

Innovation and Execution

A friend pointed out the now infamous “Creative Destruction” article by former Microsoft executive Dick Brass, asking me if I would agree with his point-of-view. It is hard to discuss that article. First, because I cannot verify his claims of “sabotage”, while also not being able to dismiss those. Even assuming those are true, one has to remember that engineers always have to be prepared to be challenged on their claims. Many engineers just want to be “taken for granted”, even when making absurd claims.

The main problem that I see with the article is that it criticizes “innovation” but then goes on and on to talk about problems with “execution”. That is the equivalent of complaining that, despite all the Nobel Peace winners, the world still has ongoing wars! Creativity and innovation brings us new ideas, great music, great novels, great policies, etc. But only disciplined execution really achieves results. Only the disciplined application of engineering allows men to build 828 meters high structures like the Burj Khalifa in Dubai.

About 2 years ago, I’ve created a presentation that I’ve adapted to several events, talking about the 3 main issues that should be addressed in the arduous process of going from papers to products inside software companies. I’ll now reuse those issues to illustrate how they can help software executives avoid having “execution” blocking “innovation”.

Setup. Several projects never reach customers not because the idea wasn’t good, or because it couldn’t be technically implemented. The problem is that it couldn’t be technically implemented by the team in charge, in the time allocated for the project. Most teams focus so much in the “problem domain” that they forget everything about the “solution domain”. It is common to see demos in which everything magically works, and the first question about “users” and “permissions” is addressed with a “that will be simple to deal with later”. Just a few months before release, there comes the “rearchitecturing” of the entire project, because security needs to be reimplemented, remote servers need to be supported, a big customer scenario has some incompatible software running, etc. All the inovative features are typically cut at such late stage.

How can executives address this? Don’t ask for demos, ask for prototypes. The prototypes should come with install instructions, and the executives, or their technical assistants, should be able to setup the prototypes by themselves. If this cannot be done then it shows that the demoware is simply no easily deployed. That is a huge red flag that needs to be addressed as early as possible, and not as late as allowed, as in many failed software projects.

Test. Demos work because the “user” is doing a demonstration, not really using the product. Agile technologies are becoming so popular not because they have a magic bullet: it is just that they avoid having test becoming an end, and not the means to achieve quality. Everything that is checked-in should work, for the “typical user”, everyday. Yet, nowadays it looks like software testing has a hidden purpose: to compete with development in volume of generated code. The application at times is failing miserably in the hands of users, but the “test harness” is producing the most amazing reports saying that the application has very high quality!

How can executives address this? Again: just use the milestone builds. Indeed, if program managers, product managers, and all the “managers” just used the applications “under their management” then the quality of the products would improve tremendously. That would also have the side-effect of making executives used to the process of seeing applications being built “bottom-up”, instead of the “top-down” approach used by demoware.

Support. I’ve recently attended some management training, and a video was shown of a corporate executive taking a potential customer call. It was laughable. This was not even a software product, but the analogies were easy to make. The executive didn’t really know the company service. Besides almost losing the sale, she created an embarrassing situation before calling a top sales person for damage control (which, by the way, the sales person did brilliantly!).

How can executives address this? Call/email/contact your company, and ask for support some product or service that you understand. How did it go? If that is the current scenario for an established product, what will happen with a new product? No amount of “support policies” and other documents placed on the product box or service contract can overcome that bad impression that customers have when asking for support and not getting proper help. Innovative products and services without good support are as good as booking a ticket to the moon, without a return ticket.

Available link for download