allan kelly

I’ve been absent from this blog for the last couple of weeks – small matter of getting married and taking a honeymoon in Thailand.  This was my first visit to Asia proper – I’ve been to Siberia which is geographically closer to Asia than Europe but culturally part of Europe – and I’ve a lot to reflect on.

For now the only say I liked Thailand, and specifically Bangkok.  I didn’t like the new Bangkok airport, Suvarnabhumi.  This is a monster airport, far too big.  It seems the airport has been built for one purpose: to build something big.  It is totally dehumanising, especially the unrelenting shopping mall once you get past check-in.

Now I’m back, recovering from jet lag and reflecting on another footnote to air-travel the Tupolev-144, the Russian Concorde, or Concondski is you prefer.  I’ve been interested in this airplane for a while – if you haven’t guess already airplanes bring out the little kid in me.  And on several occasions I’ve cited the TU-144 as an example how documentation fails to capture tacit knowledge.

Some years ago I saw a TV programme about the TU-144.  I can’t remember if I saw the Channel-4 Equinox version of the program in the UK or the PBS Nova version in the US.  Either way my main reference has been the online transcript of the PBS version.  According to this report, the Soviet Union had the blueprints to Concorde in the mid-1960’s and to some degree tried to copy Concorde with the TU-144.  This isn’t news, the world has debated this question since the TU-144 was first revealed in the mid-1960’s.  However, the program seemed to say the Soviets has far more information than was previously known.

I’ve often used this as an example of tacit knowledge, the story goes like this: the Soviet Union had the plans for Concorde but couldn’t build a copy because it lacked the tacit knowledge associated with the plans.  Some of that tacit knowledge was contained in what Ikujiro Nonaka calls the “Ba” or space in which the knowledge exists.

While I was in Thailand I had the time to read Howard Moon’s book Soviet SST that formed the basis of the Equinox/Nova TV programme.  Well, it turns out the whole thing is more complicated than it seemed and there are several insights I didn’t expect to get.

One insight I wasn’t expecting was about incremental development.  It turns out that most Soviet aircraft design was a process of incremental development.  Sometimes only a few copies of an airplanes would be built and many new airplanes were modifications of existing designs.  Whether other airplane designers follow the same route I don’t know. 

This approach worked well, it was certainly low risk at a time when a failed project was simply unacceptable.  However, the approach failed when it came to the TU-144 for two reasons.  Firstly, a supersonic passenger plane was a massive leap rather than an incremental development.  And the only precedents for the plane were military.

Secondly, the demands on civil aircraft reached new peaks in the 1960’s and 70’s.  It was no longer enough for a plane to fly and carry a few passengers, it had to fly them in comfort, interface to ground systems and do so economically.  The incremental approach couldn’t deliver the TU-144.  It wasn’t really an increment on anything that went before.

Broadly speaking I’m an advocate of incremental approaches to most things: software design, business development and so on.  However, incremental developments have their limits.

The second insight I gained was about prestige projects.  The TU-144 project should have been scrapped a lot sooner.  The American’s scrapped their supersonic airliner in the early 1970’s and probably the Anglo-French Concorde should have been scrapped too.  But Concorde and the TU-144 were seen as prestige projects for their respective countries.

My question is: how do you tell a prestige project that should be scrapped from a visionary product?  Or a big-hairy-audacious-goal? Or a revolutionary product that changes the paradigm?  (Or whatever management speak you prefer.)

Frequently in business literature we find stories of people creating products nobody thought they could, of going beyond the current status-quo, of defying the cynics and so on.  We don’t hear about the projects that fail, only those that succeed.

So, I would like to know: how do I know that an ambitious project is visionary we should back?  And when, should we recognise it as built on sand and rooted in prestige?

And so back to my story.  Does it still stand up?  Can I still use the example?  Well, yes and no.

