Concept of the Day: Parkinson’s Law

There are certain phrases in the English lexicon that are almost universally known, but their history is less well known – this is one of those phrases:

“work expands so as to fill the time available for its completion”

Cyril Northcote Parkinson

These words appear at the beginning of an article in The Economist in 1955:

It is a commonplace observation that work expands so as to fill the time available for its completion. Thus, an elderly lady of leisure can spend the entire day in writing and despatching a postcard to her niece at Bognor Regis. An hour will be spent in finding the postcard, another in hunting for spectacles, half-an-hour in a search for the address, an hour and a quarter in composition, and twenty minutes in deciding whether or not to take an umbrella when going to the pillar-box in the next street. The total effort which would occupy a busy man for three minutes all told may in this fashion leave another person prostrate after a day of doubt, anxiety and toil.

Parkinson’s Law, The Economist, 19th November, 1955

Parkinson’s initial observations were made in relation to the volume of civil servants and the amount of work being done. This is an ongoing discussion 64 years later, but not one that I feel in any way qualified to comment on. Parkinson was quite cynical about the reasons for an expanding civil service of his day – but I’ll let you read the original article and draw your own conclusion.

(Personally, in 2019, I find the caricatures of the “elderly lady of leisure” and the “busy man” jarring in their reinforcement of stereotypes.)

Where I can comment is in the business world where I see this law at play every day.

Meetings that are scheduled for an hour generally last an hour. This is remarkable when you consider the lack of preparation that goes in to most meetings. Interestingly enough meetings that are scheduled for 30 minutes generally last 30 minutes. Furthermore, there is, often, little discernible difference between the outcomes of a 30 minute meeting and 60 minute one. This is Parkinson’s Law at play.

Someone given a few hours to prepare material to present to a client will generally finish it in the time allocated and the material will be of a good quality. Given more time they would still produce material of a good quality.

Projects that are planned to deliver something over several months will rarely deliver anything in a few weeks, even when the project plan was highly speculative when created. Interestingly, it’s not unknown for projects that are planned for months to last several years, but I don’t think we can hold Parkinson’s Law wholly responsible for that.

I don’t think we can remove Parkinson’s Law altogether, what we need to do is to recognise it and contain it.

One of the powerful aspects of incremental delivery techniques like Scrum and Kanban is that they reduce the impact of Parkinson’s Law by breaking larger activities down into smaller constrained entities. Each entity is still subject to Parkinson’s Law; the constraint contains the impact within the increment.

The impact of constraints is easy to understand if you think about an 8 hour working day. Imagine within that day that you have 16 different subjects to discuss. Add to that scene 10 people sitting in a room for those 8 hours working their way through the agenda from top to bottom. What is the likelihood that with just 2 hours remaining there are still 8 items to discuss? Now imagine those same 16 different subjects and a schedule split into strictly enforced 25 minute slots that gives people a 5 minute break before the start of the next subject. What’s more this schedule requires conclusions to be reached within 20 minutes. Which of these two approaches will result in each of the 16 items being discussed? But will the conclusions reached be of the same quality as the ones discussed for longer? The impact of time on decision making is a complex one, and probably worth a post another day, but there’s evidence that decisions made quickly (not rushed) are often better than those made over a protracted period of time.

What I’ve outlined above is similar to the Pomodoro Technique. This techniques also utilises a set of time constrained slots, typically 25 minutes, and is often highlighted as a way of overcome procrastination, but I think it works just as well as a mechanism to constrain Parkinson’s Law.

My 25 minutes of writing is nearly up, and I want to read through what I’ve written, so I think I’ll leave it there.

Header Image: This is the view from Kirkstone Pass looking down towards Brothers Water and Glenridding beyond. These are some of my favourite hills partly because, for the most part, they are rarely visited.

“That doesn’t sound very agile?”

I’ve heard this phrase a number of times recently. The normal context is this:

  • Manager: “I must have the important widget for ABC Corporation by the end of the week.”
  • Product Owner: “Why?”
  • Manager: “Because we promised it to them last night?”
  • Product Owner: “I’ll have a look at the current work in progress and discuss what we can do with the team in the morning stand-up meeting. Because this is a new item, not in the plan for the current sprint I’m not sure that we can do anything by the end of the week.”
  • Manager: “That doesn’t sound very agile?”

There’s a miscommunication here. What the Manager has said to the Product Owner makes no sense to the Product Owner because what they have heard is “Well, that doesn’t sound very Agile?” with a great big capital “A”. What the Product Owner has defined IS Agile, it may not meet the Manager’s expectation of agile, but they are different things.

See: Office Speak: “Agile with a capital ‘A’” and “agile with a small ‘a'”

