Page 2 of 41

Generic is the wrong answer

Dear reader, cast your mind back to the time when you first wanted to put some information on a website.

You had to trust the crusty programmer types, and if you wanted changes they wouldn’t necessarily be able to do them at any great speed. This was fine in the stone age, around the year 2000 or probably earlier. Then, one day, the technology started to catch up with the aspirations and everything had to be done at internet speed. So crusty developed less crusty tools that let things happen quite a bit quicker.

We suddenly had content that people created for themselves. Never to be outdone the constant search for simple generic solutions to be everything meant that the companies that made the very expensive PC based tools for document management had a go at creating something. Some of their original big corporate customers kept on with them. These systems don’t work for the internet, except when you are creating some kind of library, which is the metaphor they started with.

The more considered approach was to treat managing content like it was a solved problem. The content management system (CMS) was born (or at least became more mainstream) and allowed you to manage your catalogue in one place so you could, you know, sell your stuff to people that wanted it.

Then we fell victim to the illusion of best practice. Problems are in a space where they seem to be the same, so we (software engineers, academics and other people who should know better) develop generic solutions. I mean, content is just abstract stuff that we let those tricky user types create so they can pay us. We can just pull something open source or off the shelf and say off you go to them and get back to important stuff like arguing over which 20 year old text editor is best.

But here’s the thing. The pattern user -> catalogue -> put catalog on the interwebs in front of customers is the same, but the user / business / enterprise is most definitely not. Most (not all) open source CMS were created for a small community to share info – they do that really well. However, a commercial company that sells white goods does not have even remotely the same needs as one that sells online holidays where the stock is a multi lingual database of hotels they have a relationship with. They need content management, the thing, but not in the same way, and the OSS solution is probably completely wrong. Also – you don’t want your site to look exactly like your competitors or you are competing on price, which is suicide.

Human beings are subject to pareidolia. Seeing patterns that aren’t there in the data. This is also related to clustering, confirmation and congruence biases. When it meant running away from the wind in the grass because you thought it was a lion that was ok. Now we look for levers to fix and change things that often don’t exist. Eric Reiss calls this robots in the Lean Startup. He cites the case when the US manufacturers couldn’t work out how the Japanese were getting such massive productivity gains so they went to see and saw robots. After a robot installing frenzy the US was still far behind. The Japanese spent a lot of energy understanding how they did things first and put the automation in where it made sense, gradually, and always testing the results, for their specific needs. Good practice, but hard to emulate without a complete culture change. Pareidolia (and the other biases) put robots inside processes that were still broken. In knowledge work this is even easier because adopting the latest fad is only the cost of a couple of books and some (more) training, until your organisation fails catastrophically. Danger, Will Robinson.

Best practice only works in very simple environments where all of the problems are completely understood. Buying a CMS from someone assumes that they understand your needs properly. They probably don’t. It’s dangerous.

Good practice means the using the skills of analysing the problem properly and divining the principles you should follow. A company should control its own content; after all that’s what it’s selling. This means layout, search, everything. However you might use a markup language and a standard group of elements for layout to make it easy for non-web heads to create that content. Find levers for the easy stuff, for the things that do have generic solutions that work.

Startups don’t want to spend money on stuff like a CMS that is tailored to their needs and will tend to go for the OSS solution. I think that they need to start small and find out what those needs are, just like everything in the lean approach. So don’t buy one, and don’t slavishly pull in an OSS one that will bite you and turn out to be an expensive mistake. Create something as simple as possible that meets your needs, then you will know what the needs are and where the pain is. Then you can use good practice to get to where you want to be. Then you can find the metaphor that works for you, and let your competitors try and shoe horn someone else’s into places they don’t work.

Best practice implies generic – generic means cheapest and also (face it) BORING.

Good practice is searching for the right metaphors and being patient enough to wait for them to appear. And, of course, those metaphors are the ones that work for you, might not be right for someone else.

Why I hate todo list apps

I recently had a twitter discussion about why I don’t like using Basecamp.

It’s a bit weird, I love Rails and it originated from the need to create a stable framework to create Basecamp. DHH and his colleagues were generous enough to share it with the rest of us and I’ve been using it for years to great effect. I admire DHH and the guys at the company and have read their books. But I hate their product. Using it makes me feel depressed.

I can’t see the flexibility others see anywhere. They are a poster child for great design and easy UI and it’s pretty dull and obvious, maybe that’s what the fuss is about. I’ve used it off and on for years and it doesn’t seem to have substantively changed in all that time, yet there are allegedly changes and improvements happening to it constantly. It’s also boring, even more boring than the bazillion sites you see built on top of Twitter Bootstrap – because they usually have some metaphor the coders are exploring and bootstrap’s a quick way to make it presentable while they experiment.

