Tag Archives: Daniel Kahneman

The Cost of Task Switching. “Could You Work On This Please…No Wait…Do That Please”

Change direction

Yet another of those ideas in Thinking Fast and Slow by Daniel Kahneman that leapt out at me as I read was

One of the significant discoveries of cognitive psychologists in recent decades is that switching from one task to another is effortful, especially under time pressure.

This seemed relevant to project work. Task switching is certainly costly in projects.

Before getting to switching individual tasks, it seems relevant to visit the topic of switching tasks mid-sprint. Switching tasks any time mid-sprint in agile (and indeed any tinkering with scope mid-sprint) has, in my experience, not worked well and this seems related to what Kahneman is saying. Others seem to agree about the costs of switching tasks mid-sprint. I enjoyed the exploration of this theme in the “Product Owner changes” section of this article and the “Changing Requirements” section of this oneSubstitution mid-sprint is a slightly different proposition to change. I am all for substituting scope during the project. For example, where the team is a 3rd party supplier on a fixed price and the product owner identifies new scope mid-project, we have estimated the new scope and substituted out like for like stories. This is a technique that has worked well for me and I would recommend it. So substitution mid-sprint/project can work well but changes in the middle of a sprint carry a cost to performance and morale that has often been significant for me and my team. There are some reports to the contrary, and I’d be glad to hear of other’s experiences with this.

So, Kahneman is advising of the costs of asking someone to switch from one task to another before the first is finished. This is something that should be relevant to agile and waterfall teams alike. The articles I mention above discuss the cost of switching tasks mid-sprint, which, as I say, seems to have related overheads. Much of what these articles say translates to the cost of changing work packages mid-stage in waterfall land. Work packages often come with tolerances which, if exceeded cause project issues to be triggered but we are still left with the psychological cost of task switching. So what is this cost?

As will be familiar to you, it takes a certain amount of mental investment to understand a task and think through how the requirement is going to be met. Once the task is done, the back story and details can be forgotten but, until then, it all needs to be kept in mind. Blumar Zeigarnik demonstrated how we remember unfinished tasks more easily than completed ones. The eponymous Zeigarnik Effect that she identified goes some way to explaining the cognitive effort involved in incomplete tasks versus complete ones. The theory is that incomplete tasks take up mental capacity which is “released” once the task is complete. It makes me think of caching and flushing the cache in computing but this may be on the wrong track. Such an allocation issue with mental resources would go some way to explaining the drop in productivity from switching tasks. Perhaps an explanation is emerging but the Zeigarnik Effect is not the whole story.

I imagine the “significant discoveries” Kahneman is referring to is the body of research suggesting multi-tasking is not a great idea. While the American Psychological Association (APA) says that

Although switch costs may be relatively small, sometimes just a few tenths of a second per switch, they can add up to large amounts when people switch repeatedly back and forth between tasks.

My own experience (and that of my team members) is that task shifting carries a significant cost per task (not “relatively small”). The APA article mentions two cognitive costs of task switching, “goal shifting” (getting your head around the new task) and “rule activation” (if this is what I am going to be doing then this is what I will need to bear in mind). I wonder if this is what we project managers call the learning curve or something different. Since both of these need to be repeated in some measure when you go back to the old task, they are pure overhead.

Another component which I mention above is the blow to morale. Completing tasks carries intrinsic rewards. We experience these as this is experienced as positive physical sensations, as the brain releases neurotransmitters upon task completion (notably dopamine). Similarly, extrinsic rewards often occur in projects in the form of peer recognition and stakeholders showing approval and appreciation for completed tasks. Task switching means that the team member is now further away from the satisfaction of completing the task. While they were working towards that satisfaction on the original task, they will now not get that reward (intrinsic or extrinsic) any-time soon. Instead, they are now back at the start of something, so while they might have been hours from the satisfaction of wrapping something up, they are now days from that pay-off.

To summarise thus far, we have cognitive overheads like the Zeigarnik effect, goal shifting and rule activation. These are perhaps taking up memory and cognitive resource for the act of task switching. We also have social effects such as missing out on peer approval and stakeholder appreciation and the biological perspective of missing out on the positive sensation of neurotransmitter release in the brain, which is part of the mechanics of how we motivate ourselves. There is also the cognitive perspective on intrinsic motivation. All of these paint a picture of some of the main costs in time and morale that come from task switching. Incidentally, in writing this post I came across a surprising theory on the interplay between intrinsic and extrinsic motivation called cognitive evaluation theory. It seems positive feedback is not helpful where people are already self-motivated. Kahneman mentions that the cost of task switching is especially high “under time pressure”, which projects are almost by definition (and many projects extremely so).

