Book review: Good to Great by Jim Collins

I’ve used some of the Christmas time to rush through to the end of my latest read - Good to Great by Jim Collins (Random House, 2001). I’ll admit upfront I wasn’t going to read this book but the senior management at my company have been reading it over the last year so I thought I should join in too!

Its easy to see why the book has been such a big seller. Its easy to read - short and a chatty style - and it makes you feel good, it suggests you do nice things in your company not nasty things.

Personally I don’t find it adds very much to the discussion that hasn’t been said already. Yes it introduces a few new metaphors (the Hedgehog concept and the Flywheel) but nothing you can’t find elsewhere really. In part this might be because the book is a “prequel” to Jim Collins and Jerry Porras’ Built to Last.

Yet I found the book reminded me more of another book, The The Living Company by Arie De Geus (1999). This should not be a surprise because De Geus discusses the similarities between Built to Last and Living Company so we should expect a few.

Unfortunately Good to Great lacks a good bibliography or further reading sections. This seems to be a common failing in many business blockbusters, they strip out the endless referencing that academics love and is necessary for hard research and journals to make it easier to read but at the same time you loose the context of where the book fits in or where to go next.

For example, Collins tells us that his Great Companies “confront the brutal facts” but doesn’t discuss how they do this or why they ignore them. Arie De Gues does, he explains why companies ignore known facts and what they can do about it - his solution is to “create future memories” by “planning as learning” and “scenario planning.”

(One could also refer to Pfeffer and Suttons Knowing-doing Gap on this subject but again Collins doesn’t.)

One more tiny example I have to put in so I can recommend a another good book: Collins mentions the importance of project post-mortems but that’s it. Norm Kerth’s Project Retrospectives goes into great detail on how to do this.

Why bang on about referencing? After all, references do make the book harder to read. Well, references add credibility for one. Second, I’m unhappy when an author seems to be claiming all the ideas for themselves - not that Collins does, but some other authors do. But perhaps the most important reason is so you can learn more about a particular issue.

Anyway, enough about referencing, what does this book say? The big themes are:

• No single event that creates a great company, not hiring a particular CEO, discovering a technology or launching a product. Its emerges over time.
  
• Get the right people, get shared values and the rest will come
  
• Confront the brutal facts: most companies fail to pick up on the important, life threatening or enhancing, facts and events.
  

Put all this together I found the book a pretty convincing argument for the argument that business strategy is more emergent than planned. Collins more or less says that most companies didn’t recognise their strategy until they were in the middle of it. Again, overtones here of Henry Mintzbergs’ The Rise and Fall of Strategic Planning but Collins doesn’t tell us this.

So if your looking for an easy read then this book is worth the money. If your looking for more depth then I recommend you read The Living Company . Among other thing both discuss:

• Getting the right people, and getting rid of the wrong ones
  
• Develop your people, they are there for the long term
  
• Quality discussions between people
  
• Recognising and acting on facts and events
  

In fact, one of Collins interviewees, at Kroger supermarkets, actually says “the company had a will to live.”

Product managers are software developers too!

On Wednesday night I was out drinking with ACCU members in London. For those of you who don’t know the ACCU I’d better explain. It is an association of professional developers, for my money the members are among the best software engineers in the world. Great people, if you ever get the chance to hire an ACCU member then do so, they share a passion for software development, improvement and learning.

But, as I’ve said here before I am no longer a software engineer – I am a Product Manager. And I got my legged pulled a bit on Wednesday night for that!

Perhaps I should give up my ACCU membership and my association with so many engineers. Certainly I don’t find articles in the ACCU magazines as interesting as I did – too many curly braces! – my interests have changed.

Now there is no rule that Product Managers can’t associate themselves with such groups but there is no such thing as a free lunch, if I am to embrace my new role and identity I need to give up some stuff. Every time I associate myself with my old role I’m not embracing the new.

But actually, I am still a software developer, I’m still helping develop software, I’m just doing it differently.

I’ve always preferred the title Software Developer to Software Engineer. Two reasons really, firstly, I’ve always had my doubts about how much engineering really goes on when writing software. Secondly, and more relevant here, I’ve always been aware of the other stuff that goes on.

Developing software isn’t just about cutting-code. Its about customer requirements, their problems, packaging, delivery, marketing, solving problems and introducing change.

Now I’m a Product Manager I’m concerned with: My customers, their problems and what software can do to solve their problems (which means change.)

So I’m still developing software but I am at a different place in the food chain.

I’m not really that unusual, a lot of product managers have a engineering background – and a lot have an MBA so really I’m not unusual - I’m dangerously close to being typical!

In some ways my engineering background might be a disadvantage. If I don’t jettison some of the old identity – the bit that wants to engineer and change code – I risk focusing on the wrong things. It is so much easier to stay in the comfort zone of what I have done before, to hide behind the technical rather than focus on the customer and do new things.

Failing to focus on the customer is probably one of the oldest (the oldest?) failure modes there is – both in software and in business generally.

Time is the enemy

Companies often boast about their "flat hierarchy" (and yes that term is something of an oxymoron) but it seems a flat hierarchy is deemed to be a good thing - although the reasons why this is so seldom seemed be spelt out.

I think they are supposed to be good because they speed up decision-making - the idea is that are not so many middle managers to go through to get decision.

And they are good because it allows those at lower levels to have their voices heard. A flat hierarchy allows everybody talk about their ideas to others whether they are more senior less senior or just the same level as yourself.

Trouble is, without those intervening layers there is more work for those of the top to do.

Suppose we have nine workers and each reports to one of three managers. And suppose those three managers in turn report a one manager. Each middle manager can spend one quarter of his time with each worker and the remaining quarter with his manager. And the manager the top has a little bit of spare time for external activities. Now if we take out that middle layer the manager at the top has less than one ninth of his time with each employee.

Don't get me wrong and not in favour of big hierarchies and middle managers necessarily, all I am saying is that no point in having a flat hierarchy if people hierarchy don't actually have the time for conversations and discussions. You have to allow time.

So there may be one level between you and the decision-making but will you ever get his time to make the decision? And when you need a decision or conversation will you get the time when you needed it?

Of course managers, wherever they are in the hierarchy, face time pressures. Big decisions need to be made: strategies need to be invented, deadlines need to be set, projects need to be managed and customers need be entertained.

But what about people who report these managers? Of course there is always next week to talk to them - isn't there? - External always seems a trump internal.

The hierarchy may be flat but if managers don't have time it makes no difference whether your hierarchy is flat or deep.

In the first case I'm thinking of giving your people time to help them develop. I said it before and I'll say it again:

"In my management philosophy the number-one job of all managers is to develop your people."

But it goes beyond this.

How do manager know what skills, talents and experiences their staff have if they don't spend time getting to know them?

So often the conversations that matter in the company are the ones that happen outside of meetings. But how will a manager know about these conversations if he spends all his time in meetings and talking to other managers?

On a technical project (yes, I am thinking specifically of software development) the people who do the work of often better positioned to see problems coming. Kind of an “engineers intuition” if you like. But if the manager is frugal with his time how will he ever have the time to talk these people and know about potential problems?

Also it is a matter of simple decency. People no matter where they are the company hierarchy, have a right to be listened to; they deserve to be listened to. And when they listen to they get a sense of fairness, their opinions have been heard and considered. They are more likely to buy in to the company strategy if they feel they have been listened to and treated fairly.

Often it is when the pressures are greatest that a manager needs spend most time with his people. For example, a manager introducing it change, or trying to win a big deal, or accelerate the process, really needs spend more time with his people understanding how it affects them. Unfortunately, it is just these times that managers often feel the need to be elsewhere.

Of course it is not only time starvation that creates a chasm between managers and workers. Separate cultures often develop with managers talking to managers and workers only speaking to workers. Over time managers don't feel the need to attend meetings and discussions with workers and it becomes a vicious circle.

And the same is true for workers. I've lost count of the number of times somebody has told me "they don't want that" - but who are they? And when you do asked them, they are often quite open to ideas. When communication breaks down people fall back on assumptions and stereotypes.

In short managers can get disconnected from those they manage. This is a bad thing for both sides.

So if you are manager please don't this happen to you. Take some time out of your meetings and the decisions to talk to people and find out what's going on and how they feel. After all these people are your most important asset - don't they deserve some of your time?

