Some reflections for the final blog of 2006

My previous blog entry may well be construed as me moaning about the bad customer service incident.  This is true, the problems I had with Going Places lead me to think about what the company, and others, were doing with their web sites.  Hopefully I have managed to draw some useful lessons from the experience.

It also led me to think about what I am doing, and saying in this blog.  I have a few personal rules about this blog and I have tried to explain them to readers before - well I say readers more really a case of documenting them for myself!

While one rule there isn't a listed there and which I break from time to time (regularly?) is about customer service.  I don't really want this blog to become a moan about customer service - there are plenty of other blogs for that and it would be far too easy. So I paused before I wrote that entry to think about this blog.

New Year seems a good time to think about this blog.  From time to time I think about the description of this blog on blogger and contemplate changing it.  Trouble is, so far I haven't actually come up with anything better.  So who am I latest thoughts on what this blog is...

This is a blog about what happens when technology, specifically software development, meets the business world, specifically business strategy. And to me business strategy is not really very far from business operations, there is no great divide.

In fact to my mind technology and strategy share a lot of things in common.  Both are highly dependent on people and both are highly creative.  Associating creativity with technology and strategy might surprise some people but what is the point of technology without innovation?  Similarly what is the point of strategy if it is merely a repeat of what has gone before?  Or a copy of something else?

But it is knowledge and learning that interests me most in this area.  We cannot create new technologies and new strategies without knowledge and learning.  In some ways both technology and strategy are cutting edges of the modern economy.  Both are responsible for creating the world in which we live.  And it is because they are at the cutting edge of people occupy such an essential role.  If you could replace the people in either one you are simply change the problem.  You would still need people to address the new problem.

And with that I will sign off 2006.  Hopefully those final remarks will make it clearer what this blog is actually about - to me if nobody else!

 

Web sites should not be bolt on optional extras

As our day-to-day lives become more more dependent on the Web the quality of website becomes more important.  Unfortunately many companies treat their web presence as some kind of bold on optional extra.  Consequently we end up with web sites which frankly aren't very nice to use and can actually be misleading.

That's from a customer point of view from a corporate perspective things are potentially even worse.  Companies that created a bolt on website are not maximising the benefits they can achieve from the web and properly from an IT in general.  Not only are they not maximising the benefits of the holding if only costing the more.

This had been brought home to me in the last few days by the travel company Going Places this is a UK-based package holiday company with High Street travel agents.  Such companies are having a pretty rough commercial time at the moment three factors have come together to make business more difficult:

• First the rapid growth in budget airlines in Europe means customers have more choice and package holiday company's charter airlines have competition.
• Second the Internet means that travellers like myself can put together our own holiday schedules without a travel agent.
• Finally all customers are familiar with travelling abroad so they don't feel the need for the comfort blanket of a package deal.

That said package holidays can be convenient.  So while I arranged my own honeymoon online couple of months ago without a travel agent insight, for my skiing holiday next year I opted to buy a package deal, sheer laziness on my part to be honest.

Actually it wasn't that lazy because the websites operated by the main package tour companies in the UK are pretty damn the awful.  I wonder how many people really want to download an entire 200 page full-colour holiday brochure in PDF format.  Then there is a search facility.  Unless you know what you're actually looking for it very hard to find anything.  And when you do know what you're looking for the search facility shows you holidays which aren't available. 

These guys have just picked up their off line model and dropped the online without any consideration for how it is used or what improvements they could make.  No wonder these companies are losing market share.

But actually this was trumped by experience at this weekend, again with the Going Places website.  From reasons I won't go into I actually needed to go to one of their branches.  Naturally I consulted their web site for the location of my nearest branch - although it is surprising how many web sites make this simple task difficult.

Helpfully the website for me my nearest branch was located at 42 High-Street Ealing.  So on Friday morning I dutifully made my way to this address only to find no travel agent.  Thinking I must have the wrong address I bought a coffee in a coffee shop with Internet connection and check the address.  Then I dialled the company's premium rate telephone number to ask exactly where the shop was.

Now the punchline: the operator told me the shop had closed over a year ago.  She apologised but told me there is nothing she could do about the website.

Let's think about this the moment:

• The website is totally disconnected from the company's practices, it is not up-to-date and there is little they can do about changing it
• The website is misleading potential customers and creating bad customer relations
• Tthe website is not connected with company strategy which seems to involve closing branches

This is a company that has just reported its first year in profit after four years of losses.  Even as outside it is pretty obvious to me why the company has difficulty making money.

Obviously this is a company that treats its web site as a bolt on extra.  Potentially this company would make more money if it just stopped doing a website altogether rather than having a bad one.  Instead it could concentrate on doing what it does well (whatever that might be) instead of spending many an energy on a poor website.

Unfortunately for consumers to many companies are creating bad web sites which do not create a positive experience.  Everybody suffers consumer, the company and even the website designers and fully know most of the failings in the website.

Book review: Strategy Bites Back

I’ve already mentioned this book in a blog entry a couple of weeks ago in this blog so it should come as no surprise that I’m recommending Strategy Bites Back.

If you have an interest in business strategy then this is an interesting book to read.  And if you know nothing about business strategy but think you should then probably this is the best book you could buy.  The book will come as no surprise to anyone familiar with The Rise and Fall of Strategic Planning- also by Henry Mintzberg – many of the same themes emerge.

In fact this might be the most enjoyable book I’ve ever read on business strategy – and yes, I have read quite a few.  The book takes a light hearted, serious and intelligent look at strategy and some of the contradictions and absurdities firms and strategy makers wrap themselves in.  Early on the authors admit they are trying to add some humour and fun to what can be a boring and all too serious subject.  There reasoning is: strategy needs to be fun, it needs to be fun so we enjoy doing it, if you don’t enjoy it then you probably won’t make any use of your strategy.

Another nice thing about the book is that it is structured as a series of short essays – or bites and bytes as the authors call them.  Some bites are just a page long, others run to several pages but none of them get overly academic.  I found quite a few of the bites offering really useful insights, either supporting something I already suspected or giving me a new idea to think about.  Two of the later bites in particular stood out.

One, from Harvey Schachter finally lays to rest the debate about whether strategy comes from the top of an organization down (lots of big brains sitting in a board room directing company activity) or whether strategy comes from the bottom up (lots of individual decisions and initiatives made by people who actually do the work and later adopted as strategy).  Actually says Schachter companies do both.  Yes the big brains in the board room have a role to play but so do the little people at the coal-face.

The book contains no less than three pieces from Jeanne Liedtka and while her “Strategy as a little black dress” may have the best title of any strategy article (ever) its her third contribution, “Strategy as the art of seduction” that really caught my attention.  She argues that for a company strategy to be effective it has to appeal to everyone in the organization, the strategy has to make them want to change and implement the strategy.  Thus, the importance of the strategy is not so much whether it is a “good strategy” or not but rather whether it motivates people.  That is: does the strategy seduce you and make you want to be part of it?