But the main thing is I can’t stand todo list apps.

This comes out of the way I work and think. I will write todo lists on paper and cross them off, but for anything bigger than just me (and up to 5 items) I need to visualise it and look at the flow and commitment of work. You can’t do this with static text-based lists without doing a lot of counting in your head. As far as I can work out you can’t create a different visualisation (in Basecamp) where you have a private list taken from other lists of things you care about today in the order that matters to you without creating another list that isn’t linked to the original tasks so you’d have to close everything twice. It hasn’t changed in years.

In the physical world you can do this with sticky notes or file cards and a bit of blu tac to put each piece of work into something that can be visualised and moved about. It doesn’t have to be complex, but nicking ideas from scrum and kanban around allocating points for pieces of work and limiting your work in progress (WIP) you can come up with something that lets you look at your pipeline and your commitments so you can start to have grown up conversations with other people about priorities and schedules. Limiting your WIP also gives you a far better chance of actually getting something worthwhile done. This is a big win over boring lists, but harder to understand at first.

Todo lists are, I think, a great tool for linear thinking and controlling.*

The metaphor lists give you is the linear instruction manual, codes, all you can do is change their priority and create more items. They also suffer from being unbounded, so you can just keep adding to them and never finish. There’s a very interesting time management book by Mark Forster called Do it Tomorrow. In it I found the idea of a closed list. This is a list you don’t add to and work on until it’s done – he’s discovered this makes you more productive and also you start tackling the tasks you really don’t want to do because you can’t close the list off until you’ve done them. This is a great antidote to procrastination. It’s also limiting your WIP. In fact it’s a different take on the same idea as a personal productivity booster.

So, in essence, for me the list metaphor stifles your ability to think and visualise without a lot of effort breaking out of the mental straightjackets it puts you in. There are better metaphors that allow you to easily move work about and discuss it properly with stake holders. So use them a little for small tasks, but for the big stuff – use bigger metaphors. I also think gantt charts cause similar cognitive blindness when you use them for anything other than checking if you are still on track.

* Aside: I was going to use the phrase command and control. The original meaning of this was simply that military operations have a designated officer who is responsible for seeing the mission through. How that officer does it is not defined. Some systems thinkers, for example John Seddon, use this term to mean enterprises where the people doing the work are not expected to show any initiative and be told what to do all the time so everything costs a fortune and is badly done by people who could do a much better job if left alone to do it properly. Military operations don’t work like this, people are trusted to do what their training tells them so they can achieve their objectives, see commander’s intent. Seddon’s meaning seems to have triumphed in systems thinking debates, however.

Towards a Lean Manifesto

Towards a lean manifesto

Tiny steps make things of beauty

Over a hundred years ago somebody thought it would be a good idea to make everything in tiny little steps. Each step could be done by an idiot pulling a handle. The hard part of the work was working out what the small steps were and how to put them in an order that would produce something as useful and complex as, say, a car. This somebody was Henry Ford.

If you want to make several things you need to reconfigure the more complex machines. Because this takes time and effort you will try and make sure you make lots of pieces with the complex machines before each change over. If you suddenly need to make something else because of a change in demand, the demand will have to wait.

If one of the parts of the long process to make something useful starts making things that are defective in some way the idiot will carry on pulling the handle, because that’s what they are paid to do. They aren’t paid to think or even notice that pulling the handle is making broken things.

You have to ask yourself: why do people think this is a good idea? and, who is the idiot? The person pulling the lever is at least getting paid to do it.

Before this components were made to approximate dimensions and a factory consisted of highly skilled workers putting these parts together and fettling them. Every car was in essence hand made and no two were identical, parts could not be swapped without refitting. This is where the job title of fitter comes from originally. It was a highly skilled craft job. Ford changed all this and made his cars essentially the same, and also made them so that they could be maintained by someone with a decent set of teeth and a hammer.

In essence the discovery that dividing labour up, and making the parts produced by that labour much more standard, and placing them on a moving conveyor where they are assembled in order was the beginnings of what we call mass production now. It didn’t need the highly skilled workers. That said, even Ford’s factory still had people who had the job of fettling cars that weren’t quite right, and they used to ship ones that had faults. It didn’t matter as long as they were being shipped. If you could read and were in possession of the kind of tools you would find in a farm you could get it running and the price was right.

By the way, the assertion that Ford said you can have any colour you want as long as it’s black is a myth. The early model T’s were dark green and navy blue.[^ModelT]

Beauty turns ugly

