allan kelly

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!

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.

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.

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.

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.

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?

I’m still in the back of the Airbus but I want to write about a different subject now so its time to start a new entry, Back in April I ran a session at the ACCU conference about learning in software development. If you know me you know that I’m passionate about both these subjects. Indeed, I wrote my MBA dissertation on exactly this subject – Software Development as Organizational Learning.

Well my conference life is quote different from my work life and I don’t tend to present this material in work. However I did last Friday.

I founded and run my company TechTalk programme. This is an hour slot on a Friday afternoon where somebody – usually from inside the company but sometimes a guest – talks about something relevant to what we do. Usually it has a technical focus but I’m also keen to include marketing, strategy, customers, etc.

I prefer not to schedule myself as a speaker because I don’t want it to be seen as “Allan’s TechTalks” – I organize it for and of the company, I want the rest of the company to be involved. But after a little reluctance I was persuaded I should do something.

The talk itself was slight abridged from ACCU but took the same form. 20 minutes of slides and ideas on learning then open it to the floor and see get the audience to contribute ideas.

I could have talked for longer but I believe that learning is best when it comes from within. Rather than me lecture the audience with my ideas I wanted them to make suggestions themselves. That way I hope more of them will take root.

I haven’t had a chance to compare Friday’s results with those from the ACCU conference but it felt there where more specific ideas about how we learn in the company and how we can improve it.

The killer question for me came after the talk when someone asked “What next? What do we do with this?” I wish I had a good answer to this but again, I don’t own this. The people in the room own it. I can’t force them to do any of the things we suggested I can only hope that some of them will try.

In that way it was a bit of “throwing mud at the wall” – we suggest some ideas and see which stick. Where someone shows an interest in taking up an idea I’ll help if I can but I can’t force anyone – its change you see.

One thing that came out more clearly this time that didn’t last was the barriers to learning. I think we can do a lot to improve our learning by just removing barriers.

And the biggest barrier? Well, I’m sorry to say it is ourselves. Too often we start with the assumption: “I can change this” – “I need a manager to change this” so we don’t change and we don’t learn.

Now, I’ve spent some time reading management literature, and I’ve talked a lot to actual managers. The biggest problem they seem to see – at least in my office – is: getting people try new things, invent new ideas, take ownership of something.

So, I think, to change the world we change ourselves, we try and do something new.

This is a thought that goes around and around my head, I see it again and again, Amazon is a great example, so is Google, but its not only in the web world, it applies to TV (CNN), Zara/Inditex in retailing and elsewhere – the potato peeler was the last example I spotted.

(Although I should admit, I gave up peeling potatoes some years ago: it takes a lot of effort, you are removing a layer with a lot of flavour and vitamins and your going to boil the things anyway so there can hardly be any germs there – but I digress!)

Sometime when you change something – even just in one dimension – you turn it into something else. Take Amazon for example: was it something new in shopping?

(I’m taking Amazon because its an example everyone knows and they do their job pretty well, similar points could be made about most online retailers.)

Or, was Amazon simply the catalogue-shopping model transferred to the Internet?

Remember those big old catalogues? My Mum used to borrow them from my aunts, Littlewoods and GUS – I’m sure other countries have their own equivalents. Really, Amazon didn’t go anything these companies weren’t doing already but by putting it online it enhanced one aspect of the system – items stocked:

• the range of stock increased massively – first in books then in other things
• stock was changed more frequently, a new item can be added to the system and available for people to see in a day or two; the catalogue printing and distribution system meant stock items had to be decided months in advance

Everything else Amazon did was secondary to this change – things like wish lists came later – while things like the associate programme where just electronic versions of the old system – I recommend books as an Amazon associate the same way my aunt would lend my Mum the catalogue. And in doing all this Amazon made the whole system so much easier.

At some point Amazon ceased to be an online version of Littlewoods and become something of its own.

The same is true of CNN – news was always on TV, now its on constantly, after a while it becomes something itself, part of the fabric of life.

And the potato peeler? – Well its just a knife that has been specialised.

This happens inside companies too. I once worked on software to model the electricity supply in England. At first the model took about 24 hours to run, the Analysts thought carefully about each run and each one was an event. We speeded the application up, by the time I left it was down to 3-4 hours. The analysts changed the way they worked, they could try out more “what if scenarios”, if a run didn’t look good then junk it and move on, and you saved time in preparing for the run too because you could afford to do another one if you made a mistake.

The trick with all of this is to push hard on one dimension, when you change that one dimension everything else changes. The difficult bit is knowing where to push.

I’ve mentioned a few times that I’ve recently moved from software development to product management. Consequently I’m getting a different view of the development process. And of course, I have to deal with developers who never seem to do quite what I had in mind or when I had it in mind!

Before you ask I’ll admit it, my project is not running Agile/Lean. Why not? Because a) it was running when I got involved, b) its a “small” project – small in the sense of number of people involved. Why does small matter I hear you say?

Well, many of the process advocated by Agile are for social interaction, and they require social interaction – no point in having a stand up meeting with 2 people, or trying to pair programme if most days there is only one person.

Would I like it to run Agile? Yes

How would I change it? Difficult this one, probably, placed in the position of my managers I would never have started this project. The way I view projects is like this: if they are worth doing they are worth committing lots of resources to, if they are not worth committing the resources then they are not worth starting.

Put it another way: no side bets, no micro projects.

But I didn’t want to write about project management here. I wanted to ask: who ones the project?

As a developer the answer was clear: me – not the product manager.

As a product manager the answer is also clear: me – not the software developers.

Ownership is important. When you feel you own something you work harder, you take a higher pride in your work. I’ve been feeling this problem for a few weeks but my thoughts coincided with comments from the economist John Kay in Tuesday’s FT.

So often I’ve worked at companies where the product manager role was under developed or non-existent – that is a blog entry in its own right. In these cases as a developer I’ve stepped forward into the gap and tried to fill it. Tried to direct the product, I tried to create a “roadmap”, to care about the product, make it improve.

Its a matter of pride in your work. And I see this in other developers too, even if they aren’t trying to direct the product they want it to succeed – you don’t think people enjoy working on failed projects do you?

Now I’m a PM, I’m not developing code but I am trying to think about the product strategy, I’m talking to sales guys about what they need, I’m talking to customers about how they use it, I’m trying to make sense of all this and balance the demands for features, bug fixes, improved usability and the rest. I’m not coding it but I feel I own the product.

Part of this goes back to my question of identity. I still see myself as a developer, I feel I should be coding, I feel the developer owns the product but now, well, what right have I to have these feelings of ownership?

Multiple owners may make for competing ideas and demands but it is better than having no owners. I’ve seen code that isn’t owned by anyone, it deteriorates; I’ve seen products that aren’t owned they tend to die. Ownership is important, and somehow I need to find a way of balancing the needs of the multiple owners.