Let us code!

I started this article a long time ago. And that’s a comment from a person I work with that triggered the sense of urgency to contribute to solving this problem. He said:

Stop interrupting us! Let us code!

I became sensitive to interruptions when I discovered the Pomodoro method, subject that I covered in this article.

I experimented that, when I was able to focus on one thing, I was extremely efficient. Though, I tried to influence people in teams I worked with to preserve periods of time without interruption.

People easily identify others as interruption sources. It is usually something easy to cover with a team to find agreements to stop the interruption flows and halt the downside of them.

It’s harder to admit that we are our source of disruption. We start something, get caught by notification, our mind wanders and takes us somewhere else… We need a strong commitment to resist to the multiple temptations to quit what we are doing for something else.

The problems became major with a distributed team.

With colocated teams, I experimented two strategies:

• The first one is to adopt a sign on the desk meaning that the person wishes not to be interrupted (a funny puppet for example)
• The second is to synchronize the team on the same schedule: 50 minutes of work without interruption, 10 minutes break, 15 minutes for interruptions, and so on, with a bigger break for lunch.

Synchronization is the most efficient strategy, but it’s also the most demanding one for team members.

With a distributed team, the connection flows through electronic communication means. You can observe some tacit agreement that you need to answer fast to solicitations by email, and more rapid to solicitations on chat rooms (IRC, jabber, slack or others).

If you agree with that, you can spend your whole day jumping from one subject to another without actually accomplish something.

The illustration on the right is coming from Larry Kim’s article multitasking is killing your brain, and it explains quite well the situation.

Our overall satisfaction will suffer from those constant context switch. Furthermore, each time we will try to go back to a task, it’s very likely that we will need a lot of time to regain the level of understanding of the problem we had when we left this work.

In his book Succeeding With Agile, Mike Cohn quotes the study from Kim Clark and Steven Wheelwright on the impact of multitasking on productivity that as shown in the graphic above.

In an organization where managers distribute the work and where the managers convey the pressure of instant response, the time wasted by permanent asks will paralyze the whole organization. This explains why some small teams of 10 can achieve more than teams of 300 letting bigger organizations questioning themselves.

The phenomenon will be less important in an organization where the system distributes the work. An organization in which each team member knows what he/she needs to take after a completed task.

Funny synchronicity, Jason Fried published an article on the same subject on Medium when I was writing this one. He suggests some ways to change the agreement on the use of communication tools that are important.

My recommendation would be to invest some time with the team to refine:

• The use of communication tools: what needs to be covered by email, by instant messaging, in a chat room, or what needs to be covered with share documents that will help to build a common position. In each case, we need to define what are the agreed reaction delay
• the way to protect the individual from interruptions: by accepting unavailability period, by synchronizing the whole team on the same schedule (harder if you are in several time zones), by dedicating people for a period to handle interruptions that we cannot avoid
• to play a game to understand the power of focus (like the name game)

And about you, what are your strategies to let the people that are working with you to do their job?

The header picture is from Ryan McGuire.