Liedtka’s argument is also an argument for involving everyone in the organization in strategy formation – something I’ve been know to argue myself in this blog.  And if your going to involve everyone in formation and execution then naturally your going to want to make strategy fun, which neatly brings us back to were this book came in.

Companies who understand IT get the benefits

Anyone who read my last blog entry might be wondering what it was that I found so interesting in the Sloan Management Review, well, it was this piece Generating Premium Returns on Your IT Investments which got my attention.

I've been running across the term IT Portfolio Management for a while now and wondering what it was all about.  You can always make an educated guess from such a term but then you risk getting it wrong or missing the important points.  Quite often IT Portfolio Management was associated with the term IT Governance which is something else I thought I should know more about.  Well, this piece on IT investment did three things: it set me straight about what is IT Portfolio Management, it inspired me to read more about IT Governance (I'll write something about this soon) and it provided some interesting statistics about IT success.

So, what is IT Portfolio Management?  Basically it is the idea that organizations should know what IT projects they are undertaking and should review them as a whole rather than just a one at a time basis.  The idea is that while you might have four big IT projects on the go, all of which make sense in their own right, when you look at them collectively you see that two of them are doing the same thing.

Now this is one of those things that sounds obvious.  How could any reasonable company not know it was funding overlapping or even competing projects?  Yet this happens, its quite possible large companies don't know every project that is happening, in a geographically dispersed company things get more difficult still.  Add in the way many companies distribute IT projects to business units and its quite clear that the investment group in Australia might be doing a project that looks a lot like the new business group in Sweden.

So the first step in IT Portfolio Management is simply to catalogue all your IT projects.  The next step is to review them all and then... well this is were the SMR piece is really focused.  This suggests that companies should categorise each project as: Strategic, Informational, Transactional or Infrastructure.  Each company should also decide what percentage of the IT budget to allocate to each of these types of project and use that as a management tool for managing the whole protfolio.

Well that's the idea in a nutshell, I won't go on about it any more.  The interesting thing that arises from this research is that the authors identify two types of company: those that are IT savvy - i.e. those that understand IT and can exploit IT - and the then those who are not IT savvy.

Those companies that are IT savvy can have higher profits the year after doing an IT project, typically $247 extra profit for every $1 invested in IT.  So for these companies doing IT project makes a lot of sense.

For the other companies, the non-IT savvy companies, the reverse is true.  Doing IT projects reduces subsequent profits, typically they make $909 profit less profit for each $1 spent on IT the year before.  In other words: these companies would be better off not doing IT projects.  (Which is worrying from a long term point of view.)

What occurs to me is that we can link all of this back to Nicholas Carr's arguement IT Doesn't Matter.  Carr argued that IT was no longer strategic and companies should concentrate on commodity IT.  Of course many people (including myself) took exception to this and argued the contrary.  Now perhaps we have an answer to the discussion, and its answer using one of those re-occurring business ideas: segmentation.

Carr is right, for some companies IT is not important, for those companies who are not IT savvy, they should get away from IT and find some other way to improve their business.  For other companies, namely the IT savvy ones, IT is important and can produce real benefits.

So the answer to the question: “Is IT important?” is simply; “it depends.”

Before finishing there is one more points that struck me in the Sloan piece.  One of the recommendations is: Companies should learn from post-implementation reviews and formal training.  This gives two action points.

Firstly, companies do not invest enough in IT training - typically less than 2% of the IT budget.  They optimistically think that giving someone new software is enough.  It isn't, you need to train people in it.  I've lost count of how many times I've seen this done.  Being on the development side I hear about companies who buy software but don't buy the training, or users who see the software as too complicated (it usually is) but can't get any more training; or, perhaps the worst of all, the manager who believes his staff can learn a new package (or even programming language) by reading the manual.

People are great learners, they will find a way of learning new software and even complex languages so the manager are right, why spend the money?  Simply: providing the training will help it happen much, much faster.  You want your project sooner?  You want your product delivered quicker?  Want to see an improved ROI?  Then spend the money on the training, don't leave it to trial and error and manuals.

Second point; post-implementation and in-process review help companies realise the benefits of IT projects, motivate the staff and improve organizational learning thus making the company more IT.  In other words, Retrospectives make a difference.

Too many companies talk about doing retrospectives but very very few companies actually do them.  The reasons for not doing them vary, and often when they are done they are done badly so fail to maximise the learning and change.  When they do happen and are done right they make a massive difference.

Now the question is: do you want your company to be IT savvy?  If so, start doing the retrospectives and giving people the training.  If not, then I suggest you save your money and get out of IT altogether.

So I’ve subscribed to a Serious Business Journal...

I read a lot but I don’t read everything, there are some things I positively don’t read and there are some that I just can’t find time for.  Although I read the Economist and FT regularly (and yes they do often seem to overlap – but that’s a different blog entry) I’ve felt for a while that I should be reading a more thoughtful business journal, something slightly academic in fact.

While there are many academic business journals most of them are unreadable - unless you have serious need to read them, in other words: you are in academia.  Probably the only time most business people read these journals is when (like me) they are studying for an MBA.  I finished my course thinking “I should keep reading on the journals” but, they are difficult to get hold of, expensive, and largely unreadable.

There are a couple of exceptions, most notably the Harvard Business Review (HBR).  This places itself somewhere between an academic journal and a thoughtful business magazine.  Compared to other academic business journals this decidedly easy reading.  However, if what I hear is true, while the HBR has a high circulation figure most copies go unread.  In other words, people subscribe to be seen to read the HBR – OK, they may simply find they don’t have the time but then why renew the subscription? 

Maybe I’m being cynical but I just can’t bring myself to subscribe to HBR.  I think its probably some form of reverse-snobbery.  Still, I felt I should subscribe to some serious journal....

During my MBA I also took a liking to the California Management Review.  Once in while I’ve wondered over to their website and thought about subscribing, but then I see the price, I remember its more academic that the HBR and ... well I don’t.

Then there is the Sloan Management Review, or as it is now know the MIT Sloan Management Review (SMR).  As with the other two I sometimes thought about subscribing but couldn’t see when I’d get the time to read, couldn’t justify the costs and wondered if it would be too academic.  Still, as with the other two I’ve bought the odd download from their website in the last couple of years.

And so it was that SMR used the oldest marketing trick in the book – and thats the Book of Readers Digest marketing.  A flattering letter, the offer of a free copy and a discount price.

The free copy turned up last month and I was pleasantly surprised.  Of the 15 or so pieces in this issue (Winter 2006 which means last January) there are only a few that interest me enough to read them.  But I found those I did read very interesting and it reminded me that many ideas appear first in these journals.  Such pieces are usually fresher and shorter than the books on similar subjects.

So I gave in.  I’ve spent the $125 to subscribe for a year.  Why did I finally do it?  Well, four factors really.

