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.

Power of ideas Read More »

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.

What do Product Managers actually do? Read More »

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!

Encapsulate Context becomes Encapsulated Context. Read More »

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.

Skunkworks teams for innovation Read More »

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.

How do you do innovation? Read More »

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.

Why work? Read More »

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?

Productivity & IT – US trumps Europe Read More »

Learning and change again

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.

Learning and change again Read More »

Who owns the product?

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.

Who owns the product? Read More »

Terminal 5 is Lean

wMy local airport is Heathrow. Fortunately I’m not so close that I hear the planes so its mostly upside benefit, on a good day I can leave my place, get the tube to the airport, check-in (or what passes for check-in in these days of online and self-service checking) and through security in under and hour – not bad.

Anyway, I didn’t raise the subject of Heathrow to sing the praises of my house. The airport is in the middle of a major expansion with the construction of a fifth terminal – Terminal 5, this is due to increase the airports capacity by something close to 50%.

The project is massive, to give you some idea, the smaller of the two buildings is bigger than the existing Terminal 4, there are 13.5km of tunnels in the project and its going to cost about £4.2bn – or £4,200,000,000 – about $6.7bn.

For me there is something even more interesting about T5: the project is Lean. The team building the project have borrowed a lot of ideas and techniques from the lean production movement – also called Toyota Production System and best known for just-in-time production.

The owners of Heathrow are BAA (British Airports Authority as they used to be known) and they know Terminal 5 is risk, so risky it could sink the company. They also know their core-competence is running an airport. So, current management theory you would expect them to sub-contract this project to someone like Bechtel. But they didn’t, they took the attitude: this is so big a risk we have to manage it ourselves.

Because T5 is being built within the existing Heathrow perimeter space is at a premium. So stock is held offsite or brought direct from the supplier. There is only 24 hours of materials on site at any one time, if there is a delay it will be noticed quickly. Even if you had more space it might not be that useful, there is only one road in and out of the site.

When they came to raise the roof they took all the parts and sub-contractors to a large field and had a dry run. They then took it apart, took it to Heathrow and did it for real. now that’s real team building and training.

Then there is bonus payments: these are pooled, all sub-contractors share a bonus pool so there is an incentive to work together not waste time throw blame around. And if there is an unseen problem to solve, well that’s paid for out of the bonus pool too.

I could go one but I’ll leave you to read more yourself. There is a good piece in the Economist this week, and from last year’s Economist. Pieces crop up elsewhere, like the BBC’s In Business radio programme so keep your eyes and ears open.

What’s really interesting here is the way lean is breaking out of the production system. it came from car production, I know it in software and its gaining ground in the construction industry (check out Last Planner and the Lean Construction Institute.) For years people have pointed to the construction industry and said “they know how to plan and deliver” – thing is they don’t. How often is a construction project late and over budget? And unlike in software when you construction project goes wrong people get killed.

I used to think that the software industry took wrong turning somewhere about 1970. It decided to follow big Methodologies and project planning. I’m starting to wonder if the whole world took a wrong turn.

Terminal 5 is Lean Read More »

Verified by MonsterInsights