21 October 2014

An exponential approach to peace?

While the information-based world is now moving exponentially, our organizational structures are still very linear (especially larger and older ones)…

We’ve learned how to scale technology… Now it’s time to scale the organization: strategy, structure, processes, culture, KPIs, people and systems

Opening slide

The above messages come from a punchy set of slides that have just been posted on SlideShare by Yuri van Geest. Yuri is the co-author of the recently published book “Exponential Organizations: Why new organizations are ten times better, faster, and cheaper than yours (and what to do about it)”, and the slides serve as an introduction to the ideas in the book. Yuri is also the Dutch Ambassador of the Singularity University (SU), and the Managing Director of the SU Summit Europe which is taking place in the middle of next month in Amsterdam.

Conference overview

Yuri’s slides have many impressive examples of rapid decline in the cost for functionality, over the last few years, in different technology sectors.

Industrial robots

DNA sequencing

But what’s even more interesting than the examples of exponential technology are the examples of what the book calls exponential organizations – defined as follows:

An Exponential Organization (ExO) is one whose impact (or output) is disproportionately large — at least 10x larger — compared to its peers because of the use of new organizational techniques that leverage exponential technologies.

Organizations reviewed in the book include Airbnb, GitHub, Google, Netflix, Quirky, Valve, Tesla, Uber, Waze, and Xiaomi. I’ll leave it to you to delve into the slides (and/or the book) to review what these organizations have in common:

  • A “Massive Transformative Purpose” (MTP)
  • A “SCALE” set of attributes (SCALE is an acronym) enabling enhanced “organizational right brain creativity, growth, and acceptance of uncertainty”
  • An “IDEAS” set of attributes (yes, another acronym) enabling enhanced “organizational left brain order, control, and stability”.

I find myself conflicted by some of the examples in the book. For example, I believe there’s a lot more to the decline of the once all-conquering Nokia than the fact that they acquired Navteq instead of Waze. (I tell a different version of the causes of that decline in my own book, Smartphones and beyond. Nevertheless I agree that organizational matters had a big role in what happened.)

But regardless of some queries over details in the examples, the core message of the book rings true: companies will stumble in the face of fast-improving exponential technologies if they persist with “linear organization practice”, including top-down hierarchies, process inflexibility, and a focus on “ownership” and “control”.

The book quotes with approval the following dramatic assertion from David S. Rose, serial entrepreneur and angel investor:

Any company designed for success in the 20th century is doomed to failure in the 21st.

I’d put the emphasis a bit differently: Any company designed for success in the 20th century needs to undergo large structural change to remain successful in the 21st. The book provides advice on what these changes should be – whether the company is small, medium-sized, or large.

A third level of exponential change

I like the change in focus from exponential technology to exponential organizations – more nimble organizational structures that are enabled and even made necessary by the remarkable spread of exponential technologies (primarily those based on information).

However, I’m interested in a further step along that journey – the step to exponential societies.

Can we find ways to take advantage of technological advances, not just to restructure companies, but to restructure wider sets of human relationships? Can we find better ways to co-exist without the threat of armed warfare, and without the periodic outbursts of savage conflict which shatter so many people’s lives?

The spirit behind these questions is conveyed by the explicit mission statement of the Singularity University:

Our mission is to educate, inspire and empower leaders to apply exponential technologies to address humanity’s grand challenges.

Indeed, the Singularity University has set up a Grand Challenge Programme, dedicated to finding solutions to Humanity’s grand challenges. The Grand Challenge framework already encompasses global health, water, energy, environment, food, education, security, and poverty.

Framework picture

Peace Grand Challenge

A few weeks ago, Mike Halsall and I got talking about a slightly different angle that could be pursued in a special Grand Challenge essay contest. Mike is the Singularity University ambassador for the UK, and has already been involved in a number of Grand Challenge events in the UK. The outcome of our discussion was announced on http://londonfuturists.com/peace-grand-challenge/:

Singularity University and London Futurists invite you to submit an essay describing your idea on the subject ‘Innovative solutions for world peace, 2014-2034’.

Rocket picture v2

First prize is free attendance for one person at the aforementioned Singularity University’s European two-day Summit in Amsterdam, November 19th-20th 2014. Note: the standard price of a ticket to this event is €2,000 (plus VAT). The winner will also receive a cash prize of £200 as a contribution towards travel and other expenses.

We’ve asked entrants to submit their essay to the email address lf.grandchallenge@gmail.com by noon on Wednesday 29th October 2014. The winners will be announced no later than Friday 7th November.

Among the further details from the contest website:

  • Submitted essays can have up to 2,000 words. Any essays longer than this will be omitted from the judging process
  • Entrants must be resident in the UK, and must be at least 18 years old on the closing date of the contest
  • Three runners-up will receive a signed copy of the book Exponential Organizations, as well as free attendance at all London Futurists events for the twelve months following the completion of the competition.

At the time of writing, only a handful of essays have been received. That’s not especially surprising: my experience from previous essay contests is that most entrants tend to leave essay submission until the last 24-48 hours (and a large proportion have arrived within the final 6o minutes).

But you can look at this from an optimistic perspective: the field is still wide open. Make the effort to write down your own ideas as to how technology can defuse violent flashpoints around the world, or contribute to world peace in some other way within the next 20 years. Let’s collectively advance the discussion of how exponential technology can do more than just help us find a more effective taxi ride or the fastest route to drive to our destination. Let’s figure out ways in which that technology can solve, not just traffic jams, but logjams of conflicting ideologies, nationalist loyalties, class mistrust, terrorists and counter-terrorists bristling with weaponry and counter-weaponry, and so on.

But don’t delay, since the contest entry deadline is at noon, UK time, on the 29th of October. (That deadline is necessary to give the winner time to book travel to the Summit Europe.)

London Futurists looks forward to publishing a selection of the best essays – and perhaps even converting some of the ideas into animated video format, for wider appeal.

Footnote: discounted price to attend the SU Summit Europe

Note: by special arrangement with the Singularity University, a small number of tickets for the Summit Europe are being reserved for the extended London Futurists community in the UK, with a €500 discount. To obtain this discount, use partner code ‘SUMMITUK’ when you register.



22 December 2012

Symbian retrospective: hits and misses

Filed under: More Than Smartphones, Nokia, Psion, retrospection, Symbian, Symbian Story — David Wood @ 12:19 pm

As another calendar year draws to a close, it’s timely to reflect on recent “hits” and “misses” – what went well, and what went less well.

In my case, I’m in the midst of a much longer reflection process, surveying not just the past calendar year, but the entire history (and pre-history) of Symbian – the company that played a significant role in kick-starting the smartphone phenomenon, well before anyone had ever heard of “iPhone” or “Android”. I’m channeling my thoughts into a new book that I’m in the midst of writing, “More than smartphones”. The working subtitle is “Learning from Symbian…”

I’ve got no shortage of source material to draw on – including notes in my electronic diary that go all the way back to January 1992. As I note in my current draft of the introductory chapter,

My analysis draws on an extensive set of notes I’ve taken throughout two decades of leadership positions in and around Symbian – including many notes written in the various Psion PDA organisers that have been my constant electronic companions over these years. These Psion devices have been close to my heart, in more than one sense.

Indeed, the story of Symbian is deeply linked with that of Psion, its original parent. Psion and Symbian were both headquartered in London and shared many of the same personnel…

The PDAs that Psion brought to market in the 1980s and 1990s were the mobile game-changers of their day, generating (albeit on a smaller scale) the same kind of industry buzz as would later manifest around new smartphone releases. Psion PDAs were also the precursors for much of the functionality that subsequently re-emerged in smartphones, satellite navigation products, and other smart mobile devices.

