Who needs innovation?

Or rather, who needs innovations groups? Once upon a time, people had ideas. People in big companies had ideas. And told their friends, and took them to their bosses, who if they were good ideas often took them to their bosses who had private venture funds that they could allocate to promising-looking ideas. 20-odd years ago I got my own crazy ideas funded that way: some of them turned into products, some of them died, but none of them needed someone specifically dedicated to innovations processing to make them appear.

So what changed? I worked for monolithic companies back then, I work for monolithic companies now, and engineers have always been engineers, whatever the decade (although there wasn’t really the concept of a ‘hip’ engineer back in the 1980s). So maybe the environment changed. Maybe the standards for what makes a good engineer have changed, maybe it’s the move from 5% training and PV budgets, maybe it’s even the style of management changing from hierarchical and experienced to village market and image-driven. But whatever has changed, it’s driving a need for people who can make the safe space in which innovations can thrive, and champion ideas to the image-makers and transient.


One of the more important features of an innovations program is failure. Innovations should not be low-risk (although they should be risk-managed, which is not the same things), which means that even in a well-managed scheme, some innovations projects will fail. Indeed some of them *should* fail – if this isn’t happening, then you’re either not reaching high enough to really make a difference, or your standards for what should and shouldn’t continue to be funded probably need to be adjusted. Innovations is about having the taste to choose a set of projects that might work, but also about having the sense to stop the ones that don’t. Which inevitably will disappoint several people: not just the people with the ideas that don’t get continued, but also the sponsors who put effort into backing those ideas too. And that disappointment needs to be managed, so that it doesn’t become corrosive to future projects, or to the idea of a working innovations program.

Diversity… and diversity

Helen Greiner has a lovely list of things she’s learnt about innovation, one of which is “Diversity in the workplace leads to diversity in ideas”. I think she meant that a company whose staff have a diverse set of backgrounds is likely to be more creative in its applications. One of the problems with dinosaurs is that often they are very homogeneous. As an extreme example, take the defence industry in the UK. If the workforce is mainly composed of people who got their security clearances 10, 20 years ago, then that does by definition restrain the types of people that they are: safe, no dodgy pasts, more gays than in the past but still not a representative percentage (please feel free to argue with that if you think I’m wrong), and still not a great percentage of ‘ethnic minorities’, which given the traditional non-inclusive definition of this, I’m taking here to mean people with a non-UK regional or RP accent (there’s no more beautiful indicator of inclusion than someone with an Asian face and a broad Lancastrian accent). The number of women has grown a little; the number of mothers too, but the chances of finding Greiner’s example of a Bosnian Muslim refugee mother of two are still pretty slim.

How Fast?

I spent a day with our research division recently, and got chatting to one of the chaps presenting a project. Now he’d got it going from idea to mock-up and working-if-you’re-careful system in 3 months, and that 3 months struck me instinctively as a very good timeline for developing an innovation prototype system. In some industries (and I’m looking at you, City Boy) 3 days is a long time to develop some mock-up software, but for a reasonably complex idea developed within a larger company, 3 months seems about right. That’s pure engineering judgement from a lot of years of experience, but it’s interesting to try reasoning that out. So…

There are insightful geniuses out there who see things coming a long time before anyone else, but a) unless they’re working for themselves it can be difficult to get the boss to go out on that far a limb, and b) most ideas, even the far-out ideas, are usually of their time and context. So if you’ve reached the point where you’ve thought of a new idea, then chances are that your competitors are likely to think of it sooner or later too. Which in prototype terms probably gives you a year to demonstrate to market, at best. Before you persuade the customer you usually have to persuade people inside the company, so add in 3 months getting the people you need and bringing-the-board-round lag, and you’ve got 6 months tops to go from thought to prototype. And then the money kicks in. If you’re running a set of risky innovations developments (and innovations technologies by their very nature are untried and hence risky) then you want to spread that risk over several projects that might not come off rather than a much smaller number of projects that might not come off. The resources that you have available are more than just money: they’re people’s time, their mental energy, their enthusiasm and the goodwill of their colleagues and sponsors. All of these things wear down if they’re maxed out over time… most of them would leave people in small heaps after 5-6 months of sustained effort, energy, goodwill etc, but can usually be focussed and channelled over a smaller period of time. 1-2 months is not enough to really understand all the underlying issues and technologies for a project, or to really get any hardware tested and together (unless you already know said hardware very very well). Which leaves 3-4 months as a sensible timescale. Of course, once a prototype is seen and begins to be accepted, there are usually months or even years of more work to come, but an initial short burst of effort seems to be right.

