Last weeks Economist contained an interesting piece on German exports (subscription required.) One of the things that caught my eye was some of the discussion about the problems in the Mittelstand sector. Not that long ago the Mittelstand was seen as a role-model for how British industry could do better, for example Will Hutton’s The State We're in based a lot of its economic argument on the comparison between British and German on regional industry.
Now things aren’t looking so rosy for the Mittelstand or for other parts of German industry. In fact, sometimes Germany seems to be having a hard time coming to grips with the modern world economy - not so long ago one German minister described private equity investors as “locust.”
There is still much to be admired in German industry and I’m not really looking to bash German industry - or cheerlead for British industry. I’m just interested in understanding and finding some lessons from the predicament of the Mittelstand.
One of the problems highlighted by the Economist last week was that of innovation. True, German companies can be very innovative but much of their innovation centres around incremental improvements to existing products - and in particular quality improvements. This is an engineers dream, reaching for the highest quality product possible but it also means there is less radical innovation and fewer completely new products.
Companies, and individuals, are not producing completely new products, instead they are stretching the existing products. Problem is, when the existing product more than satisfies 90% of consumers requirements does it make sense to continue improving it? There isn’t much more market to take but quality improvements may increase price.
Sometimes pushing on in one direction is the right thing to do. Other times its better to try a different direction.
Part of this problem is success. These companies have had great success with these products so not only do they expect continued success but they see little reason to change their ways.
One of our images of private business people is as risk takers, people who say “Heck, I’m fed up 9-5, I’m going my own way” and accept the risk of starting something from nothing. Its worth remembering for a moment that many of these firms were started in the decade after 1945, at that time there wasn’t much else. The risk for these German entrepreneurs was low, safe jobs in big corporations didn’t, on the whole, exists. Starting a new business was the low risk option.
And there in lies a lesson for many privately held businesses. Once the initial risk has been taken, once cash flow appears and the product has a modicum of success the appetite for risk can disappear. Boot-strapped businesses may come to value predictability, low investment, low risk developments because they place a high premium on being around tomorrow. Since there are none (or few) outside shareholders nobody is going to complain about the lack of growth.
Conversely a business that takes cash from outside investors early on has to meet their expectations, and these expectations are for growth. Since the business founders aren’t playing with their own money they have less to loose by taking a risk on a big new product development, somebody else is paying and they are taking the risk.
In effect there is a specialisation here. The entrepreneur specialises in founding the business, building the company and creating new products and the investor, be they Angle or Venture Capitalist, takes on the risk in return for the reward of profit.
Now, move forward 50 years, those who founded in their business in 1950’s are looking to retire. If they are lucky they have the management talent within their family and they can simply hand it over.
Unfortunately it doesn’t always work like that. Perhaps nobody in the family wants to be in the business, perhaps they aren’t particularly talented or maybe the most talented person is a manger in the business and not a family member. What happens next? How does the founder cash-out?
Again external investors come into play. They buy the business, giving the founder an exit, and they seek out the best person to run the business. And this is what is happening, this is why so many private equity houses are so active in Germany just now.
Unfortunately, this kind of changes the German way of doing things. Suddenly businesses aren’t owned and run by the family. Ownership and management are separated. The new owners have more appetite for risk and want to see some more growth, more innovation and reduced costs. Then, on top of this the investors probably plan to sell the business in 4-5 years.
There is nothing fundamentally wrong with this model, its been operating in the US, UK and elsewhere for a good while but it does come as a surprise to many in Germany, hence the recent debate about the role of shareholders in Germany and the social model over. (A debate I’m not going to comment on, I don’t know enough and it is German’s debate not mine.)
On the bright side, more external investors in German business may encourage more innovation in different directions. With a little luck everyone will end up better off.
Monday, May 29, 2006
Saturday, May 27, 2006
Book review: Talking about machines
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:
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.
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.
Tuesday, May 23, 2006
Office, Cubicle or Open plan?
There is a debate that surfaces from time to time about the best way to arrange your office. There seems to be a belief that once upon a time everyone who worked in an office actually had their own office. Maybe this arose because 100 years ago relatively few people did office work and a higher percentage actually did have their own office. Personally I think it is something of a myth.
But still, how do you organise your office space? Individual offices? Dilbert style cubes or open plan?
Each has its proponents, each its detractors and none of them seem to be able to agree.
Some argue that individual offices give you privacy, confidentiality, space and quiet to think in and say that the company values you.
Fans of cube argue that giving everyone their own office isn’t practical but a cube gives you some private space, some confidentiality and at least some space and quiet to concentrate in - how can anyone work in open plan?
Open plan fans usually emphasis the sociability of an open plan office, and how you can be connected to people, hear what is happening, see your colleagues - information flows around much easier - cubes put you in a box and stifle your creativity.
The subject came up in last months book. Davenport notes research that concludes
But, he can’t quite believe it himself and wonders if the need for concentration and quiet is under valued.
The subject was also covered by Knowledge At Emory a couple of months ago, Do Cubicles Help Productivity or Hurt It?
I find both these references flawed. In a word they miss Europe. As research they are flawed in two aspects, first they ignore an alternative source of data and second they ignore culture differences that help explain the effects.
Both the Wharton piece and Davenport’s critique betray their US bias. The thing is, most people I know in Europe work in open plan offices. Over ten years working in the UK I’ve never seen a cube. Few colleagues I know would swap their open plan desk for a cube. Conversely, my two years in California were spent in cubes. I hated it but I couldn’t persuade my American colleagues of the alternative.
I’ll continue to regard all studies of offices, cubicles and open plan offices as flawed until I see one that at least acknowledges that different countries do different things.
My conclusion is: a lot of it depends on what you are used to, changing from one layout to another is more about cultural change than space and information flows.
Personally, I’m an open plan man, yes you get distracted, and need some more quiet - especially in my current desk - but I see people, you have ad hoc conversations and you hear things around you.
Why mention all this now? Well actually, it links up with a theme of the last couple blog entries: software developers as the prototype for knowledge workers in the future...
Software developers, especially those trying Agile development techniques, are increasingly trying novel office layouts - like caves and commons - and sometimes working in pairs - the infamous pair programming.
But still, how do you organise your office space? Individual offices? Dilbert style cubes or open plan?
Each has its proponents, each its detractors and none of them seem to be able to agree.
Some argue that individual offices give you privacy, confidentiality, space and quiet to think in and say that the company values you.
Fans of cube argue that giving everyone their own office isn’t practical but a cube gives you some private space, some confidentiality and at least some space and quiet to concentrate in - how can anyone work in open plan?
Open plan fans usually emphasis the sociability of an open plan office, and how you can be connected to people, hear what is happening, see your colleagues - information flows around much easier - cubes put you in a box and stifle your creativity.
The subject came up in last months book. Davenport notes research that concludes
“Our research, ... , indicates that the more ‘open’ plan office environment, the more conducive it is to overall work effectiveness, when communication and interaction are critical elements of the work process.” Thinking for a Living p. 167.
But, he can’t quite believe it himself and wonders if the need for concentration and quiet is under valued.
The subject was also covered by Knowledge At Emory a couple of months ago, Do Cubicles Help Productivity or Hurt It?
I find both these references flawed. In a word they miss Europe. As research they are flawed in two aspects, first they ignore an alternative source of data and second they ignore culture differences that help explain the effects.
Both the Wharton piece and Davenport’s critique betray their US bias. The thing is, most people I know in Europe work in open plan offices. Over ten years working in the UK I’ve never seen a cube. Few colleagues I know would swap their open plan desk for a cube. Conversely, my two years in California were spent in cubes. I hated it but I couldn’t persuade my American colleagues of the alternative.
I’ll continue to regard all studies of offices, cubicles and open plan offices as flawed until I see one that at least acknowledges that different countries do different things.
My conclusion is: a lot of it depends on what you are used to, changing from one layout to another is more about cultural change than space and information flows.
Personally, I’m an open plan man, yes you get distracted, and need some more quiet - especially in my current desk - but I see people, you have ad hoc conversations and you hear things around you.
Why mention all this now? Well actually, it links up with a theme of the last couple blog entries: software developers as the prototype for knowledge workers in the future...
Software developers, especially those trying Agile development techniques, are increasingly trying novel office layouts - like caves and commons - and sometimes working in pairs - the infamous pair programming.
Thursday, May 18, 2006
Software people got there first: Wiki’s, blogs
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.
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.
Sunday, May 14, 2006
Pattern Languages of Program Design volume 5 (PLoPD5) is out - buy it now!
As some of you may know my pattern Encapsulated Context was selected for inclusion in Pattern Languages of Program Design volume 5. Well, it seems the book finally hit the streets in the last few weeks. Its available in the US now, looks like the UK will be next month.
You’ll find Encapsulated Context in chapter 3, this version is slightly different from the online version - thanks to Addison-Wesley’s sub-editing and the editors review process.
You’ll find Encapsulated Context in chapter 3, this version is slightly different from the online version - thanks to Addison-Wesley’s sub-editing and the editors review process.
So, rush out and buy the book! As for my reward... I get little more than the fame of having chapter 3 of a major patterns book, Addison-Wesley should be sending me two copies. That’s it. Its nearly four years since I started to write the pattern so I think some celebration is in order. I’ll let you know when I get the books and I’ll arrange some celebratory drinks. |
Agile software development: a prototype for all knowledge work?
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:
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.
, 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.
Sunday, May 07, 2006
Book review: Thinking for a Living
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:
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’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.
Art: a Kelly treat
Time for a short indulgence of mine: Art.
I’m feel so luck, or so spoilt this year. I was at the Serpentine galley again yesterday for an exhibition of recent works by Ellsworth Kelly. Wonderful!
I can spend a long time with one of Kelly’s pieces, for example, like Blue Curve, at first site they look simple but there is a complexity in the simplicity. And the more I look at them the more I think, I find them so energizing.
(And before you ask, no he isn’t a relation - there are lots of Kelly’s in the world. Still, he is my favourite artist.)
This come just a few weeks after I was in Cornwall for his exhibition at Tate St Ives - closing today unfortunately.
I love both these galleries because they are small, even though the Tate St Ives is only had about six of Kelly’s big abstracts and a couple of dozen of his drawing I still travelled to far end of the country for it.
I was a great fan of Tate Modern when it opened, the sheer size was impressive and the contents second to none. But after a few years the size can sometimes be draining and a little intimidating - so I won’t be supporting the plan to extend the museum.
Still, if you have a chance get to see the Albers and Moholy-Nagy exhibition at Tate Modern do so, you’ve got a few more weeks - its another excellent show.
I’m feel so luck, or so spoilt this year. I was at the Serpentine galley again yesterday for an exhibition of recent works by Ellsworth Kelly. Wonderful!
I can spend a long time with one of Kelly’s pieces, for example, like Blue Curve, at first site they look simple but there is a complexity in the simplicity. And the more I look at them the more I think, I find them so energizing.
(And before you ask, no he isn’t a relation - there are lots of Kelly’s in the world. Still, he is my favourite artist.)
This come just a few weeks after I was in Cornwall for his exhibition at Tate St Ives - closing today unfortunately.
I love both these galleries because they are small, even though the Tate St Ives is only had about six of Kelly’s big abstracts and a couple of dozen of his drawing I still travelled to far end of the country for it.
I was a great fan of Tate Modern when it opened, the sheer size was impressive and the contents second to none. But after a few years the size can sometimes be draining and a little intimidating - so I won’t be supporting the plan to extend the museum.
Still, if you have a chance get to see the Albers and Moholy-Nagy exhibition at Tate Modern do so, you’ve got a few more weeks - its another excellent show.
Subscribe to:
Posts (Atom)