allan kelly

Web 2.0 is having some fallout in the business world. It isn’t all about AJAX and Google maps, a lot of the other technologies that are broadly seen to be in Web 2.0 are of more general use. Perhaps the one with the most coverage is Blogs but Wikis, RSS, Search and tagging can all be used outside of consumer web-sites.

And I can vouch for this first hand. My employer has been using Wiki’s for a few years, at the moment I’m in the middle of evaluating search engines for the enterprise, today I’ve just set up our internal blogging system and I’m looking at fitting RSS to the website I manage.

I’m actually starting to think that a search engine, deployed in a modern IT enabled knowledge based company, may actually be one of the few example of a technology fix that actually delivers performance improvements right out of the box.

A piece by Andrew McAfee in the last issue of MIT Sloan Management Review entitled Enterprise 2.0: The Dawn of Emergent Collaboration sums all this up in the name “SLATES” – Search, Links, Authoring, Tags, Extensions and Signals.

A similar theme argument is made in this piece by Rod Boothby – although Rod seems to think this means the 20 something’s graduating from business school this year will have an advantage over the rest of us.

Both authors echo Tom Davenport who praises wikis in Thinking for a Living although he’s not sure about blogs. Are blogs an effective knowledge management tool? Do they spread ideas? Capture knowledge? Intuitively, from using them I think they do, but how effective are they? There are a lot of pointless blogs out there.

Davenport also suggests a more subtle use of blogs: to manage ones own knowledge. That is, by recording what we do we have our own knowledge available to us. I think this is true, I know I’ve included links and comments in this blog to remind me of things in future. And, as I’ve said before, blogging is a form of diary keeping; that can be useful in its own right, if it sparks some reflection on our part then it is a great advantage.

The thing is, and this continues my theme from the last entry, those who work in software development have had this technology for several years. I can’t remember exactly when I first came across Wiki’s but it was certainly before 2000. People who work in the IT industry both encounter this technology and know how to use it before the majority of other knowledge workers.

In part this is because they aren’t scared by the technology, they can install a wiki, they think nothing of engaging with the computer; in part it is because they have been closer to the people who developed these tools. Sure, I don’t know Ward Cunningham (the inventor of wiki’s) personally but I do know people who do know Ward personally.

But you don’t need Ward to create a wiki. Once the idea was out there many IT people created their own. In fact, when it comes to all these knowledge management tools software developers control the means of production – to use a phrase of Marx.

What does all this mean? Well, I think it means two things.

First researches can learn a lot from looking at IT people, they are early adopters of these technologies. Is there some new technology IT people are using today that could be the next big thing? And what about the practices and process around these tools?

Second, I think this supports my argument that IT people, and software developers in particular, are at the front of new knowledge working techniques.

Last week I reviewed Thinking for a Living, I’d like to pick up one or two points raised in this book and discuss them a little further. These are not points exclusive to Davenports work but having just read the book its a convenient focus for these thoughts.

I’m convinced that software developers (programmers, testers, product managers, etc. etc.) fail to recognise themselves as knowledge workers. Worse still, I think those that manage these people fail to recognise them as knowledge workers. So, we get discussions about “the software factory” and we hear managers describe how they can make their “factory” more efficient – as if the developers were working on a production line.

The metaphor continues, too many people in the business are concerned with “process” the idea – taken from Fredric Taylor and scientific management – that if we (the management) can improve our process then the factory will be more efficient, more productive, higher quality and so on.

What those who buy into this way of thinking and talking miss is that knowledge work is fundamentally different to factory thinking. In fact, modern factory thinking is different to traditional factory thinking. Toyota considers every one of its workers to be a knowledge worker – whether they are designing cars, advertising cars or assembling them.

The problem is, that when software developers and their managers ignore the knowledge worker aspect – either by regarding development as a factory process or as something “special” and “unique” – they miss out on opportunities, research and observations presented by the existing body of knowledge on knowledge work.

