How to multitask when you need to
Monotasking is how we give teams focus. Rather than grinding through a backlog of as many unrelated tickets as possible, the entire team solves one problem at a time. Focused teams are the key to predictable planning.
But if you've ever tried to get an organization into monotasking, you've learned two things: convincing people is hard, and sometimes you kinda need to multitask.
Let's start with the first one. Stakeholders have a hard time grasping the concept of monotasking. They'll agree on the principle but will instinctively turn to multitasking, given the chance. While they love "focus" and "predictable", they'll also push to "just quickly do". It's human nature.
Developers aren't much better at this. They'll complain that there never is time to do things right, but once you carve out two weeks to address a single problem, you'll see them worrying about whether they'll have enough to do. I've worked with teams that always wanted to have some small tickets in their backlog in case they ran out of work – as if engineering teams ever run out of work.
Finally, we, as technical leaders, aren't virtuous stoics either. While we believe that monotasking is the key to predictable planning, we also believe in keeping the team together. We can push for certain ideals but often have to compromise.
All this is to say that building a culture of monotasking is hard, and the deck is stacked against it. It takes time and effort to get there.
And that brings us to that second truth: sometimes multitasking makes sense. Let's say we have a cross-functional web team and decide to revamp the look and feel of their application. We could dedicate a Focus Block to it, but that would mean the backend developers wouldn't be able to attack the problem. If the solution is all HTML and CSS, there's little a Java dev can do.
So it would make sense to do the redesign and some other backend-related problem simultaneously. That's much more productive than the Java devs twiddling their thumbs. It's one of those cases where multitasking makes sense.
The problem is, of course, that multitasking like this gives mixed signals. On the one hand, we're teaching our teams and stakeholders that monotasking is vital. On the other hand, we break that rule when we see fit. Before you know it, people start asking for "just one small extra", and months of monotasking progress go down the drain. I've seen organizations with predictable plans revert to a muddy mess once multitasking crept in again. Chaos is cheaper than order.
So, how do we solve that? How do we pragmatically plan multitasking without giving the wrong signals?
There are two good options.
The first and simplest one is to plan the redesign as a Focus Block. The front-end devs will address the problem, but since the back-end engineers can't meaningfully contribute, they'll work on operational work. It combines a Focus Block with a Recovery Block.
The beauty of this approach is that for stakeholders, it looks like business as usual. The team is still monotasking on a single problem. We stick to the doctrine while the front-end problem gets solved.
The second and more complicated option is temporarily splitting the team in two. Remember: teams are the way organizations multitask. So, if we split up the web team for a short time, we can multitask. That means that for three weeks, there will be a front-end and a back-end team. After that, they rejoin again. Note that this comes with organizational overhead in the form of extra backlogs, boards, and meetings. The two teams won't be joining the same standup, for example.
From a planning perspective, this is straightforward. Short-lived monotasking teams are trivial to add to the roadmap, and since both are synchronized, we can even shift those Focus Blocks around on the timeline. To stakeholders and teams, this indicates that it's an unusual situation that requires a temporary new constellation. At no point does it give the signal that we're back to multitasking.
If we plan it well and are mindful of the involved risks, we can occasionally do two things at the same time without regressing to the chaotic ways of the past.
Sometimes multitasking makes sense and in those cases, we need to be pragmatic. But we also need to guard the signals we give to our teams and stakeholders.
It's yet another trade-off technical leaders must make.