“Changing your organization” - ACCU conference 19-22 April, Oxford

Don’t think I’ve mentioned this before - but apologies if I have! I’ll be at the ACCU conference in Oxford next month (19-22 April). I’ll be presenting a session entitled “Changing your organization” - although I expect to get roped into a couple of other things.

The presentation has been written for a while, well a draft has, I find that if I revise it just before the conference its fresh to me and fresh in my mind. In fact, it was putting this presentation together that sparked me thinking about revisiting my book project.

After my previous blog entry I came to the conclusion that its easier to write a book before you start a business than after it so that’s the logical order to do it. Still don’t know if I’ll ever actually start a business but just in case I do!

When I looked again at the ideas I had I found there was more material than I thought. I’m tending towards entitling it “Knowledge, Learning and Change in Software Development” - a grand title but it sums up what I’m interested in.

As I said before the book would need to solve a problem. The problem I think I’m solving - and its not completely clear in my mind - is “How should we understand software development in the twenty first century?” Still not clear who the audience is, and I’ve no idea if I can get a publisher interested yet.

So, now I’m busy at work again, and now I have an project for home my energies are directed - it feels good! - and I’ve a little less time for blogging, which is no bad thing itself.

Write a book or start a company? - Lessons for Product Managers and notes on VoIP, eBay and Skype

Some kind of normality has returned. The house move is done - although plenty to do on the new place we can live here quite normally. And my product at work is back to normal, actually that happened about a month ago but I don’t think I mentioned it here.

So, with a kind of normality returning I’m asking myself “what next?” I’m lacking a personal project now and I’m wondering what it should be. Two ideas keep coming up.

First idea is to write a book. A couple of years ago I started to outline a book that would piece together some of my Overload pieces with some of my MBA dissertation work to produce a book called something like “Re-learning software development” or “Knowledge, Learning and Change in Software Development” or even “Software Development in the 21st Century”

I started to put some flesh on the idea and even had a conversation with a publisher. She asked me the very product manager-like question “Why would someone buy this book?” “What problem will it solve?” I was kind of stuck for an answer, I could imagine a neat book but then why would someone actually buy it? I couldn’t answer that question and I eventually put the idea to one side.

The other idea that comes up again and again is that of starting a company. Being entrepreneurial. Again the question comes “Why would someone buy something from you company?” which is another way of saying “What would your company do?”

As a Product Manager I know the first starting point has to be “What problem will you solve?” All I have to do is think of a problem, an answer, and a means of putting the two together... easy really.

Of course my techie background has me approach it from another point of view “Gee, this is neat technology I could... maybe someone will pay money for it?”

At the moment there are two technologies out there that should inspire me. One is AJAX - which a key building block of Web 2.0. I see people building all sorts of stuff with AJAX but you still need to solve a problem.

Some people are resolving known problems with existing solutions. For example: office automation applications (Word, Excel, PowerPoint, etc.) This could work but you have to ask: Why will a Web 2.0 word processor be better than what is there at the moment? And given economic network-effects: Why would anyone change from the standard?

The second technology I see as big just now has a similar problem: Voice over IP. We have solved the voice communication problem, its called the telephone. Has been solved for about a hundred years, again there are network-effect economics to keep people with the traditional system yet you can cross link the two systems.

I’ve been thinking a lot about VoIP lately. Partly that is because I was reading Richard Edge’s blog and secondly because of a conversation I had with Craig Taverner a couple of weeks ago.

So far the big problem VoIP has solved is cost. It brings the price of telephone calls down. This is another point Product Manager should remember: its OK to solve a problem that has already been solved just so long as you change the solution in a superior way.

However, VoIP currently comes with another cost: inconvenience. Unless you have a PC, a broadband connection and a little bit of computer skills you can’t get it to work. Even if you do get it working to save the maximum amount of money you need the person on the other end to have a PC too. And then the two of you have to stay close to your PC.

Well, VoIP is going to get better still. Already there are routers that allow you to plug in regular handsets to the network. Like this one from LinkSys and Netgear are promising a phone that is loaded with Skype and talks to your Wifi router.

These kind of products will reduce the inconvenience of VoIP but I’m still wondering if that is enough.

The way I see it is that VoIP needs to offer something, some application, that we can’t do with regular phones. For example, although I’d played a little with Skype the thing that got me to use it a lot was the conference call facility.

Of course we’ve had conference calls on regular phones for years, but, on the whole they have been restricted to business because of the extra cost and need to set up an account. I use a traditional conference call system a lot in work but it entails dialling a lot of numbers.

With Skype I’ve been able to hold free conference calls with more people and it has been much much easier to set up.