Davenport’s book clearly regards software developers as knowledge workers. Personally I’d go further, I think those involved with software development – that is everyone: developers, testers, analysts, product managers, project managers, etc. etc. – are not only knowledge workers but they are in the vanguard of modern knowledge work.

Before we write a line of code we need knowledge work: what is the problem? who does it effect? what is the benefit?

When we write code we need knowledge: language, operating system, problem, business, ….

When we test code we need knowledge.

Every line of software code embodies knowledge. Even the humblest for…loop expresses so much about out understanding of the problem, the solution and the domain it exists in.

Sometimes software people are the shock troops of knowledge work: parachuted into hostile territory to replace aging working systems and practises with shiny new technology – no wonder they don’t have many friends! No wonder you want “geeks” who don’t communicate with people, sometimes you don’t want them talking to the people they are replacing.

OK, that’s a little bit of hyperbole and exaggeration to catch your imagination but you get the message.

Now for the interesting bit.

Software people are on the front line of twenty-first century knowledge work. They don’t make it easy for themselves – ignoring much that existing knowledge on knowledge work, learning and change – but they are making discoveries, they are innovating, they are finding new ways of working.

One of the innovations that is transforming the way we do software is agile development and lean software development – I say one innovation because despite the two names they share much in common.

Davenport touches on this a bit, he spends a couple of pages on Agile methods and he quotes Martin Fowler. But he only hints at the true potential here. If, and its still a big if, Agile/Lean can transform software development maybe these practises can be applied to other areas of knowledge work.

What would it mean for a lawyer to work agile?

How would a financial advisor’s work be changed?

A journalist?

And a doctor? – in fact Womack and Jones are already talking about how Lean can change health care. Their recent book Lean Solutions actually discusses this.

Some ideas can transfer immediately:

• Card-and-board “Kanban” systems to focus work
• Daily stand up meetings
• Team work: break the one person, one task, as long as it takes model
• Pairing: why not have two lawyers write a brief?

Behind this a commitment to increase our productivity with a focus on value adding work – eliminate waste!

And, underlying all this, the operating system on which the whole thing runs: Continual learning and improvement – the Learning Organization.

Perhaps the future of all knowledge workers looks a lot more like the current methods being deployed by agile software developers?

Or perhaps, software people are just playing catch up, maybe we’ve cut ourselves off and only now are we catching up.

As usual the truth lies somewhere between the two extremes. For myself, I believe the future of all work will look a lot more like modern software development running on LOOS – Learning Organization Operating System.

One of the regular features of this blog is that I review the books I’ve read. Not all of them, on the whole I only really write about the “serious” books I’ve read, so you don’t get reviews of novels, cook books, etc. that I read. Before I turn to the latest book I’m conscious that every time I review I book I seem to like it. If a book reviewer doesn’t criticise a book once in a while are they really objective?

I’d like to be really critical of a book once in a while but in truth I just don’t tend to read books I’m not going to like. I tend to spend some time choosing books – I read other book reviews, online and in the press and I read what the book says about itself.

So, I hope you’ll forgive me if I seem to ready too hand out praise for books. That said, on with the show.

To train journey to and from St Ives over Easter allowed me to finish off Thomas Davenports Thinking for a Living. I’d been looking forward to reading this book since I read a favourable review in the FT a few months ago. I liked the book but I did find it a little disappointing. I suspect my disappointment might be more due to me than the book. For much of the last four years I’ve been reading lots about knowledge management and organizational learning. As a result I didn’t find a lot that was new to me in this book.

The situation may well be different if your new to the subject, or looking for a starting point. As such this would be a good place to start, and given that Tom Davenport has been a major contributor to the subject area over the last few years it probably makes sense to start with his latest work than one of the older volumes.

What is perhaps new is that Davenport turns and directly addresses the question: “How can we make knowledge workers more productive?”

Now this question goes straight back to Peter Drucker, indeed one may characterise it as Drucker’s challenge, as Davenport reminds us:

“To make knowledge work productive will be the great management task of this century, jut as to make manual work productive was the great management task of the last century.” Peter Drucker, Age of Discontinuity, 1969.