Of course, project teams don’t have the final say on if the task gets switched and it may be worth it to the organisation despite these overheads. What seems important is for organisations to understand the full cost of task switching. It’s more than I thought it was.

Image is Change direction by Phil Whitehouse licensed under CC by 2.0


Optimism Or Delusion? How To Strike A Balance When Trying To Motivate Your Project Team

Read my mind

I came across a post by Ben Horsman that discussed the power and importance of being positive about project goals with the team. It got me thinking, does being positive actually help? I have found in life that some things can only be done through acting as if they will succeed. It’s allure is that it will be a self fulfilling prophesy. Also, planning for success allows us to capitalise on good luck. Daniel Kahneman suggests in Thinking Fast and Slow (p256) that optimistic leaders are more likely to succeed:

Their confidence in their future success sustains a positive mood that helps them obtain resources from others, raise the morale of their employees, and enhance their prospects of prevailing.

So there is this idea of acting “as if” something can be done to increase it’s chances of happening. On the other hand, this idea is prone to abuse. Projects with no chance of succeeding can see their outcomes made worse (and be made less tolerable for the team members) by blatant denial of reality by the leadership. James Boswell wrote in his book Life of Samuel Johnson (1791)

Patriotism is the last refuge of a scoundrel.

It may be that optimism is the last refuge of the leader of a failing project. There is a great Dilbert on optimistic projects here. In addition to being an act of desperation, my experience is that unrealistic goals can have a strong demotivating effect on people. Martin Seligman has demonstrated something he calls Learned Helplessness, which arose in experiments when dogs were faced with insurmountable goals. I suspect something related to this dynamic is what I have seen in teams where we just don’t believe goals are rationally feasible. I wrote more about Seligman and the dog experiments in a previous post. There are so many costs associated with being knowingly unrealistic; colleagues will stop trusting you, some will try to adjust your estimates in their heads back to realistic numbers (with strange results), still others may avoid working with you because they don’t want to be lead by someone who oversells what they can do. All this is to say nothing of the ultimate price of losing personal integrity by knowingly misleading ourselves and others.

So, optimism about project goals can be either helpful or destructive. Is it a question of degree? Kahneman suggests moderation in optimism so as to

“accentuate the positive” without losing track of reality.

and this may be the balance to seek. As I understand it, Jean Paul Satre suggested that we recognise that no endeavour will change our lot in life in any way that matter. So, to lend life meaning, we should take on tasks and act as if they had meaning. He suggests this will work as long as we don’t forget that these undertakings are not intrinsicly meaningful. We may be able to lend sound project teams some motivation if we act as if they will perform better than we calculate they will, while never forgetting that their chances of success or failure must simultaneously be rigorously assessed, regularly checked and clearly communicated to all.

The way I attempt to pull off this balancing act is to aim for realism, communicate optimistic goals to the team and stakeholders, clearly label these goals to all as stretch targets and give feedback towards progress.

A very interesting approach to motivation has been put forward by E. Scott Geller. Ask your team three questions, he says.

  • Can you do what we are asking you to do in the project?
  • Can the project be done?
  • Is it worth doing?

Give people autonomy and regular feedback once work commences and confidence will arise in them. These questions of Geller’s would be at home in any sprint planning meeting. Geller’s assertion that confidence follows is supported by my own experience of agile teams in action.

Geller’s ideas chime with another leading voice of our time on motivation, Dan Pink. In his book, Drive: The Surprising Truth About What Motivates Us,  Pink suggests we look to “autonomy, mastery and purpose” for motivation. This echoes my experience. I have found that agile naturally involves team members in decision making. Mentoring and supporting team members to learn on the job has also been a great way to motivate people (it is also one of the most personally rewarding aspects of my work). Finally, sharing a common goal has been a feature of all successful projects I have worked on. Not just acknowledging that senior management have a certain goal, but personally feeling that this is something that should be done. Both Pink and Geller stress the importance of team members thinking that something is worth doing. Taking time to discuss with the team what I think senior management objectives are based on and why they are globally important has always been time well spent. I have Drive by Dan Pink on my bookshelf at home and may come back to this topic, once I have read it properly. From what I understand so far, it is worth a read as much for understanding “what you thought was true about motivation but is not” as for understanding “what actually does motivate people”.