And if you are worker? Well, I encourage you to keep asking for time, keep trying to engage with your management. Please don't fall back on assumptions and stereotypes, keep asking questions.

The Inmates Are Running the Asylum by Alan Cooper

Time for another book recommendation. I've just finished reading The Inmates Are Running the Asylum by Alan Cooper. This is a passionate call the software to be more usable.

Cooper's argument is: software is not designed for usability and as a result much software is difficult to use and unattractive - he calls this "Dancing Bearware" - people use it because they have no choice.

Well designed software on the another hand is a joy to use, is perceived as being more powerful (even when it has fewer features) and creates a customer loyalty. Consequently this is good business not just good software.

(When Coopers speaks of software design he is talking about usability and anaesthetics - the same way we mighttalk of furniture design - not software design as programmers think of it with URL charts and object diagrams.)

Not only does he advocate better software design but he gives a selection of tools to use for design. This is interesting because many of the tools described are equally applicable to the work of Product Managers, e.g. personas, scenarios, etc. So the book is actually very useful to Product Managers even without the design discussion. Having said that, every Product Manager should have an awareness of the need for good product design and should read this book for that reason alone.

Programmers too should read this book. On casual reading you could get the impression that he does not think much of programmers, but in truth he is simply pointing out that they are not the best people to design software interaction.

It is hard to disagree a Cooper - he makes a very strong case. Where I do have an issue is his suggestion that we engage in the long design process upfront. Of course he is advocating we design the usage of the software, which is quite different to the way we normally talk about big upfront design of software. Still I worry that the same problems occur when we engage in long design periods without actually producing anything.

It may also be difficult to reconcile his design period with the incremental delivery models found in Agile and Lean techniques. However I'm sure we can reconcile these points of view as long as we remember to keep things simple and avoid waste.

After reading this book I'm left wondering why every software development project doesn't have its own designer. It makes good business sense: think iPod. Of all the companies I've worked for only one had a software designer - and he was cut in the first round of redundancies.

So if you are Software Developer this book is well worth the read. If you are Product Manager this book is a must read. And if you are Software Development Manager who can't understand what all the fuss is about, or why your programmers can't just develop the user interface as they go along, then buy this book now and read it tomorrow.

India running out of IT staff?

I’ve not said much about “offshoring” in this blog to date. In part that has been because while I broadly agree with the theory behind it most of my experience with it (e.g. call centres in India) has been very negative.

The other reason has been a deliberate decision to avoid a controversial subject. Controversial because those who read this blog with a business hat on see it differently from those who read it with a programmers flat-cap on.

However, a report in today’s FT caught my eye so its time to talk about this.

According to this report India will have a shortfall in skilled IT staff by 2010 of 500,000. This will come as a surprise to some but its something I’ve suspected would happen for a while. The report goes on to say that only a quarter of graduate engineers in India are actually employable by the industry - I wonder what the figure is in Europe and the US?

Add to this infrastructure problems (lack of office space, roads, power, airports) and suddenly the Indian IT sector doesn’t look that rosy.

So does this mean IT staff in the west can relax? Probably not, but there is no reason for panic.

Personally, I’ve never bought into the “India will take all our jobs” argument for a number of reasons...

1. Not all jobs are suitable for offshoring: as rule of thumb, the closer you are to the customer the more difficult it is to offshore your work. Some banks pay IT staff a premium to sit next to traders on the dealing floor, if 50 meters makes that much difference think how much 5000 kilometres makes.
   
2. Offshoring is not risk free: for a start you can’t see what your people are doing let alone look them in the eye. Then there are the external risks, for example, India nearly went to war with Pakistan a few years ago - and both are nuclear armed. Sure we had bombers on the streets of London this year but we’re talking an order of magnitude.
   
3. Law of supply: India (plus China, etc.) may have a lot of people but how many of them can actually work in IT? And how many of them are really good? Over time the price of good people will increase making offshoring less attractive. Already Indian call-centres suffer from high staff turn over rates.
   
4. Law of demand: if there is a vast movement of jobs from Europe to India we should expect to see prices in Europe fall, again this makes offshoring less attractive.
   
5. There are only a few good programmers: It is widely accepted that the best programmers are few and far between. The best are 10 or even 20 times more productive than the average. This cuts both ways: if you want to employ the best can you afford to ignore those who live in Bangalore not Birmingham? And, if they are 10 times more productive then surely you can afford to pay them 10 times more irrespective of where they live?
   
6. India needs developers too: As India develops its own demand for IT people will increase - Indian businesses need IT staff too - the faster we help India develop the faster demand will rise.
   
7. There is more than enough work to go around: as my last point suggested this is not a zero-sum game. IT has a long way to run yet, there is a lot more software to be written, the more we write the more opportunities we see.
   
8. IT is really about change: You might be able to write software in 5000 kilometres away but you can’t follow through on the corporate change programme from that distance. Introducing change has to be done locally. Western companies will increasingly look for IT staff who understand that IT is not the end but only a means to an end.
   

Does all this mean your job is safe? No
Does all this mean my job is safe? No

It does mean that as an industry there is plenty of work to go around.

Finally, and this should really be the first point: It is morally wrong to stop work going to India or elsewhere. To stop work moving would be like saying:

"We in the rich west are happy to send you aid for development, and when you are hit by an earthquake, famine or Tsunami. But, we want it to stay that way. We don’t want you becoming rich yourselves."

In the long run it is in our interest to see India develop. They are a market too. And a prosperous India will be a safer India (no nuclear wars) and a more environmentally friendly India.

The Dog and Duck is closing

Opposite my house there are a few shops. Every few months one or other of these closes and every few months a new one opens. It keeps the place dynamic. The last one to open was an up-market flower shop since when my girlfriend has received noticeably more flowers!

Just before summer started one of the old shops was re-christened “The Dog and Duck”. For the few days between the name going up and the shop opened we wondered: How can you have another pub there? For those who don’t know, “Dog and Duck” is pretty common English pub name so it seemed there was to be a new pub.

Now my road already has 3 pubs it, with another 3 off to the side and a further 12 or so within five minutes walk - this is London after all. It all seemed a bit strange, and after all, there had been no planning permission requested for a pub.

When it finally opened the Dog and Duck turned out to be a ... well, I still don’t know what it was/is selling. Some T-Shirts with the Union Flag or pictures of BritPop singers, some post-cards which would seem more at home in a design museum, and other stuff which to someone or other probably seemed “designer” or “fashionable” or even “stylist”. Personally, I just called it a BritTat shop.

Nothing it sold was actually useful, the shop may have be able to sell to tourists or Oasis fans but not on a secondary road in Acton.

The fact that I can’t tell you what it sold is half the problem. Its location is the other. Both conspired against it but the root problem was: Identity.

The shop didn’t have an Identity that could be communicated easily - look I just tried! How are people to find out about this shop? How are they to tell others?

Yes the name was very clever, and the contents where probably clever to somebody but they failed to communicate to anyone what the shop was. So its no great surprise it is closing down. (Actually, my money was on the Dog and Duck being a coffee shop, now that would have been clever.)

Businesses need identity as much as people do. They need to know what they are about. The employees need to know what the business is about. What do you say when someone says “What does your company do?”

This is more than just branding. It runs deeper. It is about the soul of the organization. I know a product company that is adding services to its line up. The intention is to help sell more products, and very conveniently services make good money so it all helps growth. But this company is a product company; its identity is as a firm that produces physical products which people buy not as a service organization.

It is not wrong for this company to add services but it needs to realise that it is changing its identity. How will its employees, its competitors and customers relate to it in future?

Identity can constrain people and organizations, it can stop them moving outside of their comfort zone but it also gives them a base, and operating system if you like, one that helps them navigate the world and make sense of it. Identity change can be a great opportunity for growth and learning but it is also risky.

So identity is good, please experiment with changing it, step outside the comfort zone, just make sure you don’t loose it in the process or you’ll end up like the Dog and Dock.

Learning to be a product manager

I’m back in the USA for a few days attending some seminars on product management. They very good and highly recommended - check out the website links, http://www.pragmaticmarketing.com/ and http://www.productmarketing.com/productmarketing/.

As I have said before his blog I have been trying to get to grips with product management and what is it product managers do for while so the seminars most useful. About half material in the seminar is like an MBA refresher course – specifically my marketing modules. The other half is really what do product managers do? And how do they do it?

