Developer Flow and Coming Up For Air

Developers shine when they get into flow, but we must be active participants in the mechanisms which make flow possible in an active organization.

Managing Developer Attention is a Whole-Organization Concern

If we zoom out and see ourselves in the context of our whole organization, we'll likely notice that effectively managing the attention of a group of knowledge workers is an essential part of the total operation. This is certainly true at Metal Toad. In one sense, our business is built on our ability to organize our developer, strategist, and project manager's thinking around each project. The fundamental value is answering:

• What should I think about?
• When should I think about it?

These can be combined with positive implications to: "What should I think about right now?" A couple important and related questions:

• With whom should I do this thinking?
• What are the concrete outcomes I should deliver?

At Metal Toad and many organizations similar to it, these questions are the lifeblood of our project management team. This post addresses the intersection of these questions and getting into and staying in flow.

Developers Must Touch Base With Their Peers & PM's

If your organization respects flow (and it should), then here's something you need to know.

There are people on your team who have something to tell you or ask you, but they have avoided interrupting you in order to respect your flow.

That's awesome. But it deserves some reciprocal attention by those of us who's flow is being protected.

Thing is, people need your attention. You must make a deal with them.

We, the flow-oriented knowledge workers, need to participate in this process effectively. And it can be pretty simple. First, lets lay the ground rules which might already be in place in your organization.

1. Knowledge workers have real protections from interruptions
2. Project management is accessible either in real time or with quick asynchronous responses (IM, email, etc.)

If you don't have a project management team, #2 is your task management software or whichever system you use to keep track of what you need to do (For example, I use OmniFocus). The same requirements apply: it doesn't bug you, but you can get immediate-ish feedback from it.

Okay, now the main point I want you to reflect on: your PMs (and perhaps your peers) are essentially building a queue of notifications for you while he/she lets you work. They are respecting your flow, and giving you the gift of allowing you to fully engage your attention, working to completion of task so you do not need to restart work or thinking after an interruption. Your piece in this process is simple but critical for the organization: as soon as you exit flow, check in.

Come Up for Air

This check in can take many forms. It can be obvious such as in person or IM, or you can create an understanding with your PM and peers about how you manage your email, text messages, or calls. For example, I have a four-tier organization of ways to get in touch with me, and how I treat them is essential to my ability to enter flow and then effectively re-engage with my team when I finish a thought or task.

• Phone (immediate interrupt): always on, but never any email or social notifications. For most developers, this might be intended only for family to have immediate access to me if something comes up. On that note, my family also knows when to use text and when to call. A text can wait, but is more time sensitive than an email, and a phone call cannot wait.
• IM (nearly immediate): I make myself available to my peers for technical escalations or anything where I can help them remain in flow.
• Text (momentary delay): I will usually ignore a text message if I am in flow, but may respond during brief moments of clear mind, not necessarily at end of task.
• Email (absolutely asynchronous): this is the critical one, and your peers and PM should know how you manage your inbox. Simple advice: do not let yourself be notified each time you receive a message if you want to be in flow. Let every email land safely in your inbox. Then when you finish your flow, open it up and process 100% of them. Keep in mind that processing email is itself flow-worthy. Check out InboxZero for more on how to do this.

Your family, peers, and PMs should know how you approach email. Specifically for the topic at hand, anyone whom you expect to respect your flow should know which channels interrupt you at which intervals. In almost all cases, they should communicate non emergency things in a non-interrupting channel, as long as you guarantee them that you will process their communication as soon as you come up for air.

Usually this is email, but that won't always work. Here at Metal Toad, we keep involved with the community and for some of our devs, that means getting so much email that what i am suggesting is not sustainable. In these cases, your task is to create the habit or communication channel that allows you to see the communications which might be important to the rest of your day, but for which your peers have been respectfully avoiding an interruption. Perhaps there is a particular subject line you can create a filter for, or perhaps you can build a habit to always IM your PM and inform your peers that if they need you for a non-blocker they can request your attention via your PM.