[Note: Following is the second part of a series on personal productivity. The first post is Email Control.]
Now that you know how to control your email, how to you deal with everything else? Throughout the course of your day, you gain ideas, discover tasks and learn of pressing needs that you absolutely can’t forget to do. How can you keep track of it all?
The key for me is streamlining my information-intake process. I used to be like my colleague who cobbles together a combination of post-it notes, scraps of paper, notecards and whiteboard scribblings, not to mention email in her inbox — all a recipe for an excessive cognitive burden! For me, the way to relieve stress — and get things done — is to limit the intake methods and funnel them into one master.
In my typical day, I’m not behind a computer screen 100% of the time. I’m walking around, sometimes by myself, sometimes having chats with people, sometimes in meetings. So I need a way to capture ideas and to-do items while being respectful of other people and being able to be in the moment (and not distracted). Therefore, in most of my human interactions, I unplug. No laptop (unless I’m pairing), no phone. I find that a screen between someone else and me creates a barrier, however slight, to our interactions, and of course, increases the risk of being interrupted or distracted (“Oh, hold on, just got an IM that I need to reply to…”). So I use an old-fashioned tool: the paper notebook. My notebook of choice is the pocket-size Field Notes notebook. It fits in my pocket, so I can come to a meeting carrying nothing but my coffee cup. I can go for a walk, hands-free. I can have an ad-hoc conversation by the water cooler and jot down an idea or task (starting from the back of the notebook) without having the awkward moment of pulling out my phone, which unintentionally brings a whole external world to intercede between my fellow human and me, when all I need is something to record a few words with that I’ll know where to find later. And that last part is the key: Rather than a random assortment of post-it notes, notecards and scraps of paper, I can relax knowing that all of the ideas and tasks that I’ve accumulated during the day are in one handy place.
[On a side note, I once lost one of my notebooks while walking in San Francisco. A kind-hearted person took the time to mail it to me, realizing how important it was — and perhaps appreciating what a humanizing tool it is! Thank you again, Sue Ann!]
Of course, sometimes it’s easier to record stuff digitally. (I’m not a caveman, after all!) Just as I limit myself to one analog tool, I allow myself only one digital intake method: Evernote. If I’m using my computer, it’s natural and fast to CMD-Tab over to Evernote, where I keep one (and only one!) to-do list. If I’m reading/researching something online and either my brain’s focused mode thinks of something or its diffuse mode presents something I wasn’t thinking of, I quickly jot it down in that Evernote note and continue. Particularly during my daily inbox-zero quest, I offload those discovered tasks into the to-do list, which is essentially what allows me to not use email as my to-do list. (Though it seems like I’m adding an unnecessary step here, I have a reason — keep reading.)
Funneling to One Work-Management System
Limiting the intake methods and recording info is only half the battle, though. At the end of the day, I have two sources of information that I need to reconcile: my Field Notes to-do list and Evernote to-do list. It won’t surprise return readers of this blog to find out that my preferred solution for managing work at the personal level is the same as my preferred solution for team and organizational work: kanban.
I’ll go a bit deeper into personal kanban in my next post in this series. But for now, I’ll explain the basics. Essentially, I keep the columns (a.k.a. work stages) fairly simple:
Options (not usually displayed)
To Do: Stuff I’m wanting to work on next
Doing: Stuff I’m working on now
Done: Stuff I’ve recently completed
The really effective bit is the rows (a.k.a. swim lanes). I use cost-of-delay profiles (more on those later, too) for the lanes:
Expedite: Stuff that needs to be done immediately
Fixed Date (and Intangible Fixed Date): Stuff that truly has to be done by a certain date
Standard Urgency: Stuff that needs to be done
Each morning, I spend a few minutes moving my to-do items from my two intake methods into my personal kanban. I use the cost of delay profiles to sort those tasks according to both “value” (or importance) and time. This is why using a simple tool like an email box or checklist is insufficient: It can’t distinguish between the time consideration of each item. Once I have created a card for each entry in my Field Notes to-do list or Evernote to-do list, I mark them as complete (Field Notes) or delete them (Evernote).
Knowing that I have captured and properly discharged every to-do item, I can relax, because:
I don’t have to worry about anything slipping through the cracks.
I don’t have to carry any of these things “in memory.”
I have one place (my personal kanban) where my tasks live (and I don’t have to keep track of various disparate papers, post-its, etc.), which is perfectly fit for the purpose of managing work.
I have decoupled the capture from the prioritization, so I don’t have to worry about when to do things.
[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.]
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.
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.
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).
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!
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.