Conference calls are an example of an application we run on top of voice connectivity. Other examples are voice mail, caller id, ring back and even faxing. Traditionally creating a new telephony application meant some experimentation plus access to telephone equipment - which tended to be complex stuff and only available to a few people in big companies.

To get your application out there was even more complicated. Telecoms companies are a traditional bunch, and for the application to be widely available it needs to run on multiple exchanges so you need agreed standards. Then you need to roll it out to a lot of exchanges so introduction was usually slow.

Now, with VoIP on Skype, Vonage, etc. you can write an application on top of the VoIP system much more eaily. More people have access to the technology and rollout means people installing the app on their PC.

Conclusion? We’re going to see more applications on voice based VoIP systems.

In fact I think we’ve already seen the first signs of this with the eBay takeover of Skype. Until now I couldn’t figure this deal out. Now it makes sense, eBay wants a sales application that integrates seamlessly with the eBay website. It also needs installed users to adopt the system and show the masses it works.

So there you go. I know the technology and I know the logic. I still don’t have a business idea. I still don’t have a problem to solve. Maybe I’ll have to go back to the book!

Business patterns the state of play

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

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

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

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

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

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

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

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

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

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

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

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

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

Is process improvement bad for innovation?

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

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

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

Could be.

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

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

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

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

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

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

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

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

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

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

Another book: Leading Change by Kotter

A couple of train journeys yesterday allowed me to race to the end of Leading Change (John P. Kotter, 1996). This is a book I’ve been meaning to read for some time. Now I’ve read it I wish I’d read it sooner.

Although it is written by an academic like most HBS press books it doesn’t come across as academic and is quite an easy read. I was once told that HBS books are ghost written and to be honest I tend to believe this. Most academics write great papers and scholarly books but aren’t so hot on easy to read literature. Unfortunately, in making it easy to read it also looses the references, I like to see the sources for ideas and places for further reading.

But back to why I liked the book...

I found the book spoke to me. This happened on three levels.

Firstly, I think the main challenge facing software companies today - and probably any business - is the need to change. The last few years have seen a lot of good ideas that have challenged the traditional way of developing software. In order to move from the old ways to the new ways we need to change.

Actually, much software and product development proceeds in a very ad hoc fashion. Consequently when we’ve considered improving things we’ve got wrapped up in methodologies, presses and standards. The real problems are much more basic: people, teamwork and change. They may be more basic but they are harder to do something about.

Software developers, and more so their managers, have hidden behind methodologies and process for far too long. Rather than chasing a process they should be addressing the real problems.

So, I think this book is useful for anyone wanting to improve their products, development and company.

Secondly the book related to my personal experience. Much of this book explains why change initiatives fail and how to avoid those failures. I’ve been responsible for introducing a lot of new ideas and change into my office. Some have been successful and change has succeeded, others have failed.

I’d like to have more of the successes and fewer failures. I’ve sometimes had trouble understanding the failures. It’s too easy to blame individuals or collectives groups like “management” but that doesn’t add much. Introducing change is about getting these people to change too.

In this book I found a lot to explain why my less successful changes have failed and why the successful ones have. So I associated with the book and it gave me some new insights and strategies.

Finally I associated with this book on a personal level. It finishes by describing the need for life long learning and the individual characteristics we need to face the future, to grow and to change ourselves. I found I could associate with this too - it matches many of my ideas.

Some Harvard books can be a little idealistic. This one is quite down to earth, perhaps because it talks about failure so much it seems rooted in real life. This book isn’t the last word in change, and there is much else that could be said. Yet in less than 200 pages it does convey a lot of good ideas.

Why work should be more like voluntary work

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

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

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

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

Actually we could add in blogging.

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

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

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

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

So, why do I do this?

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

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

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

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

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

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

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

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

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

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

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

We moved house - quick lessons about change

We moved house at the weekend. Given this blog’s reoccurring theme of change I thought its worth recording some of the things going through my mind.

Firstly, it was painful to leave the old place, I’d owned it for over 8 years and it was “home” - even when I was in California and the place was rented out.
Lesson: Giving things up is hard.

The new place is good: its bigger. But its not just about living in a larger apartment/flat I’ve moved because I want to make a life with my girlfriend. We didn’t just change for the sake of change, we changed because our lives have changed.
Lesson: Untangling cause and effect is difficult.

We’re hear and moving is just the start of the change. Although we have lived together for over two years we are now joint owners. We share responsibility. I have to adapt to this in all sorts of ways.
Lesson: Changing one thing is just the start of a chain of changes.

The new place isn’t home yet. Our stuff looks a bit out of place. Coming home after the office is strange. And we see all sorts of things we want to change. This is despite spending most of the weekend cleaning and unpacking. Thing is, it takes time to make something your own.
Lesson: You need to do things your own - ownership it important.

