dw2

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