For a few years now I’ve been interested in the application of Patterns and Pattern-thinking to the area of business and business strategy. Just to be clear, when I talk of Patterns I’m specifically thinking of the type of Patterns that originated with Christopher Alexander’s work on architecture – see PatternLanguage.com.

Alexander explained his theories in The Timeless Way of Building and A Pattern Language.

During the early 1990’s his work was picked up by a bunch of people in the software engineering community and this led to many books – the most famous being Design patterns – plus an dedicated software patterns organization (Hillside and Hillside Europe) and a series of conferences known as PLoP’s.

When I was studying for my MBA I regularly found myself saying “This could be better explained as a pattern.” Subsequently I did some searching and yes some people had done some work in this field already but often the patterns were kind of “We have this problem that IT people describe as a ‘business issue’ so lets write it as a pattern.” This kind of thinking leads you to stuff like IBM’s patterns for e-business.

Then there are Patterns written about the IT environment that can be applied more generally to business and organizations. Jim Coplien and Neil Harrison’s Organizational Patterns of Agile Software Development is one such book. Its a really good book, I might not agree with every pattern in it but I would recommend it to anyone trying to organize a software development group or indeed, anyone concerned with organizational structure.

But I was actually thinking was: forget the IT, apply pattern thinking to business in general.

This has lead me to produce a number of papers that I have taken to pattern conferences to validate my ideas – you can find them on my website. One of the fundamental tenants of pattern writing is that you should write from experience. Patterns are about what you know not what you can learn or discover. This places a limit on my pattern writing because my experience is in IT so I’ve had to do a little pattern mining.

Still, I’m not alone with business patterns. Linda Rising, Daniel May and others produced Patterns for Building a Beautiful Company. Others have worked in specific business domains, for example, Cecilia Haskins has produce a set of patterns for conference production.

Sometimes people don’t get it, or they ignore Pattern thinking and just look for “simple” patterns. That’s why I don’t consider Adrian Slywotzky book Profit Patterns to have anything to do with Patterns. (A fuller discussion of this book is on my website.)

From time to time I find others who have had the same thoughts as me, namely, Business Strategy is crying out for Patterns. Richard Veryard has had some thoughts online for a while – although I don’t think he has updated this recently.

Just recently I discovered Julian Elve’s blog on the same subject.

I don’t know if Business Patterns will ever break through to the mainstream – the mainstream in Patterns or the mainstream in Business and Strategy. But I do think they have a role to play, I also think a growing number of people are realising this and attempting to do something.

I’d like to think that one day the business community will have our own version of Design Patterns but I don’t see it happening for a while. When it does happen I expect to see business consultants at the fore. These are the natural people to be writing such patterns, they see lots of companies and have great opportunities to spot and analyse patterns at work.

According to a piece on Knowledge @ Wharton the adoption of ISO 9000, Six Sigma, TQM and other similar initiatives can lead to a decline the innovation (subscription required). Basically, as you get better at your process (i.e. you go deeper into one thing) you don’t experiment as much around the edges (i.e. you don’t go wide.)

Actually, according to this piece its not just ISO 9000 and 6 Sigma, it is broader, any process improvement initiatives. And its partly to do with people’s approach, those who are happiest in innovative environments aren’t so happy in structured environments and vice versa.

For someone like me, who is keen on both process improvement (specifically Lean processes) and innovation this poses a dilemma. Am I, by advocating process improvement and the adoption of Lean techniques actually hindering innovation?

Could be.

I like to think the answer is No. Let me explain why.

I don’t advocate blanket adoption of a process. I don’t believe that a process that works for Team X will work for Team Y – even if they are in the same company. I believe different teams have different people and since no two people are alike, no two teams are alike and therefore no two processes can be alike.

Neither do I believe in Best Practice – at least not in the usual sense. The idea that Team X can document all their best practice and hand it over to Team Y, and then Team Y will be just as good (or bad) as Team X is bunk. Again, there are different people and different experiences in each team. Neither can you actually write this stuff down because so much is tacit.