The TU-144/Concorde example still works as a headline but once you get into depth it is not the best example there is.  In fact, it turns out there are two better examples, the B-29 and the DC-3.  In the 1930’s the Soviets licenses the rights to build DC-3 planes.  Still, it was found necessary change the design, for a start the US designs used feet and inches while the Soviets used centimetres and millimetres.  In the end over 3000 LI-2 planes were built to this design.

In the 1940’s three of B-29 bombers fell into Soviet hands and Stalin ordered Tupolev to copy them exactly.  Still, the design was changed and the result was the TU-4.  Even having the planes it was impossible to completely reverse engineer them.

In both cases some changes were forced on the Soviets, like the measurement system, or the fact that some components or materials were simply not available.  Other changes stemmed from operating conditions, like the fact that dirt landing strips remained in use in Russia far longer than in the West, so planes needed to be able to land in more difficult terrain.  Either way, the “Ba” surrounding the Soviet and American versions was different.

 So, lessons from the Tu-144

• Tacit knowledge and the environment knowledge exists in (Ba) are real and important.
• Incremental development exists in many different industries; it is useful to enhance learning and reduce risk but it has limitations.  Sometimes you need to move beyond incremental development and when you do you need to recognise this.
• Big prestige can be very damaging; we need understand when something is a prestige project and when a project is truly revolutionary

Interestingly, the Tupolev website lists a TU-444 project to build a supersonic business jet.  This looks a lot like an incremental development of the TU-160 bomber.  Similarly, the Sukhoi website lists a supersonic business jet  project without any information.

As a book Soviet SST could have done with a little more editing and some more effort to make it accessible, say, more diagrams, pictures, time lines and footnotes on airplane naming schemes.  As far as I can tell it is the only book (in English at least) written about the TU-144 which is a shame because it is a fascinating aircraft.  Perhaps some of the books on Concorde contain more information.

My guess is that the book was not a big seller, certainly it is out of print and I had to buy my copy second hand from the US.  Consequently I don’t expect there will every be a second edition.   This is to be lamented.  The book was written in 1989, before the fall of the Soviet Union.  Today it should be possible to conduct much more research into the project in Russia and access more documents and still speak to many of the people who worked on the project.

One of the things that fascinates me about Russian, or a at least Soviet, technology is that much of this technology was developed independently of similar technology in the West.  In effect two independent groups addressed the same problems, sometimes they came up with similar solutions and sometimes with different solutions, building on different knowledge stores.  Today we have one global knowledge store.  Communication channels, Internet and international mobility mean we are more likely to converge on the same solutions.

 

If you can get a copy of today’s FT do so, there is a full page on the Heathrow Terminal 5 project – you can read it online but you need a subscription.  I’ve written about T5 before, and in truth there is little new in the FT piece that hasn’t been reported elsewhere.  Still, it is good to have an update and know it is still on schedule to open at 4am on 30 March 2008.

The thing that makes T5 so interesting is the approach taken by BAA (the owners of Heathrow) to the project.  Rather than take the traditional construction approach of asking “Who can do this cheapest?”  and load the contract with penalty clauses for the sub-contractor BAA has taken the approach that it needs the terminal to open on time so it has assumed responsibility for the risk and is managing it with innovative contracts.

One of the consequences is that BAA has adopted a number of techniques from the Lean production world.  Consequently the project is on time, on schedule and has a superior safety record than most construction projects.

What is especially striking is when you look a few miles up the road: 20 minutes from my house in one direction and I can be at Heathrow in South West London;  20 minutes in a different direction and I’m at Wembley stadium in North West London.  This project is nothing short of a scheduling disaster.

The British football association (who owned the old Wembley and commissioned the new one) took the traditional approach.  They sub-contracted the whole project to an Australian company called Multiplex – who, I believe, have a reputation for suing people.  This project is over budget, late, getting later and drove Multiplex to the edge of bankruptcy.

Of course the FA are OK, they signed a fixed price deal so what does it matter to them?  Well, it does matter, they don’t have a stadium yet and it was a stadium they wanted not financial compensation.  Wembley has been plagued by missed milestones, strikes, sub contractor problems and everything else we’ve come to expect from big construction projects.