My own Psion electronic diary possibly ranks among the longest continuously maintained personal electronic agendas in the world. The oldest entry in it is at 2.30pm on Friday 31st January, 1992. That entry reads “Swedes+Danes Frampton St”. Therein lies a tale.

At that time, Psion’s commercial departments were located in a building in Frampton Street, in central London, roughly midway between the Edgware Road and Maida Vale tube stations. Psion’s technical teams were located in premises in Harcourt Street, about 15 minutes distance by walking. In 1992, the Psion Series 3a PDA was in an early stage of development, and I was trialling its new Agenda application – an application whose UI and rich set of views were being built by a team under my direction. In parallel, discussions were proceeding with representatives from several overseas distributors and partners, about the process to create versions of Psion PDAs for different languages: German, French, Italian, Spanish… and Swedish and Danish…

As the person who assembled and integrated all the files for different software versions, I met the leads of the teams doing the various translations. That day, 31st January 1992, more than 20 years ago, was among my first meetings with work professionals from the Nordic countries.

I recall that we discussed features such as keyboards that would cater for the additional characters of the Danish and Swedish alphabets, like ‘å’ and ‘ø’. I had no inkling in 1992 that professionals from Denmark, Sweden, and Finland (including employees of mobile phone juggernauts Ericsson and Nokia) would come to have such a far-reaching influence on the evolution of the software which was at that time being designed for the Series 3a. Nor could I foresee the subsequent 20 year evolution of my electronic agenda file:

  • Through numerous pieces of Series 3a hardware
  • Via the Series 3c successor to the Series 3a, with its incrementally improved hardware and software systems
  • Via a one-time migration process to a new data format, for the 32-bit Series 5, which could cope with much larger applications, and with much larger data files (the Series 3 family used a 16-bit architecture)
  • Into the Series 5mx successor of the Series 5
  • Through numerous pieces of Series 5mx hardware – all of which give (in their “About” screen) 1999 as the year of their creation; when one piece of hardware ceases to work, because, say, of problems with the screen display or the hinge mechanism, I transfer the data onto another in my possession…

Why 1999 is the end of this particular run of changes is a fascinating tale in its own right. It’s just one of many fascinating tales that surround the changing fortunes of the players in the Symbian story…

Step forwards from chapter one to the penultimate chapter, “Symbian retrospective”. This is where I’d welcome some extra input from readers of this blog, to complement and refine my own thinking.

This is the first of two retrospective chapters that draw conclusions from the episodes explored in preceding pages. In this chapter, I look at the following questions:

  • Out of all the choices over the years made by the players at the heart of the Symbian world, which ones were the most significant?
  • Of these choices, which were the greatest hits, and which the greatest misses?
  • With the advantage of hindsight, what are the different options that could credibly have been pursued which would have had the greatest impact on Symbian success or failure?

So far, my preliminary outline for that chapter lists a total of twenty hits and misses. Some examples of the hits:

  • Create Symbian with a commercial basis (not a “customers’ cooperative”)
  • Support from multiple key long-term investors (especially Nokia)
  • Enable significant differentiation (including network operator customisation)
  • Focus on performance and stability

And some examples of the misses:

  • Failure to appreciate the importance of the mobile web browser
  • Tolerating Symbian platform fragmentation
  • Failure to provide a CDMA solution
  • Failure to merge Nokia S60 and Symbian

My question for readers of this blogpost is: What would be in your list (say, 1-3 items) of the top hits and misses of decisions made by Symbian?

Footnote: Please accept some delays in your comments appearing. WordPress may hold them in a queue awaiting my review and approval. But I’m in a part of the world with great natural beauty and solitude, where the tour guides request that we all leave our wireless communication devices behind on the ship when we land for the daily excursions. Normally I would have balked at that very idea, but there are times and places when multi-tasking has to stop!

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

5 December 2010

How do you cure an E72 with hiccups?

Filed under: Nokia, YouTube — David Wood @ 1:28 am

This video isn’t going to win any awards.  It’s only 13 seconds long, and is hyper-grainy.  But if you peer closely, you can see my Nokia E72 displaying a bizarre kind of visual hiccups.

