Balancing Context-Switching: 3 Keys to Optimal Productivity

This post explores the challenges of tasking information technology teams to work on the business while simultaneously working in the business.

I once attended a divisional quarterly all-hands where the VP made an expansive presentation of all the new tools and programs that we intended to roll out in the coming quarter. When it was time for Q&A, one of the directors asked a loaded question that I’ll paraphrase like: “How are we going to accomplish all of that without going nuts?

This company faced the all-too-common challenge of being organized into departments burdened with responsive support obligations, simultaneously with proactive effort required by project-based objectives.

The director who asked this loaded question was cognizant of the effects of context-switching on her team’s productivity and morale, which is known to cause burnout and turnover. She learned this over the course of past quarters that were also aggressively loaded (which is the case in every quarter for those of us that work in tech startups).

3 Keys to Mitigating

  1. Allow teams to self-organize by selecting the work from a backlog
  2. Enact transitional rituals for dev teams that mitigate drain from context switching
  3. Allocate proactive effort in half-day-sized timeboxes

How do self-organizing teams mitigate?

Self-organization is an embedded feature of product development frameworks like Scrum. The first two phases of Scrum are product backlog creation, followed by sprint planning. When implemented properly, these two rituals involve breaking down work into pieces as a team, followed by divvying it up and assuming individual responsibility for it.

When a person makes a commitment to do something in a team situation, there are some subtle but powerful mechanisms that automatically kick in, which can directly benefit your immediate objectives as well as your organization’s long term outcomes.

The first benefit is the tribal instinct to deliver for the team. When a member of a group declares: “I got this,” it means something to the tribe. It takes on a more profound meaning than management-assigned tasks that seem to get piled onto the assignee’s existing duties.

Another benefit is that a commitment motivates an individual to self-manage in order to deliver. This mitigates the need for a manager to interrupt daily rhythm with a context-switch to make sure things are progressing.

Finally, micromanagement is tedious work. This article began with the director who inquired about how all of the work was going to get done. She did so because she foresaw the pain and productivity-drain of micromanagement, which can be negated if structured to self-organize.

How do transitional rituals mitigate?

When D’Mention Systems was in years four and five, we principals were owner-employees who had taken on way too much. Like all entrepreneurs though, we still needed to get it all done while maintaining sanity. In our effort to persevere, I learned a valuable transitional ritual from my business partner, Andrew (who also happens to love coffee).

When we planned our workdays, he used to map out a Starbucks meeting route for the day, such that we would insert a venue change between each context switch (e.g., discuss managed services issues at Speedway Starbucks; accounting software backlog at University Starbucks; etc.).

It turned out that this mental and physical transition between different types of work was valuable in providing the sanity and mental capacity to go deep on one thing at a time, and then cognitively release from that. This provided stress relief for context switching (we also learned the location and ambiance of every Starbucks in Tucson).

I have since applied this lesson in leading teams at all levels and across oversight of the 4 Ps, and the benefit of the physical and chronological separation of different types of work has been paramount. It is especially important to transition and separate interactions pertaining to responsive and proactive work — they simply do not mix (stay tuned for many more posts on this).

How do half-day timeboxes mitigate?

Timeboxes are a key concept in the realm of the 4 Ps, yet leaders in that space often fail to realize that the metaphorical walls of the timebox apply to more than a mere analogy for getting things done fast. They also portray shielding between the happenings inside the box and what is going on outside.

I am speaking of the efficiency tools used to communicate in the modern team space (e.g., Slack, Teams-Chat, Skype). These tools make responsive/operational effort immensely efficient, while being a cancer to the other side of the spectrum, where proactive effort requires shelter from interruptions to enable focus. Interruptions introduce context-switching and reduce dev productivity.

Let’s talk – after lunch

To counteract this, team members must adopt rituals individually to transition themselves into whichever environment is optimal for the type of work they are executing. This enables better delivery for their teammates and customers.

One way to provide interrupt shielding is to enact practices for dev team members to have their phone/chat alerts deactivated – until after lunch. Adopting timeboxing norms like this can also make sprint planning and estimating easy with half-day time slots, while considering competing operational capacity needs.

Closing

If you seek success with self-organizing teams and transitional rituals, then some kind of timeboxing is critical in a world where our teams have to balance ops and dev. To adopt these kinds of fundamentals and execute them well, they need to be baked into organizational culture. By this I mean that support from senior leadership helps ensure standardization of rituals and habits that keep an IT shop’s culture healthy and happy.

The burden of shouldering both ops and dev simultaneously is inevitable in the modern startup, but not insurmountable. Hopefully these subtle but effective fundamentals help to increase retention and optimize productivity across your IT organization.


Mike Liskow is a business development consultant, writer, artist, entrepreneur and thought leader in the business development space for tech startups.

D'Mention Systems was established in 2003 and provides business development consulting engagements for tech startups.  

Similar Posts