Some people, like the former Government Minister David Mellor, seem to think this is quite reasonable:

The former chairman of the government’s football task force, David Mellor, agreed, saying: “It’s late, but tell me a building project that isn’t late.  This is a major project, and I just think that the fact that it may be a few weeks late finishing, in the great order of things… doesn’t matter tuppence.” (BBC, 21 February 2006)

Well, Wembley is more than a few weeks late now.  Its currently about a year late and has yet to open.  I don’t know is David Mellor has commented on Wembley more recently, or if he is aware of T5 but I’d really like know if he stands by his comment.

So, why make this contrast in a blog that is normally about software?

As I said before, T5 is built on risk sharing and lean principles, that does matter.  Terminal 5 shows that large engineering projects can be undertaken using these techniques and that they work.  And more importantly it shows that these principles transfer from car building to other areas.

 

Do you ever find out about something and ask yourself “How didn’t I know about that before?” For the last week or so I’ve been reading about the theory and practise of Appreciate Inquiry. It makes a lot of sense to me and I can see myself applying it. In fact, it makes so much sense it seems to underpin a lot of what I’ve been believing for the last few years, so I’m asking myself: how did I pick this up without knowing the name of it?

Actually the idea of Appreciative Inquiry (AI for short) is quite simple: appreciate what is good, inquire into what is good, and harness the positive energy for change.

This is diametrically opposed to many ideas of change that start from the assumption: something is wrong, something has failed or something is a problem, therefore, we must use this failure to fix the problem.

The problem with the problem approach is simple: it is a mind trap, you start looking for problems, you get negative, you focus on what is wrong. Your language becomes full of negative things – “Sales were down”, “Software was buggy”, “Delivery was late” – you loose sight of the miracle that you just shipped a 1,000,000 application, or you sold $1m of product. And when you become negative you mindset becomes negative. And when people become negative they become defensive, change actually becomes more difficult.

So AI takes the other approach: look what is good here, what did we do well? What should we do more of? And with your positive mindset you’ll look for opportunities to improve. According to the stories I’ve been reading (and yes, AI does seem to overlap with story telling) once you get the positive mindset you unleash lots of energy.

I suspect one problem with the AI approach is when you have create a sense or urgency or explain the need for change in a 5 minute PowerPoint to senior management it is always quicker and easier to cry wolf than it is to paint a picture of the new Nirvana.

Now, what about learning? Regular readers will know my proposition that Change <=> Learning. Well, the good news it that this is entirely compatible. We learn best when we want to learn, when we are enthused and focused on learning something – anyone else ever done more education than the law demanded? – If we are positive, and have plenty of energy then learning is going to be easier. If we are learning because we are enjoying ourselves then we learn more and better.

The problem tends to come when we can’t follow through on our learning; we learn how to create better software but we can’t do it (we can’t change our processes) and we get frustrated and negative. We criticize others and see failure and problems.

Before I answered the question I set at the beginning let me give you some references – this thing is worth knowing more about!

The original AI paper is by Cooperrider and Srivastva . Its pretty heavy going, very academic, mainly talks about Action Research (another fascinating topic) and contrast Logical Empiricism with Socio-rationalists. Its heavy but good, I’ve got a few other good ideas from here.

If you want something shorter try this short piece on the Harvard website. Bushe has a good piece on AI with teams here and more stuff here that I’ve not looked at yet.

Finally, for references, I read this piece by about AI at GTE. If your scratching your head saying “I kind of remember GTE” so was I, this is the old name for Verizon. Actually, a bit of Googling on appreciative inquiry and GTE brings quite a few references so may be a well researched case.

The website http://appreciativeinquiry.case.edu has a lot more too.

So, to return to my earlier question: how have I missed appreciative inquiry?

Well, on the one hand I haven’t missed it. I found a brief note in my MBA lecture notes about it and a note to myself “Read more about this”. So, I was aware of it four years ago.