If you worked in one of these factories you were dehumanised. You were pulling a lever and didn’t need much education. Ford famously paid his workers well. He could afford to because he was producing so many cars at a relatively low cost. He still had a lot of trouble getting enough people to do this, and turnover was quite high.

The highly inflexible approach to building the cars also meant that producing new models was really difficult once the line got rolling. The entire assembly plant had to be reconfigured for every change. A new model could mean months of close down and disruption and then trying to reassemble the workforce you’d laid off.

Inflexibility had another cost, if sequences of operations were done in a way that was suboptimal changing them was nigh on impossible. If you multiply something that even adds a few seconds to a process by several million cars then this becomes a significant cost you can’t do anything about.

Workers could be added and removed depending on the demand, and were regarded as disposable and replaceable, which is how a lot of capitalists still operate.

Once upon a time in the East

After the second world war there was a small company called Toyota trying to make cars for the domestic market in Japan. They didn’t have a lot of capital to buy many different machines, and neither did they have lots of orders for the same kind of car. They also had to cope with a law that said they weren’t allowed to lay people off if they had no work for them. This meant they needed to be able to produce different types of car from the same set of equipment without a lot of ceremony and also that they needed to keep their workers happy and productive for 20 or 30 years.[^MachineThatChangedTheWorld]

Their productivity was about a third of that in Germany. This was in itself a third of the USA. So around 10% of the most productive people around.[^Bryant]

They tried many things and managed to get changing the complex machinery that stamps out body parts down to a few minutes when on paper it should take hours or even days. If things needed to be moved around to make the line run a little quicker they were. Workers were expected to become problem solvers, not beasts of burden. If pulling the handle meant creating defects you pulled a different handle that stopped everything until the problem was solved.

You got paid more depending on your seniority, on what you could bring to the organisation, not on your job title. The more senior you are, the better problem solver you have become. There’s also little point in jumping to another company, you will be paid a lot less and have to start again. The Western approach of having a narrow specialism and then progressing from junior to senior while hopping from company to company did not apply. Taiichi Ohno, one of the shepherds of these ideas, talked about creating work that’s fit for humans. This makes machines the slaves and humans the masters, which is the way it should be.

By the late 1970’s the productivity picture went entirely the other way.


Mass production is obsessed with efficiency, doing each step as fast as possible. Things that are relatively slow end up with piles of stock upstream of them. Things that are relatively fast end up with nothing to do. If each step is run as efficiently as possible you come to find that the system as a whole is anything but efficient. There’s a term for the efficient approach: local optimisation, as in each person optimises what they do with no regard for the system as a whole.

Instead Ohno traded efficiency for effectiveness. Not just doing but doing the right thing. Only making things that need to be made. Effectiveness is making enough to meet the needs of the business with a cadence that minimises the amount of defects, of stopping when defects are found and finding the root cause of them.

Piecework, which is where workers are rewarded for making a number of pieces, is an early form of trying to use targets to make things work properly. But if you have to make 15 widgets to get paid a living wage by the close of the working day you will make them any old how, and maybe try to make some more if you will get paid for them. So the human being will keep pulling the lever because that’s what they’re paid to do by the idiot who owns the lever.


After something has been made it’s a bit late to see if it works properly. If you have thousands of them and they’re all broken it is also a very expensive mistake. If you optimise each step for its own sake you this is where you end up. Everybody has been doing their best by staring at their feet instead of looking at how what they do fits with everyone else.

If your culture is a problem solving culture, where everyone is listened to, then good quality will just become something you are, rather than something you do after the fact.


It’s easy to point at manufacturers of stuff and say they should eschew local optimisation in their production processes. It’s also easy say that there are benefits in pulling groups of similar products together and creating systems that can switch between them easily.

In knowledge work we can say that this doesn’t affect us because we don’t make a physical product. We can make sure that our department is as efficient as possible. We can incentivise with targets and arbitrary bonuses.

If you take a few steps back from this and think of the departments that make up an enterprise of any size you will find that you have processes that pass information between them. You will also find that there are places where this information (or stock, in fact) is gathered and starts decaying and becoming a problem. It’s the same issue of local optimisation but hidden away in the rough and tumble of operating a company; you have the departments because that’s what everybody else does. What you know, of course, is that everybody else is also struggling with quality and getting things done but just accepting it as part of the status quo.

In Lean Thinking Womak and Jones talk through a case study of a manufacturer of stretch wrapping machines. They attack the production problems and get a 40% (and more later) increase in capacity without employing any new people, they shrink their lead time from months to less than a week. Because they no longer needed to hold onto lots of unusable stock they did this without needing any more space. They no longer have to ask people to expedite orders because all orders are being delivered on time or early, the average number of defects falls from 6 per machine to less than one. They pay their workers well above the industry average because they are so much more productive so everybody wins. All of this is amazing. Then they realise that their sales process takes up to six weeks.