And finally, I don’t believe management can set out a process and mandate its adoption.

What I do believe is: it all has to be bottom up. The teams need to do their own process improvement, they need to find what works for them, they need to work with the people and experience they have in the team. Teams need to innovate their own process.

Teams can tell other people what they do, they can give them ideas, inspire them, and even coach them but they can not throw it over the wall and expect it to work.

While teams can use books, journals, consultants, outside experience to get ideas and inspiration there comes a point when they need to move beyond other people’s ideas and start creating their own. Force-feeding will only get you so far; sooner or later the teams have to be self-sustaining. After all, your competitors can read the same books and hire the same consultants.

The important thing is, this is about bottom up innovation for improved process. I believe that once people get the hang of innovating then the skills and experience will transfer from process innovation to product innovation.

And thus, I don’t believe the kind of process improvement I advocate is incompatible with innovation.

Am I trying to have my cake and eat it? You tell me.

I spent the best part of two hours this morning doing a very un-middle class thing. I put about 200 A4 newsletters through peoples doors. Its not the first, or the last time I’ve done this. In fact, I used to do it a lot more. And as usual I thought: why am I doing this?

It was for the benefit of the local Labour party. I’ve been a member since I was 19 and although I don’t agree with everything the party says and does I do broadly agree. But, that doesn’t mean I must spend two hours on a cold Sunday morning wrestling with letter boxes.

In truth there are a whole bunch of things I don’t do for money and aren’t necessarily fun. I’m on the organizing committees of two conferences (ACCU and EuroPLoP), I shepherd paper for EuroPLoP and I’ve organized a new ACCU website. None of these things pays money and while I may claim they are furthering my professional experience I think its unlikely I’m ever going to get a job because of it.

(Indeed the reverse seems more true, interviewers wonder why you do all this and I usually don’t mention my Labour party affiliations in case people get the wrong idea.)

Actually we could add in blogging.

So, just why do I spend my spare time doing this stuff? And in particular why walk the streets on a cold Sunday morning?

Certainly I’m not in the Labour party for power. I spent 5 years as a branch secretary. That was lots of work. Setting up meetings, writing members newsletter, getting them delivered and writing minutes. No real power there!

Neither do I get influence. Most of the local politicians I know don’t have any real power by themselves. And the one time did ring my friendly MP with a problem looking for help he quickly told me he couldn’t do much.

Oddly I will get a reward. When I see people I know elected as councillors, members of parliament or elsewhere I’ll know I helped. Equally, I’ll feel really down if the other side win.

So, why do I do this?

I do all these things because I want to belong to these organizations. I do them because I think these things are important. And I do them because I have benefited from others so I want to give something back.

I wouldn’t do these things if I didn’t share the values and objectives of the organizations. Even if at the moment I don’t agree completely with wants happening I know I’ve signed on for the long run. Things will change again.

Actually, and this is the reason for blogging about this, I don’t think any of this is very much different to work. I’m not the first to point this out – for example Peter Drucker said it often – but many of the same things that make me volunteer are what make us work.

I think this subject has been at the back of my mind for a couple of weeks. My office book group are currently working through Lean Software Development (Poppendieck & Poppenieck) and in the last session we considered the topic “Empower the team.” This lead us into discussions about: who should be on a team? how should a team be made up? and just why do people work?

Sure I need to earn money, I need to pay my mortgage and I like foreign holidays but there is more to it than that. Like with my volunteering I’m looking to belong and I want to contribute. I want to be part of some success.

Work is different; it takes up 8-9 hours a day – far more than anything else. And it is more of a commitment. I’m expected to be there everyday, I’m expected to be there next week, next month and even next year. But I could walk away from any of my voluntary commitments tomorrow. I could just say “sorry to busy” and people would understand.

