Context Switching

There are lots of issues to be concerned with when leading a team – who is dependable, who is not?  who is your go-to problem solver?  how do you raise the overall “level of the water” on your team?  All valid concerns.  However, what I struggle with the most is the having a team that must deal with planned strategic-type work and also ad-hoc requests – or better yet, context switching.  Context switching is the changing of focus for one or more of your team members – it is absolutely a productivity killer.

The simple formula that I use to go from a pile of work to the delivery of work is a series of filters or stages… Total Demand -> Prioritized Demand -> Capacity Constrained Demand -> Completed Work

Total Demand – this is the total “list” of all things that must be completed.  It is important to get EVERYTHING on the list and accounted for – if everything is not on the list to begin with you are setting yourself up for failure.

Prioritized Demand – this is a forced ranking of Total Demand – it must be a forced ranking… no ties.  Once forced ranked or “prioritized” the top items should be given estimates – they can be ballpark.

Capacity Constrained Demand – this is understanding how many hours per week (month, deployment cycle, etc) your development team has available.  Example – you have 4 developers on your team.  You assign 40 hours of work per week to each developer for a 4 week development cycle – that is 640 hours of capacity.  Your team can work on the first 640 hours of highest prioritized items.  Clearly this is a simplistic scenario.

So where’s the problem?  The problem is what I call “ad-hoc requests” – these are the constant interruptions that cause context switching.  Sometimes I feel like my entire day is just one big interruption.  They come in a variety forms and from all areas of the organization.  Humans – especially software developers – do not deal well with these… at all.   These ad-hoc requests force constant re-prioritization and false starts on the originally high priority items.

According the book Quality Software Management: System Thinking by Gerald M. Weinberg there is a clear productivity loss due to context (project) switching.

So how does a team leader or manager deal with the productivity loss and maintain team morale?

1. Context Switching is Real: You can pretend it doesn’t exist or that is doesn’t affect your team – it does.  Understand the struggles your team faces when their focus is switched and understand what impact that has on your project.

2. Prepare Your Team: I found that preparing your team for the reality goes a long way.  I empathize with them and genuinely understand the frustration and loss of productivity they face.  By having the mutual understanding WE as a team can overcome the switching.

3. Be Fair, But Firm: While context switching does negatively impact productivity it cannot be an excuse or crutch that team members constantly use.  In past experience I have seen this used as an excuse – quickly the excuse is shot down when the rest of the team of progressing forward and only one team member is lagging behind.  Note: our PPR process at Brulant is a big deterrent from laziness as well.

4. Be Flexible: 9 times out of 10 I am willing to let team members on my project leave early and work from home late into the night or work late a couple nights through the week and cut out early on a Friday (or another important day).  We all have families and commitments to things outside of work – I am big believer in long-term balance between work and “life”.  Allowing your team to strike that balance over the long haul should increase their overall satisfaction on the project.

If you are looking for a good read that uses a multitasking CPU as an example take a read here.  This is a good blog in general and I visit every couple of weeks.

- Bill Weber

photo credit: Zach Klein