You need to turn the searchlight on the whole enterprise. Just because you make something intangible doesn’t mean you shouldn’t question your thinking and how you do things. In some ways it’s much easier for you because you haven’t got the expense of moving heavy machines about to make your production lines more effective, in others it’s bad because you don’t see the pain. A pile of physical things costing you money and decaying into worthlessness is easier to see.

The silo metaphor is used to describe the separation of concerns into their own departments. People work for departments, not the enterprise, and their objectives align with that narrow view. Then of course we can start playing the blame game. A siloed organisation is maladaptive and usually blind to its own faults. This is one of the reasons small companies are much more nimble – they have less silos, less accretion of bony substance to choke on.

For those readers who work in the IT function, this is why you are always the blame monkey: you have too many masters. More enlightened organisations that are now breaking their offerings down into product groups or using product focussed multi functional teams that have the job of meeting specific customer needs directly without having to go and beg for resources from several different departments. This usually means the middle management tier are no longer required. Their job was originally to co-ordinate between the silos. When you have no silos you don’t need to negotiate and there are no empires to defend. These companies are winning, they actually manage do do the more with less mantra without it being another corporate self delusion.


The thing to pursue in your quest for effectiveness is value. Value is that thing that your customer has in their hand and wants to pay you for. Whatever you do, this is what matters. If you look at what you do and can’t see value then you know that you should stop doing it.

One of the first things that you need to be able to do is see what your constancy of purpose is – whose problems do we solve, how, and what makes us special? This gives you your value proposition. Then you can use this to examine what you do and throw out all of the things that don’t fit. It’s very liberating.

The British Olympic rowing team spent 4 years with the mantra does it make the boat go faster? They took this single minded approach after losing by a few hundredths of a second. It meant that every decision they made suddenly became easier, there was no deed for debate. If it goes faster, keep doing it, if not stop doing it. Very simple.


A customer expresses a need. The steps you follow and information passed between people to meet that need are the flow. The flow is different for each organisation, even in the same industry each will have its own history and steps it follows when the people working there worked out how to do things. This is why best practice is often a myth. Unless of course that best practice is a way of thinking about customer needs.

You can go on waste walks, where you follow a customer need for value all the way through and look for where you are doing things you shouldn’t. Ohno had three things he used to say you need to do when working to improve things.

  • Go see
  • Ask why
  • Show respect

In the West we are awful at showing respect and we often stop at the first answer when asking why. Ohno developed a technique called the 5 whys – you keep asking why until the primary reason is uncovered. It may well be a lot more than 5 times, or only two or three. One of the main purposes of this is to get past the blame game and off to the root causes of problems.

Showing respect means that you should never treat the people doing the work like idiots or fools. They are doing what they were told to do, and if there is anything they perhaps shouldn’t be doing it’s roots lie in how the work was originally organised. Quite often they know a better way and can tell you what it is once you remove the earplugs of arrogance and compromise.

Dirty flow

If the next step in a process can’t happen because the information or thing passed to it is wrong or incomplete then you have to go back and fix it. The flow is dirty. This is often a place where you find hidden costs, and is often why silos are so bad – the problems inside each department aren’t obvious because that department works well in its own terms. It’s only when you look at the interfaces you start to see where the pain is.

This is why the purchasing department buys cheaper tools that make the creation of defective products so much easier. This is why competing on costs is an insanely bad idea.

Visualise the work

One of the most useful and easy things you can pick up from this is the Kanban board. Kanban just means something like sign in Japanese. The boards are used so that everybody working can see where the work pieces are. They also limit the work in progress (WIP), if you hit a WIP limit you know there’s a problem before it causes you a lot of pain.

You can create Kanban boards for every endeavour, I use Personal Kanban, which in essence consists of the sentences visualise the work and limit the WIP for most of my work. I have to switch between projects so I have many boards.

It doesn’t have to be a board, people have used mind maps. When I ran a workshop recently someone just drew a picture with some illustrations of that things looked like and some arrows. The important thing is that everyone can see what’s going on.

Compromise is bad

Good enough isn’t good enough. If you only expect 80% from a process or person then you will be lucky to get 50%. Always striving for 100% means you can uncover ways to improve. Again this means leaving egos at the door and questioning everything.

Goldratt’s book The Choice talks about his approach to problem solving. He was regarded as a genius by many of the people he worked with because he could see problems with great clarity.

