Multitasking Is A LIE

I could probably just end this post right here. Read the title. Nod along (or don't). And... that's it. There's really not much more to say. Because:

Multitasking is a LIE.

But of course, I do have more to say about the destructive myth that is "multitasking"...

Exposing the Liars

First, allow me to get terribly literal here. Maybe you're convinced that you are a multitasker. Maybe your team/company prides itself on its ability to multitask. But whether your multitasking delusions are driven from within, or from the environment in which you're working, I'm here to tell you:

If you truly think of yourself as a "multitasker" - or even if you just aspire to be a "multitasker", you're ultimately, on some level, a liar.

Does that sound a bit... harsh?? Well, OK, I'm not trying to lay a personal indictment on you. But let's consider the basic facts.

Let's just assume, for the sake of argument, that you are The God of Code. You crank out solutions at an unimaginable rate. Your fingers fly across the keyboard. You spit out massive volumes of code - and... it "just works".

Great! Congratulations! You're a deity amongst the unwashed masses! So please, I implore you, allow me to sit next to you - for an hour, a day, whatever. Allow me to actually watch you work your magic.

I'm not asking to observe your coding in real-time because I'm trying to steal your mojo. Nor am I expecting to learn the Dark Arts of Multitasking merely by spying your epic process.

No. What I'm really hoping to observe is:

How many different lines of code are you writing at the exact same time??

I will bet any of you, any amount of money, that no matter how extensive your experience, and no matter how vast your pool of knowledge, that when the "rubber meets the road" and it's time for you to start doing some "real work", that you ultimately write your code one line at a time.

You might code with six massive monitors arrayed around you in some kinda supernatural halo. You may routinely have several different IDEs open at the same time. Hell, you may even have several keyboards positioned strategically around your workspace. But whenever it's time for you to work your groovy magic, on one level at least, you are no different than every single coder in the entire world. You write your code one line at a time.

It doesn't matter if this is your first day of code camp, or if this is the last day in your storied 40-plus-year career. One thing we all have in common is that we all - every single one of us - write our code one line at a time.

Not A Trivial Distinction

Does that "insight" sound silly to you?? Well, it shouldn't. Because I believe it has special relevance to coders.

Most of us are in - or have spent many sprints/months/years in - environments where a vast cadre of "business types" rely upon our (supposed) ability to multitask. And whether they realize it or not, those "business types" are all participating in an ongoing LIE.

On some level, the basic Agile process itself is a party to this LIE. You're in, say, a two-week sprint. At the beginning of the sprint, you're assigned a half dozen tickets/tasks. And every day thereafter, a manager of some sort expects an update, during stand-up, of your progress on all of those tasks.

Granted, at the beginning of that sprint, no reasonable manager will become angry because you've "only" begun working - or completed - one-or-two of those tasks. But there's still a pervasive LIE that permeates the entire process. There's a constant undercurrent of thought implying that, on some level, you're somehow juggling all of your sprint tasks at the same time.

This may be of little consequence to you at the beginning of the sprint: That magical time when even the most anal retentive project manager is willing to cut you some slack and reasonably understands that your full list of tasks will obviously take additional days - or weeks - to complete. But how about at the end of the sprint? When you've hit several roadblocks and your remaining task load is starting to look precarious??

Well, that's the time when your project manager expects you to become a miracle worker. That's when they expect you to summon the dark arts of multitasking.

This is when it's critical to remember - if only for your own sanity - that there is no deadline, no priority, no business objective, that can ever grant you the magical power to code up two solutions at the exact same time.

Agile vs. Kanban

From the above rant, you might've guessed already that, if I had my way, I'd usually be developing under a Kanban paradigm. This is an oversimplification, but at its core, Kanban essentially acknowledges that there is no such thing as "multitasking". Kanban doesn't work so much off of sprints, and focuses much more on prioritized task lists. In other words, Kanban (IMHO) more-accurately reflects the way in which actual work is done. You know, like... in the real world.

Of course, I rarely have "my way". Typically, I'm on a team where the development methodology was long-ago decided before I was ever onboard. And that decision is almost always: Agile. Over the last 10+ years, Agile has, by my estimation, become the clear, dominant paradigm in the world of software development.

And you know what?? I'm OK with that. I mean... I've worked on Agile/Scrum teams for years. It has many features in its favor. Even if you're more of a "Kanban guy" like me, it's not like Agile is somehow... bad.

Well - that's not entirely true. You see, the only time that Agile becomes a headache is when you find yourself nearing the end of an unexpectedly-challenging sprint. And even though you've copiously communicated every one of the impossible-to-foresee challenges that cropped up during the sprint, you still have your project manager standing over your shoulder trying to somehow convince you that you can absolutely finish all of this work. Today. By the end of the sprint.

This is when your stakeholder tries to invoke your mythical (nonexistent) commitment to multitasking.

Multitasking vs. OPEN Tasks

To be clear, I fully understand that most devs are perfectly capable of juggling multiple "open" tasks at one time. You start Task 1, you reach a point where you can't continue until someone gives you feedback, and, in the interim, you move on to Task 2. And during the process, both tasks are "open" and both of them are, to some degree, actively being worked.

That's fine. I get that. I don't have any problem with the (very real) concept that I may have 10 different "open" tasks in my queue at any given time.
If there's any problem in this thinking, it's when everything starts collapsing at the end of the sprint.

For one of those "open" tasks, I was completely blocked for the duration of the sprint because an endpoint (over which I have no control) was returning erroneous data. For another "open" task, it was naively estimated as being only "3 story points", but when I got halfway through the work, I realized that it's dependent upon a legacy process that no one understands - or even knew existed. For another "open" task, I'm blocked by a required bit of feedback from the client - and the client hasn't answered my calls/emails/chats for two weeks.

Despite all of these perfectly natural - and completely unpredictable - contingencies, I still have the project manager standing over my shoulder on the last day of the sprint trying to get me to commit to having everything completed by the end of the sprint. (And, at this point in the sprint, this means they want me to commit to completing everything by the end of the day.)

This is when I revert to full Cranky Old Guy mode. This is when I (for the 100th time) try to explain to anyone who will listen (meaning: I'm explaining it to nobody) that there are only so many hours left in the day. And that, even with my decades of glorious experience, I will still be confined to tackling one task at a time.

If you're keeping score, this is also the time when the PM/client/CEO/whomever starts to get really pissed off with me.

A Code-Word For "Crappy Employer"

How many times have you been sitting in an interview and someone asks you how strong you are at multitasking? They may have prefaced the question by explaining that theirs is a very "high velocity" environment. Maybe they call it "dynamic". Maybe they've even tried to cloak it in the magical phrase that theirs is an "agile workplace" (which, by the way, can mean almost anything - or nothing).

What exactly are you supposed to say? If you have a healthy dose of self-awareness, you may be thinking, "I'm extremely proficient at working a sequential, prioritized list of tasks - but I can only actually work on one task at a time." But you know that's not what they want to hear. And if you're bold enough to utter that response, it might very well signal the end of your candidacy.

So you offer some gibberish about how you can juggle ALL THE TASKS!!! And then you sit back and wonder what future insanity you've just committed yourself to.

You see, "multitasking" is one of those code words that potential employers use to mask the fact that they have no real organization, or they're understaffed, or they believe they can smooth over all the cracks in their process by repeatedly bullying the dev team.

Saying that you have a "multitasking" environment is equivalent to a real estate listing that advertises your house as "cozy". Any seasoned real estate professional knows that "cozy" is the polite way to say that your house is a few square meters larger than a matchbox. And any seasoned software professional knows that "multitasking" is the polite way to say that the company doesn't have a clue about how to manage its workload or its development team.

A Code-Word For "Overtime"

In the example I gave above, where the project manager is leaning on me, during the last day of the sprint, to somehow polish up all those tasks on the last day of the sprint, they typically know that I can't finish it all today. In fact, their pressure often implies (but rarely says outright) that I can somehow meet this deadline if I just give up my weekend to make up the difference.

This isn't a rant against any-and-all overtime. There are few dev jobs where you absolutely never need to throw in some extra hours. Sometimes, you even code through the night - or through an entire weekend. Within reason, this is just fine. It happens. Everywhere. Sometimes.

But let's be honest about what this really means. This isn't "multitasking". This is just making up for a blown sprint/project by flogging the dev team.

If this happens in your job only rarely, that should be OK. If this is their idea of "multitasking" and it crops up repeatedly, you might want to start looking for your next gig.

"Reflection" Is The Kryptonite For "Multitasking"

If you're stuck in a gig where your employer thinks they can squeeze 3x work out of you by simply uttering the magic phrase "multitasking", it may feel like there's nothing you can do. But I've found there's a simple technique that resolves a lot of the problems. I call this technique "reflection".

In this context, when I say "reflection", I mean that I "reflect" my current task list, and my current priorities, right back at the requester. I literally pull up my queue, show them the tasks that are currently waiting for my completion, tell them how long it will take me to finish each task, and then ask them directly, "Which one of these tasks can I put off so I can work on your new high-priority item?"

For example, imagine that I'm currently working on Tasks A, B, and C - prioritized in that order. (Which means, as a practical matter, I'm only working on Task A at this moment.) They all have 8 hours of work remaining. I've already informed anyone-who-will-listen that two of the three will be late.

Then the PM comes running up to me and says it's imperative that Task C gets completed today. So I show them my list and say, "OK. I was previously going to be finishing Task A today, with Tasks B & C being late. Are you cool with me temporarily dropping Task A (which means it will be late), and switching to Task C??"

The confused stares I sometimes get when I ask this question are priceless. The "reasonable ones" will say, "Sure, yeah, OK. Finish Task C today and I'll let the client know that Task A is getting pushed to the next sprint." But sometimes... the project manager looks at me, with no sense of irony, and says, "Well... no. Task A must be done today as well. I just need to ensure that Task C is also done today."

When this happens, I just look at them, suppress my snarky smirk, and shrug. Then I ask them where I can find a replicator that will create TWO of me so that I can complete both of the tasks - today. I'm not exaggerating when I say that I've seen a PM's eye start twitching when faced with this blatant (and rebellious) acknowledgment of the limitations of physics.

If the PM's a real jerk, and tries to insist that I must somehow complete both 8-hour tasks - today - I tell them, in no uncertain terms, that I will temporarily drop Task A, I will finish Task C today, and I am making no promises whatsoever for how much (if any) of Task A I will complete today.

But of course, most project managers are not jerks. Often they're begging for me to finish all the 8-hour tasks today because they think I may be sandbagging. Or they think I have some unfathomable Dev-Fu hidden up my sleeve. But when I reflect the workload, and the current priorities, right back at them, and ask them to tell me what rises to the top (and what drops), it's amazing how many times I get a much more reasoned dialog with the project manager.

Reflection also does a fabulous job of removing myself from the "line of fire". Too many times, devs clam up when they realize that they're running behind - or when, god forbid, something will actually be late. But that instinct's destructive to yourself - and the whole team. If a bunch of your work will be late, and you haven't bothered to properly communicate that with anyone, then the ensuing firestorm is firmly "on you".

But if you've been communicative throughout the whole process. And then, at the end, you realize that you can finish some of this work - but not all of it, then the reflection technique puts the onus for those decisions back where it should be. It ensures that the PM, client, or stakeholder can make intelligent decisions about what does get done - and what gets pushed to the next sprint.

Reflection's Biggest Caveat

If you want good results from my little "reflection technique", you must ensure that the person you're reflecting to has authority over all the items in your queue.

For example, imagine that I don't have a central PM for my current tasks. And I currently have an Infrastructure Task, an Accounting Task, and a Marketing Task. It's the end of the sprint and I know, due to circumstances beyond my control, that only one of these tasks will be finished on time. Then Joe From Accounting walks over and directs me to finish the Accounting Task today at all costs.

Now, I could try to put my Reflection-Fu on him. I could show him my current priority list. I could make it clear that only one of these tasks will be completed today. I could tell him that I'm currently working on the Infrastructure Task, and ask him if he's OK that I would push the Infrastructure Task to the next sprint.

But you know what Joe From Accounting is always going to say??? "Sure. Of course. Push the Infrastructure Task to the next sprint and finish my work today." Of course Joe will say that. Joe doesn't care one iota about the Infrastructure Task. And, in his world, all that matters is that I complete the Accounting Task.

In these scenarios, the reflection technique still works. But I must reflect the priorities (and any proposed re-prioritization) to someone who's sufficiently high enough in the organization that they can weigh all the pros-and-cons of completing the Infrastructure Task today, versus the Accounting Task, versus the Marketing Task. If I don't do this, it will probably just make Joe From Accounting happy (because his work will get done) - and it will piss everyone else off.

Why Does Any Of This Matter???

Maybe... it doesn't. I've seen well-oiled Agile teams with reasonable PMs and realistic clients who managed the process, extremely well, during nearly every sprint. But even when it's working at peak efficiency, any process that even implies that you may be truly working on multiple tasks at the same time represents an "abstraction layer". It's a translation that doesn't fully model the way real work gets done in the real world.

This can be outright harmful when deadlines get crunched, deliverables get squeezed, and nerves get frayed. So, for me at least, the first step in maintaining my sanity is to be painfully honest with anyone whom I come in contact with. Everyone I work with knows full-well that, you can yell at me all day about the urgency of these tasks, and the imperative to get them all done by a certain date, but I'm still going to complete my work the same way that every single person on Earth completes their work - one task at a time.

There's something downright freeing about this acknowledgment.

First, it's freeing because it relieves me of the mental myth that I can somehow complete many tasks at once. Sure... you may choose to pile 100 tasks in my sprint. And I'll make every reasonable attempt to complete them. But no matter how much "pressure" you try to bake into the process, I'm still gonna ensure that I'm working on them in the proper order, and then I'm gonna start knocking them out one task at a time.

If I "only" manage to complete 96 of them during the sprint, then the last 4 will get pushed to the next sprint. And I'm not gonna lose 3 seconds of sleep worrying over it.

Second, reflection returns the onus for project management back where it belongs: with those who are managing business imperatives. Too often, devs try to internalize all of the company's pressures. They try to "save the day" by taking on an unreasonable workload - then they work nights-and-weekends in a desperate attempt to knock out ALL THE TASKS!!! But even when this "works", in the short term, it inevitably leads to burnout and resentment in the long term.

Devs should absolutely feel a sense of "ownership" and "responsibility" for the tasks they've been assigned. But when circumstances conspire to make those tasks unmanageable in the current sprint, it shouldn't be the sole heartburn of the developer to deal with the anxious stakeholders and try to do more than is humanly feasible.

Any time a deliverable is in jeopardy, the developer should be involved in the discussion. But ultimately, by reflecting the current state of work/priorities back to the powers-that-be, the ultimate decision for what gets done - and what doesn't - should be managed by the business leaders. Not by the stressed-out developer.