Perhaps ironically, I’ve been doing voluntary work for the Labour party for far longer than I have held any job – over 15 years. Even when I disagree with the party (and I do, like over the Iraq war) I still stay involved one way or another. How many employers can get that kind of loyalty?

I think its important that we recognise that people have a choice in where they work, and when they actively choose to work for your company, or work on your team then its quite a complement. We need to recognise that and respect it.

We start by giving people a choice of a job. Once they work for a firm we can give them the choice of teams – in my experience self-selecting teams are the best. We should reward them – not just with money, with feedback on their work and show them what their work has accomplished.

And we can let them pursue their interests and passions. We shouldn’t stop them from taking an interest in a project just because they work in the wrong department, if they think they can add something them they will add their passion at least.

The challenge for managers today is to get people to choose their company, their team and their products. You’ve got to make people want to work for you.

I first heard about Naked Objects (the Naked Objects website is here) in a presentation at the SPA 2005 conference and have been intrigued since. I finally managed to find time to read the book (Naked Objects by Richard Pawson & Robert Matthews) and I can recommend it. Naked Objects brings a different approach to software architecture.

The book itself is different. Like Tom Peters Re-imagine! it is printed so it looks almost like a children’s book with lots of pictures and glossy pages. In particular I like the use of case studies – I think we in the software professions don’t make enough of case studies.

Both the Naked Objects philosophy and the Naked Objects framework are described. I’ve only skimmed the stuff on the framework, this takes the form of a tutorial section on the Java framework and seems to make extensive use of reflection so it might be difficult to port to some languages.

Still, the Naked Objects philosophy should be applicable in other languages. The approach won’t work for all domains: it won’t work where the application is of a highly scripted nature, where customers must use the software directly (e.g. a ATM/cash machine) or where there is a lot of data entry. Still, that leaves an awful lot of applications where it could work.

Naked Objects makes one very important assumption up front: it assumes the software user is not a dumb automaton but actually an engaged problem solver. This also implies you trust your staff (and if you don’t then why do you employ them?) and that they know the problem domain at least as well as the software – probably better. This allows developers to concentrate on functionality rather than interface or interaction design.

Basically, the idea is to expose objects directly. The objects have user meaningful methods with which the user interacts directly. So, if you want to book a Taxi in New York you put the New York object together with the Taxi object. In some ways it is taking Object Orientation to the extreme.

I’m not sure how this all fits with good software interaction design as described by Alan Cooper (The Inmates Are Running the Asylum) – I think in a domain where interaction design was key you probably won’t use this approach. However, where you can position your users as problem solvers the consistent interface pays off.

Once you start treating your users as problem solvers you assume that: they know best how to solve the problems, rather than try and think of everything that could happen and provide a way of dealing with it you provide the raw objects and let the users work out how to do something. And with that a large part of your work goes away, making you more productive; and because you are treating you users as intelligent beings they get more satisfaction from work and do a better job.

Overall I think the Naked Objects approach is very promising. It seems a particularly productive way of working. Everything I heard at SPA and in the book persuades me that this deserves more attention than it is getting.

A friend comes to visit me and tells me he is considering doing PhD research on the gap between corporations stated policy on corporate social responsibility and their actions.

Tony Blair looses a vote in the House of Commons by one vote.

And in Northern Ireland the Independent Monitoring Commission suggests that while IRA leadership is committed to peace and politics the members on the ground are still holding weapons and engaged in suspect activities. (Report in the Economists)

What have these things in common?

They show what happens when the top of an organization – the leaders and managers – gets separated from the bottom – the workers.

Such a situation isn’t automatically bad, it can be a good environment for innovation and risk taking. Neither do we want a situation were managers are standing over workers compelling them to do something

But at the same time it does show what happens when strategy and operations become devoiced. Strategy may be the “helicopter view” but often it is the “expected helicopter view” – how do we know what is happening rather than what we want to be happening?