Davenport sets out to address this question – indeed I agree with him and Drucker, I also accept the challenge. In doing so he does offer us some advice and stories of what others have done but you aren’t going to come away from this book with a “35 things to do to make your knowledge workers productive” – actually, to be fair I don’t think such a list is possible but I’ll leave my explanation for another day.

So, what does Davenport tell us?

Well, he accepts that the Knowledge Management Systems (KMSs) pushed by software companies and consultants in the 1990’s are not the answer. However he does see a role for technologies, specifically communications (e-mail, telephone), Wiki’s and search – although the jury is still out on Blogs.

He also accepts that it is not about process – practice is perhaps more important. (I’ll write more about this as I progress though my current book Talking About Machines.)

Davenport also suggests “after action reviews”, or, as we in the software development community know them retrospectives. Now in the development community lots of us know about retrospectives, lots of us think they are good but few do them. And when they are they aren’t necessarily as effective as they could be. According to Davenport this situation is pretty common, we could all use retrospectives more effectively.

Another idea that rings true with software developers and their managers is HSPALTA – “high smart people and leave them alone.” This is a prevalent management technique the software arena, too many people – managers and developers alike – are only too happy to say “its the people who make the difference” and under this cover do nothing. We have to get away from this idea that because we did it like that yesterday we’ll do it like that today and tomorrow.

Overall though Davenport’s main insight is that knowledge workers are not homogonous. Different solutions apply for different groups of knowledge workers, e.g. scripting might work in a call centre but don’t try it with a consultant. This might sound like an obvious statement but until its made it perhaps isn’t so obvious – the label “knowledge worker” can hide a multitude of sub-divisions.

Before I close this review I do want to commend the author for good referencing and some actual research. When he discusses ideas form other authors he tells you who they are and were they said it so you can track back to their original work on the subject. Nor is he shy of discussing his own research findings.

What makes this unusual is too factors: first, as I’ve said before, books from Harvard Business School Press tend (ironically) to omit these details, second, the book is still very readable.

So on balance: if your new to the subject of knowledge work and knowledge worker productivity this is a good place to start. If your familiar with the subject you’ll probably still get something from this book but don’t expect all the answers.

I had intended to draw a line under my comments on the ACCU conference last week. I’ve got most of it out of my system but I had to return to Peter Sommerlad’s presentation – Only the code tells the truth.

Peter’s starting point was that, well, only the code tells you the truth about the system. That is the code, the stuff that is compiled and executed, not the documentation, not the specification, certainly not the UM and not even the comments but the actually lines of computer code.

There is nothing new in this assertion really. One of the things I had drummed into me by Derek Andrews when I was an undergraduate was: code is an executable specification, and as such it is the only completely accurate specification because, well, its the one that executes!

(And thanks for Hubert Matthews for a very interesting keynote at ACCU and reminding me that Derek is still out there practising software!)

Peter’s argument continues: if only the code is the truth what are we doing with all this other stuff? In fact, maybe a lot of what we think of as “good” software practice is actually mythology that has grown up around how we do it.

At one extreme some of this myth may be rooted in good intentions, it never did us any good but we thought it might and somehow we came to believe it. (I’d put the original ISO9000 in this category.)

Some of the other myths may have been true at some point in the past but we should really ask “Is this still good for us?” – perhaps we need to abandon some practices that were good once upon a time but don’t really add value any more.

One of Peter’s suggestions was the comments in code may actually detract from its maintainability. The argument goes like this: some comments are useful, many are useless (comment “increment i” before ++i for example), others are confusing, some are downright wrong. If the code is expressive enough then perhaps we don’t need comments in here at all.

This is pretty contentious stuff and unfortunately the group allowed ourselves to get side tracked down this avenue for 20 minutes or so when really is was just a side show.

Peters other suggestions included: strong typing may reduce understandability, design before coding can be detrimental, testing after we code is wrong, “everything is an object” and a few more too. Basically Peter is challenging us to look long and hard at some of the practices we engage in and ask: are they still useful? And so it was the session became a very interesting debate.

