Multitask to Spike Productivity...Right Into the Ground
It feels like only yesterday when everyone was expected to be a great multitasker! Most have since come to realize that we only multitask to spike productivity…right into the ground. The mythical benefits of multitasking however, live on in the enterprise to a large degree.
I think it’s safe to say developers hate wasting time and effort. Our major value proposition after all is to automate, i.e. prevent waste and create efficiencies. So it’s not surprising that developers would be largely opposed to multitasking as it creates serious inefficiencies.
The Cost of Task Switching
Task switching is fundamentally hard on the human mind. Trying to hold a massive business domain model in working memory is difficult enough, much less doing so and then switching to an unrelated task and then back again. Horribly inefficient.
This is a surefire way to spike productivity…right into the ground, of course. Yet this is often the life of enterprise developers. They’re expected to be a jack of all trades type handling support, maintenance, and new development on a variety of systems.
The end result is usually all areas of responsibility suffering. It’s inevitable due to the required task switching inherent in the position. This ultimately suggests it’s a management issue and to be fair, some companies avoid this practice to their credit.
We’re Agile Though
Theoretically the Agile methodology should prevent this kind of inefficient task switching. Anyone who’s worked in the enterprise however, knows too well that “Agile” is often just a buzzword in this context.
Enterprises tend to faithfully have all the meetings. Yet when it comes to the fundamental principles like self-organizing teams, they take a back seat to other things. The most pernicious of which is not allowing developers to focus on tasks in a serial manner. Thus the task switching malaise.
In short, Agile should prevent this, but does not because most enterprises are not really practicing Agile. They tend to dress up their own bureaucracy in Agile clothing so the methodology provides no protective barrier as it would if it were faithfully adhered to.
The Biggest Problem
The biggest problem I’ve witnessed is that developers are seldom empowered to control their own time. Enterprise developers are not easily able to decline superfluous meetings. Nor are they allowed to resist external pressures such as competing support personnel vying for them to fix separate issues.
This lands our developer square in the middle of the task switching conundrum. She can’t focus on developing a new feature without being pulled off into meetings or support tickets throughout her day. Management then puzzles over why their sprints take 8 weeks and hardly anything gets delivered.
To be fair to management, budgets are understandably limited. Most companies can’t or won’t pay for separate developers to do support, maintenance, and new development. Even in these common situations though, there are things management can do to help mitigate problems.
What’s Better
First and foremost, developers should be largely in charge of their own time. Management should certainly set the high level priorities, and then developers should be empowered to accomplish their tasks how they work best.
It ultimately comes down to valuing your developers’ time and trusting them to get their jobs done. This certainly requires a level of trust from management, but if you need to babysit your developers you’ve got a bigger problem than task management.
It’s crucial that management is not only on board with this approach, but actively works to protect their development teams from outside pressures. For example, there should be a clearly defined process for reporting and prioritizing development tasks, whether support or otherwise.
This is necessary to prevent the common practice of people going straight to a developer and putting implicit pressure on her to drop what she’s doing and fix an issue. Management can prioritize all they want, but if they don’t actively prevent this it’s going to force your devs to multitask and spike productivity…right into the ground.
Summary
Task switching is cognitively very difficult. It’s also inefficient and most would agree should be avoided when possible.
The Agile methodology should prevent much of the multitasking problem. However, Agile’s core principles are often ignored in practice in the enterprise. Most “Agile” teams in the enterprise exist within a strict hierarchy and there is scant evidence of self-organization.
The biggest problem of developer productivity can often be caused by one thing. When developers are not in control of their own time, they will be forced to multitask.
Ideally, developers will be empowered to accomplish their work how they see fit. Management should also protect their development teams from those who might try to end run around the work intake process. This is a guaranteed way to multitask to spike productivity right into the ground.