Work Plans Must Account for Friction

I overheard this conversation at work one day:

Manager Shannon: “Jamie, I know you’re doing the usability assessments on the Canary project right now. Several other projects are also interested in usability assessments. How much time do you spend on that?”

Team Member Jamie: “About eight hours a week.”

Manager Shannon: “Okay, so you could work with five projects at a time then.”

Do you see any flaws in Shannon’s thinking? Five times eight is forty, the nominal hours in a work week, so this discussion seems reasonable on the surface. But Shannon hasn’t considered the many factors that reduce the time that individuals have available each day for project work: project friction (as opposed to interpersonal friction, which I’m not discussing here).

There’s a difference between elapsed hours on the job and effective available hours. If people don’t incorporate friction factors into their planning, they’ll forever underestimate how long it will take to get work done.

Task Switching and Flow

People do not multitask—they task switch. When multitasking computers switch from one job to another, there’s a period of unproductive time during the switch. The same is true of people, only it’s far worse. It takes a little while to gather all the materials you need to work on a different activity, access the right files, and reload your brain with the pertinent information. You need to change your mental context to focus on the new problem and remember where you were the last time you worked on it. That’s the slow part.

Some people are better at task switching than others. Maybe I have a short attention span, but I’m pretty good at diverting my focus to something different and then resuming the original activity right where I left off. For many people, though, excessive task switching destroys productivity. Programmers are particularly susceptible to the time-sucking impact of multitasking, as Joel Spolsky (2001) explains:

“When you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once.”

When I was a manager, a developer named Jordan said he was flailing. He would work on task A for a while, then feel guilty that he was neglecting task B, so he’d switch to that one, accomplishing little as a result. Jordan and I worked out his priorities and a plan for allocating time to tasks in turn. He stopped flailing and his productivity went up. Jordan’s task-switching overhead and priority confusion affected both his productivity and his state of mind.

Advertisement
[widget id=”custom_html-68″]

When you’re deeply immersed in some work, focused on the activity and free from distractions, you enter a mental state called flow. Creative knowledge work like software development requires flow to be productive (DeMarco and Lister 2013). You understand what you’re working on, the information you need is in your working memory, and you know where you’re headed. You can tell you’ve been in a state of flow when you lose track of time as you’re making great progress and having fun. Then your phone pings with a text message, an e-mail notification pops up, your computer reminds you that a meeting starts in five minutes, or someone stops by to talk. Boom—there goes your flow.

Interruptions are flow killers. It takes several minutes to get your brain back into that highly productive state and pick up where you were before the interruption. A realistic measure of your effective work capacity is based not on how many hours you’re at work or even how many hours you’re on task, but how many uninterrupted hours you’re on task (DeMarco and Lister 2013).

To achieve the high productivity and satisfaction that come from an extended state of flow, you need to actively manage your work time. Jory MacKay (2021) offers several recommendations for reducing context switching and its accompanying productivity destruction.

• Timeblock your schedule to create clearer focus boundaries. Planning how you will spend your day, with dedicated blocks of time allocated to specific activities, carves out opportunities for extended deep concentration.
• Employ routines to remove attention residue as you migrate from one task to the next. A small transition ritual or distraction—a cup of coffee, an amusing video—can help you make a mental break into a new work mode.
• Take regular breaks to recharge. The intense concentration of a state of flow is great—up to a point. You must come up for air occasionally. To minimize eyestrain, periodically focus your eyes on something in the distance for a few seconds instead of the screen. Short mental breaks are refreshing before you dive back into that productive flow state.

Effective Hours

At-work hours seep away through many channels. You attend meetings and video chats, respond to e-mails, look things up on the web, participate in retrospectives, and review your teammates’ code. Time gets lost to unexpected bug fixes, kicking around ideas with your coworkers, administrative activities, and the usual healthy socializing. Working from home offers myriad other distractions, many of them more fun than project work. Even if you work forty hours a week, you don’t spend anywhere near that many on your project.

One software group of mine measured how we devoted our time on projects for several years (Wiegers 1996). Individuals tracked the hours they spent working on each project in ten activity categories. We didn’t try to make the weekly numbers add up to any total. We just wanted to know how we really spent our time, compared to how we thought we spent our time, compared to how we were supposed to spend our time.

The results were eye-opening. In the first year we collected data, we devoted an average of just 26 hours per week to project work. The time tracking made us all more conscious of finding ways to focus our time more productively. However, we never exceeded an average of 31 hours per week of project time.

Several of my colleagues have obtained similar results, averaging five to six hours per day on project work. Rather than relying on published figures to estimate your effective project time, collect your own data. Recording how you work for a few typical weeks will provide a good idea of how many hours per week you can expect to devote to project tasks. Knowing the team’s average effective weekly work hours helps everyone make more realistic estimates, plans, and commitments.

Other Sources of Project Friction

Besides the daily frittering away of time on myriad activities, project teams lose time to other sources of friction. For instance, most corporate IT organizations are responsible for both new development and enhancing and repairing current production systems. Since you can’t predict when something will break or a change request will come along, these sporadic, interruptive maintenance demands usurp team members’ time with unplanned work.

The team composition can further impose friction if project participants speak different native languages and work in diverse cultures. Unclear and volatile requirement priorities can chew up hours as people spend time researching, debating, and adjusting priorities. The team might have to temporarily shelve some incomplete work if a new, higher-priority task inserts itself into the schedule. Unplanned rework is yet another time diversion.

Distance between project participants can retard information exchanges and decision-making. A contract project that involved a customer in the eastern United States and a vendor in western Canada planned some peer reviews of certain deliverables. However, the long-distance reviews took longer than expected, as did follow-up to verify the corrections made. Sluggish iteration to resolve requirements questions and ambiguity about who the right contact people were for each issue were further impediments. These—and other—factors put the project behind schedule after just the first week and eventually contributed to its failure.

Planning Implications

I estimate how long individual tasks will take as though I will have no distractions or interruptions, just focused and productive time. Next, I convert that ideal effort estimate into calendar time based on my effective work-hour percentage. I also consider whether any of the other aforementioned sources of friction could affect my estimates. Then I try to arrange my work so that I can focus on a single task at a time until it’s complete or I hit a blocking point.

My colleague Dave described what happens on his current project, whose manager doesn’t consider the impacts of time lost to excessive multitasking:

“The manager likes to split people up between teams, 50 percent here and 50 percent there, or 50, 25, and 25. But when this happens, it seems like they forget the percentages and think the team has all full-time people. Then they seem surprised at how long things take. Also, being on multiple teams means more overhead in meetings and less coding time.”

If people always create estimates without accounting for the many ways that time splitting and project conditions can slow down the work, they’re destined to overrun their estimates every time.

References

DeMarco, Tom, and Timothy Lister. 2013. Peopleware: Productive Projects and Teams, 3rd Ed. Boston: Addison-Wesley.

MacKay, Jory. 2021. “Context switching: Why jumping between tasks is killing your productivity (and what you can do about it).” https://blog.rescuetime.com/context-switching.

Spolsky, Joel. 2001. “Human Task Switches Considered Harmful.” https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful.

Wiegers, Karl E. 1996. Creating a Software Engineering Culture. New York: Dorset House Publishing.