dw2

“The time is right to accelerate the company’s renewal” – Jorma Ollila, Chairman of the Nokia Board of Directors, 10 Sept 2010

I’ve been a keen Nokia watcher since late 1996, when a group of senior managers from Nokia visited Psion’s offices in Sentinel House, near Edgware Road station in London.  These managers were looking for a mobile operating system to power new generations of devices that would in time come to be called smartphones.

From my observations, I fairly soon realised that Nokia had world-class operating practice.  At the time, they were “one of the big three” – along with Motorola and Ericsson.  These three companies had roughly the same mobile phone market share – sometimes with one doing a little better, sometimes with another doing a little better.  But the practices I was able to watch at close quarters, over more than a decade, drove Nokia’s position ever higher.  People stopped talking about “the big three” and recognised Nokia as being in a league of its own.

In recent times, of course, this market dominance has taken a major hit.  Unit volume sales continue high, but the proportion of mobile industry profits won by Nokia has seen significant decline, in the face of new competition.  It’s no surprise that Nokia’s Chairman, Jorma Ollila, has declared the need to accelerate the company’s renewal.

Following the dramatic appointment earlier this week of a new CEO, Stephen Elop, I’ve already been asked on many occasions what advice I would offer the new CEO.  Here’s what I would say:

1. Ensure faster software execution – by improving software process quality

Delays in Nokia’s releases – both platform releases and product releases – mean that market windows are missed.  Nokia’s lengthy release lifecycles compare poorly to what more nimble competitors are achieving.

Paradoxically, the way to achieve faster release cycles is not to focus on faster release cycles.  The best way to ensure customer satisfaction and predictable delivery, is, counter-intuitively, to focus more on software quality, interim customer feedback, agile project management, self-motivated teams, and general principles of excellence in software development, than on schedule management itself.

It’s in line with what software process expert Steve McConnell says,

• IBM discovered 20 years ago that projects that focused on attaining the shortest schedules had high frequencies of cost and schedule overruns;
• Projects that focused on achieving high quality had the best schedules and the highest productivities.

The experience of Symbian Software Ltd over many years bears out the same conclusion. The more we in Symbian Ltd focused on achieving high quality, the better we became with both schedule management and internal developer productivity.

Aside: see this previous blogpost for the argument that

In a company whose culture puts a strong emphasis upon fulfilling commitments and never missing deadlines, the agreed schedules are often built from estimations up to twice as long as the individually most likely outcome, and even so, they often miss even these extended deadlines…

2. Recognise that quality trumps quantity

Large product development teams risk falling foul of Brooks’s Law: Adding manpower to a late software project makes it later.  In other words, too many cooks spoil the broth.  Each new person, or each new team, introduces new relationships that need to be navigated and managed.  More and more effort ends up in communications and bureaucracy, rather than in “real work”.

Large product development teams can also suffer from a diminution of individual quality.  This is summed up in the saying,

A-grade people hire A-grade people to work for them, but B-grade people hire C-grade people to work for them.

Related to this, in large organisations, is the Peter Principle:

In a hierarchy every employee tends to rise to their level of incompetence.

Former Nokia executive Juhani Risku recently gave a lengthy interview to The Register.  Andrew Orlowski noted the following:

One phrase repeatedly came up in our conversation: The Peter Principle. This is the rule by which people are promoted to their own level of incompetence. Many, but not all of Nokia’s executives have attained this goal, claims Risku.

One thing that does seem to be true is that Nokia’s product development teams are larger than comparable teams in other companies.  Nokia’s new CEO needs to ensure that the organisation is simplified and make more effective.  However, in the process, he should seek to retain the true world-class performers and teams in the company he is inheriting.  This will require wise discrimination – and an inspired choice of trusted advisors.

3. Identify and enable people with powerful product vision

A mediocre product delivered quickly is better than a mediocre product delivered late.  But even better is when the development process results in a product with great user appeal.

The principle of “less is more” applies here.  A product that delivers 50% of the functionality, superbly implemented, is likely to outsell a product that has 100% of the functionality but a whole cluster of usability issues.  (And the former product will almost certainly generate better public reaction.)

That’s why a relentless focus on product design is needed.  Companies like RIM and Apple have powerful product designers who are able to articulate and then boldly defend their conceptions for appealing new products – all the way through to these products reaching the market.  Although these great designers are sensitive to feedback from users, they don’t allow their core product vision to be diluted by numerous “nice ideas” that complicate the execution of the core tasks.

Nokia’s new CEO needs to identify individuals (from either inside or outside the existing organisation) who can carry out this task for Nokia’s new products.  Then he needs to enable these individuals to succeed.

For a compelling account of how Jeff Hawkins acted with this kind single-minded focus on a “simply great product” at Palm, I recommend the book “Piloting Palm: The Inside Story of Palm, Handspring and the Birth of the Billion Dollar Handheld Industry” by Andrea Butter and David Pogue.

4. Build the absorptive capacity that will allow Nokia to benefit from openness

Nokia has often talked about Open Innovation, and has made strong bets in favour of open source.  However, it appears that it has gained comparatively little from these bets so far.

In order to benefit more fully from contributions from external developers, Nokia needs to build additional absorptive capacity into its engineering teams and processes.  Otherwise, there’s little point in continuing down the route of “openness”.  However, with the absorptive capacity in place, the underlying platforms used by Nokia should start accelerating their development – benefiting the entire community (including Nokia).

For more on some of the skills needed, see my article Open Source: necessary but not sufficient.

5. Avoid rash decisions – first, find out what is really happening

I would advise Nokia’s new CEO to urgently bring in expert software process consultants, to conduct an audit of both the strengths and the weaknesses of Nokia’s practices in software development.

To determine which teams really are performing well, and which are performing poorly, it’s not sufficient to rely on any general principle or hearsay.  Instead, I recommend the Lean principle of Genba, Genbutsu, Genjitsu:

Genba means the actual place
Genbutsu means the real thing, the actual thing
Genjitsu means the actual situation

Or, colloquially translated:

Go and see
Get the facts
Grasp the situation

6. Address the Knowing-Doing Gap

The advice I offer above is far from being alien to Nokia.  I am sure there are scores of senior managers inside Nokia who already know and appreciate the above principles.  The deeper problem is one of a “knowing doing gap”.

I’ve written on this topic before.  For now, I’ll just state the conclusion:

The following set of five characteristics distinguish companies that can successfully bridge the knowing-doing gap:

1. They have leaders with a profound hands-on knowledge of the work domain;
2. They have a bias for plain language and simple concepts;
3. They encourage solutions rather than inaction, by framing questions asking “how”, not just “why”;
4. They have strong mechanisms that close the loop – ensuring that actions are completed (rather than being forgotten, or excuses being accepted);
5. They are not afraid to “learn by doing”, and thereby avoid analysis paralysis.

Happily for Nokia, Stephen Elop’s background seems to indicate that he will score well on these criteria.