This opens a real Pandora’s box but its about time the software development industry engaged in some Myth Busting.

Here is a suggestion of my own for something we need to look long and hard at

Myth: accountancy correctly values knowledge based companies and their assets.
Is developing software an expense or an investment?

Most of the time when we develop software it is classed as a cost on the balance sheet. But in fact the result is an asset – software code – in which case we are increasing the assets the company owns. If this was a car or a factory it would be included on the balance sheet and it would be classed as an investment. So, £1 spent on development becomes £1 on the assets owned by the company.

Take this a step further; what about our people? – remember “our people are our greatest asset.”

In which case, sending someone on a training course isn’t a cost, its an investment and should be included on the balance sheet under assets. Companies regularly include “good will” on the balance sheet so why not people? And why not source code?

Once accept both these points the incentive for companies to invest in people and software increases drastically. No longer are these expenditures reducing profits, they are increasing assets. However, current accountancy doesn’t recognise this.

The ACCU is a technical organization – people join because it has a technical focus. But actually the secret of the ACCU is that it is really about developing people.

We help those technical people develop their technical skills – but on the quiet we help them develop their less technical skills, we challenge them to think about less technical issues. So, while you see Scott Meyers, Herb Sutter, Guido Van Rossum and Michael Feathers headlining the conference you also find people like Helen Sharp challenging them to think about development as a social activity.

One of the ways we help people develop themselves is by giving them opportunities. As I told many people at the ACCU conference last week there are three kinds of people giving presentations.

First we have the established players, the ‘A’ list if you like: people like Scott Meyers and Herb Sutter – they don’t need an introduction, people will come to hear them alone.

Second we have the ‘B’ list: I’ll put myself on this list if you don’t mind, I’ll also add people like Klaus Marquardt. We are people who have been around a bit, published some papers, done some presentations, we’re the conference filler if you like. Some of the ‘B’ list are challenging for the ‘A’ list, so people like Kevlin Henney might still be on the ‘B’ list but likely he has already moved to the ‘A’ list.

And then we have the ‘C’ list. These are the most important speakers. These are the people the conference is really about. These folks may never have spoken before, or they may have done the odd presentation. These are the people the ACCU is developing, the future talent.

Not long ago I was ‘C’ list, I’d never done a presentation, I’d written a little. By doing presentations, by writing more and by thinking I’m now ‘B’ list. Will I ever make ‘A’ list? I don’t know, I’d like to but there are other things in life too.

Actually, I usually prefer the content of the ‘B’ and ‘C’ list presentations. There are more war stories, there is more discussion and more experimentation – both in presentation style and material.

I want to say a couple of words about two speakers who stood out. These guys are making the transition from ‘C’ to ‘B’ list in my book.

Jez Higgins (who is also the new ACCU chair) did a great presentation about XSLT2, XPath2 and XQuery. He was in a difficult slot – first session of the first day but for me he set the quality bar for the rest of the conference.

I thought I knew a lot of this stuff before the presentation but Jez had plenty of surprises for me. A Suduko solver in XSTL2? – the idea really makes me think again. Things have changed with the XML support technologies and Jez did a great job of bringing me up to date. I guess I knew these technologies were capable of a lot more than transforming XML but it was a while since I’d checked them out.

Day 2 brought Thomas Witt and “Shared Libraries in C++”. Watching Thomas I saw a younger version of myself. Five years ago this was my subject, I knew far too much about shared libraries in C++ – .dll’s in Windows, .so’s on Unix, dynamic linking, static linking, memory models, etc. etc. (Check out my pieces on porting if you don’t believe me.)

Well, things haven’t changed that much in the shared library world over the last five years but Thomas has gone further and deeper than I ever went. He is truly an expert on this subject: Windows, Unix(s), Macs, object models, you name it he knows it.

So I’m looking forward to next year. We’ll have our ‘A’ list speakers to pull in the crowds and make the conference economic but the real action will be with the ‘B’ and ‘C’ list speakers, these are experts every bit as much as the ‘A’ names.

