Where does Ford make its paint?

There is a good, albeit rather general, rule that applies to the management of a successful business: focus on what you do well, then do it better than everyone else. There are numerous examples of how companies have been very successful by following this approach.

But the world of embedded software is commonly an exception …

To start with, I can cite some examples of good practice:

Have you heard of Nokia? Of course you have. It has been a dominant force in the mobile handset market for years. But you may be surprised to hear that it has actually been in business since the mid-19th Century. It made a diverse range of products from rubber boots to gas masks [my Finnish friends will probably correct me on the details]. It was a very well known name in Finland, but hardly heard of elsewhere. Then it focused on an emerging market and became a household name everywhere.

What about the car makers like Ford? They have been traditionally very successful. They have done that by focusing on what they do outstandingly well: building cars. It was not always like that. About a century ago, Henry Ford was famous for trying to make the company totally self-sufficient by owning the whole supply chain. He nearly destroyed the company by his obsession, but eventually they got back on course. Nowadays, they do not make their own paint – they source it from a paint manufacturer, who supply against a clear specification. The same goes for the glass for the windows, the windows themselves, the tires, much of the electronics and even major components like gearboxes.

Developers of embedded systems are not all bad. Hardware designers are very adept at design reuse – employing off the shelf devices or licensing IP. So why are software developers less keen? Surely they can take a “black box” approach to the use of standard “components” and simply rely upon their specifications. As systems become ever more complex, it makes sense to leave development of specialist technologies – like operating systems, protocol stacks, graphics – in the hands of experts.

Bottom line: concentrate on your core competencies and let others focus on theirs.

I conducted a Web seminar on this topic a while back, which is available as an archive.

Follow me here …

This entry was posted on Wednesday, March 19th, 2014 at 8:49 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.