“A study at the University of London found that participants who multitasked during cognitive tasks experienced IQ score declines that were similar to what they’d expect if they had smoked marijuana …”
— Forbes Magazine
over the last weeks, a few of you have pinged me about Weekend Reading drying up. I must admit, between some demanding projects and my continuing moonlighting as a handyman in our new house, I just could not muster the energy for writing.
However, in a workshop to develop a working model for a – hardware-dominated – product development organization this week, one of my favorite perennial questions came up again: Does product development require dedicated resources, or can resources be shared?
So, here are my thoughts and – as usual – some reading suggestions:
Context Switching Slows Delivery
Those of you who have been attending one of my recent presentations will be familiar with this already: There is ample scientific evidence that context switching and, even worse, multi-tasking come at a massive performance cost.
Carnegie Mellon University’s Todd Waits, for example, claims that from the 4th parallel project, 50% of capacity is lost to context switching; a 2017 USC study by Barry Boehm and others puts the figure at about 17% for two software projects with the trendline from his empirical study crossing 10h/week (that is 25% of typical capacity!) at about 3 projects. This matches the feedback I recently got from the head of PMO of a large German corporation, who told me that their internal studies showed an individual contributor’s performance to be degrading from approximately 2,5 parallel projects significantly.
When the frequency of interruptions reaches a point where it can more adequately be described as multi-tasking, truly severe performance impairments are the result. Take a look at the Forbes quote above.
Obviously, every individual project suffers even more. Having been assigned only a fraction of an engineer’s capacity, the productive share of capacity and output quality drops further.
Assuming e.g. four parallel projects handled with the same priority, a contributor would be assumed to be spending 25% of her time on the project; given the above, reality may be closer to 12%.
Even without consulting Little’s Law, project delivery now takes roughly 10x the time (!!!)compared to where the engineer would have only been dedicated to one project.
Context Switchers Will Likely Create Inferior Products
Products are created in a- and to have an impact in a particular context (business, users, …). That means that understanding and considering this context is an important determinant of a product’s outcome. Considering the overall product objectives, the product vision, and user context is crucial to develop superior products.
Cognitive psychologists Roel Willems and Marius Peelen conclude in their 2021 iScience article:“Context is traditionally considered like a Maggi seasoning, “spicing up” the core of cognitive processing. This is unlikely to be correct. Quite on the contrary, context is not something we add on to cognitive operations, it is core to cognition. Without context, cognitive tasks are often difficult and time-consuming. With context, many of these tasks become effortless and fast. Context thus both facilitates and changes cognitive processing, …”
Making developers switch contexts repeatedly will reduce their immersion into every project’s context and further degrade and slow down outcomes.
Why Can’t we Skip the Habit?
From the above, it should be obvious that dedicating engineers and developers to a single project- or at least massively reducing the number of parallel projects they have to work on will improve delivery speed and results quality.
From my work with corporate R&D and IT organizations, I see two reasons why it is not happening:
The first is that many of the traditional corporates are still steeped in an industrial production paradigm and -mindset, where resource utilization and thus (over-) assigning capacity are understood as a means to maximize efficiency.
In this mindset, R&D or IT “projects” are imagined to develop items to (largely context-free) requirements or specifications, much like production in a factory. Project managers orchestrate engineers as fungible resources along the critical path to product delivery.
The second is that many organizations have no agreed and shared priorities. Strategy and business value-oriented portfolio management are often absent, resulting in unmanageable workloads for the teams.
That’s, unfortunately, nothing new. As the late former Intel CEO Andy Grove observed: “There is always more to be done, more that should be done, always more than can be done.” (As a consequence, Grove developed and ran Intel with OKRs.)
How do we Get out of This Conundrum?
In my opinion, it starts with driving your organization to develop a (portfolio-) strategy with a clear set of 1-n priorities and introducing OKRs, NCTs, or some other means to continuously revisit them and keep the focus. At the very minimum, agree on a shared list of priorities. (If all else fails, you may need to set priorities yourself – here are some suggestions on how to).
Once priorities are clear, adjust the working model towards a product-oriented, outcome-focused, iterative, and learning one. Develop a strong product vision. Ditch project management and hire or train Product Managers. Start working to deliver more value to current and future users and customers.
Admittedly, that will not be easy, and there are no “one size fits all” solutions, as we learned again in the workshop this week. But it’s worth a try if you want to start delivering value to users and customers in a relevant timeframe.
Are Dedicated Teams Required for Agile or Scrum?
Anthony Mersino’s perspective with agile teams in mind
Build What Matters
A Synopsis of Ben Foster and Rajesh Nerlikar’s framework for vision-led product management
Five Reasons to Ditch Project Management for Product-Based IT
Insights from the Forbes Technology Council
Enjoy the rest of your spring weekend!
All the best,