So to save you the suspense I'll summarise the answer... product managers identify what customers needs and get it delivered.

But there are one or two twists...

First is, it is not what one customers says it is what a set of customers say - that is what the market says not what an individual customer want.

Second twist: it isn't the features the customers ask for that we should build but a solution to their problem. So we have to look beyond the mere feature request to a deeper level to the problem that they are encountering and then we need to build the solution.

So if a customer asks for the colour to be changed you have to ask: why? If the answer is simply that this customer doesn't like the colour then probably it is insignificant.

But if you find that many customers are asking for the change and when you look into it you find it is because you're product appeals the colour blind users then there is a legitimate reason to change the colour - there is a problem to solve.

But to properly solve the problem you have to make sure you change the colour in such a way that colour blind users can use the software. There is no point changing from one colour to another if it doesn't improve situation.

Picking up another theme of this blog, nothing I have heard here contradicts what I've written about Lean Thinking. In fact I think to ideas are completely complimentary.

• Lean thinking says: reduce waste - specifically don't do work that you don't need too, and when you do solve the problem solve it completely, no half measures.
  
• Product management says: only do the work that directly benefits the customer, work that we have qualified and will help the customer. And when you do it solve the problem completely there's no point in only solving half the customers problem.
  

So seems to me that both sides are saying the same thing don't do work that nobody wants. That may seem pretty obvious but it seems pretty difficult to actually do.

Power of ideas

John Maynard Keynes, the economist once said:

"The ideas of economists and political philosophers, both when they are right and when they are wrong, are more powerful than is commonly understood. Indeed the world is ruled by little else. Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist."

Ideas can seem small. They can seem weightless. How many ideas fit on the head of a pin?

But Keynes was right. Consider Karl Marx, his ideas where hatched during the middle of the nineteenth century but led 60 years later to the Russian revolution, and from there to the cold war that only ended in the 1990’s. Millions still live with his ideas in China, Loas, Korea, Cuba and elsewhere.

That is a powerful idea.

Maybe if Marx hadn’t had these ideas someone else would, but mankind had gone several thousand years before he came up with the ideas. Maybe it would have been another thousand years before someone had the ideas. Still, apply the Jackson Pollock test, it was Marx who had these ideas when he had them.

Something similar happens to ideas in companies.

Often it takes time for a new idea to work its way into the system, people need time to think about the idea, see if it makes sense to them and try the idea. Sometimes the people who embrace the new ideas aren't in a position to do anything with them only in time as these people move into positions of influence can they do something with a new idea. And sometimes it takes time for people to see the applicability of an idea, only over time as they now view the world with the new idea in their head does it start to make sense of them.

So as with Marx there may be a the gap between the idea and affect.

Ideas can often seem very abstract and they can be difficult for people to grasp. This is where stories role to play. By embedding an idea in a story that tells how it changed people, and what was done, the idea is less abstract and people have an example to better understand the idea. This can help in internalising the idea and seeing work can be applied in an organization.

Still it can take time for an idea to have an affect. We can speed up the work of an idea if we support it but we can also smother it. I suppose a I have been guilty once or twice of having a great idea, or at least an idea I thought was great, and by being over enthusiastic about the idea I have made people sick of the idea.

Another thing that can slow down theory adoption of an idea is the need to change some of our existing ideas. If we are to embrace a new idea we often have to give up something else - if I want to embrace the idea of a red car I need to get rid of my idea of a blue car.

And so back to Keynes who also said

"The difficulty lies not so much in developing new ideas as in escaping from old ones."

Look at the difficulty some countries have had in getting rid of Marx's ideas.

What do Product Managers actually do?

I spent a couple of years working in California, in Silicon Valley itself to be exact. Unfortunately instead of getting .com boom I got .com bust, still it was a very interesting experience.

One of the differences I found between London and California was the existence of Product Managers. I'm not saying product managers didn't exist in London but they were few and far between, whereas in California they were plentiful. These are the people actually charged with ensuring the product develops in the right ways and they seem to be intrinsic to high-tech companies.