Goldratt would look at very complex seeming systems in manufacturing, retail or project management and seem to be able to get to the kernel of what they are about. In the book he says that it doesn’t matter what the veneer of complexity is (one company profiled makes hundreds of products with a bewildering variety of products and variations) you can find a couple of simple levers that drive the whole business. He insists that it’s not genius, it’s taking the time to see clearly and not compromising on good enough.

He said was that we become habituated to difficult problems and start living with them. This cognitive blindness means that usually takes an external consultant or new manager to point out there is a better way. In order to reduce conflict we compromise with whatever’s causing the pain and then act like it can never change. You should never listen to or be taken in by compromises like this. Just as there is always a simple lever, and there is always a way to address problems where everybody wins, you just have to push really hard at it.

Typically his consultancy would find huge savings by applying their knowledge of constraints for the client, and then find at least the same again by helping the client work out problems with suppliers and customers, and then find even more by going around the loop again. Never believe you’ve finished in the process of improvement. Today’s great idea can work for a while and then become a bad idea. Things change – it’s the only certain thing in life.

Ohno would strive to improve product lines that were being phased out until the very last day, you can still learn from the improvements and why not keep your money in your pocket?


If you work for an efficient organisation and dare to be stood around you will be told to find something to do. Effective organisations have slack, where people can think about things and also where they are available to meet short term needs or swarm on problems. In finance they talk about liquidity, which means that not all of the resources are committed. Some of them are kept back so that they can be used to overcome short term problems in the market. You can do the same thing with people. But, please, stop calling them resources. Staplers and pencils don’t have initiative or drive, they are very bad at problem solving without the help of a friendly human.


Not all of the changes you try will have a positive effect, sometimes they will make things worse. This is part of discovering what works. You need to have experiments that can fail without destroying the company. You also need to say what success and failure look like before you make any changes. You may not be able to say anything quantitative, or only guess at an improvement. This is fine.

We have been involved in a lot of software changes where all we were supposed to do was ratify a pet idea coming from the board. So there wasn’t any point in calling it an experiment or even collecting any data. If you are doing this just be honest about it or it devalues the process.

Small batches

An accidental product of the Toyota way of organising work was they used small batches to make relatively small runs of specific cars. Then they realised that this meant they were only making what they needed to without having to create a lot of stock and the machines were running at the right cadence to deliver.

Jim Benson, one of the originators of Personal Kanban, says that big batches can kill and I agree with him. They take up space, they decay over time, and if you have introduced defects you end up with lots of them instead of a few you can throw away or recycle.

This also means that you probably don’t run into constraints in the way Goldratt talks about, where they control the whole process. Small batches and reasonable buffers stop constraints from … constraining you. That said, understanding Goldratt’s ideas gives you some more tools if you become stuck.


If there are a lot of steps to deliver value you can have one of them stop working for a while because stuff happens. You need to be able to keep moving, so having a small buffer upstream of any complex or expensive processes means you can keep running while you sort it out. These processes are your constraints.

Projects are evil

If you want a can of beans you can go buy one. If you want to do something new or different with your customer you can’t go buy that capability. Projects start from the false assumption that you can buy things like market share or better quality. What you can do is experiment and overcome your ignorance, then you can see how the knowledge you have gained can be used to improve or avoid mistakes.

Budgets are evil

Budgets buy projects that buy beans, not capability. Instead a pool of money for experiments is needed. This mitigates risk and makes sure you aren’t throwing your money at white elephant projects that won’t add value.

So a budget becomes how much you are willing to spend on experiments discovering new markets or enhancing what you’ve already got. You can stop spending when you realise it’s not worth it any more and do something else. This is also very liberating.

It does mean that the simpleminded invest a couple of bucks and get four bucks back model doesn’t work. It used to in the days of massive brands and lack of choice, which ended in the 1980’s.

A Lean Manifesto

We acknowledge that lean has become a brand. Despite this we feel it is less compromised than agile has sadly become, and also has a much broader remit that software alone.

In brief:

  • Preferring work that’s fit for humans over humans fitting work
  • Preferring shared visualisation over unread documentation
  • Preferring rational continuous improvement over slogans
  • Preferring testing over guessing and waste
  • Preferring 100% over good enough
  • Preferring collaboration over winning
  • Preferring feedback over fire fighting
  • Preferring value over bureaucracy

Everything we do is contingent on discovering a better way

Theory comes from doing and seeing

Theory is contingent on discovering better theory

The only constant is change

If we learn we do not fail

Deming and the 95%

A few people have commented on twitter about Deming’s contention that 95% of what you see is down to the system and only 5% is down to the individual. They keep asking where he got the 95% from.

