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.
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.
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.
Whilst I was talking through a possible taxonomy of Jurassic business entities, S commented that it made most sense to be a crocodile. Which is something like a dinosaur, but smaller, more agile (mostly), better adapted and still around. It’s a thought. I’m not sure how well this analogy will survive, but it could be worth investigating.
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?
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.
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.
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.
I’ve been spending quite a few evenings of late at the Girl Geek Dinners, the Women in Technology events and various women leaders in technology things. The generation gap between the older girl geeks who fought for equal treatment and the girl geeks coming through now who thankfully don’t have to see or do the things we oldies saw or did back in the day is fascinating to me, and worth a post in its own right, but today I’m excited about something else: the ‘C’ word.
Until relatively recently, the women engineers that I’ve worked with have been very careful about mentioning their children (the ‘c’ word in question, in case any of you thought it might abbreviate something else). As a general rule, I’ve seen secretaries and PAs put pictures of their children on their desks, chat openly about their children’s development, take time out to look after them as a right. But female engineers. Photos were rare, talking about kids restricted only to close friends, time off always accompanied by embarassment. And never, and I mean *never*, did anyone have that conversation about relative priorities, about the real work-life balance. And even considering it in front of the men? Noooo.
But this week I’ve seen a senior woman engineer do just that: tell everyone that her priorities shifted for a while when her kids were young. And she did this in front of her (male) boss. And nothing exploded. This past year, I’ve seen several women presenters list their children amongst their significant achievements (and we are talking some very senior women indeed), and professional women out and proud of their side-by-side roles as both professionals and mothers. And this is so wonderfully refreshing. I never became a mother myself, but I am proud that we have grown up so much as a profession that women don’t have to choose between images any more. I couldn’t be part of this particular movement myself, but to those women who did have the courage to say “I’m a mother too”, I salute you.
Meanwhile, on a slightly less historical note, I’ve found and signed up with an interesting volunteer effort – IT 4 Communities. It’s a place that puts geek and charities that need geek skills together, and as such it’s much to be encouraged.