A brief bit of history: the E72 unfortunately became waterlogged.  (Ahem.  Old habits die hard.)  I took out the battery immediately, and left everything to dry out in an airing cupboard.  After putting the battery back in and restarting the E72, things initially looked fine.  The device booted OK, and I could start navigating around the applications.

But about one minute after booting up, the display starts doing the kind of weird vertical jitter you can see in the video.

This display malfunction reminds me of my childhood days, when TVs would sometimes experience problems with their “vertical hold”.  In that bygone era, there was usually a “vertical hold” button you could twiddle on the back of the set, to fix that problem.  (Note to younger readers: this was before the advent of TV remote controllers.)  However, although the E72 has lots of keys and buttons, none of them is labelled “vertical hold”.

It also reminds me of one more thing.  This kind of vertical jitter is, sometimes, part of the normal display on my E72.  But it usually only happens once at a time, rather than getting stuck in a loop.

Does anyone have any idea what causes this vertical jitter?

I’m hoping for a more precise answer than “water damage”.  I think there must be at least some software aspect to it:

  • The jittering doesn’t start immediately when the device boots, but only after a delay.  It looks like it’s triggered by some of background software process, which eventually kicks in
  • The speed of the jitter changes, depending on what else you do with the device.  For example, if you start a new app, the jittering temporarily stops, but then restarts
  • Whenever the jitter is occurring, the multi-coloured Nokia rotating “busy indicator” icon (I think that’s what it’s called) is just about visible on the title bar, suggesting that the device is trying to do something.

I wondered if there was anything in my own phone’s setup (e.g. the apps I had installed) that might, somehow, be causing this behaviour.  So I went back to the factory settings.  However, this didn’t cure the hiccups.

Almost certainly, I’m going to have to give up on using this particular device, but before I reach that outcome, I’m hoping to find a way to stop this behaviour!

In the meantime, I’ve been struggling to use an N900 as my primary smartphone.  It’s an interesting experimental devices, but it’s miles away from being ready for main-time usage.

Added later: Thanks to @taike_hk for suggesting the use of a microscope, distilled water, alcohol, and a hairdrier. (But I don’t particularly relish the thought of disassembling my E72…)

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 August 2010

Co-existing with Android

Filed under: Android, Nokia — David Wood @ 9:51 pm

For some time, I’ve wanted to learn more about Android.

Not just theory, or second hand knowledge.  I wanted my own, direct, practical knowledge – obtained by using an Android device “in anger” (as the saying goes).

Playing with a device for a few minutes – for example, at a trade show – fails to convey many of the real-world strengths and weaknesses of that device.  But it’s the real-world strengths and weaknesses that I want to experience.

It’s important for me for work reasonsAccenture Embedded Mobility Services are involved in a stream of different Android projects.  (Among other things, I want to be able to install and use various experimental Android apps that some of my colleagues have been writing.)

It’s also important for me for personal productivity reasons.  If an Android phone turns out to be a smarter phone than any I’ve been using so far, I want to know about it – so I can use it more often, and become a smarter person as a result.

But there are sooo many Android devices.  Carphone Warehouse had a large selection to choose between.  For a while, I struggled to decide which one to pick.

In the end, I chose a Nexus One.  That’s because it is the device most likely to be quickly updated to whatever the latest version of Android is.  (Other Android phones include customisation layers from device manufacturers, which seem to need to be re-done – and painstakingly re-tested – whenever there’s a new Android version.  Unsurprisingly, that introduces a delay.)