It is very easy for leaders to say “We will do X” but for the workers on the ground to ignore the message. Perhaps they’ve heard X, Y and Z in recent years and have started filtering our management messages.

How can we expect our leaders to lead if they don’t know and understand what the issues people on the ground are up against? Nor do they know the solutions the people on the ground are implementing, or whether they are compatible with the espoused strategy.

Nowhere is this truer than in the realm of knowledge workers – and in the knowledge workers I know best, software developers. It is said that a developer makes a decision every 15 minutes. But is this decision compatible with the strategy? Does it move us towards our goal?

Of course the developer can’t stop and ask the managers view every time, they need to make a decision – they probably don’t realise they are making the decision a lot of time. To ensure the right decisions are made the two need to have a close dialogue.

This dialogue can only happen if both sides make space and time for it. All too often software developers don’t know they need it, or avoid it because they would rather be coding. And managers frequently fail to make the time for it – perhaps because they are busy making strategy. There need to be occasions were both sides can talk and explore these issues.

The need to bridge the gap between the two groups in an organization is never more acute than when change is happening. My examples above discussed companies trying to take their social responsibilities more seriously, politicians trying to change the law and society and a terrorist group changing its mode of operation.

I once worked for a company that decided it should be CMM level 2. They hired some consultants to write the process. They appointed some “change champions” who then rolled out the process, and they audited the whole thing to make sure it was what they wanted.

Trouble was, the processes didn’t fit the work people did. For starters it was a “one process fits all” approach. Someone once likened it to “pouring quick drying cement on the rails of progress.” It wasn’t too long before the company saw software development as a problem, people were to be cut and work offshored. And they quietly dropped CMM along the way.

I think its also fair to ask if this is simply a break down in communication with the top of the company failing to communicate to the bottom, or whether, it is actually possible for those at the top to impose their strategy and vision on others by merely repeating the message. Perhaps, in order to be part of a vision one must play a role in formulating it.

It all reminds me Harold MacMillan, British Prime Minister 1957-1963. Once asked why his Government hadn’t achieved everything he set out to achieve he said

“Events dear boy, events”

Do you ever find your living out the examples in the books you read? I think I am…

Arie De Gues says:

“The fact is that the word strategy has tends to be misused. It should not be a noun; you should not ‘have’ a strategy, in the sense of a document which the organization follows. Rather, strategy should be a verb: strategy is something you do, rather than something you have.” The Living Company

(Now there is a lot I could say here about how this discussion of nouns and verb links up with Patterns but I’ll leave that for another day.)

Another strategy thinker, Henry Mintzberg, also rejects the idea that strategy is a plan. In the The Rise and Fall of Strategic Planning he made the case that strategy is not a plan you draw up and execute. He cited the case of the Canadian military, one study showed that they produced plans when they had nothing else to do. When they had something to do, like fight a war, they just got on and did it.

“the organization either planned or it acted; otherwise the two seemed unrelated. When the milirary has nothing to do, it planned, almost as an end in itself. …
But when the Canadian military did have something to do (such as fight in Korea), it threw its plans aside and acted.” The Rise and Fall of Strategic Planning

To my mind much of software design is like strategy. (And by design I’m talking about the internal architecture stuff). Having an architectural design is a something you might want to do when you have time but your design will always evolve. Who was it that said

“No plan survives contact with the enemy”

(A quick Google search offers von Moltke or Heinz Guderian.)

What is important for both business strategy and software architecture is that the whole team know the direction, the objective and are fully on board. The planning, the designing, only serves as a learning exercise, what is important is what you actually do.

In the “plan as noun” world you can’t really get this. So often a few chosen ones – maybe just one – devises a plan/architecture and presents it to the others and say “Here it is, all we have to do now is make it”.

Everyone can have their own copy, they may even get to “sign off” on it so they can be help accountable for building it but this method has a number of faults