He used to run a course, which is still available as a book: Four Days with Doctor Deming. At the very beginning of the course he invited the participants to play a game with red and white beads. There’s a youtube video describing it here. The you pick up beads with paddles, the workers are rewarded for picking up white beads and punished for red, even ‘fired’.

When you look at the numbers for the game it turns out that the workers have no control over the physical process of selecting the beads. In one trial someone may do really well, and in another badly and get ‘fired’.

In statistics we use confidence limits. When we take a new measurement you look at it and can perform some analysis to say how likely it is that the measurement falls inside the existing set of measurements. Typically we use the 95% confidence limit to say that there is a one in twenty chance that the measurement doesn’t fit what we were expecting. If it falls inside then we have what’s known as the null hypothesis, that there isn’t any noticeable effect for that particular measurement.

Deming’s point was that in most processes any effect that the individual may have is swamped by the system their are part of, in fact the variability they cause is just part of that system overall. So if measurements are falling within the confidence limits you can’t point to one person over another and say they’re better or worse.

So changing things, for better or worse, mean you have to change the entire system. It’s an iron rule, the system always wins. No amount of arbitrary targets, shouting, or wishing can change this. I cover this in more detail in the video talks on my consultancy website.

A life without the standards police

In any complicated endeavour there are some things that can really cause you to get a little stuck and working on stuff that’s just not important. When working with teams it’s pretty important to ensure that each team has a similar approach to things like how they realise architecture, lay out applications and code, which of the excellent JavaScript libraries they use and so on. Otherwise it starts to create silos and mean that there is waste when you try to manage the flow across teams.

One way of doing this is to have some kind of gatekeeper who inspects everything and makes sure it complies. This is the standard backwards command and control way of assuring quality: do the inspection after you can perform any intervention that might resolve the problem. It also means you have guaranteed that there will be a bottleneck. Of course, you can have it in front of any work, where there is some kind of oversight. This just means the delay is upstream of any value instead of down.

Instead, there’s an old trick, which is to have swat teams. These are teams made up of experienced individuals who know each other well and work together. Their job is to start new projects, but not finish them. They also work with teams that are stuck or lagging to help them get past whatever problems they have.

The swat team hands off to the less experienced team that will finish the job, it means that there is already a body of knowledge of how we approach things, what the architecture is, etc. built into the project. Of course, this will require pairing and patience. But it means that work gets started well, in a standard way, with all of the levers for continuous improvement in place, by people who know how to do this. Then it’s picked up by others who learn what the standard approach is, without a gatekeeper and a lot of bureaucracy.

This is a team version of staff liquidity, which is discussed in the Commitment book. Staff liquidity uses experts’ knowledge and skills in such a way as to make sure there is enough slack to deal with emergencies and still get the work done.

Next release of Unicorns in the Mist, speaking tour of the UK

I’ve just released another version of Unicorns in the Mist and working on building my consultancy portfolio. Have a look at FJFDIDM to see what I’ve been doing. All of the video content is here.

Speaking at Lean Agile Scotland – this is September 19-20 2013 in Edinburgh. The talk is based on the new material presented in the September 2013 release of the book.

Speaking at Agile Cambridge this is September 24-27th, 2013 at Churchill College, Cambridge UK. This is an updated reprise of the “it’s not your fault” talk on the consultancy site. I believe that InfoQ will be filming the session and I’m proud to follow in the footsteps of many people I admire.

I’m attending, but not speaking at, Design it, Build it which is 7-8th October at Gateshead, UK (the 8th is my birthday).

I’m also going to Lean Conf 2013 which is 26-27th October in Manchester. So, if any readers want to talk to me please seek me out if you are at any of these events, they’re all worth going to.

Indistinguishable From Magic: Shaming, Social Media, and the Impact of Online Power

Indistinguishable From Magic: Shaming, Social Media, and the Impact of Online Power

Tom Morris: I’m not an experience-seeking user, I’m a meaning-seeking human person

Tom Morris: I’m not an experience-seeking user, I’m a meaning-seeking human person

How I coach

The process and the people

I am a Level 3 Kayak (L3K) coach and have been for several years, probably around 15. In the software industry there are a lot of folk who call themselves coaches, but I do find myself wondering if they’ve ever had any kind of formal training. It took me a lot of time, money and personal risk to become a coach and I don’t regret it at all.

By the way, I don’t consider a three day Scrum Master course to be formal training. I had to meet the prerequisites, which were things like being a Level 2 coach, and holding various first aid and rescue qualifications. Then I had to do a three day course, where I became a candidate, then I had to amass at least 50 documented hours of supervised coaching, and then I had to do another 3 days assessment. The people running these courses had to go through very stringent criteria to run them.