Best of all, this is the ACCU developing talent, this is ACCU giving people space and time to stretch themselves and its why I’ll stick by the organization as I move further and further away from programming.

I’m at the ACCU conference in Oxford this week. As always the conference is lively and giving me a lot to think about. I’ll blog some more about this next week.

But, before then: Monday’s FT had an interview with Larry Ellison of Oracle. He discussed the possibility of Oracle producing its own distribution of Linux. One of the drivers for this is to allow Oracle to compete with Microsoft in the OS market but it wasn’t the only one.

According to Ellison some of Oracle’s customers want a single supplier. They want one company to take responsibility for a systems performance. In other words, they don’t want the ERP vendor saying it is a database problem and the database vendor saying it is an OS problem.

So, if Oracle had its own distribution of Linux they would test that the OS worked with the database and the database worked with the ERP. What I find interesting here is that Oracle would be selling “piece of mind”, “proven software”, or simple “tested applications”.

The value add would not be in the products themselves but in the fact that they all worked together and were shown to work together. In other words, producing the software isn’t the difficult bit, testing it works together is. Hence it is the testing that adds the value not the development.

To my mind this is either a great step forward or a sign of a truly crazy world. I’ve not worked out which yet.

I’ve been wanting to write about Path Dependency for a while. Its a subject that fascinates me but I’m not quite sure I understand what is means and how it affects us.

The idea comes from economics and at its simplest path dependency says “History matters” – or, how we got here effects the way things are. Things are the way they are because of all the decisions that have been made up to this point. Sometimes this can explain why our theories don’t explain the real world – yes, this does touch on chaos theory too.

There is an interesting paper by Margolis and Liebowitz entitled “Look, I understand too little too late” that makes for a good starting point. One of the classic examples of path dependency is supposed to be the Qwerty keyboard. But the authors demonstrate that this isn’t really the case. They go on to question the whole idea of path dependency as an economic force.

So, maybe in economics the theory doesn’t apply. But I think it does apply to software.

All too often when you look at a piece of software it just doesn’t work as you might expect it too. It is programmed in C++ when Python would be a better language, or it is procedural based when OO would be better, maybe it just implements its own data structures when it should use a library. It seems every programmer when confronted with code he didn’t write says “this is awful… maybe we should rewrite?”

It doesn’t just happen at the code level, look at the whole product: are all the features still needed? Perhaps our product is difficult to use because we needed so many features two years ago but now they get in the way.

And the same thing goes at the process level: we write requirements documents because that’s the way we’ve always done it, we throw code over the wall to tester because that’s what we did at the last place. We are slaves to the past and ignore better ways of doing things.

I think a large part of this is path dependency at work. Not entirely, sometime it is because we now understand what we are trying to do better, and partly it is because we have more options available now, but largely it is because of how we got here.

Every individual decision made sense at the time. However, the cumulative set of decisions isn’t the optimal one now. Yet it is difficult to justify changing it now.

So often our theories, whether in Economics, Software Development or Business assume that should be just are: theory says that supply equals demand so it will, theory says code should be unit tested so it is, theory says that Business should concentrate on core competencies so they do. But, unlike Physics these things don’t happen instantaneously. We might need time to let the system adjust, or we might need to give it a helping hand or remove some blockages.

Path dependency may be a grandiose term but is makes an important point: often how we got here is a better explanation of the current situation than how it should be is.

I think much of what we call “design” is about breaking path dependency. Rather than accepting how things are, rather than doing things the way they always have been done, design is about finding a better way and encouraging people to do it that way instead.

That goes at the code level, the product level, the process level and at the business strategy level. We should respect the ways things are, they are that way for good reason (even if we don’t understand them all) but that doesn’t mean we can’t change and improve.

I’m still working out what path dependency means to me and my world view. I think its important and can explain a lot. As I work it out I’ll update you.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Could be.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Actually we could add in blogging.

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

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

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

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

So, why do I do this?

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

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

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

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

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

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

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

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

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

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

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