“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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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”.
- 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.
- 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.
- 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.
- 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“.
dw2 
Love the remark that 2 turkeys do not make an eagle! Absolutely true!
Though, I would like to add one thought to that remark from Anssi. It is that typical Finnish culture which brought up Nokia from producing rubber boots to be a worldwide leading communication technology company. Software Development is as much about culture as it is about technology.
Comment by Yusuf — 2 March 2011 @ 9:20 am
Your list omits an important item, let’s call it item zero:
0. Choose the right partner. (Where “no partner at all” may be the right partner.)
Now the question is: did Nokia make the right choice of partner?
To answer this, we need to ask: why did Nokia seek a partner? The answer is ecosystem. For too long Nokia has always been about the phone and it only realised relatively recently the importance of the ecosystem around the phone. I know that one of the reasons for the initial creation of Symbian was to form an ecosystem, but despite initial good intentions the was never any real concerted effort to create that ecosystem (either within Symbian, Nokia or any other members of the partnership). It was always about the next phone.
The iPhone was initially successful not only because it was a pretty sexy phone, but also because it plugged right into Apple’s existing ecosystem – an ecosystem that Apple has continued to extend to support the iPhone. Android was initially successful because, as well as creating a great UI, Google put a lot of effort into creating a successful ecosystem. (For example, it’s developer environment is great. Earlier this year, for fun and out of curiosity, I wrote my first Android app. It took just over three days and that included learning Java (I hadn’t previously written much more than a Java “hello world” app). The result is here: https://market.android.com/details?id=org.mjbudden.android.solarsystem )
If you accept the premise that, to survive, Nokia needed to obtain an ecosystem, then the question becomes which ecosystem? The choices were: really try and make a go of Symbian or MeeGo, or join an existing ecosystem. (Had Nokia acted early enough it probably could have also had the option of buying Palm.) In the end, by most reports, it came down to a choice between Google Android and Microsoft Windows Mobile.
Of these choices, I don’t think Microsoft was a particularly wise choice. Microsoft has one of the smallest ecosystems. It has the will and finances to extend that ecosystem, but it’s track record in the handheld/mobile space has been very poor. It’s attempted entry into the palmtop/PDA market with Windows CE circa 2000 went nowhere. It tried to kickstart the tablet market, but totally misjudged what people wanted in tablets – Windows Tablets were heavy, bulky clunky things (at a time when the technology existed to make them much smaller and lighter than they were). Microsoft has never made an appreciable dent into the mobile phone market. I think Nokia made a mistake in doing a deal with Microsoft.
What about Android? I think it’s a slightly better match. Google’s patent portfolio is weak, Nokia’s is strong: therein lies what could have been the basis of a partnership.
But actually I don’t think either was a particularly good choice. Nokia has gone from leader to laggard in a few short years. The way to regain its position is not to try and crawl its way up from the bottom. The way back is to disrupt the market.
So how could Nokia have disrupted the phone market? The answer is by re-entering the market on the back of a different parallel ecosystem, the ecosystem of the web. Rather than choosing Symbian or Windows Mobile or Android, Nokia should have made the browser engine integral to the phone and made HTML/Javascipt the development environment.
Comment by Martin Budden — 2 March 2011 @ 4:07 pm
spot on martin. when i speak as a developer people think i’m just another fan boy. I’m glad some one shares my view.
Comment by ifeoluwa walter — 6 March 2011 @ 10:29 pm