There is also an identity thing at work here. I was the old place, the new place... well I don’t know who I am here yet.

Our big adventure started on Friday morning. I woke up with a cold that I’m still trying to shake off. I can’t help feeling the two are related. The stress of the move? The worry? Perhaps this lowered my immune systems.
Lesson: Mental and physical are interrelated.

As most people do we engaged the services of professionals for our move. The legal people seemed to drag things out, one of the real estate agents involved was difficult, the other was fine. The removals firm where great.
Lesson: professionals don’t have all the answers, you can outsource a lot of this but you still need to manage them.

Unfortunately, due to the craziness of the British telephone system we are without broadband internet. This will probably be the case for another week or so. That’s doing to restrict my surfing, blogging, e-mailing and what else. Maybe some good will come of it!
Lesson: the rest of the world can’t move at your pace

Its been over two years since I last used a dial up connection. I can’t imagine how I lived with this all the time! Truth is, we didn’t do half the things we now do online. You come to realise how much you need fast internet.

These are just my initial thoughts - quick and dirty. I’m sure there is a lot more about change I could learn from this experience. I’ll keep thinking about it and let you know - who knows, I might even be able to relate some of these points back to business and software development!

Reprise: Why does everyone write their own CMS? (and the New ACCU website)

Back in November I agonised about this question. Well, things have moved on and I’ve had the chance to think about the question.

At the time I was grappling with 2 websites - both with proprietary CMS technology. Shortly afterwards, wearing my ACCU hat, we took the decision to dump the sub-contractor and their CMS technology. (A full report is on my website if you are interested.)

We replaced the sub-contractor with Gnomedia who have done an excellent job using the Xaraya CMS system. In just two months Xaraya, Gnomedia plus some ACCU volunteers have built a new website that has gone live this week - see www.accu.org.

While I’m talking about that site I have to thank the team: Tim Pushman at Gnomedia, Tony Barrett-Powell (the ACCU website editor) and Jez Higgins.

Throughout this time I’ve continued to wonder: why with so many commercial and Open Source systems out their do so many people write their own CMS?

Still, I think I’ve started to understand why.

First, it isn’t really clear what a Content Management System is. In fact, talking about Content is itself wrong. When was the last time you bought Content? You don’t go to Blockbuster to rent Content, you don’t visit Borders to buy Content. There is no such thing as Content.

Content is a collective term covering anything but we usually mean text documents. This can be presented as Word or PDF and may be styled as a manual, an FAQ, a How To or many other things. But content also includes sound recordings, video recording and just about anything that can be digitised.

The whole idea CMS is mixed up with Websites, Knowledge Management Systems, Learning Management System and even Learning Content Management Systems. I think many people just want better tools to manage what is on their website.

Then, there is the whole issue of Content management regardless of the web. It is increasingly possible to create text, videos, sounds, whatever, and use that in multiple places.

For example, technical authors working for a software company may write release notes, manuals, internal documentation and training documents. The same topics may be covered in all of these so why duplicate the work?

It turns out there are systems like AuthorIT for just this scenario. So when you talk about CMS are you talking about managing your raw materials or managing what appears on the web.

Bottom line: a CMS does not necessarily manage a website.

Third, a common requirement of a CMS system is to target information at different people. So, on the ACCU website members can log in and access extra documents. On a corporate website different customers may see different information. It turns out that the role of identity is quite important in CMS systems.

And it turns out that identity is itself a hard problem. Sure you can do it small scale on your PC, and even medium scale on the office network, but as you move from tens to hundreds and even millions of users the problem of who should see what gets increasingly difficult.

My friend John Merrells can talk about this for hours. In fact he’s now CTO of a company trying to fix this problem - http://www.sxip.com/.

Finally, as Jonathon Sefton has pointed out to me online and in conversation we just don’t understand the domain of CMS systems. I think this explanation actually covers everything I’ve said so far. The domain is big, the subject mater is unclear and the set of problems is hard.

Yet it appears so easy doesn’t it?

So, everyone’s set of problems is a subset of the whole. It therefore seems easiest to solve your own set of problems. The systems out there all try and solve t0o many for you today so look too complicated.

I think I’ve started to understand why people write their own CMS systems. I have to say, having seen what Xaraya can do, I think anyone writing a CMS is making a big mistake.

Naked Objects

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

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

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

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

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

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

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

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

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

Events dear boy, events

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

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

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

(And yes, if you ask I found the same pattern in Russian history.)

What have these things in common?

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

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

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

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

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

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

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

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

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

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

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

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

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

“Events dear boy, events”