dw2

2 March 2011

On turkeys and eagles

Filed under: Microsoft, Nokia, partners, software management — David Wood @ 12:39 am

Two turkeys do not make an eagle“.  That was the response given in June 2005 by outspoken Nokia EVP Anssi Vanjoki, to the news that two of Nokia’s rivals – Siemens and BenQ – were to merge their mobile phone divisions.  “The integration of the handset units of the two companies is equivalent to one big problem meeting another”, Vanjoki remarked.  It was a remark that caused some consternation in the Symbian boardroom at the time, where both Siemens and Nokia were members.

Six years later, the same pointed saying bounced around the Internet again, this time in a tweet from Vic Gundotra, VP of Engineering at Google.  On this occasion, the alleged “turkeys” were Microsoft (where Gundotra himself had worked for 15 years) and Nokia.  The tweets anticipated the February 11th announcement of Nokia identifying Microsoft’s Windows Phone as its new primary smartphone platform.  Gundotra’s implication was that Nokia’s adoption of Windows Phone would end in tears.

Behind the barb and the humour, there’s a very serious question.  When do partnerships and mergers create genuine synergies, that add up to more than the sum of their parts?  And when do these partnerships, instead, just pile one set of problems onto another – akin to tethering two out-of-form runners together as a team in a three-legged race?

That question is particularly challenging in the world of software, where Brooks’s Law tends to apply: Adding manpower to a late software project makes it later.  This statement featured in Fred Brooks’s 1975 book “The mythical man month” – a book that my first software director asked me to read, as I was just starting on my professional career.  I vividly remember another statement by Brooks in that book: “Nine women can’t make a baby in one month.”

Having extra people in a project risks increasing the number of interconnections and the varieties of communications needed.  The homely proverb “Many hands make light work” implies that more software engineers would get the job done more quickly, but the equally venerable saying, “Too many cooks spoil the broth”, comes down on the side of Brooks’s Law.

Many of my industry colleagues and acquaintances tell me that the most productive, effective software teams they ever worked in were small teams, of perhaps only 7-50 people.  Seen in that light, there is some sense in Nokia’s decision to significantly reduce the size of its software development teams.  But what are the prospects for successful synergies from the newly minted software development partnership between Nokia and Microsoft?

Some differences between the development styles of Microsoft and Nokia are well known.  For example, Nokia spreads software development across many sites in many countries, whereas Microsoft prefers concentrated development at a smaller number of sites.  Relationships between developers and testers are much closer at Microsoft than at Nokia.  Microsoft keeps tight control of source code, whereas Nokia has been centrally involved in several open source communities (such as Qt, MeeGo, and Symbian).  Viewing these differences, what steps can be taken to heighten the chances of positive and lasting cooperation?

Given this background, I offer ten suggestions, for any pair of companies embarking on a major software partnership or merger:

  1. Don’t insist on uniformity. There’s no special need for the two partners to adopt the same tools, same processes, or same internal language.  It’s the interface between the two software teams that matters, rather than whether the teams look like clones of each other.
  2. Do insist on quality. Where the software from the two teams meet, that software needs to work well.  Quality comes well ahead of quantity.  Otherwise, huge amounts of time can be wasted in debugging issues arising during the integration of the two sets of software.
  3. Be ready to revise opinions. Expect there to be misunderstandings, or for new insight to emerge as software from the two teams comes into contact.  Be sure there’s sufficient nimbleness, on both sides, to revise their software quickly in the light of learnings at the point of contact.
  4. Become experts in interface management. This is the discipline of seeking to preserve compatibility of interface, even when new features are added, or performance is improved.  Here, the “interface” includes non-functional aspects of the definition of the software (including behaviour under stress or error conditions), as well as the original set of functionality.  And when interfaces do need to change, be sure that this fact is properly understood and properly communicated.
  5. Avoid feelings of “us and them”. Find ways to build positive bonds of trust between people on the two teams.  This can include staff interchange and secondments, and shared online community tools.
  6. Practice “tough love”. Where problems arise in the interaction between the two teams, it must be possible to speak frankly about these issues, rather than keeping mum for the sake of some kind of dysfunctional “peace and quiet”.  Provided a good fulcrum of shared trust has been established, robust discussion should lead to light rather than heat – a focus on “what is best” rather than “who is best”.
  7. Keep the end-to-end experience firmly in mind. Mainstream market adoption of software needs more than just neat technology.  The larger the overall software system, the greater the need for world-class product managers and designers to keep on top of the development project.  There’s no point in optimising individual parts of this system, if there’s a fundamentally defective link in the overall chain.
  8. Paint a compelling, credible picture of the benefits that the partnership will bring. Members of both teams must be inspired by the “why” of the partnership – something that will give them sufficient reason to dig deep when times become tough.  In practice, this picture will involve a roadmap of envisioned shared success points.
  9. Design and celebrate early successes from the relationship. Identify potential “quick wins” along the path to the anticipated future larger successes.  By the way, in case these quick wins fail to materialise, don’t sweep this fact under a carpet.  This is when the tough love needs to kick in, with both sides in the relationship being ready to revise opinions.
  10. Keep investing in the relationship. Don’t take it for granted.  Recognise that old habits and old mindsets will tend to re-assert themselves, as soon as management focus moves elsewhere.  Early wins are an encouraging sign, but relationship managers need to keep the momentum running, to avoid the partnership from stagnating.

