When I first ask someone this question, I usually get a brutal answer: not a chance!!! This is what I’ve learned the hard way: true innovation is a process. Accidental innovation is not a process, but a fortunate mistake. 😉 In order to innovate, you have to follow a recipe because innovation must be consistent.

Many people think that technical guys are closer to innovation. That is not true! Most engineers have a pretty chaotic thinking. Sounds surprising? Brains with too much processing power tend to process things speculatively out of order.

Playing It By The Book Or By The Ear?

There are books about software design: how to come up with great products, how to create reliable products, great architectures and so on. Millions of them are sold every year and still most software is crappy, the experience is poor, and people hate it.

Why? Don’t software engineers read books? Do they forget everything they read? I believe the reason is of psychological nature. When people become familiar with something they tend to neglect the bad things, gain too much self confidence, and skip validation steps.

In theory, everyone is able to understand a simplified software development process:

• Story – Define what you want your product to do
• Requirements – Define what you think is absolutely needed to back up the story
• Sketch – Make a live representation of the requirements in the fastest way possible. Get a reality check from potential customers/developers, dig out the problems in requirements etc.

If the effort is worth the trouble, you’ll move on to the next steps:

• Refine the requirements – The first requirements you gathered were pretty generic; before going to implementation it is needed to go into detail
• Implement – Satisfy your micro requirements
• Test – Make sure that it works in order to satisfy the requirements
• Ship it – If it works, then ship it to the ones who can tell whether the requirements have been well fulfilled or not.

Tra La La…La La

Playing it by the ear will get you to a completely different context, which, from an objective perspective, gets to look a lot like this:

• Story – You need a PhD to understand it. Team thinks that’s normal, because the first version of the story was not enough and you wouldn’t have understood it properly anyway.
• Requirements – Team thinks that they are nice in theory, but why the hell do you need requirements that cannot be fulfilled later? So the requirements include tips on how to implement the bloody thing. 😉 Furthermore, all requirements have been investigated and can be done. There were some impossible great-to-haves in the list, but they were identified and dropped.
• Prototype – Team built something, but it was crap. That’s why they spent a couple of days on this beauty. Yes, a lot of its code can be reused!
• Review?!? Team thinks the best review can be done inside the team because they know best. 😀 No major issues so far!
• Implementation – Team is happy that they did a great job! The process says something about more accurate requirements. Not necessary at this point; team believes that lot of quality time was spent on requirements when they first started the project.
• More on implementation… Basically it works great. Unfortunately, testers do not understand that it is not a completed final product, so of course that there are still a lot of issues to be dealt with!
• Late!! Management says product is late. What do they know about software development? It’s complicated! Do they have any idea how many issues the team solved?!?
• Uhh, finally it was shipped. What? People do not like it? They will, most likely they do not understand it!
• They still don’t get it?!?? Team thinks that irrespective of their exceptional work, marketing is targeting only hopeless customers! Buhuhu 😉

Sounds familiar?

Building Something Right And Building The Right Thing

The situation above might look bitterly funny and surreal, but it is how things actually work in lots of teams. The difference between building something right and building the right thing is very subtle. Being too much involved in the process makes you vulnerable. Innovation is about raising the bar on each level, starting with the story.

From the engineering perspective, the process is hard to follow. Being an exceptional engineer is not only about technical skills, it is also about wanting more, even when others say everything is perfect. It’s like training for the Olympics without a coach. If your teams cannot be challenged internally, build this role in your company. Challenging is not about criticizing, it’s about raising the stake, showing that there are better ways and the best are yet to be discovered.

BTW, think about Apple. Many people say that innovation died with Steve. Others that he actually was an opportunist. I think that Steve was the top challenger in Apple, and this is what Apple needs now.