Somewhere along the road Manager Types have picked up the impression that they can ask Agile Teams to do whatever they want and it will be done at the drop of a hat. In their understanding Agile equates to “no planning” when the reality is that Agile means “planning differently”.

I suspect that this impression of Agile as ultimate flexibility is derived solely from the name and not from any study of the practices of Agile. In many situations I suspect that the Manager Types haven’t done any training on Agile and are simply fab-surfing with the hope that the latest fad will, at last, be the answer to all of their problems. What they haven’t realised is that Agile will only be an answer to some/many of their problems if they engage and embrace it, and to do that they need to understand it.

Navigating in the Mountains, Using the Right Technique for the Conditions – Testing an Agile Analogy

One of the joys and challenges of being human is that we communicate and understand differently. Some people prefer numbers and facts, others need a picture or a story. Art exists in many forms because it helps us to break through and communicate.

I’ve been trying out a new analogy recently and wanted to expose it to a broader community to see if it resonated. I’d love to hear your views.

One of the joys of my life is a day walking in the hills. There are various skills that that you need when you are out in the hills, perhaps the most important being navigation. I call navigation a skill because it isn’t a method, it’s a collection of tools and techniques that you need to apply in the right situation to get the right result. The tools and techniques that you use on one particular day, or even during a specific hour, are influenced by several factors, including:

  • Visibility – How far can you see?
  • Local knowledge – Do you know where you are going? Perhaps you’ve been there before?
  • Terrain – Is there a defined path? What are the hazards ahead, or to the left or right?

If visibility is good; if there’s a defined path and you are walking a route you’ve walked many times before you join the chosen path, look ahead and walk. Navigation is straightforward and doesn’t require you to spend all of your time looking down at a map. When things are really good you can even see places where the journey could be improved by taking a slightly different route or by taking a shortcut.

This approach is fine until the factors above change. Clouds roll in causing visibility to drop to a few metres and you arrive at a point where the defined path becomes less distinct and the terrain becomes indistinct. At this point the navigation techniques need to change, it’s time to get the map and the compass out.

For anyone who hasn’t used a map and compass in this situation what you need to do is to take a bearing. This video shows you how to do that:

Further details here.

The important point is right at the end of the video:

  • Take a bearing,
  • Pick a landmark that you can see,
  • Head to that landmark,
  • Take another bearing at the landmark,
  • Repeat until you get to the point where you are wanting to go.

Unless you are a very skilled navigator and there are lots of visible landmarks it’s not likely that this approach will get you directly from A-to-B, but it will get you there. Even if you could navigate on the direct route it’s likely that there will be obstacles in the way that will cause you to stop and adjust. Navigating this way is slower than when conditions are good, taking a bearing takes time and diversions cause extra work.

The key skill in this approach is to take bearings often enough to keep you focused on the end goal, but not so often that you are spending all of your time taking bearings. The length between bearings depends upon the amount of visibility and the available landmarks. If you can only see for 5 metres, then that’s as far as you can navigate. The last thing you want to do is to pick a landmark that is itself out of sight, that’s a recipe for disaster because you are likely to miss the landmark in the mist and plunge yourself into a situation where you don’t know where you are on the map. Relocating yourself on a map is another skill, slowing progress further.

Some days you start out on a walk where visibility is good and you have great local knowledge but that situation can change rapidly. That’s when the approach needs to change to match the conditions.

Projects, particularly IT projects, are journeys from one place to another. The methods that we use should be dependent upon the conditions, that’s where this analogy comes in. Agile is fabulous for those situations where it’s a bit foggy and the path isn’t clear. Take a bearing, pick a landmark and then sprint to it, then take another bearing. Lean isn’t great in the fog, but is the fastest way of making progress when conditions are good. Even in a Lean situation you may still want to define some interim goals to maintain motivation but you’re not changing the path or the destination just because you’ve reached an interim goal. Even if you think that the road ahead is clear and you can follow tried and tested routes doesn’t prevent the conditions changing and a different type of navigation being required.

Like all analogy this isn’t a perfect picture of the different approaches, but it’s helped most of the people I’ve described it to. Does it work for you?

Concept of the Day: The Law of the Instrument – “To the man with a hammer…”

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

Abraham Maslow

More commonly expressed as:

“To a man with a hammer, everything looks like a nail.”

(I’ve not attributed the common version to anyone because that appears to be up for debate)

The Law of the Instrument is another of those cognitive biases, which appear to be fruitful ideas for these Concept of the Day posts. I think that the reason I find biases so fascinating is that they reveal things about the way we think and provide explanations for why we behave in certain ways and certain situations. The Law of Instrument highlights our tendency to place an over-reliance upon a familiar tool. I suspect that each of us has at least one example of situations we’ve encountered where this has been the case.