• Arie De Geus points out: those who aren’t involved in creating the plan will take longer over actioning the plan
• Mintzberg points out that way doesn’t instil motivation, after all, your building someone else’s grand design not your own
• Mintzberg also points out there may be errors in the execution of the plan, of course, if your designers are good enough they will have anticipated these and allowed for them, they plan will be fool proof, or at least allow enough time to fix it
• Most of all the environment and requirements made on the plan change

So for me, I believe strategy and architecture are much more about discussion, I want to hear debate when I am planning. I want to use the whiteboard, I want everyone to join in at the whiteboard. When we produce something I want it to be shared by all. And I want everyone involved, those who will produce the product and those who will authorise it and allocate resources.

Maybe I’m sounding like a broken record, I’ve said much of this before in my essay “An alternative view of planning” but I’m drawn to these ideas again because of where I am right now.

As I said a couple of weeks ago my project is currently “stood down” – I won’t go into detail, enough to say I still have a job and a role but not a lot is happening on the project.

One of the things I’ve been asked to do is to “set a vision” and “create a strategy”. Thing is I’m a team of one, there is nobody to discuss this with, only myself. And instead of white boarding with many I’m going to PowerPoint the whole thing.

This is lonely and depressing. I end up running over the same old ground. In a couple of weeks I’m supposed to present (PowerPoint) something to some folks who’ll decide if we get to move the project forward.

The thing is: I’m like the Canadian army, I have nothing to do so I’m planning.

Are software architectures copies of the organizations that create them?

Often this is true but is it always true? And more importantly is it a good thing?

In 1968 Melvin Conway wrote a paper that discussed this topic. It has since been passed down as developer folk law that.

“If you have 4 developers writing a compiler you will get a 4 pass compiler”

Or,

“If you have 4 developers writing a GUI based system you will have 3 ways of doing anything (mouse, menu and shortcut key) – only 3 because someone has to manage the others.”

There is even a pattern by Coplien and Harrison (Organizational Patterns of Agile Software Development) of this name that describes the situation in more detail.

Trouble is, things are just more complicated than that.

What if your company is bought? What is the relationship between architecture and organization then? Or, if your development is outsourced? What if you are geographically separate? What if you adopt Extreme Programming?

And, have things changed since 1968?

In an attempt to understand the “law” and answer some of these questions Lise Hvatum and myself facilitated a focus group discussion at EuroPLoP 2005. The resulting write up from both of us is now online at on my website.

So what do I think about Conway’s Law?

Well, I don’t think Conway’s Law is a law, in that much I agree with Kevlin Henney, it really describes a force. And the name of the force is Homomorphism.

I believe Homomorphism is a strong force, I believe it is always present, I believe it was stronger in the 1960’s but it is still strong and most importantly it is self-reinforcing. I also think its the default architecture for most organizations.

I agree with Neil Harrison, in the ABC case study the organization changed from one structure to another and the architecture followed, they stayed within “Conways Law.”

The big question for me is:

• Which comes first: Organizational structure or Architecture?

Conway was right when he said that the design that occurs first is seldom the best. Question is: how do you create a better one when the existing one is self-reinforcing?

More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology – they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.

All too often technology companies respect those with technical skills and ignore the need for management skills, they reward those who are technical more than those with good management ability.

When I think of the really good technical people I know, myself included, sooner or later they all come to the point where they realise that to solve technical problems requires them to work outside of the technical domain.

Time fly’s, I still feel young but when I realised this morning that this time 10 years ago I was working on a project for Railtrack I felt a bit older. That project taught me a lot about how not to run a project, it also lead to a lot of thinking over the years.

In the mid-1990’s the British Government set about privatising the railway system. At the time British Rail owned and ran everything to do with trains in Britain. It was too big to privatise in one go and the Government wanted to bring about competition on the railways so it was broken up into many smaller pieces.