Second, I think many of the authors I’ve been reading in the past couple of years had a similar philosophical bent to Cooperrider and Srivastva so, even if they hadn’t be directly exposed to appreciative inquiry, they were leaning towards these theories and I’ve picked some of it up from them.

And third, and this is the big one: I think I’ve had some of my AI bent washed from me in the last year to 18 months. Ever since I became a Product Manager people have been asking me to “Identify the problem you are trying to solve” add to this my own emphasis on some Lean/Agile techniques which ask you to “Fix the biggest problem first” then “do it again”.

So, I think I’ve become Problem Focused. This has had two effects: first it has subjected me to the “we have a problem” approach, I’ve been caught up in the language and thinking of problems and this has had a negative effect on me and my own thinking. Second, the problem approach has hidden my AI bent.

When I think back I didn’t convert my employers to Agile Software Development because we had a problem, I converted them because I saw an opportunity. What’s wrong with that? The developers who bought into the ideas of Agile and Lean did not do so because they were trying to fix a problem, they did it because it seemed like a good idea.

Long live the Opportunity! Appreciate the good! To hell with problems!

One of the reoccurring themes in my work is the need for those who are involved with a problem to find their own solution and to implement that solution. I can get quite passionate about the need for action and the demotivating effects of having someone else work out the solution and simple pass it on for you to execute.

Still there may be occasions were an outsider’s view can be helpful. I’m sure we’ve all been in situation were we are powerless to effect a decision, it could be events in our office, our company’s strategy, or Government policy, perhaps its a football team selection. What is obvious to us, and often obvious to our drinking partners too, somehow isn’t obvious to those charged with making the decisions: our manager, the prime minister, the team manager. Why is the obvious not so obvious?

One reason might simply be that we (who think we see an obvious answer) lack information. Sure doing X is obvious, and sure the people in charge have considered it but doing X will effect Y. That Y exists and is a potential problem might not be common knowledge, or it could be something that we are simply ignorant of.

This explanation also works in reverse, particular were knowledge is needed. For example, as someone with lots of experience in IT I have a lot of knowledge, this allows me to see obvious solutions to many IT problems. So, its obvious to me that bid Government IT projects will go wrong but that never seems clear to those who authorise them.

A second reason is that what we consider obvious simply isn’t obvious to those making the decision. Perhaps they see a lot of related issues so can’t see the wood for the trees; perhaps they have some personal stake that makes it hard for them to do X; or perhaps it simply isn’t obvious. In such cases it can be possible to be too close to the problem.

I noticed this the other week. I was having problems sorting out some problems of my own when a friend called looking for advice for her problems. After hearing her problems I made some suggestions, the solutions seemed straight forward, at the end of the conversation she said something like “Yes, they are good ideas I’ll try them.” While I was able to solve someone else’s problems I couldn’t solve my own.

So, sometimes you can’t solve your own problems even when there is an “obvious” solution. You need help to see the problem. How can we reconcile this with my opening point about the need for people to find their own solutions and act on them? Well, I think the trick is two fold: first know when you need an outsiders opinion, and two, if you are that outsider, try and give the solution in such a way that the person asking takes the solution as their own.

In his book The Living Company Arie de Geus suggests the role of planning, particularly scenario planning, is to create memories of the future. By under taking the planning exercise we conceive of how the world may look different, we prepare our brains for a future that is not simply a repeat of tomorrow. The actual plan isn’t so important, the important thing is we’ve imagined and visited a world that is different.

This last weekend’s FT has an interesting piece on the increasing world urbanisation, particularly in India and China – here is the link. What caught my eye was mention of China’s museums of the future. This is the second time I’ve heard of these museums which display the designs and plans for the cities China is building and extending.

Future museums strike me as a great way to create future memories. The idea that I can go and see how things may, or should, be in the future is brilliant. Perhaps they even have people on hand so I can ask questions of. Of course I don’t now if the Chinese planners are explicitly trying to create future memories or if they have read Arie de Geus but that’s not really the point.