I used to have a colleague who would write documents in Microsoft Excel spreadsheets – which his Personal Assistant would then retype into a Microsoft Word document. He knew how to use a spreadsheet, so that’s what he used.

In a similar vein, many organisations send out corporate communications as Microsoft Word documents because that is what the corporate communications team are comfortable creating them in. This annoys everyone, especially the people on mobile devices.

We’ve covered Excel and Word, so I didn’t want to leave PowerPoint out :-). Not sure I need to give an example here though. we have the phrase “Death by PowerPoint” for a reason.

Most of the features of most applications are rarely used, because people don’t go looking for more effective ways of doing things. Once you’ve worked out how to create a table it’s likely that you’ll always create a table that way. I’ve seen several methods employed by applications to nudge us away from our ingrained behaviours, but we keep coming back to the hammer that we already have available to us.

Organisations are dependent upon the data analysis that people do in Microsoft Excel because that’s the tool they are familiar with, when far better tools exist.

The language used by many coding projects is defined by what the chosen developer knows. There’s rarely much discussion about finding the right language, and hence the right developer, for the project.

There’s a current trend to move people to Agile project management methods. In many cases organisations are moving from having one methodology for project management, which was only appropriate to some types of project, to another project management methodology which is only appropriate for a different set of projects. The thought of running two different project management methodologies is regarded as heresy. Agile has become the one-size-fits-all answer to project management.

The Abraham Maslow in the original quote is the same one who produced the Hierarchy of Needs. What better example of The Law of the Instrument could you wish for? The Hierarchy of Needs has, for many, become the universal tool for explaining people’s behaviour. Whilst The Hierarchy of Needs is a useful tool, it’s very unlikely that there is a universal tool for explaining all of human behaviour.

Like all biases, the first step in overcoming it is to recognise that it exists. What we all need in our lives is someone who is regulalrly asking us “why did you do it like that?” Our answer to that question will be a good guide to thye impact of The Law of Instrument in our lives. Another good question to ask is “is there a different way of doing this?” It’s unlikely there isn’t an alternative but if you can’t think of one then you need to challenge your bias.

Cognitive Bias Posts:

Concept of the Day: Creative Destruction

Do you think you know what creative destruction is already? I thought I had a pretty good handle on its meaning, but there’s always something to learn.

Creative destruction is an economic term which was derived from ideas put forward by Karl Marx (yes, that Karl Marx) by Joseph Schumpeter and published in 1942. Like many concepts that are developed within one field, with a specific meaning, the concept of creative destruction has been taken and used in many different fields resulting in a broadening out of the original meaning.

This is an extract of how Schumpeter described it in Capitalism, Socialism and Democracy:

The essential point to grasp is that in dealing with capitalism we are dealing with an evolutionary process. It may seem strange that anyone can fail to see so obvious a fact which moreover was long ago emphasized by Karl Marx…

Capitalism, then, is by nature a form or method of economic change and not only never is but never can be stationary…

As we have seen in the preceding chapter, the contents of the laborer’s budget, say from 1760 to 1940, did not simply grow on unchanging lines but they underwent a process of qualitative change. Similarly, the history of the productive apparatus of a typical farm, from the beginnings of the rationalization of crop rotation, plowing and fattening to the mechanized thing of today linking up with elevators and railroads is a history of revolutions. So is the history of the productive apparatus of the iron and steel industry from the charcoal furnace to our own type of furnace, or the history of the apparatus of power production from the overshot water wheel to the modern power plant, or the history of transportation from the mail-coach to the airplane. The opening up of new markets, foreign or domestic, and the organizational development from the craft shop and factory to such concerns as U.S. Steel illustrate the same process of industrial mutation if I may use that biological term that incessantly revolutionizes the economic structure from within, incessantly destroying the old one, incessantly creating a new one. This process of Creative Destruction is the essential fact about capitalism. It is what capitalism consists in and what every capitalist concern has got to live in…

That’s a lot of words to get your head around, so I suspect an example is needed and there are numerous:

When was the last time you purchased a cassette tape to listen to some music? First there was vinyl, then along came cassettes, then the CD was the most popular format but that’s mostly been overtaken by online music and music streaming services like Spotify. In each of these changes there was a destruction of the industry that was the previous mechanism for transporting music. One upon a time there were thousands of people employed in the production, distribution and retail of the cassette tape, those jobs no longer exist because we no longer buy cassette tapes in anything like the volume we used to. Through all of those changes music has continued to grow, arguably those changes were necessary for that growth to happen.

Creative destruction is the process of tearing down what’s already there that is precipitated by the adoption of an innovation.

