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.