The cost of switching apps

When I think about switching apps, I am less interested in the movement between windows than in the work a person has to reconstruct after moving. Which brief explains this task? Where does the decision live? Is the status in the conversation the same as the status in the project?

Those are useful questions for a team to investigate. They are also questions that productivity statistics can make harder to discuss honestly. A striking number is easy to repeat without its sample, its definition, or the limits of what it measures.

Three sources help frame the problem. They examine different things: toggling between applications, returning to interrupted work, and the coordination around work. I would use them to choose what to examine in a team, rather than as a forecast of what changing its software will save.

Toggling has a measured reorientation cost

In their August 29, 2022 Harvard Business Review article, Rohan Narayana Murty, Sandeep Dadlani, and Rajath B. Das describe a five-week study of 137 people on 20 teams at three Fortune 500 companies. The average person toggled between apps and websites nearly 1,200 times a day. The authors estimate just under four hours a week went to reorienting after toggles, about 9% of a year’s working time. Read the HBR article.

That is a finding from a particular group and an estimate by the authors. It is not a measurement of your team. Nor does it mean every switch is unnecessary: some work needs information or capabilities from different places.

My practical takeaway is to examine the transitions that exist only because information is split. If someone opens another app just to check which copy of a decision is current, investigate the duplicated decision before blaming the person for switching windows.

Returning to work is different from refocusing

In Gallup Business Journal’s June 8, 2006 interview, Gloria Mark describes her team’s research: shadowing 36 managers, financial analysts, software developers, engineers, and project leaders for three days. Of interrupted work, 81.9% was resumed the same day. Among that work, the average interval before resuming was 23 minutes and 15 seconds, with about two other tasks in between. Read the Gallup interview.

That measures when people resume interrupted work. It does not measure a fixed period during which someone cannot focus. The intervening tasks are part of the interval, so calling the whole interval time spent refocusing misstates the result.

For a team, I would turn this into a question about returning: when you come back to a piece of work, can you see the decision and the next action? A clear place to resume is a concrete thing to improve, even without assigning a universal cost to every interruption.

Coordination is broader than app switching

Asana’s Anatomy of Work Index finds that 60% of a person’s time at work goes to “work about work.” The same Asana article says the average employee uses 10 different apps every day. Read Asana’s account.

The category includes coordination around the work, rather than app switching alone. Do not treat the percentage as time that disappears if you remove applications. People still need to agree on priorities, ask questions, and communicate decisions.

I would not add these figures together. They concern different activities and different research settings. None establishes a guaranteed saving from adopting Zanbase or any other product. Their value here is as a reason to look closely at the unnecessary coordination in your own work.

Follow a piece of work before counting tools

Choose a real deliverable and follow its path with the people responsible for it. Start at the request. Find the brief, the conversation about scope, the current status, and the place where the final decision belongs.

Write down each handoff that asks a person to repeat information. Does someone copy a deadline into a message? Does a reviewer need to ask for the brief? Do people know where to record a change after agreeing on it?

Keep this review about the workflow. It should help the team explain where information belongs, not turn into an assessment of how often individual people open applications. A list of tools tells you what the team has. Following a deliverable tells you what each tool requires the team to do.

Remove redundant tools where the work allows it

Look first for overlapping jobs. If two places both hold the authoritative status of a project, choose which one owns that status. Then decide whether both tools still serve a purpose.

Fewer tools can be a useful direction, but do not remove a specialized capability solely to reduce the count. Ask whether the remaining setup supports the actual work, including review, access, and delivery. The test is whether people can complete the workflow with less repetition.

Make the decision explicit. Name where the work starts, where its status lives, and where someone should look for the latest decision. Give the team a clear destination before asking it to stop using another one.

Keep the work and its discussion together

Choose a home for the work and keep the conversation about it close enough to follow. When a discussion changes the scope, put the resulting decision where the next person doing the work will look.

Use links to the authoritative brief or task instead of maintaining fresh copies in every conversation. Add a short explanation of why the link matters. A bare link can be difficult to interpret; a pasted copy can become a competing source. Aim for a useful reference to one maintained place.

Check access when sharing that reference. The intended reader should be able to open the source, or understand whom to ask. This is a working agreement for the team to adopt alongside its software choices.

Evaluate a workspace against the handoffs

Zanbase is one option for bringing chat, docs, and projects into one workspace. Its links and mentions let people connect the relevant work. That fits the direction I am building toward, but it is not evidence that moving a team produces a particular productivity gain.

Other options include reducing overlap in the tools you already use, choosing one home for project status, and agreeing to link back to decisions. Start with whichever change addresses an observed problem in your workflow.

After changing the setup, revisit the same deliverable with the people who do the work. Can they find the brief, identify the current decision, and resume the next action without asking someone to reconstruct the context? Those answers are a better basis for your next decision than applying a published average to everyone on the team.

Products used

• Chat
• Docs
• Projects