When people are faced with change, whether is be new buildings, a new environment, or a changed work environment, maybe new processes they are naturally inquisitive. If their questions can’t be answered they start to hypothesis and make things up – they create their own future memories. Since they don’t know their hypothesises are right they have doubt. Doubt about the future, and some possibly negative hypothesis creates fear.

Now your change efforts are facing an up hill battle, fear and doubt have entered the scene and different people have different ideas about what the future should look like, so, when the future does arrive they respond to it differently rather than consistently.

Creating future memories is one way to overcome these problems. Future memories can help remove the doubt, uncertainty, fear and help build a shared understanding of what the future will look like and how we should act when it arrives.

So far I know of several ways of creating future memories:

• Shared planning, specifically scenario planning – hence why I don’t like planners being a separate cadre
• Future museums, like in China
• Process miniatures, like the XP Game, these allow people to rehearse a future process in a small way.

A think the right sort of training can also help if it is interactive and allows people to rehearse future events. I’ll leave this hanging as I don’t know the magic ingredients for such training.

At the risk of sounding paradoxical I think one area were future memories might be able to help is with project retrospectives. I’m a big fan of these, I think they make sense and can really help your project teams learn and improve.

However, one of the problems I hear about with retrospectives is that teams undertaken them but then don’t follow through on their results. For example, during the retrospective the team identifies a problem and suggest a solution, everyone in the room agrees to do it. But outside the room, the next day, nothing actually changes. The team carries on as before.

I wonder if, after the retrospective, after identifying problems and solutions the team can somehow create a future memory of itself doing this. Maybe the team could build a model of the change, or maybe role-play the change. The idea would be to have team members understand and practice the change to remove doubt, uncertainty and misunderstandings.

Perhaps we need to pair retrospectives with future-spectives.

I’ve been using PDAs for about 12 years now, I started on a Psion 3a, then a 3c, then I moved to a Series 5, didn’t like that and moved back to a 3mx and finished on a Revo. As you can tell I love the things, the 3mx is still my favorite PDA but it was obvious at the time that it needed to move forward. The Revo should have been that move but it had two flaws: a poor case design and persistent battery problems.

In the end Psion got out of the market. Another British IT company that couldn’t crack the US market (the US OEM deal was too little too late) and consequently couldn’t compete worldwide. The company still survives and through Symbian the software is competing worldwide on phones not PDAs.

Anyway, I still like PDAs and I can’t imagine life without them. So, four years ago, when it became clear what was happening to Psion I jumped to Palm. The hardware was good but the software lacked functionality, still, it was a good product and I used it. However, it never quite merged into my life the way the Psion did – this may well have been changes to my lifestyle.

A couple of months ago I came to the conclusion I needed to do something about my aging Palm – the case was cracking. So I looked at the Palm website and go hooked on the idea of a LifeDrive.

I’ve had it over a month now and I have to say I’m disappointed with it.

In theory the LifeDrive is a great idea. Its a Palm PDA, and its an iPod (4Gb hard disk), its a voice recorder and a portable web terminal (Wifi and Bluetooth onboard). Sure it does all these things, but it doesn’t do anything really well. The PDA software (diary, address book, etc.) hasn’t really moved forward in 4 years; the music software is difficult to use and only seems to want to play 3 tunes before you have to do something; the voice record isn’t a patch on my Sony SX-56 and the Wifi takes for every to get a connection – and half the time tries to connect the wrong network.

So I’m disappointed with the LifeDrive. I probably should have done more research and maybe I should have jumped ship to a Microsoft based product.

But there is a bigger question: just what is Palm playing at?

Failing to move your software forward and poor products are not a route to success. Then I read that they have product delays coming up.

This goes back to their decision to split hardware (Palm) from (Palm Source) software and concentrate on the hardware. Which actually sounds like the Handspring strategy from a few years back. Remember Handspring? The Palm spin off that produced PDA’s using Palm OS. In fact, one could say that Palm has become Handspring. (Maybe not surprising as Palm actually bought Handspring about 4 years ago.)