For help with a Nexus One, I owe a big debt of gratitude to Kenton Price of Little Fluffy Toys Ltd.  I first met Kenton at a recent meeting of the London GTUG (Google Technology Users Group), where we both listened to Google’s Wesley Chun give an upbeat, interesting talk about Google App Engine.  Later that evening, we got talking.  A few days afterwards, Little Fluffy Toys became famous, on account of widespread publicity for their very timely London Cycle Hire Widget.  Kenton & I exchanged a few more emails, and the outcome was that we met in a coffee shop next to the Accenture building in Old Bailey.  Kenton kindly leant me a Nexus One for a few weeks, for me to find out how I get on with it.  Just as important, Kenton quickly showed me a whole raft of fascinating things that the device could do.

But then I got cold feet.  Did I really want to stop using the Nokia E72, which has been my “third brain” for the best part of a year? My fingers have learned all kinds of quick, useful methods for me to get the best out of this device.  (Many of these methods are descendents of usage patterns from even earlier devices in the same general family, including the E71 and the E61i.)  I also heard from many people that the battery life on the Nexus One was poor.  What’s more, during the very first proper phone call I did with this phone, the person at the other end told me several times “you’re breaking up – I can’t hear you”.  (Of course, a sample size of one proves nothing.)

It was the transfer of all my “phonebook contacts” from the E72, to be merged (apparently) with my email contacts on the Nexus One, that gave me even more reason to hesitate.  I wasn’t sure I was ready for that kind of potential restructuring of my personal data.

So I’ve compromised.  I already have two SIMs.  One lives in my E72, and the other usually sits inside my laptop.  Well, I’ve taken the SIM from the laptop and put it into the Nexus One.  For the time being, I’ll keep using the E72 for phone calls and text messages.  And probably for lots more too.  But I’ll use the Nexus One for lots of interesting experiments.  (Like showing friends and family members Google Goggles…).

I expect this usage pattern will change over the weeks ahead.  Let’s see how things evolve!

Earlier this evening, I used my E72 to take the following picture of the Nexus One perched next to my “second brain” – my Psion Series 5mx.  Hmm, that Nexus One battery indicator does look worryingly low.  (Maybe I should turn down the screen brightness…)

12 August 2009

No magic dry rice

Filed under: death, E71, Nokia, twitter, Uncategorized — David Wood @ 10:28 pm

Rice potHere’s a tale of my personal naivety.  Hopefully others can learn from my errors.

Last Thursday, at about 6pm, I bent forward.  When I’m not looking at it, my Nokia E71 smartphone usually resides in my shirt pocket.  But because I was bending forwards, it slid out, and started crashing towards the floor.

I was disconcerted, but not too much.  The same thing had happened several times before.  I had learned that the E71 has incredible engineering, and it usually survives falling onto the floor, without even a dent or scratch to show for the experience.  It’s a solid piece of work.

But this time was different.

I was in a toilet, and the E71 landed straight in the water closet.

Things were bad, but they could have been worse.

Thankfully, I had flushed the toilet a few minutes earlier, so the bowl was clean.  (Well, as clean as toilets get.)

Without any conscious thought that I can remember, my hand shot into the water after the E71, and pulled it out.  Immediately.

I shook some water off the phone, and looked at the screen.  Everything seemed fine.  The phone was still switched on, the home screen was still live, and when I pressed up or down, the highlight moved up and down the display.  “What a great device”, I thought to myself.

There was still some water dripping off the device, so I thought I’d better dry it out.  I took off the back, removed the battery, and dabbed every visible area with paper towels.  A few seconds later, I put everything back together again, and pressed the On key.

In retrospect, that was my first big mistake.

The E71 seemed to boot up as normal.  The screen lit up, and the apps started.

Then I saw that there was no signal.  No problem, I thought, there’s poor signal strength in this hotel.  (I was in The Bingham, in Richmond upon Thames, for a work leadership team offsite meeting.  It’s a fine hotel, but we had been remarking all day that the cellular signal strength was poor in the rooms we were using.)

I rejoined my colleagues, and for a while forgot about my phone’s big escapade.  After all, there were plenty of other things to discuss.  (And I felt too embarrassed to mention that I had just thrust my hand into a water closet.)

That was probably my second mistake.

