13 September 2010

Accelerating Nokia’s renewal

Filed under: leadership, Nokia, openness, software management, time to market, urgency, usability — David Wood @ 8:29 pm

“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.


  1. Very nice article. but the question is will nokia follow this ? Nokia’s biggest weakness right now is failing to execute their nearly perfect vision and plan . i dont see how someone with no virtually no real knowledge of mobile phone industry is going to help it .

    Comment by tamoghno — 13 September 2010 @ 8:55 pm

    • The executive team that will carry out Nokia’s vision will surely be a combination of (relatively) old and (relatively) new. The incoming CEO will bring his own special set of skills, but he will need to rely on well-chosen people from the existing executive ranks to assist him. This wider team will have huge knowledge of the mobile phone industry.

      Comment by David Wood — 13 September 2010 @ 9:00 pm

  2. A great post and a refreshing break from a lot of the commentary on this situation, which offer a *lot* of opinions but few solutions (even Jean-Louis Gassee couldn’t do better than ‘use Android/Windows Phone 7’). Nokia need to change to succeed, but superficial change like a new OS is not going to fix anything.

    I really appreciate the first point, as a test engineer. I would use the analogy of challenging 2 people to cook a meal. One in 15 minutes – the other in 1 hour. The first will invariably end up making mistake upon mistake at the beginning and work themselves into a situation where the end up throwing everything in the pot just to finish cooking half an hour after the second guy. Being ex-Symbian myself I know exactly the kind of deliberate, dedicated focus on quality that you’re talking about.

    Comment by Brendan — 13 September 2010 @ 9:10 pm

    • Brendan,

      I fully agree that there’s no “quick fix” from changing the mobile software platform. First, any such change will be disruptive, and take longer than most people expect. Second, without addressing developer culture issues, the same issues that impact the current projects are likely to re-emerge in the new world.

      Having said that, I don’t rule out the question of re-examining the ways different platforms are being used. However, this is where the Genba, Genbutsu, Genjitsu principle comes in. There are layers of both hype and scorn around the existing platforms. The new leadership team needs to be sure it gets behind that spin (both positive and negative) to find out what’s really happening in different projects. They need to “go to see the real facts for themselves”.

      Comment by David Wood — 13 September 2010 @ 9:39 pm

  3. Nokia’s biggest problem is generic “large company disease”. I.e. there is a very feudal organisation within the company with significant disconnects between groups that should be working closely together.

    The new CEOs first and most important job is to make everyone pull together in the same direction. It’s going to be great seeing if this can be done.

    Comment by David Durant — 13 September 2010 @ 9:52 pm

  4. Quantity is not quality. Nokia’s only vision is to cut costs everywhere you can. Nokia’s only measure of success is how many units they ship per year.

    You can talk about visions, power to execute, level of incompetencies or Risku plan, all I see as a user are products of sub-standard build quality and hardware specifications upon which their OS can’t perform.

    If Nokia was in car industry they would be trying to build Lexus with Toyota approach.

    Comment by Michael R. — 14 September 2010 @ 8:15 am

    • Hi Michael,

      You can talk about visions, power to execute, level of incompetencies or Risku plan…, all I see as a user are products of sub-standard build quality and hardware specifications upon which their OS can’t perform

      I agree, Nokia has to fix the latter issues – the ones that end users see and experience. But that doesn’t mean the former issues are unimportant. On the contrary, the former issues are the causes of the latter ones. Fixing the vision, power to execute, and competence level (etc) should result in fixed product quality.

      Comment by David Wood — 14 September 2010 @ 9:00 am

  5. Small mistake: “Companies like RIM and BlackBerry have powerful product designers” – Blackberry is not a company, it is a product.

    I am generally not sure if recruiting a manager from Microsoft, with their dreadful development cycles, is such a good idea, but I may be wrong.

    Comment by Bart — 14 September 2010 @ 11:11 am

    • Hi Bart,

      I meant to say “Companies like RIM and Apple…”, rather than “Companies like RIM and BlackBerry…”. Thanks for catching this typo – which I have now fixed.

      Microsoft have their share of dreadful development cycles, true, but some parts of Microsoft (e.g. the Office group, where Elop worked) have better processes in place. However, I’m not expecting Elop to single-handedly improve Nokia’s over-long development cycles. Instead, I’m hoping that he will bring in and enable suitable consultants and senior managers to effect this change.

      Comment by David Wood — 14 September 2010 @ 11:21 am

  6. It is a nice article, not just for Nokia for any company which wants come out strongly.
    In addition my feeling is Nokia has gone into a state where they think they are the best in the world, for others to reach them it will take many years. That complacency is creating spoil sport.
    As you said, they are upgrading to higher levels of incompetency.

    Comment by Rajesh K — 27 September 2010 @ 8:46 am

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.

%d bloggers like this: