Self-Management Practices, Part 1: Email Control

[Note: Following is the first part of a series on personal productivity. Whether you work remotely, in-person, in a team or as solo contributor, most professional people in today’s knowledge economy need to develop the competency of self-management. I aim to share some of my techniques for self-management, learned through discovering my own weaknesses and using my strengths and applying the ideas of others to create structures and practices that militate against those weaknesses and help me focus on getting things done. Topics I plan to cover include personal kanban, pomodoro technique, planning by cost-of-delay and sustainable pace.]

Email Control

I’ll start with perhaps the most ubiquitous and nefarious enemies of personal productivity: Email. Do you control your email, or does your email control you?
Email used to control me, making me respond to it on its terms, overwhelming me, creating unnecessary cognitive load. Now, I control this silent killer of productivity. Here are a few of my practices.

Inbox Zero

no-new-mail

Why am I smiling in this picture? Because I have no email!

I can’t tell you how much of a difference having a policy of inbox zero — that is, at some point during my day, having no email in my inbox— has made. Before Merlin Mann’s thorough talk inspired me to set and live by a inbox-zero policy, I used to worry about those unresolved messages: Had I forgotten something? Was someone waiting for a response? Sometimes I had indeed forgotten, or someone was waiting — in which case I caused dissatisfaction around me. However, many times, no one was waiting, but still my brain, not being certain of that, couldn’t let it go, and I had to deal with unresolved threads spinning in my mind, causing unnecessary cognitive load.

Today, I have a recurring daily card in my personal kanban (more on that in another post) to get to inbox zero — actually two: one for my work email, and one for my personal. Because I devotedly follow my personal kanban, this ensures that I actually do it. (If you’re interested in combining your inbox with personal kanban, you may want to try Flow-E, a new tool from the makers of Kanbanize.)
This leads to other virtuous practices: First, I’m able to give people a 24-hour response expectancy 90% of the time. (Don’t you just hate it when you have to nag someone with a followup email?) Also, I don’t overreact to email requests*, which frees me to manage my work on my own terms, not simply the random arrival rate of the message; one study found that 70% of work emails were attended to within six seconds of their arrival — that’s what I consider overkill in terms of service-delivery expectation! And because of those two things, I’m able to actually switch off email throughout the day.
*The technique that supports this is planning by cost-of-delay, which is another post in this series.

Turn Off Email

Given that it takes people on average about 25 minutes to reorient back to a task when they get interrupted, it’s a wonder that people who keep their email open ever get anything done (other than incessantly replying to email!).
Yes, it’s possible to not have your email tab (or email app) open all day. I check my email roughly three times per day (morning, lunchtime, late afternoon). And I work in a global team, in a global organization, so I’m getting email around the clock. If people need me to respond to a request faster than 24 hours (or during my core work hours, four hours), I make sure that that know they can reach me other ways (e.g., text, Google hangout).
desktop-notifications

Just say no to enabling desktop notifications.

What percentage of your day is email open? Why is that? Perhaps you have a good reason, but you might try removing desktop and phone notifications and checking to see if you’re more productive.

Email should scale with your role/position/level

If you’ve ever gotten promoted, did you notice an increase in the amount of email you received? Regardless of my level and responsibility, I’ve tried to keep my incoming email manageable — that is, I can usually get to inbox zero in 30 minutes. If you reach a place in your career in which you have to hire someone to manage your email for you, you’re doing it wrong. Instead, look for different ways to interact with your stakeholders — better feedback loops, more face-to-face time, delegating decisions to others, working in a team. By responding to people’s email — or having your admin do it — you’re simply exacerbating the problem.

Five sentences (or less)