About 15 minutes later, I pulled out the phone again, curious to see if the signal had returned.  This time I noticed some fading at the bottom of the screen.  The two pieces of text for the soft buttons were illegible.  Water vapour had clearly got in behind the screen.  Woops.  So I separated all the parts of the phone again.

When I finally got home, I tried drying everything again, putting everything back together, and switching on.  This time things looked much worse.  The phone still gave the little vibrate immediately after the On button was pushed, and the screen and keyboard lit up.  But nothing else happened.  After around 30 seconds, the screen and keyboard switched off again.

I tried a different battery, and I tried plugging in a mains lead.  The result remained the same.

Then I thought of something different to try.  Twitter.  At 1.22 in the morning I tweeted:

dw2 wonders how long it will take his Nokia E71 to start working again, after dropping it in a basin of (clean) water yesterday

Twitter produced results.  Lots of them.

The first was at 1.23 in the morning:

kevinmcintyre09 @dw2 Would suggest leaving it in the airing cupboard for a few days to dry out

The next came at 1.27:

croozeus @dw2 It took my Nokia N95 a week before it dried out completely! Still it doesn’t charge but works properly…

Then at 1.28:

jomtwi Heh 🙂 RT @OscarB: Everytime I write “Symbian Foundation” I think of @dw2 as Hari Seldon

Then at 1.42:

dan_mcneil @dw2 http://bit.ly/83A1 may have some clues…

Then at 1.54:

jebbrilliant @dw2 Have you tried putting the E71 in a bag of DRY white rice?

And so the stream of tweets continued…

[I confess: one of the above tweets is irrelevant to this particular tale – but it’s so funny I left it in.]

Whoever said “the Internet never sleeps” has a point.  However, I was tired.  I put the E71 in the airing cupboard and retired to bed.

The next morning, I started reading some of the links, and a dawning realisation set in.

The above bit.ly link resolves to “How to Save a Wet Cell Phone” which contains the elementary advice (which I had failed to consider):

  1. Get it out of the water as soon as possible. The plastic covers on cell phones are fairly tight, but water can enter the phone in a short period of time, perhaps only 20 seconds or less. So grab your phone quickly! If you can’t get to it in time, your best bet is to remove the battery while it is still under water. Water helps dissipate heat from shorts that can damage the phone, so most damage occurs when the inside of the phone is merely wet and there is a power source. This can go both ways. Being under water is more likely to short the battery to even more sensitive contacts, so be careful.
  2. Don’t panic. Your phone will probably not be too damaged if you right away take it out of the water. While it’s in the water, immediately take it out.
  3. Remove the battery. This is one of the most important steps. Don’t take time to think about it; electricity and water do not mix. Cutting power to your phone is a crucial first step in saving it. Many circuits inside the phone will survive immersion in water provided they are not attached to a power source when wet.

To repeat: “most damage occurs when the inside of the phone is merely wet and there is a power source … electricity and water do not mix … Cutting power to your phone is a crucial first step in saving it”.

There’s not much more to say, except that I left the E71 in the airing cupboard for several days, with no luck, then I put it in a bowl of dry white rice for several more days, with no luck either.  There are certain kinds of damage that no amount of embalming will fix.

To be philosophical, there are points I could make about the need for prompt and skillful action following an accident to ensure good chances of survival, but I’ll save that for my next blog post.

8 February 2009

Smaller is not necessarily more beautiful

Filed under: MIDs, Nokia — David Wood @ 2:16 pm

I’ve been using a Nokia E61i as my main phone for at least 15 months. I’d grown very fond of it.

However, as part of the integration of Symbian’s corporate IS structures into those of Nokia, all Symbian employees who previously ran the BlackBerry Connect push email service on older phones like the E61i have been migrated onto a newer phone – the Nokia E71 – with a “Mail for Exchange” connection to the Nokia email servers.

To avoid too many changes happening at exactly the same time, I left it until Thursday this week to unbox my E71 and start personalising it. For about 24 hours, I switched back and forth between the two phones, but I now think the E61i is switched off for good.

