dw2

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.

15 December 2008

Accelerating out of molasses

Filed under: disruption, modularity, Nokia, time to market — David Wood @ 4:00 pm

Michael Mace has posted a characteristically thoughtful article on his Mobile Opportunity blog:

Every time I think about Nokia and Symbian, I can’t help picturing a man knee-deep in molasses, running as fast as he can. He’s working up a sweat, thrashing and stumbling forward, and proudly points out that for someone knee-deep in molasses he’s making really good time…

The posting is entitled “Nokia: Running in molasses“. It arose from Mike reflecting on some of what he heard at the recent Symbian Partner Event (SPE) in San Francisco. The posting is well worth reading. I appreciate the issues that Mike raises. These issues are significant. But as you might expect, I have a somewhat different perspective on some of them.

Large software doesn’t mean that software development has to go slow

Charles Davies, Symbian CTO, pointed out to us that Symbian OS has about 450,000 source files. That’s right, half a million files. They’re organized into 85 “packages”…

There are economies of scale as well as dis-economies of scale. The point of the careful division of the Symbian Platform software into packages is to enable each of the resulting packages to have greater autonomy – and, therefore, to progress more quickly.

There’s one subtle point here. Many of the packages include teams from both Symbian and from S60. This applies to cases where the separation of functionality between the two formerly distinct companies resulted in sub-optimal development. Now that Nokia’s acquisition of Symbian has completed, these boundaries can be intelligently re-designed.

Disruption, size, and organisational design

This brings me to a comment on the ideas of Clayton Christensen. Here’s another extract from Mike Mace’s article:

If the folks at Nokia really think they are well positioned to crush Apple, they need to go re-read The Innovator’s Dilemma. Being big is not a benefit in a rapidly-changing market with emerging segments.

Agreed, being big is no guarantee of being able to respond well to changing market conditions. That’s why I’m personally a big fan of Agile. Agile can help established companies (whether large or small) to launch and embrace disruptions. As Scott Anthony, one of Christensen’s co-authors, has recently commented in his article “Can Established Companies Disrupt?“:

The data suggests that it is increasingly common for an established company to launch disruptive innovations. More and more incumbents are learning how to embrace disruptive principles such as:

  • Put the customer, and their important, unsatisfied job-to-be-done at the center of the innovation equation
  • Embrace the power of simplicity, convenience, and affordability
  • Create organizational space for disruptive growth businesses
  • Consider innovation levers beyond features and functions
  • Become world class at testing, iterating and adjusting

As I said, being big can have its advantages as well as its disadvantages, so long as individual parts of the company have sufficient autonomy. The hard part is knowing when to seek closer ties, and when to seek looser ties. One of Christensen’s later books had some very interesting advice on that score. I can’t remember for sure whether that book was “The Innovator’s Solution” or “Seeing What’s Next“. The advice was that where performance remains a critical differentiator, you should look for a tight coupling. Where performance is already “good enough”, you should seek a loose coupling – with open APIs and a choice of alternative solutions.

As soon as I read these words, some time around 2003-2004, I had a gut reaction that, one day, the relevant teams in Symbian software engineering and S60 software engineering ought to be combined. It took a long time for that insight to be fulfilled. But now that it’s happening, there’s plenty of good reason to expect the resulting combined company to start accelerating its development.

Development in parallel with change

Back to Mike Mace, commenting on the SPE presentation by Charles Davies:

Davies talked about the substantial challenges involved in open sourcing a code base that large. He said it will take up to another two years before all of the code is released under the Eclipse license. In the meantime, a majority of the code on launch day of the foundation will be in a more restrictive license that requires registration and a payment of $1,500 for access. There’s also a small amount of third party copyrighted code within Symbian, and the foundation is trying to either get the rights to that code, or figure a way to make it available in binary format.

Those are all typical problems when a project is moving to open source, and the upshot of them is that Symbian won’t be able to get the full benefits of its move to open source until quite a while after the foundation is launched. What slows the process down is the amount of code that Symbian and Nokia have to move. I believe that Symbian OS is probably the largest software project ever taken from closed to open source. If you’ve ever dealt with moving code to open source, you’ll know how staggeringly complex the legal reviews are. What Nokia and Symbian are doing is heroic, scary, and incredibly tedious. It’s like, well, running in molasses.

I have four comments on this:

  1. Even though the full transition to open source may take up to two years from the initial announcement of the foundation (that is, until mid 2010), there are plenty of other things happening in the meantime – with a series of interim releases that progressively convert more of the software from the community-source Symbian Foundation Licence to the open-source Ecliplse Public Licence;
  2. There will be new technologies and new UI features in these interim releases;
  3. The interim releases should already achieve at least some of the considerable benefits of both open source and community source; the first packages which will become available under the EPL are being chosen so that independent developers can do useful things with some of them (including contributing back working code enhancements);
  4. The legal reviews may initially seem daunting, but with the help of modern code-scanning tools and with the advantage of “practice makes perfect”, the process is likely to speed up considerably along the way.

Cool stuff in the lab

Mike ends the main part of his article as follows:

Nokia still has a lot of time to get it right. But do they really understand what needs to change? I can’t tell, because all I usually get from them is monologues on how big their business is and how much cool stuff they have in the lab.

I accept that analysts must inevitably hedge their bets, regarding the extent of future success of the main mobile operating systems, until a period of proving over the next 12-24 months has shown what these operating systems can actually accomplish. I eagerly look forward to the day when more of the Symbian and Nokia roadmap of stunning new technology, new services, and new user experience attains greater visibility. When that happens, analysts are likely to come down off the hedge.

My own expectation is that the moves to integrate Symbian and Nokia, and to create the Symbian Foundation, will see a substantial speed up of innovation over that time period. But I’m not taking this for granted. After all, I’m well aware of the original subtitle of “The Innovator’s Dilemma”: “When new technologies cause great firms to fail“.

Create a free website or blog at WordPress.com.