Multitasking is for Managers
Sometimes, it feels like once you have reached a certain level of seniority, as a developer, you are not allowed to be in the zone anymore. Preparing for meetings, sending status updates, keeping track of team progress… If you want to do it right, you just can’t afford to get into the zone like you used to.
Because, if you are in the zone, you forget about everything else. If you are in the zone, you can’t multitask. But as a developer, you need to be in the zone.
Some problems are really complicated, so you can’t come up with a good solution unless you devote your entire attention to the problem. Understanding that piece of horrible legacy code and finding a way to change it without breaking it can be impossible unless you are way in the zone. So you can’t multitask.
Are we destined to give up solving challenging problems? Is there a way to be both communicative and still do highly technical work?
Multitasking is Easy
Among programmers, it is common knowledge that context switches are extremely expensive. Among managers, not so much. For some reason, a lot of them seem to think switching contexts is not a big deal. I used to put it down to deliberate ignorance, until a colleague told me about The Maker’s Schedule.
The Maker’s Schedule differs from the Manager’s Schedule in that makers work on tasks that can span days, while managers go from one meeting to the next, picking up small tasks in the meantime. Makers follow their own plans. Managers have to reserve time if they don’t want someone else to fill in their schedule for them.
This is only possible because the kind of work managers do doesn’t require nearly as much focus as the kind of work that makers do. I don’t mean to say that their work is easy. But as they like to say so themselves: I don’t need all the details, just give me the outline.
Keeping in Sync
Okay, now we know why multitasking works for managers, but not for makers. But we still need to keep in sync. And if managers are not allowed to interrupt us, then how can they possibly know what we’re up to?
As a programmer, you are probably familiar with push versus pull communication. Pub/sub is push, RPC is pull. What if I told you that the Daily Scrum was meant to be a “status push”? And did you know that Kanban is referred to as a “pull system”? Combine the two and it makes perfect sense. You ask for work when you’re ready, you step out of the zone once a day to deliver a status update.
The key here is control. You decide when to send a status update, and when to ask for more work.
The Perfect Lead
But we’re not really in control at all, are we? Writing software is a creative business, “creative” being a euphemism for “messy”. Stuff pops up all the time. Some requirement that seemed crystal clear during the planning session suddenly has some weird edge cases. You were promised an answer to a question, but apparently it’s a really difficult question, because it takes ages.
There is no way around it. Somebody has to pick up those things, someone with a can-do, pro-active attitude (yuck). And that is why, as a lead developer, you have to submit to the Manager’s Schedule. You are the Servant Leader, but you don’t serve your manager… You serve your team!
You submit to the Manager’s Schedule, so that your fellow developers don’t have to.
Don’t be a Bottleneck
And so, I’m afraid there is no way around it. Even if you’re not an actual Lead Developer, you are still the person who’s expected to chase after information. You are the one who can afford to not be in control. You are the one who sucks the least at switching contexts.
The only problem is, because you’re not in control, you are constantly at risk of becoming a bottleneck. Luckily, you are also the one who knows exactly how not to become one. Break up tasks. Break up pull requests. Small refactorings. Test Driven Development.
Start every task knowing someone else might have to finish it.