• I think I’ll learn some new stuff, it will expose me to things I might not see otherwise.
• The dollar is weak at the moment so it is cheap and a low risk – even if the discount price turned out to be not so discount.
• SMR is quarterly, so I have three months to read each copy.
• I can now get all the kudos of reading a serious management journal while being able to look down on those who read the mass-market HBR.

How will I know if the journal is worth reading in future?  Well I could use the Dr Dobbs test...

I’ve long had a theory that if your sitting on the Tube and you see someone reading Dr Dobbs then you should immediately hire them.  If someone is interested enough to read Dobbs they are going to be a good programmer.

The theory doesn’t hold the Economist or HBR.  They may be good journals but they are too common (you’d hire too many people) and they don’t set the threshold not high enough to make the reader an instant hire.

Now, lets see what I think about SMR readers in a years time...

Rational decisions?

I'm currently reading Strategy Bites Back and I'll write a proper review in time.  Before then I read something on Friday that really made me think.  The book is organized a series of essays, summaries and reprints - the "bites" of the title.  The bite I read on Friday was by Spyros Makridakis who is a business school professor so he should know what he's talking about.

What he says is: manager have a hard time making rational decisions. 

They may think they are making rational decisions but they probably aren't.  And its not just managers, its all of us - even engineers!  This is because....

• Most people only look for evidence to support the point of view they hold.  If we believe something we don't tend to look for opposing evidence.
• When we do look for supporting evidence we may not always find conclusive evidence but we'll think positively of the evidence we do find - even if it is isn't quite what we needed.
• We are far more likely to remember evidence that supports what we think than evidence that challenges what we think.
• Making decisions in groups doesn't necessarily help because we suffer from "group think".
• Managers are in a worse position because they rely on information filtered at various levels below them, since everyone below them suffers from the same problem it is unlikely that opposing evidence will ever get in front of a senior manager.
• Finally, many of the things that our culture leads us to believe are true aren't, e.g. we make better decisions when we have more evidence - this doesn't hold, indeed, for all the reasons I just outlined more evidence may simply support our initial position.

So making a rational decision is hard, very hard.  And not just for us, what about for our competitors, our employees, our employers and everyone else in our business?  The same effect works on them too so they won't act rationally, and how do you predict what an irrational person or business will do?

My question is: if making a rational decision is so hard what can we do about it?

At the moment I don't know, I find the whole thing quite worrying.  This much is clear: we need to learn to accept opposing evidence and we need to make a positive effort to seek it out to correct our natural bias.

Which makes the question: how do I seek out evidence and information I might otherwise avoid?

Again I don't have the answer.  It does seem that putting yourself in unusual situations might help, opening yourself to new ideas and talking to different people should help.  I'm also reminded of Scenario Planning – one promise of scenario planning is to help you consider the world differently and practise for difference scenarios.

For the moment thought the world just got a lot more irrational.

Incremental solutions

Mary Poppendieck recently pointed out this piece on one of the mailing lists I subscribe to.  It is a piece in Fast Company magazine online about Toyota's approach to improvement.  It is well worth reading.

Working to improve things in your organization means you have to tread a narrow path.  On the one hand if everything is good you risk complacency - nobody sees the need to change or improve anything.  On the other hand if things are bad and need changing then you risk depressing everyone by constantly talking about problems and failings, people get defensive and don't want to change - this takes us into the arguments around appreciative enquiry.

So, you want to motivate people to change but you don't want to get them all defensive.

The Fast Company piece describes how Toyota are constantly making improvements to their process and products but nobody seems to be defensive or upset by failings.  The pull factor is the urge to do better, its the promise of a better tomorrow, a more productive company, a better factory, more enjoyable work.  To some degree Toyota may have pre-selected for employees with a problem solving attitude but they have also created a culture were people see opportunities to get excited about and not problems to get depressed about.

The net result is that Toyota are constantly improving, and that means many incremental improvements and solutions on top of existing incremental improvements and changes - thousands of changes a year in one plant.

I like this, I'm a fan of incremental change, incremental improvements and solutions.  However I'm also aware that incremental change often gets a bad press, that's because incremental change can go horribly wrong and make things worse.

The problem with incremental solutions is that you don't tackle the underlying problems, rather you only tackle the immediate problem and the obvious issues.  Unfortunately we see this with many Government actions: tariffs to protect industries from overseas competition, financial support for declining industries, sticking plasters for infrastructure - sometimes we need a root and branch overhaul, or we need to recognise that some activities have no long term future and we are better letting them slowly die while we developing new ideas and industries.

Sometimes radical change is needed and I don't want to say that incremental change can solve every problem.  But, and this is a pretty big but, if you need radical change then you have failed at incremental change.  The objective of incremental change should be to ensure that you never need radical change because you have already adapted yourself to a changing environment.

Look at Toyota, lots of small incremental changes, you don’t see major change programmes like you do at Ford or GM.

The problem for incremental change is to avoid simplistic solutions which only tackle the immediate problem, the symptoms if you like.  Before you make incremental changes you need to fully understand that which you are proposing to change.  You need to think deeply about the issue/opportunity/problem, talk it through with other people, maybe model the situation and your proposed solutions, maybe create some future scenarios, engage in systems thinking, understand the real problems and look for alternative solutions. 

And when you do change look to see if your change makes a real difference, or whether there are any unforeseen side effects.

In short: incremental change needs to be thought through and considered in depth.  Don't jump at the first thing you think of.

Having said all that don't let the need for analysis and deep thought stop you from making a change, don't get caught in paralysis by analysis.  Get use to changing often and changing fast.  So what if you get things wrong once in a while?  You can always put things back the way they were and mark it down as a learning experience.

That's an awful lot to do for a small change, but then, I never said this stuff was easy.  If it was easy then we'd all be doing it and it wouldn’t need writing about.

Extreme Managers

First there was Extreme Programming, now it seems we have Extreme Managers – according to the Financial Times.  The mention of Extreme Programming always made me imagine programmers jumping out of airplanes with keyboards and programming in freefall, the parachute opening and them surfing their keyboards to the ground. 

Extreme Managers – lets call them ‘XM’ – it seems prefer four-in-a-bed sleepless nights.  Manager, their partner and two Blackberries - whether this is one Blackberry each or whether the XM has two Blackberries themselves isn't mentioned in the report.

(In fact, the FT report is a cut down version of a forthcoming report in the Harvard Business Review, which most likely is the cut down version of a more academic report and in all likelihood will be turned into a book by Harvard Business School Press - such is the incisions world of business publishing.)

It seems Extreme Managers like working 12 hour days, 70-hours a week, they manage teams spread through the world, they are always-on, travel a lot but, perhaps surprisingly, actually really like their jobs.  At first sight it looks like a win-win, managers like the work, companies like the results - after all they are only paying for 40 hours a week.

There are obvious problems here: what about their families?  If they actually have any.  And their health?  Such people are creating health problems for themselves and society further down the line.

Then there are the hidden problems: these people can burn themselves out, and by the sounds of it these are people the company comes to depend on.  Second, these people enjoy their jobs but don't want to keep doing and eventually will quit, again the firm looses out.

For managers I think such extreme hours are a red flag: they say "This person can't delegate", they say "This person can't manage their own work load" - they should be prioritising more and cutting away the unnecessary items.

And what about the people who report to these managers, if these guys are always on the run when do they find time to sit down and give feedback to their staff?  When do they have time to help their reports develop? 

Even if they can find the time what kind of message are they sending to their workers?  First they are sending the message "I'm always busy, don't bother me" so they have closed their eyes and ears to problems, staff development and ideas from the shop floor.  Second they are making a very bad role model for those who might one day replace them.  XM's are only making their own lives worse.

The word the report doesn't use but should is "Sustainability."  These jobs are just not sustainable in the long run.  When you look at it this way the interesting thing is sustainability itself.  More and more this is the issue: for the environment, for personal health, for corporate success, for individual projects.  We need to move to a world were, at all levels, we do things in a sustainable way.

Unpaid overtime has always seemed a dangerous thing to me.  If a firm relies on its workers working 50, 60 or 70 hours a week but only pays them for 40 it isn't charging the true cost of its goods.  This is very true with software companies; you see development teams proud of pulling 60-hour weeks to ship a product.  The company may make a profit if it only pays for 40 hours but what if it had to pay the true cost, for 60 hours?  Quite possibly the profit disappears.

In other words, the business model does not work; in the short run you are dependent on the good-will of your workers to give money to your shareholders.  In the longer run this model is not sustainable either.  The replacement costs of the product are far higher than you think, the risks of product development are far higher and your dependency on individual's is far higher.

Over the long run not paying for overtime is not a win-win, its a loose-loose.  Your company shouldn't be proud its workers pull a 60+ hour week, its not commitment, its a sign that you don't understand your business.

So many bad companies in the world

It never ceases to amaze me how many bad companies there are in the world.  Companies that provide bad customer service, poor products, treat their employees badly, break all the rules in management books and yet continue to survive and trade, and even make profits.

Such companies grow to a certain size, usually not very big, a few hundred people at most, and then stagger on for years.  Sometime I think starting a company is as easy as falling off a log, it is growing of a company that takes skill.

Unfortunately I've worked for a few of these companies in my time and many of my friends still work for such firms.  It seems incredible to me that software firms don't invest in training, don't send their people to conference, these guys are in the knowledge business, how can they close their eyes?

And I wonder about restaurants were the food is poor and service worse.  Don't these guys ever eat in other restaurants?  Why should I wait 45 to get the bill? Does anyone ever come a second time?

Poor websites are one of the things that get me often.  Has anyone who works for British train companies ever booked a ticket online?  You can choose from about 8 different sites, each of which simply has a different skin over the same (poor) booking system.  Then the choice of tickets - why tell me about the tickets I can't buy?

Now I must say I do not include my last employer in this list, sure they laid me off but I actually consider them amongst the good - or at lest the neutral.  Sure they made mistakes and they weren't perfect but they were good, not bad. 

Good companies on the other hand seem to be few and far between.  Sometimes it seems there are so few of them I can name them: Toyota, Dell, Shell, Southwest Airlines, SAS Institute, my former employer, ... - OK, I know, I've read too many case studies at business school, the same names come up again and again.

Optimistically I want to believe that there is a silent majority of good companies out there that just don't get case studies written about them.  Actually, I think most of us assume that to be the case, that's why we keep looking for these companies, unfortunately it can be hard to tell them apart when you only have a few hours in an  interview. 

A suggestion for job hunters: do your own due diligence on potential employers, search the net for them, not just websites check news groups and mailing lists too.  See if you can get some financial information on them - I've been using UK Data and Companies House to get some financial background.  You might not find a lot but you might find a red flag.  Yes, you have to pay for these services but its not a lot of money when you look at your salary then multiply by several years.

Anyway, back to good companies...

I'm not saying the good companies are perfect, most of the companies I just named have slipped up at some time or another but on the whole they get it right.  But why are there so few good companies and so many bad companies?

So I have a theory.  The theory is in two parts.  I've already given you the first part: there is very little to stop you founding a company.  At least in the UK you can be banned from being a company director but you have to break the law first.  Many of the companies I'm talking about are just run bad, not illegally.

As long as you have some idea that is different enough from the competition you can get into business.  I'm not saying this is easy, look at the life expectancy of new companies, most fail.  I'm just saying that if some element of your product is good you can get up and running.  You could have a unique product, a great sales guy, you could be first into the market or just a good location for your shop or website.  This is all you need, you don't need to know much else, the better this one idea the worse you can be at everything else.

If you get that bit right you can get everything else wrong.  You can treat your staff badly, you can ignore strategy and you can ignore your customers.  And the longer you are in business the more entrenched your position will be.  Sure you are open to competition but as long as nobody notices you can continue.