Think that’s too much advice? Believe you could give attention to one or two of these pieces of advice, and “wing it” with the others? Think again. Major software partnership is major effort. Skimp on the details, and you’ll end up with two turkeys tied together as unhelpfully as in a three-legged race. Invest profoundly in the partnership, however, and you may indeed see the birth of a new eagle.

Note: the above advice would still apply, even in the taking-things-one-step-further “acquisition scenario” discussed by Andreas Constantinou in his latest VisionMobile article “Is Microsoft buying Nokia? An analysis of the acquisition endgame“.

Advertisements

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.

13 August 2008

There’s more to Open Innovation than Open Source

Here’s the challenge: How best to capitalise on the potential innovation that could in theory be created by users and developers who are based outside of the companies that are centrally responsible for a product platform?

This is the question of how best to make Open Innovation work. Recall the following contrasts between Open Innovation and so-called Closed Innovation – taken from the pioneering book by Henry Chesbrough, “Open innovation: the new imperative for creating and profiting from technology”:

The “closed innovation” mindset:

  1. The smart people in our field work for us
  2. To profit from R&D we must discover it, develop it, and ship it ourselves
  3. If we discover it ourselves, we will get to the market first
  4. The company that gets an innovation to market first will win
  5. If we create the most and the best ideas in the industry, we will win
  6. We should control our IP, so that our competitors don’t profit from our ideas.

The “open innovation” mindset:

  1. Not all the smart people work for us. We need to work with smart people inside and outside our company
  2. External R&D can create significant value; internal R&D is needed to claim some portion of that value
  3. We don’t have to originate the research to profit from it
  4. Building a better business model is better than getting to market first
  5. If we make the best use of internal and external ideas, we will win
  6. We should profit from others’ use of our IP, and we should buy others’ IP whenever it advances our own business model.

In the modern world of hyper-complex products, easy communication via the Internet and other network systems, and the “Web 2.0” pro-collaboration zeitgeist, it is easy to understand why the idea of Open Innovation receives a lot of support. The challenge, as I said, is how to put these ideas into practice.

It’s tempting to answer that the principal key to successful Open Innovation is Open Source. After all, Open Source removes both financial and contractual barriers that would otherwise prevent many users and external developers from experimenting with the system. (What’s more, “Open Innovation” and “Open Source” share the prefix “Open”!)

However, in my view, there’s a lot more to successful Open Innovation than putting the underlying software platform into Open Source.

To see this, it’s useful to review some ideas from the handy summary presentation by leading Open Innovation researcher Joel West, “Managing Open Innovation through online communities”. Joel makes it clear that there are three keys to making Open Innovation work best for a firm (or platform):

  1. Maximising returns to internal innovation
  2. Incorporating external innovation in the [platform]
  3. Motivating a supply of external innovations.

Let’s dig more deeply into the second and third of these keys.

Incorporating external innovation in the platform

The challenge here isn’t just to stimulate external innovation. It is to be able to incorporate this innovation into the platform. That requires the platform itself to be both sufficiently flexible and sufficiently stable. Otherwise the innovation will fragment the platform, or degrade its ongoing evolution.

It also requires the existence of significant skills in platform integration. Innovations offered by users or external developers may well need to be re-engineered if they are to be incorporated in the platform in ways that meet the needs of the user community as a whole, rather than just the needs of the particular users who came up with the innovation in question.

  • This can be summarised by saying that a platform needs skills and readiness for software management, if it is to be able to productively incorporate external innovation.

Motivating a supply of external innovations

The challenge here isn’t just to respond to external innovations when they arise. It is to give users and external developers sufficient motivation to work on their ideas for product improvement. These parties need to be encouraged to apply both inspiration and perspiration.

  • Just as the answer to the previous issue is software management, the answer to this issue is ecosystem management.

But neither software management nor ecosystem management comes easy. Neither fall out of the sky, ready for action, just by virtue of a platform being Open Source. Nor can these skills be acquired overnight, by spending lots of money, or hiring lots of intrinsically smart people.

Ecosystem management involves a mix of education and evangelism. It also requires active listening, and a willingness by the platform providers to occasionally tweak the underlying platform, in order to facilitate important innovations under consideration by external parties. Finally it requires ensuring that third parties can receive suitable rewards for their breakthroughs – whether moral, social, or financial.

Conclusion: On account of a legacy of more than ten years of trial and error in building and enhancing both a mobile platform and an associated dynamic ecosystem, the Symbian Foundation will come into existence with huge amounts of battle-hardened expertise in both software management and ecosystem management. On that basis, I expect the additional benefits of Open Source will catalyse a dramatic surge of additional Open Innovation around the Symbian Platform. In contrast, other mobile platforms that lack this depth of experience are likely to find that Open Source brings them grief as much as it brings them potential new innovations.

Create a free website or blog at WordPress.com.