What Nobody Has Written Yet About Nokia, Elop, and the Burning Platform

Why Nokia Topics Generate So Much Flame and Hype

The crisis and restructuring at Nokia resonates with the Russian heart because the USSR recently collapsed, and Yeltsin was restructuring it. When things "got going" with the USSR, everyone was speaking the truth on every corner. Truth poured from TV screens and newspaper pages, books were written in volumes. Everyone had their say about the crisis. After the discussions, society plunged into the routine of daily affairs.

The situation with truth-telling about Nokia is a carbon copy of the USSR's collapse. Most opinions are a cocktail of financial report interpretation, analysts' personal grudges, and readers' personal experience. My opinion is based exclusively on my own experience and knowledge of the company, so I don't claim absolute objectivity.

Suomalainen Yritys, or the Role of "Sisu" in a Finnish Company's Strategy

Finland has historical roots that explain Nokia's strange behavior in various situations. Finns work diligently, conscientiously, without whining over trifles. Finnish engineers are mostly introverts. Finnish extroverts look at your shoes, not their own, when talking to you. Introverts who work meticulously can move mountains.

A Finnish engineer needs to carefully plan everything, verify it, and read the documentation before starting work. The ability to methodically work over a long period, overcoming difficulties, is called "sisu" by the Finns. There's no single translation into English.

Finland was under Swedish rule for a long time, then was part of the Russian Empire, then survived the Winter War with the USSR and paid reparations. Constant pressure forged the "sisu" psychology in the Finnish people.

The Finnish engineer's weakness is an environment that demands quick reactions and rapid decisions. In dynamic situations, meticulous Finnish engineers get lost because they need to plan and verify everything in advance.

By 2001, Finnish Nokia engineers had earned their authority through hard work on NMT and simple but reliable GSM phones. The company began expanding, focusing on mobile phones. Nokia sold off its tractor and television divisions, which weren't related to the core business.

How Pekka Became a Manager...