Well, I tried to explain that. I’m not sure I did very well at it, but I think it’s an important concept to chew over – maybe at more length and with less haste next time.


Many of the female engineers that I’ve worked with suffer periodically from a severe lack of confidence. I guess it happens to us all sometime: that little voice saying “why try, you’re not going to make it work”, “you really can’t do that as well as X”, or “who are you to be telling Y what to do”. I’ve always seen it as a bit of a problem, to be countered with careful handling when found in others and with the phrase “do what you can with the resources you’ve got” for myself. But much as you can have faux amis in language, so maybe you can also have a false enemy in a loss of confidence. Maybe, just maybe it’s a useful thing, a check-and-balance that you’re going the right way and doing the right thing. It’s all too easy to rush headlong into a project, then cling grimly to it as it turns into the mental equivalent of a bucking bronco (or to borrow a military phrase, into the hamsterwheel to hell) – perhaps under these conditions these can be harnessed as useful moments of introspection rather than suffered as destructive losses of confidence.


Requirements can be a little problematic. User, system and technical requirements are difficult enough to define well in a customer-driven field where there is a defined customer who is expert and knows exactly what they want, but in a field with a non-expert customer or no customer, they can be close to impossible.

In innovations, there is typically no defining customer, so you have to create requirements against a series of expert guesses about who the end user is, what that end user is likely to want and to use the system for, who the buyer is (and their own estimate of the end user, which is itself likely to differ from the eventual end use) and against market moves that you can only roughly predict from what you can see of your potential competitors, suppliers and market-makers (where they exist too).

And if you’re innovating in a fast-moving field (e.g. consumer electronics or finance), the merit of carefully creating and working against requirements can itself be debatable because the field could itself move on whilst the requirements are being created. At which point we get into spiral development, rapid application development and other agile requirement-development models. Most of which, from the outside at least, look rather chaotic (in the bounded rational sort of sense of chaos). Just ask yourself: how many projects has Google delivered on time recently? And how much does that matter?

On the Importance of Being Honest

How important is honesty in business? For many of us, the image of businessmen – I mean businesspeople – is that of players in a large-scale game of poker, where deception is common and nobody ever wants to show their hands. Maybe that exists in the middle layers of some places, from and between people using image and perception to gain their next promotion, but on the whole people at the strategic layers of business appear to be essentially honest about what they do, what they want and what they believe their company to be. This is amply backed up by studies of leaders and enterpreneurs, which show that honesty is one of the most externally valued traits by venture capitalists, and the trait most likely to be rewarded with money. So honesty at the strategic level of a company is to be broadly applauded.

The flip side of strategic honesty is when it highlights a disconnect between the layers of a large company; where an honest assessment at the top of the company does not match an honest assessment from the bottom of it. A great deal of political courage may be needed to admit that this is the case, and a great deal of effort may be needed to bring the two assessments into alignment, but the cost if this is not done is almost always much higher (in trust, stress, and even in lost contracts) than if it is. I’m not suggesting that every strategic player puts all their cards face-up on the table at all times, but they really shouldn’t kid themselves into thinking they’re always holding 5 aces.

Living organisations

I’ve been reading “transferring tacit knowledge in extended enterprises” by Nousala et al. Yes, yes, I know, but it’s useful for work. So today’s thought is “how far can we take the organisation as organism analogy?”. The paper picks up on a previously popular theme, that organisations (companies, cities, any complex set of interacting people) can usefully be modelled as if they are living organisms. Which includes concepts like autopoiesis – how do we know when something is alive, and rather more Popperian theory than I’ve seen since I was last at university.

Now I have a soft spot for the independence of mitochondria – the idea that something as complex as a human can contain cells that are not only doing their own thing, but just happen to be hanging around in the neighbourhood. But I digress. What is perhaps more important is the question “is a company a cat or a big shaggy dog?”. Does it exist on its own terms and selfishly decide its own fate, or hang around with its tongue sticking out waiting for someone to throw a stick for it? If a company like that is a dog, then how come dogs manage to survive? And can I use the caveman analogy now, that the dog-human symbiosis evolved because dogs were a really good early-warning system and hence worth being fed by the humans.

I really really want to explore these ideas, I have a dozen others hanging around them, some serious, some not-so-serious, but I can’t. I’ve had my one thought for today. And this is hard, so terribly terribly hard. But I’ll sit on my hands now and keep trying to reach for that elusive simplicity, that golden possibility of clearer communication. Aargh.

One a day

Hokay, I’ve committed to one a day. One post every day; one paragraph on just one idea. It’s going to be difficult: the fear of not capturing every idea immediately is always with me, but I’m going to try. Today, I have no ideas. Tomorrow, I’ll think of something.