A set of Train Operating Companies (TOCs) where established to run the trains, and one company, Railtrack, was given the track to run. The BBC have plenty of stories on what happened to Railtrack, for example this one, but none of these talk about APLAN.

To bring about this vision Railtrack needed a new timetabling system, the old one kind of worked, it was a MSDOS based computer system (PROTIM) and lots of paper. This didn’t matter much because the timetable didn’t change much, just twice yearly increments. But for the new world of competition something much bolder was needed… and so project Access Plan, APLAN for short, was born.

By the time I joined the project in September 1995 it had failed once already and had been passed to a second software development company – Sema. At its height there where about 120 people on the project. The odd thing was that few of these where programmers: at most 12 C/C++ developers, 2-3 Visual Basic developers and 4-6 database DBA’s / SQL developers. The rest of the team was business analysis, testers (system and user acceptance), architects (who didn’t code and came from a COBOL background) and managers: lots of managers.

The project was priced on time and materials so there was money to be made. I was a contractor working on an hourly rate (6 days a week), there was my agent (adding 20-25% for themselves) and then Sema, with their own staff living in hotels and working on a T&M basis plus the a mark-up on the contractors. Railtrack was paying the bill but they where still owned by the Government so it was really the tax payer paying.

Just to make sure we all got the job done to a suitable standard we worked to ISO-9000. We had think process manuals and even thicker requirements, architecture, specification, functional specification and test plan documents. Unit testing happen religiously but it wasn’t automated. (This was the project where I realised that ISO 9000 was evil.)

The project was a “success” – it shipped code, Railtrack used the system to produce a new timetable.

The project was a “failure” – very early on the most ambitious ideas about train companies bidding to run trains had been dropped. Towards the end of “phase 1” even more features where dropped and much of the final timetable was produced on paper.

Trouble was: who was going to tell the Prime Minister the system was a failure? Sure everyone at the code-face knew things weren’t going to work like people envisaged, even the first line management knew that. But the message was watered down as it got passed up the chain. If the CEO of Railtrack or John Major knew the true extent of the problems the privatisation couldn’t happen.

And if it didn’t happen when it was scheduled to happen well… everyone knew that Tony Blair would be Prime Minster in a matter of months so it might not happen at all. So the project was a classic Death March.

“Phase 2” was cancelled before it even got started. Yet with the bulk of the system in place Railtrack had to continue to use it. I even rejoined the project two years later to develop parts of it – but that is another story.

Of all the lessons I learnt on this project two stand out.

Lesson 1: Inside every large project is a small one struggling to get out

This project created its own size, more people required more people. It was T&M so there was an incentive to add people. We could have lost 80% of the people and achieved an awful lot more than 20% of the work.

Yes, 20%, 30% or even 40% would not have been what the Government wanted but that leads to lesson 2.

Lesson 2: Some projects shouldn’t be done

I often asked myself: what would I do to fix the project? By the time I was on the project it was already too late.

I often asked myself: how would I have run the project? I knew a lot of techniques to improve things, and I know a lot more now, but I don’t know any that could make this project a true success. The only conclusion I can give is: the project should never have been done in the first place.

Some projects are too big, too complex, too ambitious, too time constrained that they should not be attempted. As a supplier you should not accept such projects.

Of course there will always be someone, somewhere, who given enough money will attempt it but these are actually the worst people to attempt such a project. If the customer will not listen to advice and does not realise what they are getting into it is their own problem.

No, if someone comes to you with such a project you should try to persuade them of a better way: extend the time allowed, break the project into chunks, reduce scope. Infact, this is more than just a “should” it is your duty!

But if at the end of the day you can’t persuade them to accept an alternative don’t do the project: you don’t need the money that much and your staff will thank you for not making them do the project.

In ten years a lot of things have changed: Neither Sema or Railtrack exist any more, I’m not a contract programmer any more, our business models where not sustainable. Unfortunately death march projects still occur.

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

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.