First impressions are that, going from the E61i to the E71, there are scores of small but valuable improvements in the usability and feature set of applications. These improvements add up to a powerful reason not to go back to the E61i. They’ve been very nicely implemented.

Another big plus point is the built-in GPS.

No wonder the E71 has received so many rave reviews.

But yet, but yet, but yet: I confess to missing the larger keyboard and the larger screen of the older phone. For someone who does a great deal of data entry into my smartphone, the smaller keys (although implemented as a technological marvel) mean that I mis-hit keys more often than before. (And several keys have been removed from the keyboard altogether – you now need to use the “Chr” key to type them in.)

Another slight drawback of the smaller form factor is that, to my mind, the vibrator is less powerful, and more easily missed. So I’ve missed more incoming phone calls in the last few days than in the preceding week. (I’ll need to develop some greater sensitivity…)

Whilst the prevailing wisdom in the smartphone industry is that smaller and lighter phones reach larger markets, I count myself as part of a small but growing sub-market of users that would prefer larger hardware. For us, a larger keyboard and screen – up to a point – add significantly to the overall usability of the device as a high-volume data-input and data-output terminal.

The iPhone is another example of a phone that was larger than prevailing wisdom said would be tolerated by mainstream purchasers. Previous to the launch of the iPhone, industry usability experts held the opinion that a device with the dimensions of the iPhone would inevitably have a limited market. However, as the iPhone shows, if the user experience is good enough, worries about device size tend to fall away.

So I am personally looking forward to seeing the software enhancements of the E71 available in larger devices – whether these devices are called “smartphones” or “MIDs” or whatever.

Small is beautiful – yes – but it’s not the only beauty.

Footnote: For an excellent introduction to the E71 from the point of view of an E61i user, see the comprehensive comparative review by Steve Litchfield.

1 February 2009

Signs of change

Filed under: Nokia, Symbian Foundation — David Wood @ 11:40 pm

My main place of work since September 2000 has been Symbian’s offices at #2 Boundary Row, a short walk from Southwark tube station in central London. During all that time, the building has displayed signs with the “Symbian” name.

But when I visited the site earlier today, the signs of Nokia’s acquisition of Symbian are now very visible: the Symbian signage has been replaced by Nokia signage.

1st February marks the next stage in the integration of Symbian, the company, into Nokia. As with all large changes, the idea is to tackle things stage by stage – to avoid too many things all changing at the same time. Legally, Symbian became a part of Nokia Group back in December. 1st February sees Symbian employees adopting new email addresses, new security passes, and logging into a new network. More changes will occur in the weeks and months ahead – including key dates in the launch of the Symbian Foundation organisation, and the availability of Symbian Platform releases (replacing the previously separate Symbian OS and UI releases).

Joining Nokia’s IS network also means retiring Lotus Notes as our mail engine (although we’ll keep using Lotus Notes for various internal discussion databases and other groupware purposes). Those of us who are working as part of the launch team for the Symbian Foundation are experimenting with Google Apps as the provider of our email services. I’ve had a Google Mail account for my personal use for a number of years, so I’m already familiar with this system. It’s got some fine features. My first couple of days using it for business purposes, however, are making me wonder if it really is fit for more demanding usage. Time will tell. In the meantime, to my mind it’s another illustration that browser-based apps are not yet fit to fully displace locally hosted apps. They’re not fit to fully displace such apps on the PC, and they’re very definitely not fit to fully displace such apps on mobile devices.

28 January 2009

Package Owners contemplating the world ahead

Filed under: architecture, Nokia, packages, passion, Symbian Foundation — David Wood @ 3:13 pm

I’ve just spent two days at the very first Symbian Foundation “Package Owners workshop”, held in a Nokia training facility at Batvik, in the snow-covered countryside outside Helsinki. The workshop proved both thought-provoking and deeply encouraging.

In case the term “package owner” draws a blank with you, let me digress.