I also have to attend recognised events every few years to make sure I’m still up to date. I don’t see this in the software industry. I do see a lot of pretence and bureaucratic certification, but that’s a different thing.

A L3K can take people on white water, assuming he or she feels they are competent and the group isn’t too big. In fact I spend a lot of time working on flat water with the Guides and Brownies, which means I work with total beginners aged between 8 and 10 who can’t even hold the paddle. Many coaches don’t like this, they want to work with older and more experienced paddlers.

I love it. It means I have to keep going back to the beginning and making sure I can express them in ways people can understand. It means I never lose contact with the fundamentals. There is a story about an American football coach, who used to begin every training season holding a ball and saying gentlemen, this is a ball. You have to have the fundamentals or you won’t go far, and you have to return to them or you may lose your way. 

People learn by doing. There is no substitute for this, but equally there is  a problem where you can create an ingrained habit that is a bad habit, where that habit holds you back. This makes coaching a very tricky proposition, it’s not practice makes perfect. Although this is true, it’s perfect practice makes perfect. You need the input of someone standing outside where you are, who knows the common faults and their solution. Then you need to be willing to sometimes start again, or at least it feels like it. You need to be practicing in a way that grows your skill, not embeds problems.

For example in the kayking forward paddling is a fundamental skill. A beginner will place the paddle in the water and pull on it, this will give them some forward movement, after a while of trying and experimentation they will learn to paddle forwards in a straight line. But if you were to compare their paddling action with someone who was say, a top-level slalom competitor, you would see a number of differences. Mostly to do with keeping the paddle close to the boat and using twisting of the body rather than just movement of the arms to engage the core and leg muscles for maximum power.

So you have to keep learning to paddle forwards over and over again as you get better. I’ve had to almost go back to the start three times in the last twenty odd years I’ve been paddling and every time I come out of it with a better, more powerful stroke. But I can’t fill a beginner’s head with this stuff, it would only confuse them and put them off. I always try to get them twisting if they can understand it, that helps a lot.

When you find yourself in a coaching situation the other thing is you have to go where the people are. What this means in practice is there’s no point in talking about a complex stroke, or rolling your kayak, or even the many techniques for rescuing people who have come out of their kayaks until the person can paddle where they want to go consistently and competently. They first need to be relaxed, and have a certain competence, before they even try to do anything more difficult. They have to be able to paddle forwards somehow before they can improve upon it.

In fact, they are incapable of taking on any more information until they get past the fears and annoyances they are experiencing right now. 

Introducing something new

When I was a very new coach we used the acronym IDEAS

  • Introduction
  • Demonstration
  • Explanation
  • Activity
  • Summary

I think these points are pretty obvious, with the possible exception of explanation, which briefly touches on the why.

Of these Activity dwarfs the others. My big fault when I was new to coaching was talking too much. You need to show what needs to be done in small enough pieces and then get them to show you what it is they thought you said by doing it. That’s the process, not talking. Demonstrating, doing, not talking. Watching them in action and knowing the common stumbling places to help them overcome them, not talking. The summary is also extremely important because it helps the good behaviour become fixed.

Finding a coaching opportunity

There are two kinds of opportunity:

  1. Catching people doing it right – reinforcement
  2. Catching people in need of correction or direction – tuning

Notice I was very careful not to say doing it wrong. If you see a behaviour you don’t want you must work out where it came from and then correct it. If someone is doing it wrong, it’s your fault for not explaining or demonstrating well enough, or they just weren’t ready for the finer points the first time you showed them.

It’s not a problem, just show it again. As long as they are paying attention and trying their best there’s nothing to get worked up about.


The worst word you can use is but, particularly with male participants. Everything positive you said before the but is lost. Because of our school system and the way we’re wired, we listen for the negative, so criticism and correction have to be couched very carefully. It’s best, in fact, to ask a question to try and draw out the reasons for the problem. It’s best to let people discover the right answer themselves. A coach is a guide, an instructor instructs – be careful to be the former. A coach creates a safe place for people to learn.


No matter how keen somebody is to learn something once they get tired they will start to find it hard. Try something else or just bring the session to a close. If you start to flag then the same is true.

Bad habits

It’s important to inculcate good habits. For example, one of the worst things you can do when surfing or using support strokes is to lean back. When you are a beginner on flat water you discover that it lowers your centre of gravity and makes things easier. On moving water it creates vulnerability and also locks your hips, making control and recovery much harder. So I teach leaning forward and encourage it, but it doesn’t always go in.

So, in coaching people to be better coders recognise the bad habits – rushing in hacking instead of thinking, pasting in whatever comes out of google without understanding it, having a cynical attitudes that damage team productivity or a default position of blaming others – which usually comes from not listening carefully and checking assumptions.

This also links with tiredness and stress; when you are tired you fall back on the original habits you had because they were the first thing you learned. They are the default position, so cultivate good habits from the beginning. I know from my own experience that this is far harder than it sounds.

Beginner’s mind

The beginner doesn’t know what they don’t know. So in fact they are capable of discovering new things that the coach can’t see because of their preconceptions. It’s always good to engage with the beginner, that’s how you keep yourself fresh. It also means that beginners aren’t necessarily wrong, and the questions they ask can be really useful and stimulating. It saddens me that our awful educational culture means that people often don’t ask these useful, gem like questions, because they’re afraid of looking silly or standing out. I’ve built my career on a playful, constructive silliness.

Beginners also need simple rules to help them – rules that an expert knows are more like guidelines. Simple rules can get you from zero to 80%, and they are always worth sharing if you have some. But just be careful they don’t become the dead hand of bureaucracy and start choking everybody. Rules are a what and very powerful, but an expert knows the why and when to bend or break them. Beginners need to lay in the good habits, so don’t confuse them, and stay quiet until they start to hit the limitations of the rules, then they can learn.

Humble mind

Part of going where people are means you must leave your ego at the door. Part of respecting the beginner’s mind means that you must also listen to what beginners have to say. If you don’t listen you are no use. You can’t go where someone is if your arrogance means you can’t see the map they provide you. This is why I often feel doubtful at self-appointed coaches, and why I don’t get on with the macho culture you often find in software teams.


If your participants aren’t enjoying the experience they won’t learn anything except they don’t like it. If you aren’t enjoying it you won’t be able to share what you have to share. So always look for fun and interest in what you do.

Empowerment is a lie

How many times have you heard employers or politicians talking about empowerment?

They’re going to give you permission to make decisions that affect you, or perhaps the people you serve. They’re going to allow you to organise things in a way that makes you feel happy with what you do, gives you the autonomy to do it right. Oh. That’s big of them, isn’t it?

This rests on some fundamental fallacies:

  1. In order to have any capability beyond some repetitive mechanical work someone has to give you permission.
  2. Someone has to pick you, and other people (therefore) have to wait.

Think about it – did Gandhi ask anyone for permission? He saw a problem with the world and just started doing whatever he could to change it. I went to Thinking Digital in May and one of the talks towards the end was a 15 year old who had come up with a cheap test for pancreatic cancer that will find early stage using carbon nanotubes, antibodies and filter paper. Wow.

He’s bright, very bright. But lots of other people are too. He was upset by the loss of a relative to this disease and decided to do something about it, he read a lot and came up with some things to try. Then he badgered some medics with research facilities until one let him come and try to develop a protocol.

It works, I hope it will come soon too. But the point I’m making here is no-one told this fantastic young person no. No-one gave him permission. He just went and did something that makes the world a better place.

So, the next time someone offers to empower you tell them where to get off. Pick yourself.

If you work in a way that creates systems and processes where human beings make human decisions then empowerment is not needed, permission is not needed. Grab that filter paper, grab those nanotubes, talk to that person.


Since I first made this post, which is a sketch of an idea I will develop further in Unicorns in the Mist‘s next outing more things have occurred to me that I wanted to share here.

I was chatting on Facebook and realised that I believe empowerment is also insulting. To clarify:

Insulting to the “empowered” – as in “you’re no longer too child like to look after yourself”. My take comes from a lot of the rhetoric you used to hear when people who had been disenfranchised by poverty or some disability where being ‘empowered’ by the state to make bogus ‘choices’. Instead of addressing the real need for creating systems that meet and help their needs they were so powerful they can fill in a survey. This is of course a simplification but I hope it helps getting the point across.

And, of course, the flip side of being given permission is that it also allows the giver to take it away again. That’s big of them too. It assumes a paternal relationship and distribution of power where the empoweree (sic) has to rely on others to validate what they do. Just take a look at the whole crazy gang of incompetents and buffoons that try to run your life and think about how little permission they can ever grant you, or anyone else.

One of the other speakers at Thinking Digital was talking about opening up government data, which is a cause dear to my heart. Apparently at least some of the nominal owners of this data are concerned that people like us, the poor unwashed masses, might draw the wrong conclusions from this data. Wrong in terms of whatever ideology or spin they want to put on it. So the empowerment that this data may bring should be conditional on whatever they think we should be saying or knowing. Yeah. Bless them.

As Deming is reputed to have said in Jesus Christ we trust, all others must bring data. I’m not a Christian, but the rest of the sentiment is sound 🙂

© 2020 Francis Fish

Theme by Anders NorénUp ↑