(As I've noted before product managers exist outside of the software arena but these are often marketing rules concerned with branding, advertising and image.)

Of course back in London we had Business Analysts who performed some of the same role but the two are very different beasts - product managers are much more outward looking and business analysts are normally inward looking. Of course some of this is the difference between a product company and the bespoke development organisation.

As I've noted here before this is the year when I became Product Manager. Last week somebody asked me an interesting question: “what is it product managers do?”

So I waived my hands a bit and I said something about understanding the customer, understanding customers needs, customer problems and what they are looking for a product.

And the product manager needs to talk to the technical people who developed the product so they can understand what is possible, what new technologies are coming, and how the product might be able to meet customers needs.

In a way that product manager is a translator, translating what the developers say to the customers and translating what the customers say to the developers. But there's more to it than this.

There's an element of creativity, seeing beyond the customers immediate concern to what could be, and imagining how the different technologies can be put together to create something new.

There is also the question of product strategy, where is the product going? What will look like in a years time? What about the competition? Is there even a competitor?

Then there's the question of marketing: so-called inbound marketing (finding out what the market wants) and outbound marketing (presenting the product to market). The marketing and strategy questions are very closely related.

And you can throw in here something about product vision too.

Of course all this these be aligned with company strategy, so you might well get involved with setting the comely strategy to. Normally the product strategy will support the corporate strategy, if product strategy and corporate strategy are different there will be problems.

Then there's the question of project management. In some organisations that product manager might be quite close to the project management, in fact they may do themselves. The product I look after has a small development team so I get involved in a lot of project management decisions. On bigger teams than maybe for a project manager and a product manager.

However I've also seen situations where there is a product manager, a project manager a software development manager and maybe a technical lead too. When this happens you have too many cooks. It is often said that the best software development teams a small but there is no point in having three or four software developers and another four or five managers.

But I digress....

In many ways the product manager is a product champion. In this part of the reason why think a product manager's role is essential. The product without a champion is unlikely to move forward and advance. Of course there should be room from more than one champion, the more people who are enthusiastic about the product the better.

So being a product manager is a mix of all these things and probably a few more.

Unfortunately that is rather longer answer than some I would like - I'd like to have a more succinct answer to the question. So I need to keep thinking about this and see if I can come up with a nice short answer.

Kabakovs' at the Serpentine

A little blog interlude...

If you live in London and you’ve not been to the Serpentine Galley then you’ve missed something good. And if you’ve not been recently you’ve not seen the Kabakov’s latest installation piece – The House of Dreams.

I went on Saturday and it is great. I like installation art and this is amongst the best. It simultaneously took my mind off the million-and-one things I’m always thinking about and let me escape. At the same time is cleared my mind and let me think about some of the big issues in life.

The exhibition is one colour: white, and its arranged as a serious of sleeping compartments – where you can dream! You are invited to lie down on the bed and let your mind wonder.

Highly recommended!

Encapsulate Context becomes Encapsulated Context.

The naming of patterns can be a tricky business. There are all sorts of rules of thumb, one can use, for example: favour and nouns over verbs, tell the reader what to build and describe what you get rather than what you do.

My first proper pattern, Encapsulate Context, didn't follow these rules. In fact, there was a lot of debate over the pattern name, if I remember rightly. I originally called it a Program State, then during the writing it became Encapsulate Exclusion Context, and when it was workshop at EuroPLoP the group felt the name Encapsulate Context was best. So it became Encapsulate Context.

Well a while back, I rrealised the name Encapsulate Context broke a good many of the rules of thumb, but I felt that it was too widely known to change.

Earlier this year, I submitted the pattern to the editors of the forthcoming patterns book Pattern Languages Of Program Design (Volume 5). The pattern was anonymously peer reviewed by two other writers, and in the best tradition of anonymous review one of these thought the name was fine, and the other one wanted a radical change.

The one who wants a change wanted the name changed on the grounds they it confuse Smalltalk programmers. Since the pattern is aimed at C++ and Java programmers this wasn't a big concern of mine. And again, I felt the naming Encapsulate Context, had a certain history.

( The book, by the way, probably won't appear until early in the New Year but you can pre-order it already Pattern Languages of Program Design 5.)

So when the book appears the pattern will be Encapsulate Context but since then, the name been on my mind more and more. Finally I decided to change it.

There is now a new version on my web site using the new name. Well, I say, a new version. Apart from changing the name, i.e. adding a single d, there isn't really any change.

Moral of the story? Embrace change, don't let the past, confine you.

Encapsulate Context is dead, long live Encapsulated Context!

Lean Solutions by Womack & Jones

I've raced through my latest book, sign of a good book, an interesting read, and most of all, a sign of large print!

This month's book has been Lean Solutions by Womack and Jones (2005), two of the original authors of The Machine That Changed the World (Womack, Jones & Roos, 1991).

In some ways, Lean Solutions is an update of the earlier book for the start of the 21st century. It updates the ideas with some good examples from outside Toyota. I particular like the Tesco example, and the study of the sports shoes.

Did you know that training-shoes (sneakers) need to be ordered 5 months in advance? Or that Nike alone produces more sample shoes than the fourth largest manufacturer? (And that was before Adidas bought Reebok, so I guess it's more shoes in the third largest manufacturer now.) It all because the industry is not lean.

Order have to be made so far in advance so they can be sent to Asia for manufacture. They have to manufacture enough to ship a large container to the US or Europe. And that transport takes time. That needs to be divided into smaller loads and distributed. There are delays and buffer stocks at every stage.

So, not only is there a lot of surplus in the system but the company isn’t very responsive and customers often find items out of stock. In fact, it puts the whole economics of lowest-cost manufacturing into doubt - and all that implies for offshore production.

The book focuses on customer rather than manufacturing. The authors identify the main customer problem today: lack of time. So it is fitting that several of their studies are drawn from service industries such as medical care and car maintenance.

But the authors go beyond lean thinking and case studies. They envisage a world where lean is the norm, they discuss how the world could be and how all our lives could be improved. The author’s set an agenda that you massive change the way the world works.

If you know a bit about lean this will teach you a lot more. If you know about lean from older books this will update you. And if you want to be lean this will give you some good examples and stories to tell.

Pricing on the internet and destroying your brand

Things are cheaper on the internet right? We all know this, no stores to rent, no shop windows to make up, no sales staff - and customers pay for delivery.

Well it seems not. According to a report in today's FT Sony has lead a group of electronics firms (including Philips, Panasonic, Hitachi and Sharp) who have been charging internet retailers more for goods then high street retailers. Their rational is that high street firms help build “the brand proposition and purchasing experience.”

Purchasing experience? Have any of these people ever shopped at the likes of Dixon's or Currys? Its a ghastly experience. And I don’t recall Best Buys being much better. There are shops I go to for a positive purchasing experience but I know I’m going to pay more.

If Sony and co want to reward retailers they should pay them a separate fee, one that is open and clear to all - the same way Intel do with their “Intel inside” promotion. What they are currently doing is just keeping prices high.

For Sony this comes on top of last weeks Rootkits revelation (see SysInternals for all the details) which resulted in them being branded SpyWare by non-other than Microsoft - full story on the BBC

Sony has enough problems at the moment - declining market share, declining profits, restructuring and redundancies. The new CEO Howard Stringer has enough to sort out without the company getting a bad name.

And that is it really, Sony used to be known for quality (e.g. Trinitron televisions), innovation (think Walkman), reliability - maybe a little more expensive than Sanyo or Sharp but worth the money. Now it isn’t the leader - in TV (that’s Samsung in flat panels) and Apple’s iPod has displaced the Walkman, its not the competitor it was.

The firm has tried moving into software - hence Sony Picture Entertainment and PlayStation Games - but that bet hasn’t yet paid off - so its still dependent on hardware where it has problems competing.

So, is there a connection between a declining market share and attempts to increases prices by the back door? Or putting their neo-virus software on our computers? One thing is for sure, customers certainly don’t want higher prices and don’t like their SpyWare.

Maybe there is a link, maybe as Sony struggles managers are trying covert tactics.

Will it work? Probably not but as these stories emerge it isn’t going to help the brand, in fact, the more Sony carry on like this the more damage they will do to their brand and reputation.

And I don’t think Howard Stringer really wants that. I'd guess the first he knew about these activities was when he read his morning paper. And I’d hazard a guess that he doesn’t like the idea. Trouble is, someone further down the tree is trying to optimise their little bit of it: prices up, piracy down - may it will work for a little while but it could damage the whole company.

Outsourcing has downsides too

It seems that outsourcing is nothing to do, we regularly hear announcements of companies outsourcing one activity of another. And when I am gathered in professional company the topic of conversation frequently turns to outsourcing. When it does there are two reoccurring theme is, the first being fearful ones own job, and the second being the difficulty of working with outsourcers.

It is worth spending a moment to clarify our terms. Outsourcing is when a company decides that one activity or another is no longer core to their business and then subcontract it to a third-party. So for example, a marketing company might outsource their IT helpdesk.

Then there is offshoring. This occurs when a company decides that one activity or another is better done in a foreign location, perhaps somewhere where the wages are lower. In the few years there has been on lot of attention given to services offshoring, in the press.

We should be clear that offshoring is not outsourcing and outsourcing is not offshoring. True, that two often go hand in hand, but they do not need to.

Sometimes it seems like outsourcing is inevitable, and all companies must do it to the maximum. However, I suspect that many organisations involved with outsourcing have not really contemplated the downside or downsides even.

There was a good example of this a couple of months ago, when British Airways flights were disrupted by a strike at a catering supplier. According to the BBC this has cost British Airways £45 million.

Now, the logic of outsourcing service that British Airways is not a catering company. Therefore it should outsource its catering, this logic seems sound.

Think again, British Airways make most of their profit from business class travel, and one of the reasons they gave for someone travelling business class, as opposed economy, is the superior food. So, if BA food is so good that I should pay more money for it how come it isn't core to BA's activities?

Second, this supplier has now cost BA £45 million. By not having the catering under its own control BA has exposed itself to a risk, one wonders how much money BA has saved by outsourcing the catering.

Finally, there is a damaged BA's reputation and image. The catering dispute disrupted their flight schedules, their reputation for timely flights and their reputation for food on flights. All of this needs to be considered when outsourcing operation.

Now these thoughts about BA have been on my mind, for while, but I had been prompted to write about them, because of a personal experience with outsourcing.

So at this point you might want to stop reading because what follows is largely a personal moan. I’ve not done this kind of public blog complaint before but I think it fits in with my outsourcing theme, and yes, there is a lesson at the end.

Having said that, most of what follows is me getting this matter off my chest!

A few months ago I decided to change my credit card. I have for over 10 years been a customer of First Direct - a division of HSBC. First Direct are a good bank but about six months ago they introduced a new credit card statement format. To put it simply, this format is pig ugly, I have enough ugly things in my life as it is and I don't need this statement format.

So I started looking around the new credit card, and as it happened one of the department stores I like, John Lewis, happen to have a credit card available. This looked like a good deal to me. So I decided to get one to replace my existing First Direct card.

Things started badly, I applied on their website and was told I was rejected, it seemed my credit rating wasn't good enough. This was a big surprise to me and I immediately got in contact with them. It was an even bigger surprise when they told me I had actually been approved the card, and I be receiving it soon.

Web site says one thing, computer system record another. That sounds like a problem to me - it should have been warning enough, but I carried on.

The ironic part is that during the application process, I discovered that John Lewis has outsourced their credit card to HFC, who are a division of HSBC! (Fortunately, they had a different statement format.)

The card arrived, and I had to get registered with their Internet banking service. They took three attempts to send me an Internet ID that worked. Even then their security regime is painful. I know credit cards need security, I don't dispute that, but the inconvenience level is just unrealistic.

Again, I should have given up at this point but I carried on.

Then I started to find the card was refused places. First by Amazon, I called the company, who told me that the Amazon debit had been authorised. Now what am I supposed to do here, and you can't speak to Amazon and Amazon has always worked on my other credit cards. In fact, if Amazon software had a problem of credit cards they would be out of business very quickly.

Still, I carried on using the card, including on some trips overseas and to the USA. But then, on my second trip to the US since receiving the card it started being refused there too. Having a card refused is always embarrassing, and it also very inconvenient. The thing was, it worked sometimes, and got refused some other times.

So on my return I called HSBC/John Lewis, and they told me that before I go aboard I should call them and tell them I'm travelling, this kind of defeats the purpose of having a credit card. The whole point of having a credit card is for convenience - I have been abroad eight times since I got the card and now they tell me I'm supposed to call HSBC bank and spend 10 minutes on hold before I can use it, then it is inconvenient.

Neither does it explain why the card worked on my first US trip, my trip to Germany or Finland. And I don’t care that they are open 24 hours a day to be told, when I do call them nobody is available to take my call.

So, you might guess, the card is going. The point of recounting the story is that it does link up with my earlier discussion of outsourcing. John Lewis department store, have a very good reputation, a very good brand, a brand that is about quality and service however the credit card that bears their name is about anything but quality and service.

Although we say John Lewis has outsourced their credit card operation this is a historical view. The company used to run its own store card operations but decided to convert the store card to a full credit card and pass the management of this to a specialist credit card provider.

In truth John Lewis have nothing to do with this card, it is really a brand stretching exercise for them, their brand on one more product. While for HSBC it is just another “badged” affinity credit card.

My card will be cut up and returned to "John Lewis financial services" most likely with a complaint along lines of what you have just read. An HSBC employee will handle the query and John Lewis will be none the wiser but it is their brand that has been damaged.

The IT systems behind the card clearly have problems:

• the website tells people they are refused when they are approved,
  
• the online banking system issues IDs that don’t work,
  
• the system is incompatible with Amazon
  
• and it erratically blocks debit requests from overseas (either it should be blocking them all or none.)
  

Have they actually tested this system?

Again, nobody at John Lewis or HSBC will hear these problems because the card return will be processed as one of many but their quality is falling.

How do you loose a million customers? One at a time. I’m actually a good customer, I’ve told them my problems, I’ve given the opportunity to get things right but they can’t. Most customer will just give up using the card silently.

Yes, John Lewis may make some money out of their branded credit card, but the card is damaging their brand. Next time I shop there will I find kitchenware outsourced? Or deliveries? Stock control?

I hope they have checked their numbers - especially since one disgruntled customer has just told the world in his blog!

Why does everybody write their own CMS?

There are two website in my life. First, the one I'm paid to look after as a product manager, this is my company’s, extranet site that provides information on our product and allows customers to log support calls. The second is the ACCU's website, yes, it looks a bit dated, we been trying to put a new one in place using a subcontractor but things haven't gone smoothly as we'd like.

In both cases, the companies concerned have written their own CMS system - that is my employer the subcontractors. When we asked for tenders to develop a new. ACCU website four out of the five submissions used proprietary systems.

Yet the world is full of off-the-shelf CMS systems, for example Plone, Mambo, OpenCMS, Microsoft SharePoint , and the list goes on. Yes, some of these are portals and some provide other functions, but my general point is: There are a lot of you choose from, without writing your own.

Yet, everybody seems to write their own, since getting involved with these websites I have spoken to several companies, and many individuals and it is a reoccurring theme, everybody writes her own CMS.

I think part of it is that CMS systems should be simple, and anyone who has a little bit of development knowledge feels they can write one.

And it seems that many of the CMS systems available are very complicated.

The term is CMS is quite broad, and covers a lot of ground, it seems mean different things to different people.

And add to all this the fact that so many CMS systems are actually evaluating them

I sure there are more reasons, it would seem that nobody has written the perfect, or even the 80% good, CMS system. So maybe there is space on the market for one more CMS system...

Do you ever start something and then wish you hadn’t?

I’m not the kind of person to drop things, I might start something and regret starting it but it is unusual for me to drop it part way through. Well I do sometimes but there is often a good reason.

I feel like this about my recent set of Blog entries on innovation. I got fired up by an idea, wrote about it then kind of found myself in a dead-end. I would have liked to research this and come up with more ideas but two things happened. First, I have a lot more projects on the go and these are projects I have commitments too (e.g. EuroPLoP, VikingPLoP write-ups) and second, I came to realise how vast the subject of innovation was.

So, I’d like to attempt a quick summary of where my thoughts on innovation are and then move on to other subjects. The need to complete my ideas on innovation is getting in the way of writing other blog entries and thoughts.

(I’ve also learned something about the blog media, it is better suited to short self-contained pieces which are loosely linked than long running closely linked entries.)

So Innovation...

I started my search with an appeal for me ideas like 3M’s “20% personal projects.” I was hoping to find some more ideas along these lines. Now I look at that and think that many of these ideas would be simplistic “quick fixes.”

I’ve come back to something I already knew – in fact something I stated in the first piece but didn’t pick up as a theme; namely: Innovation is about learning, problem solving and knowledge.

As a manager you should be concentrating your effects on making your organisation learn better. Innovation will follow. In a learning organisation you can then proceed to things like “20% projects.” Introducing these ideas into an organisation that has difficulty learning may get a few wins but isn’t going to be very effective.

But there is more to it than just learning. You need to create an “operating system” in your organization, onto of this you can run your learning and innovation applications. The operating system needs to provide for: trust between individuals, respect for individuals, rewards from the company, feedback to everyone, a tolerance of diversity and an understanding of failures – which implies that failures don’t get punished.

In reality I’ve come full circle on these ideas. Back where I was before I blasted off on my “innovation mission.”

Anyway, normal Blog service can now be resumed. Yes, I’ll talk about innovation from time to time but no long campaign to pin it (or anything else) down.

Drawing innovation to a close

It's been about two weeks now since I started this series of blog entries on the subject of innovation. I have given the subject a lot of the thought both online and offline. What is interesting is that I came across nothing on a par with 3M’s "20% personal projects time" rule, that is. I've not managed to come up with any more specific actions you can take.

But not quite there are two more things. One of which I have mentioned in passing already.

You can copy the big corporations, of all, and create your own research and development group. This group can be specifically charged with innovation. This is traditional approach taken by big corporate, and in particular, pharmaceutical and other research based companies.

Big R&D departments are not so fashionable these days, they still happen, Microsoft in particular is an example of a company that spends extensively on traditional R&D. Of course as I pointed out there is a danger in creating an R&D department.

Another way to get innovation is to buy it. I had kind of forgotten about this until an article in the recent issue of Knowledge@Wharton brought up the subject.

Although some companies like Cisco have made a strategy of buying innovation iit has always seemed a bit of a cheat me. After all it is not so much your innovation, as so many else's, you are just rich enough to buy it! And this is probably not be a viable strategy for small company.

So there you go, another couple of ways to get innovation. In my next blog entry, I intend to round off the subject with some thoughts I've been having. Then we can return to business is usual... of course. I'm not really sure what business the usual is in this blog, but there you go!

More on innovation

I’m taken with this idea that innovation is obvious. Why? Well, if innovation is not-obvious we need to work at it, and I’m not sure what we do about it. Maybe those answers will come.

But if we stick with the idea that innovation is obvious I’ve got lots of ideas on how to help it. Considering obvious innovation is the base case, if innovation is obvious and we cannot exploit it, if an organisation cannot harness it, then what chance does it have with non-obvious innovation? So, lets crack obvious innovation then we can tackle non-obvious.

In a modern world it is very easy for innovations – obvious or not – to be crushed, to be passed over or to be ignored. How does this happen? Well, there are a number of hurdles any idea must overcome.

For starters there is the time hurdle: we as individuals only have so much time, most of us have demands on our time from within our organizations and outside. If we can’t give time to innovation then how can we ever hope to think of the ideas let alone develop them into something?

The second is money: to develop an innovation may require money, say to buy the parts we need to create a prototype, or to get the resources (e.g. books, software) we need to explore the idea.

And of course, time is money so if we are short of money we are probably short of time too.

In both these cases there is a need for Slack. Tom De Marco has even written a book on just this subject – obviously called Slack (2002 - Slack). The thing is, if your every minute and every penny is accounted for in advance you aren’t going to have the time or money to pursue innovations. This is frequently the case when we work on highly scheduled projects.

When an innovation is processes based we open the whole question of change management. For example, suppose you want to try XP in your software development organization: yes XP is an innovation; yes it is obvious (because enough books have been written about it) but, are people prepared to change the way they work? Are managers prepared to take a chance on something?

So, innovation may be stifled because some people are not prepared to try something new.

It may also be held back because people are risk averse. In particular, people in positions of responsibility may be more comfortable repeating something they have done before than trying something new. And if they will not try something new then who else in the organisation will?

Neither will people pursue new idea if they are seen to be punished when it doesn’t work – or even ignored when they try something that does work. For example, sticking with the software development process example – because I know a little here – lets consider Joe and Fred who work for two separate software development companies.

Joe and Fred learn about Agile processes. They introduce the ideas to their teams. Fred’s team fails miserably and come pay review time every other manager is given a rise but not Fred. Clearly he will be deterred from trying any other new ideas.

Joe meanwhile has a modicum of success. Then his organization is re-organized – as companies are wont to do. And in the new structure Joe finds that he is effectively demoted. Is he going to be inspired to try any other new ideas?

Thing is, organizations need to be tolerant of risk and failure, and, just as importantly, ambiguity. This is easily said and hard to do.

Sometimes we crush new ideas because we put people in boxes. We assume that the R&D department will have the new ideas and not front-line staff. People respond accordingly – I spoke about this in my last Blog, “the Jackson Pollock example” and it related back to what I said a while ago about identity.

Ideas can also be crushed when they seem threatening. Again, Joe’s Agile team may not have space for an “architect” in the team, people in the company who consider themselves to be “architects” may feel threatened and work against Joe – either actively or passively.

Just because one person exists in one place on the organizational chart, say “Marketing” doesn’t mean they can’t have a good idea about another area, e.g. manufacturing.

The same thing happens when a potential product threatens to cannibalise sales of an existing product. Perhaps it is better to burry the new idea. But isn’t it better to cannibalise your own sales than have a competitor come up with a similar idea and steal your sales?

With all these ways to crush an innovative idea is may seem remarkable that new ideas survive at all! Big companies have more of these “defence” mechanisms than small companies and so crush more ideas. Small companies have few defences – indeed some small companies come about when people get fed up of their ideas being crushed and leave the big company to pursue a new idea.

Of course, in a big company there may be more time and money to develop the new ideas. The firm may be profitable enough that it can take more risks with more new products.

So, both big and small have their advantages. However, there is a need to develop and nurture a culture of innovation. If you don’t do this when you are small it is harder to introduce (retro-fit) when you are large.

Obvious innovation and the Jackson Pollack example

My recent entry on innovation attracted a few comments, some verbally to my face, and some online, were we can all see them. One online poster, ended his comment by saying "innovation is obvious, isn't it?" - I find very interesting idea itself. Certainly there is a tendency to regard a lot of innovation as non-obvious. If for a moment we flip the default and assume innovation is obvious then there is a lot we can learn about innovation.

I would like to introduce something what I call the Jackson Pollack example. We will use Jackson Pollack is an example, although Mark Rothko, Ellsworth Kelly or a number of other modern art artists could fill the bill equally. It goes like this

Have you ever been to a modern Art exhibition, and as you view a piece by Jackson Pollack, a visitor close by, says "that's not art, I could've done that" or perhaps they say: "Looks like something my child date."

They might be right. In these observations there is an important point is: they didn't do it, Jackson Pollack did, it was he who had the idea, it was he who implemented, it was he who showed the idea, it was not the person standing next to you at the exhibition. Sure, the idea may appear obvious in retrospect, but did it appear obvious when Pollack did it?

At the time the Pollack worked art was changing. Still, he went against a lot of conventions produce his drip paintings. Other people may have had the same idea as Pollack, but they didn't implement it, why they didn't implement it we don't know, we can only speculate, but I'm sure that some of them would have been bound by convention, the convention and that says the painting must be easily recognisable, the convention that says it should be a landscape or a portrait or a still life.

We are surrounded by conventions, and sometimes an innovation needs to break the convention. In retrospect, it may be a convention that needed to be broken but that might not be obvious the time. To break convention risks upsetting people, it may even be career limiting, and so there are good reasons why we don't break conventions - reluctance to break convention is itself a restriction on innovation.

Of course, one reason why Pollack was able to do what he did was because he was an artist. He had an artist's training, and he had a track record of producing pictures. Therefore, he was taken seriously by the artistic community and the art dealers. The same might not be true of your neighbour in the Art Gallery, who has no training or background in art.

This scenario plays itself out in business as well, firms may expect to see innovation from the Research and Development Department, but may not be expecting it from other places in the company. When innovation is posed by, say, the checkout operator iIt may not be taken seriously.

The question for business is: can it afford to only take innovation is from where they are expected? By ignoring the proposal from the checkout operator the company may be closing its eyes to proposals worth thousands or millions of Euros.

So, to sum up then: innovation may be obvious, but there are plenty of reasons why we might lose it.

The Jackson Pollack example shows us:

• Having the idea is important, but so is having the idea first. And so is following through on the idea.
  
• What is obvious in retrospect may not have been obvious at the time.
  
• We sometimes need to break conventions and this might make us unpopular.
  
• Sometimes, we only take innovation seriously, when it comes in, the people we expect to be innovative.
  

So challenge for the company wishing to be innovative are:

• How do we help people follow through on their ideas?
  
• How do we allow people to break conventions?
  
• How do we harness ideas when they come from unexpected sources?
  

Skunkworks teams for innovation

Continuing on the theme of innovation, there is another common technique used by companies to produce innovation. Often it used to develop somebody's innovative idea and is sometimes used to generate innovative ideas as well. This is the skunkworks model - or to give it a less jazzy title: separate your imaginative team.

In this model, the team that is to produce the innovative product is separated from the main organisation. The people involved a ring fenced, they may work at a separate location, they are removed from the day-to-day life of the company, and in particular, the politics and blocks on innovation that exist normally. Sometimes these teams are kept secret.

This technique has been documented in countless stories, indeed, Lockheed Martin have trademarked the term skunkworks. If you want to know more about this method you could read Coplien and Harrison's Skunkworks pattern and in their book, Organizational Patterns of Agile Software Development, 2005.

(I have also discussed the technique in pattern form, Separate Imaginative Teams.)

Hamel and Prahalad also noticed this technique in their Harvard Business Review article, Corporate Imagination and Expeditionary Marketing - May-June 1991.

There is something macho about this technique: the image of a bunch of brave souls going off to design and create a new product, cut off from the Corporation, free from the politics and infighting. And sure it does work, companies do create new products this way, however, this technique also has a downside.

This technique may create a new product, it may bring about an innovation, it may get you out of a hole right now, but it does little to make the overall organisation more innovative. In fact, it may detract from the overall company's innovative ability.

To start with the innovative people are separated from the rest of company so none of their expertise or experience is directly accessible by the rest of the company. Neither do they form role-models for other people in the company. Many times, the new product development is invisible to rest of the company - they just get on with their regular work.

And when the product is produced in must somehow be folded back into the company. The rest of the company may not understand the new product. Indeed it might be quite different from the company's main products. Therefore there is a learning curve, while the new product becomes part of the stable.

The people who have created the new product also need to be folded back into the company. But while they have been outside the mainstream, they may have got used to a different way of working, a freer environment, a lack of politics or structure. To these people re-entering the corporate fall might be difficult. Indeed it might be easier to leave the company altogether.

Meanwhile, the people who remained with the company working on the old products are not working on the shiny new thing, they may become resentful of those working on the new product - especially if the skunkworks team are seen to be given privileges or better resources.

And there's not forget one the points made by Arie de Geus which I noted a few days ago: it is not just the taking of decisions that takes time but the acting on them too. The people outside of the company have made all sorts of decisions, and when they returned to the company they expect those others to act on them - there will inevitably be a delay. Indeed, there may be a repeat of the learning curve.

Perhaps, one of the most famous examples of this approach was Xerox's Palo Alto Research Centre - or PARC for short. Xerox set up a research centre on the other side of the country, stuffed it brilliant people and gave him plenty of money. The project succeeded, it invented most of the features we find in the modern PC.

But the project also failed, the team was so far removed from the main Xerox Corporation and the company could not usefully exploit their innovations. Still the researchers found a way, and many of them left Xeroxto found successful start-up companies in Silicon Valley, for example Adobe and 3Com.

So, on balance, I am not a fan of the skunkworks approach to innovation. If you want your company to be innovative you have two embed, within the company, and within the values.

How do you do innovation?

There is a lot of hot air spoken about innovation. Indeed, there is probably more talk about innovation than there is actual innovation itself.

I started to get all excited about innovation on Friday, when one of my managers said:

“Allan, do you know anything we can do to improve innovation?”

Of course there is one obvious answer: 20% personal projects, its the 3M example – and now Google. Just about everyone seems to have heard this example so I’ll be brief in my comments: at 3M engineers are encouraged to spend about 20% (figure varies depending on who you read and which company it is) on “personal projects.” Some of these projects eventually make it to full products, like Post-it pads and Google News.

But are there other things you can do?

I was excited so I went home and started looking through some of my textbooks and journal archives, my question: just what do you do to produce innovation?

On the one hand innovation is just an extension of problem-solving, which is itself an example of learning. So doing innovation is firmly within the knowledge and learning agenda I keep banging on about. But on the other hand, innovation is so specific it is a subject in its own right.

Regular readers of this Blog will know I don’t have much time for “big brains”: I don’t believe that the CEO, CTO and a few managers can sit in the boardroom for six hours and come out with a new product. Most innovation is bottom-up.

Nor do I believe you can schedule innovation: Ever seen a project plan with a date pencilled in for innovation? No, you can’t timetable it.

So, how do you do it?

Looking at my books I find advice like: improve you ability to learn, trust your employees, organize your business structures to promote innovation, value innovation, align your HR policies (reward innovation and risk taking), don’t punish failure, and so on. These are all big, macro solutions, they may be necessary but they are not sufficient, you need something else.

You can set your business environment up to encourage innovation with these ideas, you can show people it is valued, but what do you do?

This is where the 20% personal project comes in. It is something you could do today. It is easy to see how you could get a new idea out of it – whether that is a product or process innovation.

A few months ago I was able to speak to someone who works at Google and they described how this works.

Engineers need to spend 20% of their time on a personal project. But many of them don’t know what to do, so most of them are open to suggestions. Meanwhile, the product managers have the opposite problem. They are identifying things the company could do, but without a prototype or proof of concept they can’t get any official resources.

So the product managers look around and find engineers who need projects. They then have to interest the engineers in working on their idea. If the project goes well they can then go official and ask for full project status.

(By the way, read my lips: No project managers!)

The trouble with this example, the 20% example, is the one everybody cites. It seems. When asked: “how do you do innovation?” People reply with a 20% example. What is actually happening is that this example is getting in the way of other ideas and examples of how you do innovation!

So, dear readers, the challenge for you:

what does your company do to encourage innovation?

I need your ideas and experiences.

Why work?

In my last entry I wrote about The Living Company, there's a lot I could say about this book that you're better off going to it read yourself. It isn't my intention to give you a review or abstract in this book buyer would like to share a few thoughts.

While these thoughts concern the role of the individual in the corporation at its most basic level it poses the question: Why do we work?

At one level it is an easy question to answer: we need to pay for our food, clothes, housing, etc. But there is a deeper level to this question and one that concerns the relationship between the individual and the company. We could rephrase this question as, what do I hope to get out of this job? With the emphasis on, I.

For de Geus and his Living Company profits are only a means to an end. Similarly, wages are only a means to an end. In working for a company, and in employing an individual, the two enter into a pact. The corporation promises to give the individual opportunities to further themselves and to grow as a human being, and the individual undertakes to help the company continue in his quest for survival.

De Geus explores this argument in depth. While he accepts that one size does not fit all and that in different firms things need to be done differently he is an advocate of the recruit early, retained the life human resource philosophy. Of course, this has its problems and he does discuss some, but these are discussed from the corporate side

I was left wondering what of the individual who does not get hired by such an enlightened company, is such a person condemned to work for "inferior" companies from the rest of their working life? I suppose I'm thinking of myself when I ask this question, when I graduated from university jobs were thin on the ground and I considered myself lucky to get a job with a 12 month fixed term.

And what of the individual who is unfortunately laid off from the corporation? And particularly when this occurs, halfway through one's careers, how are they to return to an enlightened employment?

De Geus does consider the need for companies to periodically let people go. For him this occurs, not when a company needs to downsize, but when an individual can no longer grow. Of course, sometimes in a downsizing company there may no longer be the opportunities for individuals to grow. At this point de Geus actually starts to sound like Jack Welch.

Welch (Headline Book Publishing, 2001) also advocates a human resource policy based on individual development, of course, being Welch, he is a lot more hard-nosed about it and relates the policy directly to the bottom line of the company. He also advocates a pro-active policy of dismissing people who are considered to be in the bottom 10%.

This is all tough stuff, and maybe, just maybe, the idea that the company can no longer offer an individual opportunities grow and it is therefore best they leave the company, well maybe, this is just the sugar coating that managers can tell themselves so they can sleep at night, when the newly ex-employee is wondering where his next wage comes from.

Don't get me wrong. I think these authors are making a good point, and I am very attracted to the idea that it is through work that we grow and improve as individuals, but I also see a potential for self-deception.

Interestingly, these ideas of growth and, shall we say, weeding out, sitting well with my blog entry of 12 October 2005 - Productivity & IT - US trumps Europe. Maybe this is just a simple case of statistics, if the company is to be above average. In needs to remove those below average and encourage those above-average.

And what of me on a personal level? As I've written here before, I am now a Product Manager, a recent change, and one that is giving me room for. Looking back on it and not sure many of the companies I have worked for have really offered growth opportunities.

There is a chapter in book one of Douglas Adam’s is Hitchhiker's Guide to the Galaxy, where he describes the evolution of Vogons. I can't recall the exact words, but he says something like

"evolution took one look at the Vogons and decided they weren't worth bothering with, so the Vogon’s decided evolution was worth bothering with just on with it."

I sometimes feel like that about my career! Some of those large, enlightened companies, took one look at me and decided they didn't have a career for me, so I just got on with it myself.

Actually, I don't think I'm alone in this scenario, I think many of those who entered the labour force during the late 1980s and 90s encountered the same situation. I like to think things have changed now but I don't know.

Still for me, the wage is important, but so is the growth. And as I get older, the relative importance of growth increases.

Another month, another book -The Living Company

Sitting on planes is boring, one of few advantages is that gives you a chance to read, and so it is that idea to read yet another book. This time the book is “The Living Company” by Arie de Geus - 1997, Nicholas Bealey Publishing.

This is a very good book, as one might expect from the title its thesis is that companies resemble living organisms. As a living thing the primary objective of the company is not to make profit but to survive. Profit therefore is not an end in itself but merely a means to an end, for without profit there firm cannot survive.

Arie de Geus is the author of a well-known Harvard business review article entitled "Planning As Learning" - if you have not read this it is well worth the $6.

As one might expect this book expands on this theme, the important point about planning is not produce a schedule that allow individuals to consider possible scenarios so that their thinking goes beyond a mere projection of the past.

Continuing on from this he argues that everyone affected by a decision should be involved in the making of the decision. On the face of this might appear to slow down decision-making process that is not the case. Because making a decision is only half the story, what is the key is made in the acting upon by involving more people in the decision-making process we ensure that action happens sooner.

It was only as I came towards the end of this book of the obvious occur to me. As regular readers of this blog will know I write Patterns, the originator of patterns, Christopher Alexander, calls on us to create patterns that live, in the same way Arie de Geus callers are those to create companies that live. To my mind there are obvious parallels here and further validate the use of patent theory when considering the business domain. Hopefully I'll explore these parallels further in future patterns that are.

Productivity & IT - US trumps Europe

I’m in the USA this week – part business part pleasure – so its a good time to think about some of the differences between the US and Europe and the UK specifically. On this occasion I’m given food for though by a study from the London School of Economics Centre for Economic performance on growth in the USA and Europe.

The full report is available from the Office of National Statistics for free, and it has been reported in the FT (10 October 2005) – I’m sure it has been reported elsewhere too. I’ve only had time to read the FT story but I’ll try and read the full report in the next few days.

The report is interesting because it looked at the difference in productivity growth between Europe and the USA in the last ten years. It appears that the USA is increasing productivity faster than Europe. But the really interesting thing is: US companies in Europe are increasing productivity inline with the US rather than Europe. This implies it is management practices not local culture that is having an effect.

It goes on to attribute this to two reasons. First US companies make better use of IT. This might come as a shock, after all, US and European companies have access to the same IT resources – we can all buy the same Sun servers and SAP software – so it can’t be the IT itself it must be the way you use it.

(Actually, there is another shock here, there has been some doubt in the past that IT has actually delivered increased productivity at all but we’ll leave that for another day – take a look at material by Erik Brynjolfsson and others if this interests you.)

The second reason is something quite different: HR practises. Seems US companies promote their best workers faster than European companies and get rid of under-performers faster too. In effect they are rewarding the performers and filtering out the also-rans.

I can relate these ideas to what I’ve seen in US and European companies. So, where does this leave us?

Well the good news is there is gold in IT. The bad news is you can’t just “add IT” and make your problems go away, you need active management too.

If this comes as a surprise to you then good. Think about it. If this doesn’t come as a surprise to you then good, you now have the evidence.

Either way we have to ask: what are we going to do about it?

Going to speak

Since I know a thing or two about computers I often get asked by friends and family “what computer should I buy?”

My answer is simple, “how much money have you to spend? Buy a computer that much money and plan to replace it in three years time.”

My logic here is, just about any computer on the market today is good enough for your needs, most people are word processing, spread sheeting, surfing the net, and e-mailing. If you doing anything more complicated, e.g. gaming or software development, you probably know more about what computer you should have than I do.

The second half my advice is based in fact that machines date and explore the best to place on at regular intervals.

So then, if I follow my own advice I should buy a new machine now, my laptop is just over three years old, but when I look at the market things haven't really moved far forward, my laptop still does what I wanted to do.

One thing might change this though. When I got this laptop I got a free copy of DragonDictate, voice recognition software, I recently playing with this I quite like it. So I have decided to order an updated version in trying using more frequently.

The reason for telling this is simple, DragonDictate makes mistakes, I don't always spot them, so as I have started dictating my Blog entries you might start to see some mistakes. Now maybe I'll find the need for a new computer.

On project management

I finished my last entry by taking a swipe at project management and even project managers. That was probably unfair but the fact is I am not a fan of project management

It could be a career limiting move to speak against project management but I feel I should say something to explain my sideswipe, I should explain my thoughts.

Of course I'm not naive enough heretical think projects “just happen" - there needs be some kind of project management but it is the form project management usually takes that I have a problem with. I am not alone in my views, but they are somewhat heretical.

In their book “Lean Software Development” Mary and Tom Poppendieck explain why much project management practice is contrary to the principles of lean. Henry Mintzberg wrote an entire book in criticism of strategic planning - although “The Rise and Fall of Strategic Planning” (1994, 2000) is largely concerned with the differences between strategy and strategic planning much of what he says can be applied equally to project management.

More specifically the authors Lauri Koskela and Greg Howell have written papers claiming the whole theory of project management is obsolete, e.g. “The theory of project management is obsolete” (2002) and the “Theory of project management explanation of novel methods” (2002). (Actually, one of their criticism is that project management lacks a theory and academic underpinning.)

I've even discussed this subject myself before - see "An alternative view of planning". Of course my view of planning it comes from the software/IT perspective and it may be dangerous to extrapolate to all project management, but this is the feel I know.

So, as I see it, the problems with current project management on multiple:

• Planners are divorced from those doing the work
  
• Planning is not used as a learning tool, it is used as a control tool, this can lead to planning being used to apportion blame
  
• Responsibility is removed from those doing work, after all the plan says can be done so is merely an exercise in executing against the plan
  
• Accuracy: planning is based on estimates which definition in wrong
  
• Extrapolation from the past: planners so often assume that the future will be like the past
  
• Planning limits our expectation, because extrapolate from the past, and because the use estimates, and because they ignore the learning we are limited to what we expect to happen
  
• Plans become defensive barrier behind which people hide: manages no longer talk to those doing the work they talked of project manager, who in turn talks the people doing the work, nobody has to answer for this, we just compare ourselves to the plan - which of course nobody really believes
  

Finally planning is demoralising, what we have a plan or users execute. A good project manager execute the plan - the workers are minor fact, and all too often they know this.

So that, in a nutshell is why not fan of project management and planning.

Yes it sounds like I have moved from talking about project management to talking about planning - and I know they are different but is the emphasis put on plans is what I don’t like about project management. (Some of the points made above (e.g. responsibility, learning, accuracy) still hold even if you don't have a plan, you just have a project manager who create a barrier.) The subsequent “execution against plan” and “exception tracking” are all part of what we define as “project management” today.

So, what I put in its place?

The answer is quite long. I give you some ideas in the last, and earlier, blog entries. In a sense, the "alternative” is what this blog is all about. Or, put it another way: the alternative is a work in progress.

Stay tuned.

Knowledge based product development

Today is my birthday, I always like where possible to take the day of work and do something enjoyable. This time I’m at home taking it easy, catching upon reading and writing. One of things is allowing to his finish reading my latest book. I normally have two or three books go at once, usually a novel, something serious and perhaps another book which I wish I had time to read.

I've commented here before that I have recently become a Product Manager - when I say recently it was almost six months ago now. Of course I want to be a good product manager so I've been looking around material to tell me how to be a good product manager, much to my surprise I find that there are very few books written on the subject of product management.

Indeed depending on your industry the role of Product Manager differs. In some industries the role of Product Manager is concerned with brand management and marketing, in other industries, like the software industry that I work in, Product Manager means somebody who determines what features the product needs, what work should be done on the product and who talks customers about what they want from the product.

So even when you find literature on product management you have to check to see which of the two types of product manager it is referring to. There is more literature on product management as a branding and marketing role then there is on product management as a development role.

In my search for product management books I came across "Product Development For The Lean Enterprise" by Michael N. Kennedy, 2003. This book describes what lean product development is, or rather what knowledge based product development is - as a book itself says knowledge based is a better description than the lean but lean is a better known term. The book is good in that it discusses not just product development but also the change process required to move from an existing product development setup to a lean, knowledge based, setup. What is unusual is that the book is written in the form of a story.

The story form makes it easy to read the book but makes it more difficult to understand what is speculation in what is hard evidence. This is compounded by the fact that the book does not give a great number of references. Indeed I was disappointed that the book fails to reference one or two books already in this field, for example "Thinking Beyond Lean" by Cusumano and Nobeoka, 1998 - another book I would recommend.

That aside, the book is worth reading and I recommended to anybody interested in the subject of lean production or product development.

So what does the book say? I won't give a full precise but here is something to wet your appitite.

It points out that Toyota have a radically different product development strategy to just about any other organization. For example Toyota use setup-based engineering, so rather than design, say, one new gearbox for a car they may develop several new gearboxes and select the best one, or combine the best features of those developed into a new gearbox.

This may seem shocking to many project managers who see wasted resource but there is more to come. Toyota does not use traditional project planning scheduling techniques - no GNATT charts here. Instead they rely on hard deadlines, a fully engaged workforce and personal responsibility to meet meaningful dates.

The idea is that developing a new product is not just a one-off project it is part of a bigger learning exercise within the organization. The exercise generates new knowledge, this knowledge is itself an asset to the company, so the company is seeking to increase its stock of knowledge and experience. In effect developing a product is simply a learning exercise.

There is an interesting theory here the book does not discussed but I will. I don't know of top my head who suggested this theory but I do know that I heard both Alistair Cockburn and Jim Coplien discuss the theory.

According to this theory there are two types of game, there are finite games, e.g. tennis, Cluedo, football, these are games which have a fixed stars and a fixed end, typically they are played to win at the end of the game there is a winner and there is a loser.

And then there are infinite games, these are games that never end, e.g. your career, life itself, in these games the objective is not to win but to survive, the games may be played in rounds and survival in one round allows you to play again.

In business, and specifically a product development organizations, you want to create a new product, you want to bring that product market and you want to be successful, in this way you're playing a finite game and you're playing to win. But at the same time you are playing in infinite game because there will be another product after this one and another round to the game. So in each round you play you have two objectives, the first is to win this round and the second is positioning yourself for the start of the next round.

So often when we develop new product, and specifically when we developed new software, we are concerned with the current project. We want to meet the current deadline so we do everything we can to meet the deadline but sometimes in doing that you are lessening your chances of winning the next round.

Software shows this perfectly, when you wish to meet the deadline is very easy to cut corners, to leave bugs unfixed, not to refactored code (so it becomes a mess) or too misuse the architecture in a way it should not be used.

The insight Kennedy, Toyota, Cockburn and Coplien offer is that is wrong to treat each round of the game in isolation, knowledge accumulated during one round is useful for the next round, indeed it is essential as the key to future competivity because in a knowledge industry, like IT and software development, knowledge is the greatest asset.

Unfortunately, many "best practice" project management techniques (or is it project managers themesleves?) fail to appreciate this.