(Advice for software companies: make sure you sell on going support and maintenance for your products.  I've seen companies survive for years on this revenue alone without selling anything new.)

The flip side is you probably won't grow very large, and if someone does notice your weakness they can easily topple you but in the meantime you can employ a bunch of people who don't actually have a good time working for you.  Thus explaining why so many people seem to work for bad employers.

The second part of this explanation is statistical: being a good company means doing a lot of things right.  First you still need the product, location, idea what ever, you still need that essential driver.

Then you need to do your product or idea well, you need to treat your customers well, you employees well and get everything else going well.  This is so much more difficult than being a bad company, there are a lot of ducks to get in the row.  And if you are successful you'll probably attract more attention from competitors - although you should be able to fight them off better.

So, simply because being a bad company is so much easier than being a good one I would expect there to be many more.

Now, under this model, every bad company reaches a size were it is just about manageable by the people who run it badly.  Think of this as the Peter Principle for companies if you like.  Some good companies will start off good but as they expand they'll get it wrong, expansion is hard and they too will hit the Peter Principle.

A few companies will get it all right.  They will manage the growth, they will keep the good product/idea/location.  These companies are real killers, they will be super successful.  Its just that there won't be very many of them because this is hard.

Consequently, most of my friends are condemned to work for bad companies.  Sorry.

I have to put a disclaimer in here.  I've never founded a company that employed anyone other than me. I've come close a couple of times but I've not done it.  Real entrepreneurs out there are quite right to say "What does he know?  He's never done it."  I agree, I've never done it.

All I'm saying is: to me, it looks like starting a company is as easy as falling off a log - provided you have an idea.  The hard bit is growing a company, keeping it good and avoiding the Peter Principle.

Introduction to Agile presentation online

Earlier this week I gave an Introduction to Agile presentation to a small company in central London.  This was a private presentation so no big conference or other named speakers.

Here is that presentation, please feel free to let me have your comments.  Did I miss anything?  How would you have done it differently?

And of course, if you would like me to deliver a similar presentation to your organization please get in touch.

 

Book review: Weinberg on Writing

As regular readers will have noticed I Write.  I write this blog, I occasionally contribute to ACCU journals – although I have contributed a lot more in the past – and I’m half way to writing a book. (I expect to sign the contract before Christmas now.)  Recently, I’ve become aware of the need to improve my writing so I thought I’d so in the time honoured way: by reading a book.  When someone recommended Weinberg on Writing I decided this was the book for me.

Gerry Weinberg is a minor legend in the computing field.  He’s probably most famous for one of his early books, The Psychology of Computer Programming (get the Silver Anniversary Edition) - it was in this book that he coined the term “Ego-less Programming”.  Since then he’s gone on to write many more books – if his publisher’s description is to be believed over 40.

(While we’re on the subject of Weinberg’s books, a quick note to my friend who asked me earlier today “How much should I charge for my consultancy services?”  The answer is in Weinberg’s The Secrets of Consulting even if you are not a consultant this book is worth reading.  There is lots of good advice for work and life generally.) 

In Weinberg on Writing he sets out to describe his Fieldstone method of writing.  Basically, this method entails collecting lots and lots of ideas for book section and assembling them into different books.  There is other advice for writers here but this is the subject he comes back to again and again.  As it happened, this technique isn’t a million miles from the way I write.  

Weinberg spends a lot of time on describing how to find and collect the fieldstones needed to write the book.  My problem tends to be the reverse.  I’m forever collecting stones, I see interesting ideas everywhere, its a question of finding the time to put these stones in good homes that I have.  Still, the blog and the current book use up lots.

I liked the book and although I found it covered a lot of territory I had already visited I still found good advice.  I probably would have found more value if I had completed more of the exercises he describes for budding writers.  I didn’t find any significant revelations in the book so in that way I was a little disappointed but again, I think thats because I’ve already addressed some of the issues in my own way.

If you are a budding writer then I highly recommend this book – and I recommend doing his exercises.  And if your not a budding writer then keep your eyes open for Weinberg’s other books, none of the others are about writing, many are about computing but not all, and they are all well written and useful.

 

IT does matter - at least sometimes

Ever since Nicholas Carr wrote IT doesn't matter there has been a well publicised debate on the real value of IT in modern businesses.  Sometimes Carr is right, commodity hardware and commodity software is good enough, there is no competitive advantage to be gained by going beyond cheap commodity products.

But sometimes IT does matter.  Sometimes IT can be the source of competitive advantage, sometimes it can help you do things you couldn't do otherwise.  I'm always on the look out for these instances and the front page of today's Financial Times gives a great example.

The London Stock Exchange (LSE) has just announced half year profits up from £26m to £76 - yes a three fold increase.  This is on trading volume up 42% to 744bn shares.  And the reason?  An improved IT system.

Over the last 10 years stock exchanges - and related institutions - have switched to electronic trading systems.  These have multiple advantages over the old "open outcry" systems: accuracy, speed, process automation, etc. etc.  Perhaps one of the biggest benefits is that electronic trading systems allow fully automated trading, a computer programmed with the right algorithms can conduct the trading.  This is more than just automating the process it is a radical change in the basis of share trading system and has helped hedge funds reach their current position.

Earlier this year the LSE introduced a new version of its trading system, SETS.  In reality this probably meant a software upgrade, perhaps a hardware upgrade, maybe even bandwidth upgrades.  The hardware is commodity boxes (Sun boxes I think) and the bandwidth is purchased from regular communication providers, the software is the interesting bit, this is specific to the LSE.  A change to the system usually means a software upgrade, and sometimes this can go wrong - like it did earlier this week at the London Metals Exchange (LME).

In the case of the LSE and its customers IT does matter, it allows them to do something different and it can make a big difference to the bottom line.  But it comes with risk, it matters because your business now depends on this stuff, like at the LME.

This IT is expensive and difficult to get right - I know, I worked on the Reuters end of the LIFFE Connect trading system when it went live in 1999.  As the LSE shows, when you get it right it makes a big difference.

However, IT also has its limits.  Its all to easy to dream up some big new idea, some strategy and say "Technology will implement it."  Technology has its limits and this can effect strategy is a very real way.  A good example of this is the problem Skype faces, describe by Robert X. Cringely in July.

Although most people think Skype is a pure peer-to-peer networking system it isn't.  Because of Network Address Translation (NAT) Skype needs to impose a server into most calls.  These don't have to be Skype’s own servers, they've worked out how to borrow server bandwidth from others but as the user base grows this will become a bigger problem.

For Skype there is no short or medium term way around this problem - their techno-business strategy means at some stage they had to get access to lots of server.  Consequently it was almost inevitable that they had to sell out to a big player like eBay or Google sooner or later to get access to more public servers.

Meanwhile, Skype, and similar VOIP technology, is changing the business strategy of other companies, obviously traditional telcos like AT&T and BT are vulnerable, so to are mobile operators like Vodafone but also  companies who simply use telephones - which is most of us – face change.  Even if in the long term VOIP becomes yet another commodity technology it is causing change now, and that is strategy and that is important.

So, there you have it, another reason why I still believe IT is important.  Ignoring IT in creating your strategy is wrong, letting it run the entire show is wrong, you need to find a middle way, which is were you need people who understand both.

Lessons from the Tu-144

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 So, lessons from the Tu-144

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

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

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

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

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

 

Book review: Learning for Action (SSM)

I’ve just finished reading Learning for Action by Peter Checkland and John Poulter (2006).  The book is an introduction to Soft Systems Methodology, or SSM for short.  Now I’ve read the book I have an understanding of what SSM is, how it might be used and why it would be useful.  I’m not about to run out and do any SSM but I now know when I might find it useful.

The book is well written and short – always a positive feature, although a little on the expensive side.  It is intended more for students than the casual readers but this doesn’t get in the way.  I think I made the right choice by starting with this SSM book rather than any other.

So, why did I read it?  Two reasons really.  First I’ve been talking about “Systems thinking” with some people and was wondering “How do you do it?” so I wanted to know more.  SSM is itself a form of systems thinking.  Second, I’d come across references to SSM on several occasions in the past and always meant to go back and read up on it so this was my chance.

Normally I run a mile from anything that claims to be a Big-M Methodology but on this occasion I’m quite impressed.  I think this is because SSM is very self-aware and the authors know the dangers of Methodology.  The roots of SSM are in Systems Engineering and related fields like Operational Research, the authors respect these fields but it was through recognising the limits on these techniques that SSM came to be.

So, despite my fear of Methodology I think this methodology looks useful in helping people step outside their normal environment and consider that environment from outside.  As such SSM facilitates and triggers learning – hence the title of the book.  It turns out that SSM is also a form of Action Research which is also from where Appreciative Inquiry began.  Once you know this several things fall into place, for example, SSM does not addresses “problems” but “problematic situations.”

Having read this I hope to have the opportunity to get involved with an SSM exercise in the not too distant future.

 

Business Patterns update

Back in July I took my latest work on Business Patterns – or Strategy Design Patterns for Technology Companies to give us a more descriptive title – to the EuroPLoP 2006 conference.  I got lots of good feedback on the work and I’ve finally had the time to finish updating the papers and post the revised versions on my website.

There are two papers:

• Situating Business Patterns – a paper about pattern theory and how it relates to business patterns.
• Patterns for Technology Companies – two more patterns in the series.

I’ve now collected quite a few business patterns and added some theory to support them – all available on my website.

What I should do now is compile all these papers into one PDF for easy access – and to cut out some of the boiler plate duplication that ends up in each paper.  That would also help me with the administration of these papers, I’ve run out of titles so I’m introducing a numbering system!

I had thought EuroPLoP 2006 would mark an end to the development of this series.  Instead I’m thinking about a few more patterns for next year.  There has been a little external interest in these patterns this year so maybe things will start to move.

 

Compare and contrast: Terminal 5 and Wembley Stadium

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

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

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

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

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

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

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

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

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

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

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

 

Book review: Software Ecosystems

Software Ecosystem by Messerschmitt and Szyperski (2003) is a book that was recommended to me about a year ago, a book I bought about 9 months ago, and one I started reading about four months ago.  I’m sorry to say I’ve only made it as far page 77 and I’m putting it on the shelf.

The book is interesting, the book is useful, the book does offer some insights into the software industry, the business of software and how software effects our business.  Yes I have learned things from this book.  The trouble is, the insights and learning don’t come along fast enough.  I feel as though I should read this book, it talks about business, software and the business of software but it idn’t a gripping read.

That I feel this is probably as much of a comment on me than it is on the book.  I’ve been around the IT industry in professionally for 15 years now and I’ve already learned much of what the book has to say.  Unfortunately, I think that is probably true for most of people who have been around the industry for half the time I have.  Certainly, if you’ve spent a few years in ITC and spent some time studying or thinking about the business you won’t find much new in this book.

Which begs the question: who is this book for?

Certainly the book has an academic style, the research style, it doesn’t present new research or long literature reviews, and it isn’t overdosed with references in the way academic research usually is.  So, my first thought is that this is a book for people studying the ITC industry – and software in particular.  It could almost be a text book for a course.

Yet something about the book doesn’t seem aimed at students.  While thinking about the audience I looked at the back cover were one commentor suggests “Marketers, programmers, consultants and lawyers all…” while another says “required reading for any student of the computer industry”.  I think the reviewers are right.

This is a book for people who don’t really understand the software industry and want to.  For such people this is a good book for bridging the divide between the business world they know and the strange world of software.

So, if you are a student who has this book on a course list then read it – or at least dip into it, its probably too long to read in one semester.  If you are a lawyer or a marketer who find they need to work with software people and understand the industry then read it.  But if your have an IT background, and you think about your industry, then there are better books to read.

All change

As some of you may have noticed I’ve been blogging a bit more in the last month.  There are two reasons for this.  First, I’ve started using BlogJet – more on this some other time, and second, I’ve got more time on my hands, my employer has downsized and I’m an ex-employee as of today.  This is a blog that returns again and again to the subject of change and here it is again.  My ex-employer has decided on some changes and those changes effect me. 

On the whole I’m skeptical about the power of corporate management to actually change a company, it always seems to me that the guy sitting at the top wearing the CEO hat has little power to change what the guy on the production line 6 layers below actually does.  I’m not saying you can’t, I’m just more of a believer in bottom-up strategy and change than top-down.  However, you can lay people off from the top and that effects everyone all the way down.

Lay-offs are a very blunt tool for this, sure they are a fast way of creating change but they are also a bit like rolling the dice and seeing what happens next.  You can probably have a fair idea what will happen when you axe an entire department or product line but when you pick people from all over the organization what happens next?  Sure you bottom line improves, but how does the organization fill those gaps?  Perhaps more importantly, how do you ensure that some gaps don’t get filled, say, you have decided to stop doing X, you can get rid of the people doing X but how do you make sure the people doing Y don’t try to cover for the loss?

This isn’t to say you shouldn’t downsize.  If improving the finances is the top priority do it.  Neither is it to say you shouldn’t do change this way, rolling the dice, shaking things up will produce change, as long as you have good people in place things should work out for the best.

Actually, I think a lot of change initiatives come down to rolling the dice.  When you introduce a change you can never be quite sure how things will turn out.  If you have a work force that is empowered, act under their own autonomy and are used to having freedom in their work then you never really know how they will react.  Conversely, if you have a work force that just does what is told and lives in fear of management you may well get unexpected behaviour as you ratchet up the pressure and fear.

So what can you do?  How do you weight the dice for a better outcome?

Well, in my model of the world management is like steering a boat.  You have a tiller and you constantly adjust it, so, as a manager you constantly communicate with your workers, you make it clear were you are trying to go and you are constantly applying minor changes to the tiller, a little left, a little right, a gentle touch to keep you going in the right direction – nothing too drastic.

Then you have the oars, one on the left, on the right.  These can complement or contradict the tiller – assuming you have both.  One oar is marked Leadership and the other is marked Authority, sometimes you give it a little leadership and sometimes you apply a little authority.  Hopefully you are going with the current so you can leave the oars out of the water most of the time and just use the tiller.  And thats the other part of the trick, to find the route that allows you to naturally go in the right direction.

Enough of company change, what about me?  How am I facing up to change?

First thing here is that I’ve just been through the British redundancy process.  I’ve seen people made redundant in Britain before and in the US.  The British process used to be a lot more like the US process: “Get your things, leave now” – short and sharp.  Now Britain is more “European” so it involves drawn out consultations.

The consultation process is supposed to be reasonable and fair.  I’m sure it works well if you are a car company and your closing and entire factory with unionised workers.  However, for a small, high-tech company with non-unionised workers its a pain for both managers and workers.

Managers naturally want to get the redundancies over and get the company back to normal.  Workers want certainty – both those staying and those going – but the British process drags it out.  Management are supposed to go into the process with an “open mind” (and can be prosecuted if they don’t) but workers don’t really believe this, they see game play and politics, they see managers stepping through a legal process because they have to with little hope of changing the outcome.

I’m sure some management groups do go into the process with a closed mind and set script but I’m also a believer in Occam’s Razor and I don’t think management start off with some script, stage directions and a pre-determined ending.

(I should make one thing clear, I have absolutely no idea at all how much of an open or closed mind my ex-employers had when they started their process.  I’m optimisitic and think they did have some openness but I have no idea how much.  My comments here are made in general from limited knowledge and experience.)

Anyway, now I’m unemployed and I need to get myself into gear for finding work – or at least earning money.  I suppose I should be spending all my time doing that.  Instead I’m spending a lot of time finalising the arrangements for my wedding next Saturday, on top of that I’m finishing off some writing projects and reflecting a bit on what has just happened – hence this blog entry.

And what next?

Well, I’d like to help companies build great software, and through building great software build great companies.  Both these objectives lead to one thing: building people.

Question is: how should I do this?

Well, I might just go and get myself another job as a Product Manager, a Project Manager, a Business Analyst, a Software Development Manager or something like this.  If you know of such a job call me!

Or, I might set up shop on my own and sell my consultancy services on these topics.

Sometimes it seems like I’ve done everything in software, I’ve been a developer, team leader, product manager, change agent, programmer, analyst, a system administrator, I’ve had a couple of entrepreneurial dabbles and a bunch of other stuff too.

So, if you know of any company that would like a few days advice on how to improve their software development process, practices and strategy let me know I’m available right now.

More stories for knowledge management

I went to the a lecture by Karl-Erik Sveiby – actually it was the UK launch of his new book Treading Lightly.  Karl-Erik is a professor of Knowledge Management at Hanken Business School in Helsinki and his new book discusses the use of stories by Australian aboriginal tribes to communicate knowledge over 60,000 years.

The story of how the Nhunggabarra tribe passed knowledge from generation to generation through the stories is also the story of how they kept their tribal law and the basis of their whole society.  At first I thought this form of story telling would be similar to that discussed by Stephen Denning in The Springboard and other books but it turns out there are differences.

For Denning stories are a way of communicating knowledge and creating change.  To this end the stories are designed so the listener can imagine themselves in the story and draw lessons quickly.  In contrast, the stories Sveiby talks about are used to communicate continuity and law, the stories are deeper and it takes months or years for the listener understand the full meaning of the stories.

While Sveiby and Denning seem to outline different types and stories and different uses for them I don’t think the two forms are mutually exclusive.  For Sveiby the stories are about passing on a culture, storing knowledge and ensuring sustainability.  For Denning stores are about creating change and refocusing knowledge.  Sveiby’s stories are thousands of years old while Denning's are new.  It just comes down to how you design your stories and what you are trying to achieve.

The important point is that people communicate and manage their knowledge through stories and these stories can be used for a variety of purposes.

There is a link to Patterns here.  In The Timeless Way of Building Christopher Alexander suggests that patterns for building are handed down from generation to generation – something that was largely a verbal tradition.  He also suggest that, particularly in the twentieth century, some patterns have been lost.  Therefore, to capture patterns for the future we need to document and formalize our patterns so we can communicate the designs.

I have been suggesting for a while that Patterns are a form of story.  In making this suggestion I have drawn on the work of Denning.  Now it seems that Sveiby’s description of stories also fit – Patterns are a means by which a culture can capture and pass on knowledge to future generations.  Which all goes to add support to the theory that Design Patterns are a form of story that contains knowledge.

Progress on Open Source CMS

Picking up my discussions about Content Management Systems… two things stand out: first “content management” is a broad topic and needs sub-dividing, second there seem to be thousands, if not millions of Open Source CMS systems out there.

Well, good news, bad news, good news.

Good news: there is a white paper from Seth Gottlielb at Optaros (January 2006) which is very useful in getting a grips with the Open Source problem and giving some hints on the sib-division problem – “Content Management Problems and Open Source Solutions.”

Bad news: I know some of the sub-divisions of CMS, things like “Document Management System”, “Web Content Management System” and “Enterprise Content Management System” but so far I haven’t found a good list of definitions.  How many sub-divisions are their?  When is a CMS “Enterprise” and when is it not?

Good news: I installed Joomla CMS this week – its a spin-off from Mambo – on WAMP (Windows, Apache, MySQL and PHP).  The install was actually quite painless, apart from a few problems getting PHP to work on Windows with Apache everything went well.

Anyway, thats it for now, just wanted to capture these thoughts, so much going on, lots of blog entries to come!

Bad role models make for poor management

I have read too many theories and ideas on management style for my own good.  Most of these theories suggest things like: listen to your people, work out what motivates them, give them good work, don’t order them around and so on.  Truth is: I agree with all of this, it makes sense to me to treat people with respect, assume they are cleaver and work with them rather than ordering them about.

Some people will say I’m just an idealist.  They may say that that kind of thinking is what separates books and ideas from the practical realities of life.  Some may go as far to say that because I believe all this “west coast” stuff I don’t understand how real management works.  And these people will point out to armies of managers and companies they have know who don’t take this advice.

Well, I can’t argue with the numbers.  I’m sure many managers and companies don’t take this kind of advice.  I’m sure an awful lot of them don’t even know about these ideas or even think about “management style” and what works. 

So what is the alternative?  The alternative, which I’ve taken to calling the “Hollywood style” or “Default management” (for reasons which will become clear in a moment) is all about Command and Control.  Its about telling people what you want them to do and just expecting them to do it.  As in a Hollywood film the manager always knows what is best, time is always pressing and the grunts on the ground just have to do it – if they don’t then just hold a gun to their head.  O, and everyone understands exactly what the manager wants. 

Managers who subscribe to this theory probably don’t know they even have a style.  They just do what they think a “manager” should do.  There are two sources for this theory.  

The first is Hollywood.  The all action hero, bursts onto the scene, tells people about the way it is, doesn’t explain how he is going to fix it but starts telling people what they should do: “secure the roof”, “get the women and children out the fire escape”, “stay low”, “cover me”.  He rushes off, beats the baddy and saves the day.  It is only him, the guy in charge who understands what needs to be done, everyone else falls in line, everyone does just what he asks and he saves them.

The second source is the way the military operates.  Or rather, the way us non-military types think the military operate.  Having seen a selection of old war films we think we know that the Generals at the top know everything, they tell the Colonels, who tell the Sergeants, who tell the men.  And then the guys on the ground just do it, they execute the plan – and its the plan that is all important.  In this model the CEO is the General, managers are Colonels and the guys on the guys at the code-face are the ones that get shot. 

For the record, I’ve read a little military history and I’ve known a couple of ex-military people, from what I can tell this isn’t necessarily how it happens but it is the model many people have in their head. 

So, getting back to managers.  It seems to me that many people get to be managers without actually discussing what it is a manager does.  They need to manage and they adopt the ideas and style they’ve seen in Hollywood films and what they think military commanders do.  Consequently this becomes the default management style for most people.

Tech companies, at least the software companies I’ve spent most of my life working for are particularly bad like this.  Software guys tend to get promoted because they are good technically, faced with the need to manage they use the default style.  Meanwhile, people who do think about this stuff are see as non-technical and consequently don’t get the chance to manage any other way. 

The more people who adopt the default style the more it seems like the style we should all follow – safety in numbers – while we deprive ourselves of role-models.

Unfortunately this means many people have bosses who have picked up everything they know about management from Hollywood films and out dated versions of military command and control.  Thus, these people never get to deliver their best which is a shame for them, their managers and the companies who employ them all.

 

Return to Content Mangement: 7 reasons for CMS

Regular readers of this blog may recall my on-off deliberations on Content Management Systems (CMS) – like this entry from last November.  Well, I’m at it again, this time I’m trying to come up with a simple solution for a better corporate intranet.  One thing I have learned is that talking of Content Management Systems this confusing, simply this is not a very useful name.  The problem they is content management covers such a wide field that when I say “content management” I mean one thing and when you say “content management” you mean to indifferent.

In fact we already have some widely used tools for content management, namely a hierarchical filing system (whether on our own PC or a shared network drive) and web-servers like Apache.  Given these the question becomes why do we want something more than these?

Well in the last few months I’ve thought of seven reasons why you might want to go beyond these basic tools.  And once you know why you want to go beyond these tools you can start to think about just what it is you want when you say "content management system".  So without further ado here are seven reasons why you might want a CMS.

1. CMS as a better Web server

In the same way that desktop publishing software represented a better form of word processor it seems CMS systems represent better web-servers.

2. CMS as a better filing system

Directories, folders, files and dryers are good but they are also complicated and it is easy to lose stuff.  Therefore having it “managed” is appealing.

3. Re-purpose content (re-purpose not re-use)

Sometimes we want to use the same content to different purposes.  For example technical authors write manuals and some of that content could be extracted and put into a help file, or online help system.  Similarly marketing literature may appear on the Internet, public website and in sales brochures.

4. Regulatory compliance

An increasing number of firms need to keep track of their documents and correspondence for audit purposes and to satisfy legal requirements.

5. Document life-cycle management

When is a document past its best?  When is a document to be replaced?  How do know that the latest version?  How do know document needs updating?

6. Version control documents

This follows on from the last two points but is worth calling out in its own right.  On a filing system (VAX and similar excepted) there is one document, if you want to version the document you have add a number to the file name and remember to update it.  This is laborious and complicates things especially then you need to track which version was in current at which time.

7. Document archive

Overtime all organizations collect more and more documents.  Many of these documents aren't needed on a day-to-day basis, in fact they are in a way day-to-day, but you need to keep them for reference purposes or because they might just contain some gem of knowledge that is useful sometime in the future.  (Again this tends be related to regulatory compliance but not always.)

So there are seven reasons why you might want a CMS.  It is not an exhaustive list by any means, in fact I’d welcome some more suggestions.

Public sector ITC

The Work Foundation (yes, odd name but it makes sense when you read their description of themselves) has released a report on public sector IT projects. 

Sometimes it seems hardly a week goes by in the UK without the media publicizing another failed Government IT project.  This report – and at 43 pages I haven’t read it all (yet) just executive summary and the conclusions – looks like a valuable and informed contribution to this debate.

The report is called How ICT? and is free.  (There is also a short summary in the FT – you might need a subscription.)  Interestingly this report has tried to look at technology projects from the point of view of the end-users, the workers on the front-line.  Its these people who use the system daily, these people who will see the immediate benefits or the immediate problems, and its the attempt to make these people more productive that the projects are all about.

(By the way, has anyone else noticed IT is no longer IT but ICT – Information and Communication Technology.  Thats another TLA to put next to IMS and IS and IM and …)

So what does the report say?

Well, ICT is about more than technology.  Its about changing the processes people use, its about the people involved in the processes and it is about the technology too.  Yes you have to manage the technology but its not the only problem, you need to carry the people with you and change the way they work to get the benefits.

The report also recommends: “Strong project management skills are vital” – it fills me full of thoughts of project managers with GANT charts – but then goes on to say “projects should be broken down into manageable chunks” which sound much more reasonable, then “a structure created for planning and monitoring progress” which seems entirely sensible.

Of course the report doesn’t say anything about how you should run your development effort but everything I’ve read so far suggests it is entirely possible to run it on Agile/Lean principles.

Although the report is about the public sector I think most private sector organizations could benefit from having a look at it.

Running as an analogy for software developers

Mail arrives from an old friend in Silicon Valley:

“So just as we get back from the show to recover, rebuild relationships with our wives and kids (since we've been working constantly for 3 weeks prior) they want us to drop everything again”

Meanwhile, a different friend tells me that he doesn’t know when his project deadline is.  He’s got his burn down chart that shows when he thinks he’ll finish but this doesn’t seem to matter to anyone just now.

So, what do these two, apparently opposite situations have in common?

Well, it makes me think that developing software is a lot like running a race.  I’m know I’m not the first to think of running as metaphor, after all SCRUM actually has development sprints but not every development is a sprint.

It all comes down to distance.  First of all, you need to know how far you are going to run, you need to know were the finishing line is.  We might start projects with only a vague idea of the deadline: next November should; and even if we do know it might get changed.  The thing is, when your deadline is makes a difference.

Unfortunately the deadline is all too often the finishing point.  Personally I like to pace myself so my work is finished before I get to the deadline.  There are two problems here.  First: all too often we’re asked to do more work than is actually possible in the time allowed.  We try and put a quart into a pint jug.  Gung-ho management can actually make this sound like a good thing.  However, if management don’t prioritize and give guidance on what to do they are really abdicating their responsibilities to developers.  They are saying:

“We want to you to do all this work, this is a challenge to you.  We don’t want to know if you can’t fit it all in, just make it fit somehow.”

So, either they have to extend the deadline, or they get a selection of requested work chosen by the developers.

The second reason why my approach fails is the tendency for people to say “Arh you’ve finished, in that case you’ve got time to do this as well…” and increase my load.

Still, back to the race analogy.

If I’m running a sprint I know I need to run just as fast as I can.  I know it will soon be over and I can recover.  I know that if I have a chance to pass someone I have to take it, there may be risk but there probably won’t be a second chance.  In a sprint the start and end are clearly defined and its a straight run.

Thats different to a 400m, you still have to run damn fast but there is an element of pacing.  You will get second chances to overtake someone but you won’t get many – so the risk equation changes.

An 800m changes things again, its much more about pacing yourself, and the risks are different again.

Normally developing software is something like a 800m.  You have near deadline but its not so close that you drop everything.  Sometimes when you have a 100m deadline you drop everything else in your life.  I did once port a piece of software overnight.  Six of us: Roy and me coding (porting) like nothing else mattered, two more developers riding shotgun, and two managers ordering take-away food and biting their finger nails.  We took risks and worked in a way we would never have done if we had another day, let alone another week or a month.

And on a long run, like a marathon, things change again.  Its all about pacing yourself, you need to know when to run fast, when to hold back.  You need to stay on the course, often you find it is not well sign posted so you need milestones and navigators to help you.  Although your competing with the others in the race your also co-operating in a way.

Or maybe development is more like a relay-race, you have to work as a team.  Or maybe its like hurdling, someone puts obstacles in the way.

So what does this analogy teach us?

I think it emphasizes the importance of pacing yourself.  You might be able to run 100m fast but running 800m is not the same as running eight 100m races back to back.  Everyone knows this about running so why don’t they see it in development?