A good antenna engineer (let's call him Pekka) would become a senior engineer, then a specialist, then a senior specialist — then career growth along the engineering track would stop. As of 2003, Nokia's policy implied continuous growth only through the management track. To earn more money, an engineer had to become a manager.

Nokia created manager positions based on years of service. Under this scheme, Nokia acquired the status of an almost government organization with a seniority-based hierarchy: 3 years of work — senior engineer, another 3 — specialist, and so on.

Pekka is a great antenna engineer but a poor manager. He works excellently alone but feels uncomfortable managing others. As soon as he becomes a manager, he's invited to 20 meetings a week, his opinion is needed on various issues, plus work meetings, planning, and reporting.

In a short time, Pekka realizes that the only thing he has time for is attending meetings and forwarding information to various departments in a lazily compiled form. The higher the department, the fewer words and PowerPoint slides. The lower the department, the more questions.

Over time, Pekka starts losing touch with reality. Plans look nice only in his head, while reality lags behind because someone needs to do the actual work, and a Finn will also think everything through thoroughly. After a while, we get a typical talker-theorist manager of the mid-2000s who can't live the old way but doesn't know the new way.

Every year, Pekka approves essentially the same thing in the roadmap, and every year it comes more smoothly because he repeats polished, verified arguments. He asks himself — why is the super antenna planned for 2004 still in the 2005 and 2006 plans?

At some point, Pekka realizes the number of committees exceeds his capacity. Every decision requires diving into details, but he physically can't keep up, plus he's losing his qualifications, plus nobody can start working without his approval. Decisions need to be made quickly.

Seeing that implementation can't keep up with the talking, Pekka discovers "risks." The concept of "risks" is great for Pekka because you can introduce an infinite number of risks into any problem analysis. If a task isn't moving, you can always surround it with a high level of risks.

How Anxious Managers Worked...

The super antenna gets approved year after year because everyone is working well. A paradox? No. After the plans are approved, most managers get promoted the following year and deal with other problems. Pekka spends another year explaining things to the new generation of managers. Then another year, until he moves to a higher position and dumps the problem on his successor.

Nobody can blame Pekka for not pushing the super antenna. But to push it forward and start work, you need a product that agrees to adopt it. And there, other managers with their own risk assessments don't want to take on a new, untested feature. And they don't have time to dive into the details.

To resolve the situation, anti-patterns begin to be applied:

1. Postponing decisions by restructuring the problem, breaking it into components, or reformulating it
2. Making decisions through compromise and shared responsibility — "I agree if everyone agrees"
3. Postponing decisions using risks as the key argument that masks uncertainty

The result is a management layer that talks a lot and smartly, finds countless reasons to "discuss later" and "in more detail," but makes no real decisions. This assessment is an extreme caricature, but it's needed to understand the big picture.

The main idea: Nokia's decision-making system was corrupted by multi-level bureaucratic hierarchy and managers fighting with themselves. Most "mature" decisions were made due to the company's sluggishness, out of necessity, when the situation was driven to a critical point requiring immediate escalation.

Strange Design Decisions

From Pekka, let's move to Maria — a senior UX designer for S60, developing the browser UI. The menu in S60 had up to 4 levels of nesting and about a hundred items. Maria designs it following existing patterns that call for creating a submenu item for every little thing. She doesn't care about the other 20 menus in the phone and their duplication.

Maria could spend two months discussing whether to name a new submenu item "Clear browsing history" or "Clear history" and ultimately name it "Clear data" because it's shorter and the localization doesn't exceed one line.

Maria does all her work in Adobe Acrobat with special templates, producing PDF files. Developers cut out raster screenshots and redraw everything themselves. Nobody tries to offend Maria because she's nice and a good person.

The main guy assembling all the menus in the phone sighs and squeezes in yet another menu item, redrawing everything from Acrobat. He'd do it all properly himself, but there's no time to explain things to Maria at length, otherwise he'd create an awkward situation by ignoring someone else's opinion.

Finland is a country of average people. Attention is given only to the underperforming and lagging behind. If you're smart and talented, you won't be encouraged or held up as an example, and if you're also immodest, you'll be reprimanded. Those who fall behind are the center of attention, every tiny step of theirs is considered an achievement.

People understand the S60 menu problem exists, but when fixing it comes down to the personal level of Maria or Pekka, rarely does anyone take responsibility to say "Maria, you're doing a crappy job." Rarely does anyone try to push for a more creative approach to work. She's working on something — fine.

The Bonus and Motivation System

It didn't matter how an employee worked during the year — poorly, normally, or excellently. It didn't affect salary — it only increased over time, never decreased. It only affected the annual bonus, which due to convoluted calculation schemes was never significant. The final difference between a poorly performing employee and one doing double the workload was a couple hundred euros per year.

The performance evaluation system was dubious. Priorities set at the beginning of a half-year became irrelevant by the end. New priorities would emerge, and managers would suggest giving an average rating — "normal."

The salary increase system was very murky. Raises negotiated by unions for inflation were several times higher than what you'd get for doing double the workload over several years.

This led to the emergence of "gonzo workers" who, understanding that you can't get a salary increase in one place, hopped between different positions in the organization with salary bumps, producing nothing substantial. It was more profitable to postpone important decisions and not see things through.

The greatest salary increases were achieved by people who left Nokia for another organization and came back. Inside Nokia, there was some kind of policy, but after leaving and returning, no limits applied. You could leave as a senior developer, work for a year at a subcontractor as a project manager, and come back as a senior manager with double the salary in two years instead of several years of hard work.

Insane Subcontracting

At some point, when there were plenty of managers, they decided that some projects were more profitable to outsource to third-party organizations. For example, Jukka, 35 years old, wants to be a manager. He works on the SMS editor. They make him a manager and let him manage editor development at a conceptual level. Architecture astronauts promise a truly global editor, so let's not hire developers — let's outsource it. Jukka will be responsible for tasks and training.

The benefits are obvious — no need to hire permanent employees and pay taxes, costs are clear and plannable, quality criteria are controllable. When it's time to shut down, there won't be problems.

Nokia compensated for the crisis and internal career growth problems with hired workers disguised as subcontracting. An incredible number of firms proliferated in Finland, existing on Nokia subcontracts — TietoEnator (Tieto), Sesca (NeuSoft), Flander (Symbio), Almare (Plenware, Cybercom), Digia, Accenture, Ixonos, and so on. Later this was extrapolated to outsourcing based on class differences — hiring 10 programmers in India instead of one in Finland.

The main problem with subcontracting is that competence and know-how get diluted between two companies, nullifying all previous achievements. Not all knowledge is transferable; outsourcing kills internal competence.

In 2008, Nokia closed a factory in Germany and a department handling local communication in phones — one of the most advanced departments. It was bought by Sasken. Nokia signed a subcontracting deal with Sasken, and the department continued working with a reduced staff. A year later, Sasken dissolved the department, moving operations to India.

Imagining how the contents of German engineers' brains, accumulated over several years, could be shipped to Bangalore and used to train even 10 times more Indian programmers is impossible. This is just one story among many similar ones.

Nokia developed a system of perpetual outsourcing — on a site basis. The main value is the code, but outsourcing technological competence that represents the core business is not possible. Nokia's outsourcing model was the reverse — code and technology implementation were done in dozens of subcontracted organizations.

As a result, in some areas the management layer became the final link in the hierarchy — a crowd of smart talkers setting technical requirements for third-party organizations. Their main talents weren't being fully utilized. In working with outsourcing, there was no understanding of the contract's contents. Some key requirements, having passed through the hands of several managers, simply dropped out of the product.

An organization where the core business is one big subcontract — that was Nokia before 2008.

Symbian

When Nokia released the 9110 Communicator in 1998, it became clear that without a multitasking OS, things would be tough. Whether it was needed for regular phones is another question, because the iPhone and Windows Phone 7 later showed you could build a phone without a "full" OS.

Nokia didn't have the resources to write an OS on its own. But it at least wanted to develop the UI itself. Between Windows CE and EPOC, Nokia chose EPOC because Microsoft wouldn't agree to separate the UI from Windows CE.

In 1998, the company Symbian Ltd. was created, with founders Psion, Nokia, Ericsson, and Motorola. Symbian Ltd. made three platform versions — for Nokia (S60), for Motorola and Ericsson (UIQ), and for the Japanese market (MOAP). All had different UIs and feature priorities. A kernel feature accepted for UIQ could be delayed by a year for S60 or vice versa.

EPOC and Symbian were written in C++, but in times when there was no unified standard yet. Symbian was known for its peculiar C++ programming quirks, which were profanely revered by developers. Developing the kernel in C++ meant that nothing from open source could be used without porting, which hindered development.

The SDK model and documentation were idiotic. A bunch of disparate API packages and an inconsistent approach to using them led to an interesting situation. To set up a development environment and write "Hello World!", the average developer needed up to a week. Compare that with Xcode for iOS or the Android SDK. It's no surprise that in two years, more iPhone apps were written than for Symbian in its entire lifetime.

Developing for Symbian was a difficult task for independent programmers. A separate type of specialist emerged — the Symbian developer. After Nokia's mass layoffs, some found it hard to find work due to low demand for this skill.

The problem was solvable by creating more coherent APIs, organizing documentation and examples, writing RADs for Eclipse. This started being done in Symbian's twilight — partly through Qt, partly through plain C libraries. But the time was lost, and independent developers quickly moved elsewhere.

Was this a problem with the operating system? No. Symbian could have been polished to a competitive state. Looking at the last Symbian devices, things had been quite carefully refined. But Nokia's problems weren't in the OS or technical decisions — they were in the sluggish organization that couldn't keep up with competitors.

There was an OS whose kernel was developed through subcontract negotiations between Nokia and Symbian managers. Middleware and UI were written by Nokia as S60, with specific phone programs needing features not yet implemented. Symbian made the OS not only for Nokia but maintained two branches for other participants. S60 with all of Nokia's bells and whistles was offered as a separate platform for licensees — Samsung and LG.

The situation reached absurd levels. A programmer from S60 and a programmer from Symbian could implement a feature ahead of schedule, test it, and put it in the build. Then this working feature would be sequentially removed from the release due to managerially incompetent risk and priority calculations. Programmers had to modify tested code to isolate the feature.

One core component of Symbian's communication library was written by a student during a summer internship. No improvement requests were accepted because nobody knew the code, refactoring couldn't meet deadline requirements, and the risk of touching it was significant. The component could go untouched for years because of risks.

Over years of this model, bureaucracy and buffer layers grew, while product quality declined. For each specific phone release program, there was a terrible headache — what to build the software from? Wait for Symbian, S60, write it ourselves, or outsource? This all happened against the backdrop of dynamic priority shuffling and conflicts of interest among managers.

What Is Fragmentation?

Nokia had several more levels of fragmentation. It arose gradually and began to intensify when a clever guy named Anssi Vanjoki appeared, who through aggressive behavior and pressure proved the necessity of creating a Multimedia division.

There were attempts to create S90 (Touch UI phones long before Android and iPhone) and N-Gage (a mobile gaming console). S90 used a stylus instead of a finger. Years of work, hundreds of people, the unreleased phones 7700 and 7710, tons of prototypes, millions of dollars spent essentially for nothing.

N-Gage was supposed to be a mobile gaming console. Two devices came out — N-Gage and N-Gage QD, then the initiative was shifted to a service similar to Microsoft Xbox, where it died. Users couldn't understand why they needed to launch N-Gage when they could just install the game. The app distribution policy was absolutely insane. Also millions of wasted dollars.

Anssi pushed his agenda, and Nokia released three smartphone lines — regular, multimedia (stubbornly called mobile computers), and business. Apart from the letter N in the model number, nobody could clearly articulate how they differed. There was the Nokia 3250, which was more powerful than some N-Series phones and included all the features. Nobody could coherently explain why it wasn't "multimedia."

A mobile analyst's saying: if someone says "Mobile Computer" when talking about a phone, they work in Nokia Multimedia. This is absolutely true.

Meanwhile, fragmentation physically resulted in team duplication. There was a team with an X million budget developing camera software for the main S60 line. In a neighboring city sat another team with an even bigger budget making camera software for "mobile computers" — that is, the same smartphones with an N prefix. Two teams, double the costs, two code branches that never intersected. At the same time, another team at Symbian was making camera software for UIQ.

There were many such duplicated teams. E-Series (business smartphones) also had fragmentation because business team priorities didn't align with multimedia, and all of them together got in the way of the regular S60 guys' plans.

Due to fragmentation, a huge amount of money was wasted on double (and sometimes triple) work. Exact figures are hard to state, but if they're ever revealed, a couple of Arab sheikhs will choke with envy.

On Insane Expenses

Since we're talking about spending, we must mention the morning Helsinki-Oulu flight. A regular MD-11 for 200 passengers. 90% were Nokia employees. The joke was that the remaining 10% were industrial spies. Everyone paid 30 euros for a one-way taxi. There were other flights too — to London (Symbian), Germany, Canada, etc.

A mid-level Nokia manager would "fly up" enough in a year for a Finnair silver card, equivalent to OneWorld Ruby — 40,000 points. A European flight gives about 3,000 points, a US flight about 5,000. If a manager was on a virtual team spanning Finland, Canada, and China — permanent gold status and business lounges.

People flew a lot, flew often, to every corner of the world. Sometimes it was easier to fly from Finland to Germany for a couple of days, hold an hour-long meeting, and fly back. When they started cutting costs, they installed Tandberg video conferencing systems at $20,000 each. Nobody used them because Finns are shy and don't like showing themselves on camera.

Why create virtual teams across different time zones when coordination consumes an unreasonable amount of money and time? There was a tradition of having representatives from all countries and continents. If the goal was to let Finnish engineers see the world, mission accomplished. If the goal was efficiency, it was the wrong approach.

Another expense item was company acquisitions. In 2005, Nokia spent $430 million on Intellisync. Nobody could explain what exactly was purchased. They didn't even have a SyncML solution. All they had was vague MSN services and an Outlook-Palm sync engine written for 16-bit DOS. I applaud Intellisync's owners.

One of Nokia's useful acquisitions — Trolltech, which wrote Qt — cost $150 million, nearly three times less. Nobody was killed, fired, or charged for wasting money. Spent God-knows-what on God-knows-what, and that's that.

The full list of acquisitions shows an enormous number of purchases. A significant portion of acquired companies dissolved into Nokia without a trace.

There were also cases of buying professional services instead of companies. From 2002 to 2008, Nokia paid an English company of five people $1.8 million per year for an Outlook sync program. The company didn't own the source code until it was sold separately in 2008. The company subsequently left software and opened a real estate business in London.

The core problem was the absence of accountability. Collective decisions are formed through compromise, responsibility gets smeared. Bought a thousand Tandberg sets for $20 million, installed them, and never mind. Then a smart guy comes along and says they're not needed — a decision will be made. Everything in that spirit.

On Secrets and Mobile Analysts

In the 2000s, Nokia didn't care about user opinions. There was no feedback form, no web analytics, crash analytics, usage analytics, or any other statistics. Few people had any idea WHAT real people wanted.

Mobile phones were invented based on magical calculations using a strange coordinate system — from housewives in Peru on donkeys to vice presidents of tech companies on one axis, and young enthusiasts, surfers, gamers, music lovers, pragmatic leaders on the other. Smart diagrams were created with clusters showing potential niches. How this was done without real user feedback is unknown.

The result was new phones every year. Apart from design innovations, it was hard to tell how one differed from another in terms of software. WHY did the company spread itself across multiple models within a year?

Out of ten phones released per year, the number of decent ones rarely exceeded 2-3. Even if the software was 99% identical, everything depended on the lead product manager. If the manager was good, the product was relatively bug-free.

Many remember the 6300, N95, E71; few remember the 7500, N96, E72. Phones like the 7610 and N97 were recalled with a sense of shame. It all came down to the manager.

If the manager had a personal desire to release a quality phone, they'd test it day and night, push everyone, delay the release when necessary. But such people were few. Unfortunately, I've described the managerial characteristics above. Combined with the lack of accountability, this produced the results everyone saw.

Meanwhile, there was no understanding that people don't buy phones 3 times a year, and in 2005, people were still using models from 2000. Nokia employees lived with prototypes that wouldn't see the light of day until the following year. So quality complaints were often dismissed with "but that's such ancient stuff!" This disconnect from reality.

Firmware updates were only done at service centers, only fixing bugs, with no new features or platforms. Customer retention was completely absent; instead, there was mass production driven by exhausted managers who were chronically short on time and kept a stack of "risks" in their pockets.

Explaining to a manager that they needed to spend a month on refactoring to improve stability and extensibility was practically impossible. That's wasted time. Why refactor something that already works?

Against this backdrop, articles occasionally appeared in the press with criticism, improvement suggestions, and sensible ideas. It would be foolish to say the problems weren't visible internally. Articles were quoted and forwarded, but due to the lack of clear accountability, action was rarely taken, only on the most egregious issues like mass defects.

There was a PR department that handled voicing the company's official position. Its capabilities for organizing feedback and escalating it to the right level and teams were minimal.

Polite Finns don't like arguing and confronting. Any attack or criticism puts them in a dead end, makes them blush, and silently walk away quickly. It was easier to ignore mobile analysts criticizing Nokia than to descend to the level of public brawling. This created the precedent that Nokia was behaving arrogantly, supposedly unwilling to take responsibility for quality.

Against this backdrop, some mobile truth-seekers gained a loyal audience inside Nokia among employees who wanted to fix problems, trying to point out shortcomings using analysts' words.

People with access to prototypes would give them to well-known mobile experts. Those experts would promise private feedback and help improve the product. In reality, all experts want is to get an exclusive. Here we need to distinguish between real experts and "those" experts.

Nokia hires testing organizations, organizes focus groups, and prepares non-disclosure agreements with liability. That's how real experts work.

All the rest engage in self-promotion and truth-seeking, and their desire for recognition can exceed the bounds of decency.

One analyst published a review of the N8 prototype before its official unveiling. Nokia's management was forced to move the announcement to the next day. He threw his sources under the bus. There were consequences for the people who allowed the leak.

Countermeasures against the analyst weren't carried through. Having talked his way out of it, he continues to actively show off in public, passing personal emotions off as objective information.

A person who gives away prototypes without an official NDA is fouling their own nest. Announcement and release dates are very precisely calculated; nothing is as carefully calculated by manufacturers as announcement and release dates.

Hardware specs are planned well in advance and carefully. Software can theoretically be pulled together for the hardware after release via a hotfix or update — not ideal, but not fatal. If you misjudge the hardware, competitors will eat you alive. You need to pick quality hardware at a profitable price point so that after the announcement, competitors' countermoves are minimized.

Announcement and release dates are very carefully calibrated moments when everything should come together and generate profit. People who violate confidentiality by leaking specs are idiots. Declining profits hit their wallets and can cost them their jobs.

For a certain time, the secrecy regime was so lax that all roadmaps, names, and specs were available online. Prototypes were stolen from factories, left in taxis, stolen from DHL hubs. Entire presentations leaked online. Analysts discussed the specs of repeatedly unreleased prototypes. Compare that with Apple — there's much less such information there.

About Ovi in the Summer

The apotheosis of the company's development was the attempt to pivot to services. The company had no competencies, infrastructure, or methodology for creating quality services. But management presented an elaborate plan stating directly that Nokia's main competitors were Apple and Google, which already had service infrastructures. Samsung wasn't explicitly recognized as a competitor — it was viewed as a hardware company that wouldn't survive competition with service companies. The proposal was to build a competitive infrastructure from scratch and call it Ovi ("Door" in Finnish).

The first step was implementing Agile practices across all areas of development. The number of scrum masters and product owners went through the roof. A bunch of evangelists ran around the organization with Agile bibles, proposing an extreme approach where agile methodologies and anarchy seemed like the same thing.

Few people understood how to adapt agile methodologies to their area. Previously, software development stemmed from hardware development, where nothing decent can be applied besides waterfall because it's hard to be agile when assembling hardware. Software was tied to specific end-product requirements with formal UML descriptions and RUP-like methodologies. A developer had to provide functional and design specifications before writing code. This was burdensome, and there were agile advocates shouting about it from every corner. Having gotten what they wanted, these same advocates froze, turning Scrum into an idiotic mechanism where developers had to log every step, entering time down to the minute, instead of calmly writing code. The question of team scaling was nearly unsolvable and was handled using the old waterfall approach.

The second step was getting an answer — which services exactly? And which to tackle first? There were enormous numbers of proposals that eventually suffocated. Nothing better was found than replicating the same bundle — maps, contacts, mail, files, music, video, pictures.

While it was easy to justify the need for services internally, it was very difficult for the end user. Similar Google and Apple services already worked, and building competitive ones quickly and making users switch was extremely hard. The main bet was on existing Nokia phone users, who through their phones could be "hooked" on Ovi services. The hooking was supposed to start with the app store, which succeeded, as did the maps service.

The third step, which caused confusion, was the question — on which technologies would Nokia build its infrastructure? In some cases, the answer was trivial — take open source, attach a database to the backend, build on JavaScript and RESTful APIs. There were also those who waved SOA volumes around, talking about WS-I, SOAP, and WebServices architecture. There weren't fundamental debates, but different services were built on different ideologies. Experienced specialists had serious doubts about the optimism, but enthusiasm and money won out.

When Agile teams from Vancouver to Bangalore got to work with a lack of experience in building mass services and organizing inter-communication models, things moved slowly.

Many things from the "door-ification" era benefited Nokia. Agile adoption, NPS, organizing analytics and feedback channels, focus on customer retention, partial departure from Symbian, release of maps and navigation apps.

Ovi quietly died; some services were transferred to Yahoo. You can debate whether Ovi died before the strategy change or the strategy change killed it. Either way, history is silent about the total amount of money pumped into the initiative.

One More Positive Element

The management layer didn't go anywhere. By the law of conservation of mass, they flow where the money is, where you can talk and demonstrate bustling activity. That's what happened with Ovi. Loudmouths and theorist managers surfaced there over time.

Nokia regularly released various types of phones for vague segments that didn't want to be pigeonholed, asking for fewer models but better quality with backward compatibility. Since there were many products, there were business processes — Product Creation Process, describing what to do for a phone. One of the newly emerged Ovi ideologues presented a Service Creation Process, a carbon copy of PCP, just replacing the words from "product phone" to "product service." Exceptional idiocy, but it reflects the mental state of the management layer.

The positive moment: Ovi somewhat pulled managerial dead weight away from phones, allowing people to calmly polish Symbian and seriously tackle Maemo on Linux to create a platform for the war against competitors.

Some things were accomplished. They eliminated the nightmarish perpetual outsourcing model by buying Symbian. Developers were offered Qt — a coherent package that was relatively easy to install. A clear versioning system was introduced, fragmentation was being removed. After attaching Qt to Symbian, they began porting to S40 and Maemo. Qt as the main library and a unified toolkit significantly eased development. Qt managed to cushion the terrible outsourced code. Symbian was turned into the open-source community Symbian Foundation, and most of the code was opened under EPL.

After buying Symbian, a number of requirements managers who had been flying to London found themselves without work. Some seeped into Ovi, but a considerable number continued to poison the organization. Then Ovi effectively died. Where did the management layer gradually flow to?

At this time, Nokia was pouring funds into MeeGo, the successor to Maemo, and preparing to release the N950, N9, and others. Along with the funds, the management layer migrated from the now-irrelevant Ovi into the platform. From precisely this moment, the company was doomed.

Many people note that MeeGo's end result wasn't bad. It could have been even better. Original UI design, honest Linux, Qt. The project was buried by the plague of talkers in the form of decision committees, governance groups, and dead weight, with which MeeGo was turning into the same sluggish monster of old times.

So What Did Elop Actually Do?

Imagine — you have a company that's a leader, but all growth indicators are zero or negative, while competitors are gaining momentum.

Everything is planned for years ahead, there's collective responsibility everywhere (or its absence), detailed strategic planning is done reluctantly and traditionally none of it gets delivered on time, tons of money have been and are being spent on God-knows-what, every step gets stuck in the swamp, there are philosophizing specialists everywhere who haven't actually done anything for a long time, an endless set of people-processes.

The core business has been outsourced, and you can't breathe without subcontractors. You can't release a phone with 1280x720 resolution despite having the hardware because Symbian isn't optimized for it yet, and the optimization will finish when it's no longer relevant. You can't release an LTE phone, even though the technology has been invested in from the beginning, because implementing it on MeeGo will take a year and a half. There are already Korean LTE models, rough around the edges.

What would you do? Here's what Elop did:

• Neutralized the influential component of the managerial dead weight. Abolished all committees, decision boards, and governance groups.
• Abolished collective responsibility and introduced personal accountability. Every manager is responsible for decisions in their area; ill-considered decisions affect careers.
• Neutralized the competence component of the dead weight. If you're a theorist-blabbermouth in Symbian — "goodbye!" No Symbian; if you want to work in your field — go work at Accenture.
• Eliminated subcontractor feeding troughs along the main business line. Non-core business was moved to outsourcing. Some subcontractors had latched on tightly, and for a long time it wasn't possible to detach them without damage.
• Optimized costs. Fragmentation was eliminated radically — by eliminating the cause. No OS — no problem.
• Eliminated virtual teams, and therefore the need for travel. Independent parts are developed on a site basis.

Separately about MeeGo. There was real hope it would survive, especially since Windows Phone as a platform wasn't much better. But after observation and analysis of operational components, the conclusion was dismal — Nokia's internal machinery was incapable of producing software at the required quality within the required timeframe. One reason: the dead weight that had permeated the organization, including MeeGo.

Further attempts were approved to compete with Android using a Linux-based platform with MeeGo developments. But they were buried for the same reasons — software development processes were sluggish, and there was no more time.

Meanwhile, the money dwindling inexorably on Ovi, Intellisync, flights to Bangalore and London, insane subcontracts.

I'm deliberately not examining other aspects of Elop — early promises of WP products, factory closures, etc. That's been thoroughly discussed many times. However, in conclusion — Elop had no other option but complete restructuring by outsourcing the core software development to another company.

Internal processes at Nokia had driven development into a brutal dead end, and even Android wouldn't have saved the company due to the pervasive bureaucracy and consensus-based compromise decisions.

I strongly ask you to note — this information reflects the situation as of 2010, before the restructuring and strategy change. Today's Nokia is a new company that took shortcomings into account during reorganization and fought against them. Unfortunately, many insiders don't understand the true reasons for the strategy change, the platform switch, and the new methods. This post is not so much insider information as an attempt to explain what Nokia did to itself. How things stand now, the author doesn't know, but believes the measures will lead to success.