I mentioned “personally feeling” that something should be done. I once had a Japanese language teacher called Hasegawa Sensei. She made it so abundantly clear that she was personally invested in us talking quality Japanese that it was infectious. We actually cared more because we knew she cared so much. Paying attention to the work produced by the people in my team is something that I strive to do and I wonder if that ever has the effect of making them care more about the work they do.

Both Pink and Geller have great Ted talks, that lay out some of their ideas on motivation. In so far as their ideas relate to motivating project teams, I find them very persuasive and in some part, familiar from seeing agile teams at work. Horsman’s article makes a point restated in a much more nuanced way by Kahneman. If my reference to Satre is justified, positivity has it’s place but must always be clearly labelled as such and people must never lose touch of the reality of what the project’s prospects are. There is so much more to say about motivation. Pink addresses one obvious question I have not gone into. Some think that people are paid to work on projects and that should be motivation enough. The truth is more subtle than that, I find, and it is has been well worth taking time to consider what motivates people, something I am still far from getting to the bottom of.

Image is Read My Mind by Shirokazan licensed under CC by 2.0

Anchoring and Adjustment

Now I find this really strange. If someone gives you a completely crazy example answer to a question, then asks you the question, your answer is influenced by the crazy answer they first gave you. Even obviously random “information” interfers with our reasoning. Participants who span a roulette wheel before answering questions about how many African nations there were in the UN, gave lower answers if they span a low number before answering.

This makes me think of two aspects of task estimation in project life but, as an aside, it also shows how information can be completely useless but is, nonetheless, data.

So, to the subject of task or cost estimation. You are in a meeting at the start of a piece of work or project and someone asks you “Roughly how long will it take?”. They may even say “we won’t hold you to it”. The anchoring and adjustment heuristic shows us that they will be influenced by what you say, even if you say “Well, it is not 3 weeks”. My experience is, don’t be tempted to guess a number off the top of your head. According to Kahneman and Tversky, we “use” all “information” we receive on a topic and that ties up with my experience. If you must give a number before you have a chance to plan or estimate, be sure to also give a % confidence (which would be very low).

The other thing that came to mind was planning poker in AGILE project management. I always get push back from project teams when I suggest team members think of their estimates and then all write them down before revealing them and discussing them. “We don’t need all that fuss”, they say. Of course, there may be several aspects of psychology effecting group estimation. Nudge Theory and conformity in general come to mind but it struck me that anchoring and adjustment was relevant here too. Also, I wonder if those with low confidence in their ability to estimate tasks would be especially vulnerable to anchoring and adjustment.

Looks like there is more interesting stuff on this here.

Those who shout loudest…

I have been learning about the availability heuristic. Faced with the question “Are there more words with K as the third letter or first?” most of us answer incorrectly that it is “K first”. Kahneman and Tversky suggest this is because it is easier for us to think of words that begin with K than to call to mind words with K as the third letter.

So this got me thinking about project life and stakeholders in particular. I often have conversations with colleagues about stakeholder feelings, for example “How do stakeholders feel about a December delivery?”. I realised that the project team frequently go with the opinion they can most easily call to mind (there is usually little time for these discussions). This view is that which is voiced most often and most loudly. Thinking it over, it is clear that this is often not the majority view. The upshot of this is that other, equally important, stakeholders who feel differently don’t get their voices heard.

One answer I found is to ensure that wide consultations are carried out (e.g. surveys or user conference consultations). It is then important that the views are captured, analysed and communicated to the project team. It might be good to bring this up with the team periodically to remind them that the loudest voices do not necessarily represent the majority view.

I realise this is only one reason why the loudest stakeholder view carries sway in projects and one way to counter that. Loud stakeholders often get more influence because it is recognised that their views influence other stakeholders and can create general perceptions of the project. It just struck me that the availability heuristic seemed to relate to some aspects of “Those who shout loudest get heard”.

Canny Man

I am working in IT and studying psychology and was recently struck by how some of the experiments of Kahneman relate to project life. Inspired by this, I am planning to write about what I am learning and how it relates to my working life. For more info see my about section.