In the early days of PDAs – and I should know, I was a summer intern at Distributed Information Processing, DIP, the guys who developed the Atari Portfolio – it made sense for hardware and software to be together because they evolved together. So we had the Apple Newton, Psion, Palm, DIP, Poqet and so on who produced hardware and software.

When the market matured it made sense to split, and specifically get out of hardware. So Psion spun out Symbian, Palm created PalmSource and HP, Dell and everyone else started using Microsoft Windows CE/Pocket/whatever. Nothing really surprising there, the same pattern happened with microcomputers (i.e. the machines before PCs) were we had TRS-80, Sinclair’s, etc. etc. each of which had its own software for its own hardware. And the same pattern is playing out in phones as manufactures increasingly use standard platforms from Symbian, Microsoft, Nokia and others.

(It is interesting to think of other devices were this split could happen next. Already there are signs of it happening in the TV and set-top box market, what about cars? There is a lot of software in them these days, or kitchen appliances?)

(And Apple are the exception, they never split hardware and software. Arguably they should have done and some reports say they may still have some kind of play lined up.)

Palm have done well to survive this long but don’t think they’ve got much of a future. They are a small hardware player in a large market, they can’t innovate (or even update) through software and their products seem to lack focus. They’ve done well to survive this long but I don’t think they can continue.

People tell me that PDAs are a bad sector to be in. The convergence of phone and PDA will leave one winner: the phone. But, having used PDAs and phones for so long I think there will always be a niche for PDAs that do things phones don’t, or are unsuitable for – like running my wine database. Unfortunately I’ve not seen a PDA product that is suitable. Maybe this is just me, maybe I’m in a minority of one.

I originally read Thinking Beyond Lean (1998) over four years ago, it was good at the time and its still good. A few weeks ago I picked up the book to check something and decided it was worth a re-read. Four years ago I didn’t know as much as I do now about lean production and lean product development so I thought it would be worth another look.

The book is a study of how car companies develop their products, and specifically, how they reuse the designs to product additional products, e.g. the Ford Mondeo in Europe is the Ford Contura in America and a Jaguar something in both places. Of course, as you might guess from the title Toyota is the pace setter in this field as in so much else.

I did write about the book after my first reading and still agree with what I said then, there is good advice here we can apply to software development.

The book is interesting for two reasons. First it is an interesting insight into product development at some very companies. Second it looks at the subject of reuse in a context of multi-project management.

Make no mistake, the car industry has problems reusing its designs. Reuse is difficult. The overriding lesson is: reuse doesn’t just happen, you have to arrange for it to happen.

Cusumano and Nokeoka do identify four models of reuse, or rather four models of design, three of which are reuse and I think its worth naming them here:

• New build: design something new from the start, even if you could reuse something there are good reasons why you might do this.
• Concurrent: two or more projects running concurrently developing new products, usually one is the lead project
• Sequential: design something new, leave it alone for a while then try to reuse it for a new product.
• Design modification: design something new, leave it alone for a bit then come back and tweak the design for a new version.

Four years ago I thought these models were useful in describing software development and I still do. However, the software industry doesn’t think like that. We have four models of our own:

• Framework: we create a project that has no objective but to create a platform for others to reuse. Usually these projects are expensive and often they fail.
• Reuse will just happen: made famous by the OO movement, the idea is that if programmers write “objects” (later components, now SOA components) then somehow they will be usable by others.
• Cut-and-paste: probably the most widely used; our own version of design modification.
• Packaged: we buy something someone else has written and work with it through an API.

I think only the last of these can really be claim to be a success.

There are lots of reasons why a reuse attempt can fail but mostly they boil down to organization. So, to make reuse happen you need to get the organization right – we’re back to Conway’s Law!

But there are other reasons, e.g. accounting. If project B is six months behind A and reuses their designs then who pays the bill, A or B?

And reuse may not always be a good thing. If you are competing on innovation then continually reusing your existing products may stop you creating innovations. It may also stop you from producing distinctive products – one of the problems Volkswagen had when it got very aggressive about platform sharing.

Yet another problem, not mentioned in the book, is your product life cycle: if all your products use they same platform then they will all age at the same pace and will all need replacing at the same time. So, just when your cash flow is low (because all your products are old) you will need to spend a lot replacing them.

I think the main difference in reading the book four years ago and today is my own scepticism about reuse. Four years ago I still believed we in the software industry could do it, all we needed was the right approach. Now I’m not sure. I think the level of complexity in software is so great trying to product something for reuse isn’t worth the effort in most cases.

That said, if the software industry is to make any headway here we need to take on the issues and lessons described in Thinking Beyond Lean .

Shortly after taking over IBM Lou Gerstner famously said “The last thing this company needs is a vision.” In an era when businesses men often seem to compete with each other for “vision” this was a brave thing to say – particularly for a technical company. I’ve been thinking about that comment for the last week.

Some years ago I was a developer at a small software company in South London. A few months after I joined they hired a Software Development Manager and charged him with sorting out developement. One of the games I’ve played with myself over the years since then is to ask myself: “In his position what would I do?” – in other words, what would my vision, my strategy be.

Last week two people I know were in the position of taking over a existing group, and my advice to them, well, the last thing you need for your new team is a vision. Sure you need your own strategy for taking over the team but beyond that I don’t think you should have a strategy.

I’d better explain myself…

If I come in with a fully formed vision for my new team, particularly if I spell it out in PowerPoint slides then it is my vision. This might be great if I’m trying to persuade investors to put money into my company, or trying to find like minded people to join me on the quest but when the people are in place it does nothing to get their buy in or address the real problem.

When you take over an existing team there are existing problems, organizational issues and a lot of history. If you come in with a vision you don’t take any of these into account. Sure, being new is a great position to be in, you have a fresh pair of eyes, you can see what others can’t because your not mired in the thick of it. But, your going to need these people to deliver something.

So, you walk into your new team, give them your PowerPoint, and talk them through what you are going to do. Your communicating your vision, your strategy, not theirs. Your task, as you have defined it, is to get your people to execute your strategy. You have to explain the strategy, they will interpret it, they may not have exactly the same interpretation as you, will you ask them to play it back? Or will you assume they got it? And if they don’t quite get it? Will you explain it again, and again until they do, or will you listen to their comments and change?

And once they do understand it your going to have to ensure they do it. You now have a policing action on your hands – make sure they do what you want. (Fortunately management have tool for this, its called MBO – Management By Objective.)

So I don’t think this is a good idea. I do have an alternative, I’ll outline it here, I’ve done most of it although, to be honest, I’ve never done it in the kind of systematic way I’m laying it out here – but then I’ve never laid it out like this before.

First don’t do anything. Listen, watch, learn. Look around you. See what people are doing, specifically see what your team are doing.

Second, expand this into a longer investigation phase. Talk to the team, talk to them one-on-one, talk to their customers, their suppliers and any other interested stakeholders. Find what all these people think of the team, what they should be doing, what they are doing, and how they are performing.

Do you observations for a while, at least a month but maybe as long as three months.

Next get the team together. Find out what they problems they see collectively. Find out what they see as their overall goal. Now this could be tricky, hopefully what they are doing and what they think they are doing matches up with what the other stakeholders think. If they don’t your going to have to correct that, but I think in the broadest sense there will be something everyone can agree on.

Now work back. Get the team to collectively agree on what they should be doing to solve the problems. Don’t tackle all the problems, if possible throw some of them away, i.e. just don’t do them if you don’t have to. Remember people can only focus on so many things so don’t pick too many.

Once the group is in agreement it will probably help to work with everyone one-on-one to find out how they see the team, the aims and their responsibilities.

At no stage should you attempt to tell them a vision or a strategy. Let them work it out. These are bright people – if they aren’t why are they working for you? They are going to be far more motivated when they create the strategy and vision then when you tell them it.

Don’t worry that what they come up with isn’t what you expected, what others want or were the company is heading. You can correct this over time if you find a problem, the trick is to expose your team to the wider picture, make them aware of what the corporate strategy is, give them examples of were it is working and then help your team work back to change what they do.

I honestly believe that when bright people know where everyone is heading and are allowed to work things out for themselves they will a) get it right, b) be very motivated to do it, c) you’ll get a better answer because you used more brains and got collective action.

This may mean eating some humble pie and you don’t get to play with PowerPoint. The point is: it is not your ideas that are important, it is the team’s ideas. It is not important for you to have a big idea, it is important for you to help the team, and the people in it have big ideas.

Do it right and you will get a strategy and vision, and it will be a truely shared vision.

Talking About Machines is a book I have been wanting to read for some time. It is a study carried out by Julian E. Orr of photocopier service technicians – early 1980’s I think. That might not sound very exciting but the findings are. Basically, Orr discovered that what is important is what the engineers do on the job, not what their managers think they do. Classroom training is OK but you really learn what to do on the job, a lot of it verbally from your immediate team – and this team is more important than the corporation.

If that sounds obvious then maybe it is, but why do we so often ignore it?

Anyway, I’ve been wanting to read this book because references to it keep cropping up. I think I first heard of it reading some of John Seely Brown’s papers – most likely Organizational Learning and Communities-of-Practice but I can’t be sure. (If you haven’t read that paper then do so, if free at that URL so you have no excuse.)

So, a sense of interest and duty lead me to this book. True, it is significant, it is important but… well, it is also somewhat long winded. Still it pulls some important truths about the nature of modern work.

For example: we think of technicians as people who show up, look at the fault, fix the fault. We believe they just do it. In truth it there is a lot more to it than that. For a start, the same technicians have to deal with users of the machine, the social setting of the machine and the inaccuracy of the information the machine gives them.

OK, here’s the truth. I read the first few chapters and the last chapters, I skimmed or missed the ones in-between. As I read it I increasingly felt I was learning little new to add to what I had read in the references to it. Perhaps if I had read more I would have found more new stuff.

Two bits do stand out.

Early on Orr notes that while we may study a problem, we may even train for a problem when faced with it we may fail to recognise it. This rings true, how many case studies did I read in business school were the problem was obvious? Why didn’t the (far more experienced) people in the case study spot the problem and the solution? Why they didn’t notice it was a problem they already knew?

Perhaps you don’t spot the problem because at the time you don’t have all the information you need. Perhaps you don’t spot it because you arr too close to it, or too remote from it. Perhaps you don’t spot it because, well there are any number of reasons. This idea has got me thinking, how many problems I face now are ones I’d know the solution to if they were presented as a case study?

Second, toward the end Orr says:

“The management of the corporation … has pursued a strategy of de-skilling through the use of directive documentation. This does not actually deprive the workers of the skills they have, however; it merely reduced the amount of information given to them.”

I run across de-skilling regularly, so many company strategies, products or procedures are aimed at de-skilling people, but do they really de-skill? Or are management fooling themselves? Most likely they just shuffle the skills a little.

So many software tools are aimed at deskilling a job, yet how often are we repeating the mistake Orr describes? Rather than invest in tools perhaps we should be investing in people, rather than “de-skilling” them we should be re-skilling them. All too often managers are prepared to invest in a tool but not in training.

(And what of the tool makers? A complicated job may result in a complicated tool, people end up needing training on the tool. Tool makers need to ensure people get this training to use the tool effectively and demonstrate the value to the purchaser. But, if what you learn in the classroom isn’t much use, how are we to train these people?)

Summary then:

Orr’s book is worthy read and has some interesting insights. I’m sorry I couldn’t read it all but it was just too slow. Maybe I’ll come back and cherry pick the remaining chapters – umm… I’ve said that about books before, it rarely happens!

The book shows us that technical work is much about the social environment, learning doesn’t happen the way we like to think it does, and strategies that sound good don’t always work they way we thinkg.