In 1850, 58% of total employment in the U.S. was in agriculture, today it’s 2.5%, since the 1960’s manufacturing has fallen from 27% total share to 9% today. Both of these being primarily driven by increased mechanisation and automation allowing the U.S. to produce more food than ever before. The old mechanisms for production had to stop for the new ones to become mainstream – they experienced creative destruction.

Recognising that a revolution is taking place, or about to take place, is powerful knowledge. There’s no point in investing in new cassette manufacturing machines if the revolution of digital music has already started. There’s no value in training a large manufacturing workforce if the work is going to be done by a robot. The wisest organisation is the one that gets out of manufacturing cassette tapes whilst the business still has a value, leave it too late and the value of the business will have been completely destroyed by Spotify.

Moving away from economics, how about all of those internal processes that have existed since they were created in 1998? What would a new entrant into your market do? would they carry the baggage, or do something automated or lean? We have to seek these situations out so that we can proactively do the job of creative destruction.

How about those ways of doing things that you regard as tried and trusted? Are they really relevant to the current world? Is there room for some more creative destruction?

If you prefer a video example this may help:

 

Concept of the Day: The Tragedy of the Commons

I like concepts that have a history and this one dates back to 1833 and an economist called William Forster Lloyd.

The concept refers to a hypothetical situation where unregulated grazing on common land could create a situation where an individual herder, acting in their own interest and within their rights, could result in overgrazing. The overgrazing would then result in a tragedy for the group of people who use that common.

(In the UK Common Land, the commons, is land that is available for use by the Commoners for a particular activity. Livestock grazing was, and still is, a regular use for common land. The origins of common land go back to medieval time and thus some land has been grazed by Commoners for hundreds of years.)

Over the years the commons has become a metaphor for many situations where a resource is shared.

A great technology example of the tragedy of the commons is email SPAM. The actions of a few people significantly degrades the value of the email utility for the majority and results in a cost to everyone who uses it.

In the UK there’s been a lot of news coverage recently about the overuse of antibiotics, particularly people going in to their doctors and demanding medication even though they are of no value to their condition. The actions of these individuals has contributed to the rise of antibiotic resistant bacteria which is highly likely to result in the common value of antibiotics being destroyed for the majority.

There are so many business situations where the tragedy applies. I’ve seen many teams fail to be effective because an individual was optimising their activities to the detriment of the group.

Put simply, the tragedy of the commons applies to those situations where people’s personal short term interests are at odds with the longer-term interests of the group. I’m sure you can think of many, many more examples?

Concept of the Day: Fundamental Attribution Error

I’ve written a few times about our many biases, this is another one along the same lines. This one is slightly more complicated to understand, but once you do I hope it will challenge how you interact with people and how you respond to situations.

Imagine you are sat in an update meeting and you are going through the list of actions from the previous meeting with the assembled team. You get to an action that John is supposed to have progressed and you ask him how he has got. John looks at you surprised, “Was that my action?” He says. You continue to go down the list until you come to another action that John is supposed to have completed. This time John looks a bit embarrassed and says that he hasn’t had chance to look at it whilst writing something into his notebook. The very next action is another one for John, again, no progress, this time he looks down and taps something into his smartphone.

How do you feel about John? Why do you think he hasn’t made progress on his actions?

Your response to John probably demonstrates fundamental attribution error.

Let me explain.

Attribution is what we do when we project a perspective or characteristic onto someone. Put simply, there are two classes of attribution.

Dispositional Attribution is the class of attributes that make up someones character, the internal characteristics; they are lazy, they are disorganised, they have no focus, they are arrogant.

Situation Attribution is the class of attributes that relate to the situation, the external characteristics; they are in too busy, they are having a bad day, they aren’t well.

Then there’s the Fundamental Error part, this is where our biases come in.

It turns out that when attributing a perspective or characteristic onto someone else we tend towards Dispositional Attribution. In our scenario we are most likely to characterise John as lazy or disorganised. We then have a tendency to use that attribution for future interactions with people – “There’s no point in giving actions to John because he’s too disorganised.”

Here’s the really interesting part though. When we assess our own performance in a situation we tend towards Situational Attribution. Now imagine you are John; what’s your reason for not doing you actions? It won’t be because you are lazy, it won’t be because you are disorganised. Your reasoning for your own behaviour will be because you didn’t get a good night’s sleep, or because you are too busy, or even because you are just having a bad day.

The way that we judge others is radically different, even opposed, to how we judge ourselves.

The chances are that neither Dispositional or Situational factors will be wholly responsible most of the time.

So next time you are in a situation and find yourself assessing people’s motives, attributing, it might help to ask yourself which side of the spectrum you are on. Perhaps there are situational factors that you hadn’t thought of?

Here’s a video that’s probably clearer than my ramblings: