I recently started looking into the impact that context switching and multitasking has on product development. I quickly came across some interesting work by the late Gerald Weinberg (computer scientist, author, professor).
This table contains data on Weinberg's research on context switching that was published in his book - Quality Software Management: Systems Thinking [1].
Looking at the numbers alone is staggering Let's visualize them to really feel the pain! Say that you have a product team of 14.
Wow...
This can be applied at smaller scale — consider the idea of project bundling or bloating.
"Oh, well let's just add X to project Y and we will get more done without context switching."
By bundling, or bloating, a project, it's like putting projects in projects. Chances are, the added scope is different enough that it itself will cause context switching within the project. We haven't optimized for anything, we just distributed the context switching within the project!
So what's a learning tax?
Recently I've been having conversations about context switching and exploring the ways teams structure around outcomes. When teams identify an outcome or goal that they want to achieve, typically there is work that needs to be done to figure out how to best reach the goal. Call it discovery, research, interviews, etc... it's all about learning how to best reach the goal.
If we rush into the build phase without putting in the time for learning or discovery, we may easily find that we did not reach our original goal or the results did not meet our expectations.
The following diagram may vary by project, your current industry knowledge, access to information, access to users, etc... There is always a learning period when doing something novel.
Arguably, learning & discovery never ends. It's continuous and that box should actually be extended all the way to the right.
So where does the tax come in?
It comes in when we stack projects during annual / quarterly planning without realtime and continuous reflection. We don't know what we don't know, so when we take a stab in the dark around how long we think a project 'should' take, we have to be careful and reevaluate the start time of the next project.
Take a simplified annual roadmap that is based on initial estimations.
As the year plays itself out, teams learn what works best to effectively drive the goals set within a project. When it comes to accounting for the time constraint, two options for adjustment come to mind:
- Stick with fixed plan to drive next up, paying the learning tax more often and losing out on the benefits of velocity and established learning. You may get to the end of a project, dictated by a fixed timeline, and decide to move onto the next project when it's "close enough." By doing this, you may miss out on the best results and outcomes as velocity starts to pick up.
- Allow reflection and goal measurement to drive next up. If projects have measurements (OKR, KPIs, SMART Goals, etc.), then it's possible to know how much our work has moved the needle in the right direction. We can use measurements to determine when to move onto the next project. The learning tax will still be paid, but paid only after we have received a highest return on investment since it was last paid.
"But you ran over the fourth quarter!"
Possibly - this is just an hypothetical scenario and it can play out any number of ways. One thing is for sure though — you will have maximized team efficiency and most likely have a better product for it.
Take away
How are the ideas of context switching and learning taxes connected?
There are inefficiencies in change. When we context switch, we have to change what we're thinking about. When we change outcomes, we have to learn and understand what will positively impact them.
