Multitasking Is A LIE
Tags: productivity, programming, agile, kanban
Published: 2020-05-15 01:54:06

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"...
<br/>

## 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_.
<br/>

## 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_.
<br/>

## 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_.
<br/>

## 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.
<br/>

## 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.
<br/>

## 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.
<br/>

## "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.
<br/>

## 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.
<br/>

## 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.