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 solve 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 stop the downside of them.

It’s more difficult to admit that we are our own source of interruption. We start something, get caught by a 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 2 strategies:

  • The first one is to adopt a sign on the desk meaning that the person wish 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 is established through electronic communication means. You can observe some tacit agreement that you need to answer fast to solicitations by email, and faster 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 really accomplish something.

LarryKim-MultitaskingThe illustration on the right is coming from Larry Kim’s article multitasking is lilling 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 highly probable that we will need a lot of time to re-gain the level of understanding of the problem we had when we left this task.

MikeCohn-ContextSwitchingIn his book Succeeding With Agile, Mike Cohn quotes the study from Kim Clark and Steven Wheelwright on the impact of multitasking on productivity that are shown on the graphic above.

In an organization where the work is distributed by managers and where the managers convey the pressure of instant response, the time wasted by permanent asks will paralyze the whole organization. This is 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 work is distributed by the system, 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, on 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 each individual from interruptions: by accepting unavailability period, by synchronizing the whole team on the same schedule (more difficult if you are on several timezone), by dedicating people for a period of time 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 work?


Header picture is from Ryan McGuire.




One thought on “Let us code!”

Comments are closed.