Given that you will always have some email to deal with — and that can be an appropriate communication medium — the last tip relates to knowing how to communicate effectively with email. My main practice here is the “Five Sentences or Less” response (http://five.sentenc.es/), which forces me first to think about whether email is the right medium and second to clarify and condense my thoughts in my reply. This allows me to communicate assertively and clearly, while “paying forward” to my recipients less email cruft on their end. Be honest: When you receive an email that requires scrolling, how many of you actually bother reading it in its entirety?
How do you know whether and how to reply? Some smells:
  • You’re attaching something: Before you drag that doc into the email body, consider putting it into a shared team space (e.g., Jive, wiki, Google Docs) and simply including the link to it. In addition to simple hygiene of facilitating versioning and collaboration,  you’re also helping people to avoid using email as a document repository. Don’t force people to keep your email.
  • You’re writing more than five sentences: If you can’t say it in five sentences or less, chances are that you need better fidelity communication; try a video or phone call. If you need something to serve as documentation that needs to live beyond a phone call, write the document and share the link.
  • You’re writing only one sentence (or word): Simple yes/no responses can be better handled in other ways, such as instant messaging.
  • You’re writing something that will require group discussion and/or decisions: We have other, better ways of group discussions, namely video calls or quick in-person meetings. If it’s a simple decision or set of preferences, create a survey and send the link. And please — whatever you do — don’t use email to try to find out “what time works” for each person in the group. It’s not 1999 anymore!

 

Advertisements

Software-Delivery Metaphors from Basketball

Basketball practice, circa 1925, courtesy Seattle Municipal Archives

Basketball practice, circa 1925, courtesy Seattle Municipal Archives. Then, as now, the WIP limit in the game is exactly one.

March has begun, and that means March Madness, when many Americans turn their attention toward basketball, with unbridled hopes in NCAA tournament brackets and the thrills of underdog upsets. Basketball offers not only the promise of nail-biting college tilts but also some helpful metaphors for software delivery. Read on for an assist for your team!

Practice Your Free Throws

I was never a star basketball player (I made it only as far as the high-school sophomore team), so I was keenly aware of my need to practice in order to build my skills. For instance, I always found that if I were having trouble making field goals (which was not infrequent!), it helped to practice free throws. With no jumping involved and no one defending me, this allowed me to simplify my form and focus on the basics. I reasoned that, if I couldn’t hit a free throw, I had no business trying longer-range shots in complex situations. Even now, I still can’t figure out why players who take most of their shots from behind the three-point line can’t seem to reliably make free throws.

The same is true in software delivery. For instance, before you can realize the goal of continuous delivery, you need to discipline yourself in automated testing and continuous integration. Be able to reliably answer in the affirmative Jez Humble’s three questions:

  • Does everyone check into mainline (at least) once per day?
  • Do you have a suite of tests to validate your changes?
  • When the build breaks, is fixing it the team’s #1 priority?

If your team aspires to continuous delivery, you can’t keep chucking up the same code or try to do it in the midst of delivery commitments and deadlines with a bolted-on “devops team.” You need to slow down in order to speed up — take time to write tests at the proper levels and integrate continuously. If your throughput is lower to begin, so be it. It’ll be higher in the long run.

Planning Flow During the Timeout

If I had scored a point for every standup with the report-to-the-leader anti-pattern that I’ve witnessed, I’d have made varsity. I understand the accountability idea behind Scrum’s three questions, but I have rarely seen it implemented in practice in a healthy way. The standup tends to be rote, individual-oriented, low-energy and low-value, with teams sometimes abandoning them for “real work.”

Contrast this with a timeout in basketball. It’s fast, full of energy and purposeful. Why? The timeout is focused on how the team can work together in the next short period of play. That’s it. Imagine if the coach went around the circle demanding that each player describe what he had been doing:

  • “Well, coach, I missed two jumpers but made a free throw.”
  • “I’ve been guarding #18. Still plan to guard him after the timeout.”
  • “I’ve been running up and down the court. No blockers.”

Anyone who has been watching the game knows these things! Likewise, we were all in the office yesterday; we know you’ve been working. In a timeout, individuals don’t report status; the team proactively solves its main impediments to flow:

  • “They’re double-teaming me, coach. That means someone is going to be free — let’s get Christopher or James the ball more.”
  • “I can’t keep up with #18 — Chike, can you drop down and help me guard him in the low post?”

In a timeout, conversation is lively and self-organizing; no one waits to be called on. When the timeout ends, the team runs back onto the court knowing the plan. Does your software-delivery team know the plan when standup ends? Treat standup (a.k.a. daily flow planning) more like a basketball timeout, and orient your standups toward the team and flow.

A Whole-Team Approach to the 7-foot Constraint

That brings us to one last metaphor from basketball: System constraints are like a defense that you have to dynamically figure out. The Theory of Constraints tells us that every system has a constraint that governs its output. In basketball, this constraint is sometimes easy to spot, whether it’s the 7-foot dude who is blocking everyone’s shots, or your point guard who keeps turning the ball over. In basketball, both on the playground and on elite NCAA courts, teams adapt to their constraints. It happens so fast in basketball that we don’t even think about it: If the 7-foot dude blocks shots from close range, a coach may deploy a lineup of better perimeter shooters or a player who is quicker and can draw fouls from the big man. Another example is a double-team situation: The team doesn’t expect a double-defended player to try to keep scoring — no, the team comes to help him, since one player is usually free. Basketball players do this almost instinctively, because they share a common goal: Score more points than the opponent.

In knowledge work, constraints are more difficult to see, and a lack of goal-orientation inhibits whole-team approach to the constraints. For example, if a person is “free,” it’s easy for a dev to pull in new work, heedless of how busy or “double-teamed” the QA is. That’s why we use WIP limits and make our constraints visible with tools like cumulative-flow diagrams. (In basketball, the WIP limit is one: It’s called the ball. When your teammate is double-teamed and you are unguarded in the open, you don’t grab another ball from the sidelines and start playing, do you?) Whereas basketball players naturally practice the art of work leveling by constantly taking a whole-team approach to constraints, we in software development can do the same. We merely need the help of simple job aids and a shared goal, which doesn’t mean staying busy as individuals, but means finishing work.


Rules for email

My personal rules for email:

  • Turn email off
  • Zero inbox daily
  • Five-sentence replies
  • Process email inside a pomodoro no more than three times a day (morning, lunch, afternoon)
  • Set expectations (24-hour policy, out-of-office auto-reply, provide alternative contact means)
  • Use email only after exhausting other communication means, in this priority:
    1. Face-to-face conversation
    2. Video conversation
    3. Audio conversation
    4. Instant message
    5. Web-site post/comment