Over the last few years, there have been several important structural rearrangements of the Symbian OS software engineering units, to improve the delivery and the modularity of the operating system code. For example, we’ve tracked down and sought to eliminate instances where any one area of software relied on internal APIs from what ought to have been a separate area.

This kind of refactoring is an essential process for any large-scale fast-evolving software system – otherwise the code will become unmaintainable.

This modularisation process is being taken one stage further during the preparation for opening the sources of the entire Symbian Platform (consisting of Symbian OS plus UI code and associated applications and tools). The platform has been carefully analysed and divided up into a total of around 100 packages – where each package is a sizeable standalone software delivery. Each package will have its own source code repository.

(Packages are only one layer of the overall decomposition. Each package is made up of from 1 to n component collections, which are in turn made up of from 1 to n components. In total, there are around 2000 components in the platform. Going in the other direction, the packages are themselves grouped into 14 different technology domains, each with a dedicated “Technology Manager” employed by the Symbian Foundation to oversee their evolution. But these are stories for another day.)

Something important that’s happened in the last fortnight is that package owners have been identified for each of the packages. These package owners are all highly respected software engineers within their domain of expertise.

We’re still working on the fine detail of the description of the responsibilities of package owners, but here’s a broad summary:

  • Publish the roadmap for their package
  • Have technical ownership for the package
  • Be open to contributions to their package from the wider software community
  • Evalutate all contributions, and provide useful feedback to the contributors
  • Maintain a good architecture for the package
  • Act as feature sponsor in their package area
  • Manage package deliveries.

This is a huge task, so most package owners will rely on a network of approved committers and other supporters in order to carry out their role.

(Instead of “package owner”, the word “maintainer” is used with a similar meaning by some other open source projects.)

Over the next month, the nominated package owners (along with some of their line managers) are each attending one of three introductory workshops. Each workshop lasts two days. The goal of the workshop is to review and discuss how software development processes will alter, once the source code for the package is available to a much wider audience. Many processes will remain the same as before, but others will alter, and yet others will be brand new.

As I said, the first of these workshops has just finished. There were people from at least three different continents in attendance. I knew a handful before, but for many others, it was the first time for me to meet them. Without exception, they are singularly impressive individuals, with great CVs, and (in most cases) with glittering track records inside Nokia or Symbian.

Not surprisingly, the newly minted package owners brought a variety of different expectations to the event. Several already have considerable experience working with open source software. Others are, naturally, somewhat apprehensive about the changes.

A series of presenters covered matters such as:

  • An overview of the operation and architecture of the Symbian Foundation
  • Great software developers and open source principles
  • Tips on growing a successful community of external contributors
  • The importance of meritocracy
  • Tools and processes
  • IPR considerations, licensing issues, and legal aspects.

There were also small group breakout sessions on topics such as “What are the key challenges and issues facing package owners?” and “What are we going to do differently from before?”

What impressed me the most were the events on the first evening. After a dinner and optional sauna session, the participants gathered again in the seminar room, and spent another three hours reviewing ideas arising from the group breakout sessions from earlier in the day. The passion of the package owners stood out. In their own individual ways, they displayed a shared strong desire to explore new ways of engaging a wider community of software developers, without destabilising the mission-critical projects already being undertaken. These are all busy people, with multiple existing tasks, but they were ready to brainstorm ways to adopt new skills and processes in order to improve the development of their packages. (And I don’t think it was just the Lapin Kulta speaking.)

I half expected the fervour of the debate to die down after a while, but the buzz in the room seemed as strong at 10.50pm as at 8pm. There was a constant queue of people trying to get hold of the marker pen which had been designated (with limited success) as giving someone the right to speak to group. The workshop facilitator had to speak up forcefully to point out that the facilities would be locked shut in ten minutes.

With this kind of intelligence and fervour being brought to bear in support of the Symbian Foundation’s tasks, I’m looking forward to an exciting time ahead.

Older Posts »

Blog at WordPress.com.