Email. Twice daily. No more, no less.
On a recent trip to Las Vegas, I picked up The Four Hour Workweek for my Amazon Kindle to read on my flight. When I came back from my short vacation, I decided that I was going to change how I approach email on a daily basis. In my position, I receive a lot of business-related emails on a daily basis, whether that be from employees, clients, or potential clients. A typical day would consist of me trying to get a few tasks done while keeping an eye on any new requests. This resulted in a lot of context-switching and my days were extremely fragmented. Our team had started an experiment where we’d track all of our time throughout the day on printout. Our goal was to log all of our start/stop times for each activity and also capture each interruption within those time windows. After just a few days of doing this, I was noticing how much time was being spent on emails each day. I also noticed that it was rare to have a full hour of uninterrupted work on a single activity. Aside from distractions that you’d typically find in an office environment, email was keeping me from attaining the level of focus that I was seeking on my work.
So, using some motivation from The Four Hour Workweek1, I opted to come back to the studio and change my behavior. That morning, I emailed my entire team and my clients to let them know that I would only be checking my email at 10am and 4pm each day. I explained that they could call me at the studio if there was something that needed my urgent attention. Admittedly, I was nervous as I hit send. What was I getting myself into? What were my clients going to think? Would they think that I’m just an unorganized mess?
Three weeks later…? It was one of the best emails that I’ve sent in ages.
The Results… (so far)
Here are a few realizations and conclusions that I’ve been able to attribute to this change.
My World Didn’t Collapse
Before I made this decision, I came up with a lot of excuses for why this was a bad idea.
- I might not respond fast enough to a new sales lead
- A client might forget and send me an urgent request via email
- Insert any other reason related to you just not following up quick enough…
In three weeks, none of these things has bitten me in the ass. It hasn’t been perfect, but I don’t believe that it’s had any significant impact that outweighed the benefits.
Less Time Spent on Emails
I spend less time on email than I did before. Why? I don’t treat email the same way that I used to. As a result of approaching email differently, I noticed that I am now more likely to keep my emails short and sweet… and most importantly, to the point. One of the great things about Gmail is that it’s made it easy to have conversation-style emails with people, but it’s also made it too easy to have conversations with people. I now realize that so many conversations that I would participate via email would entail single sentence questions/responses with similar length follow-ups. Each time you come back to that email, your attention is on that conversation and those can eat up a lot of time if you’re not careful.
So, now that I’m checking email twice a day, I tend to write only what is necessary to move the conversation forward until the next time I check my email. As a result, email conversations are slower now, but they aren’t taking as much of my time. The benefits have outweighed the negatives.
More Focus Time
Since this change, there has been a handful of days where I have been able to focus completely on a single activity (task) for over a hour at a time. My record was nearly three hours one morning early last week. Unfortunately, I completed the task I had budgeted five hours for was finished in less than three. ;-)
I’m able to do this more now because I’ve been able to release my check-your-email-again-just-to-be-safe demons. I’ve been able to trust my system and I’ll share some tips on how I eased myself into this.
More focus time has allowed me to spend less time working on individual tasks because they are subjected to nearly as much context-switching.
More Creative Time
Another benefit that I’ve seen since this change is that with this time that I’ve salvaged, I find myself with more time to be creative. I haven’t pinpointed what the reason behind this is, but I do feel like I’ve been more creative the past few weeks than I have been for the several months prior. Perhaps it’s just a side-effect to altering my workday… or that I don’t feel like a victim to the INBOX… or that it’s been extremely sunny in Portland… or that I’m more aware of how I’m spending my day.
Whatever it was, it started within days after I implemented this new approach to managing email. I’m happy to attribute it to this for the time being. ;-)
How I Did It
Here are a few things that I did to start this process. Credit is due to Tim Ferris for suggesting most of these and here are some of my further thoughts.
List Your Excuses
Chances are, you don’t have as many as you think you do. I started with the critical ones and really weighed the pros/cons. It’s safe to use the, “Will anybody die if I do this?” question to help you respond to each of these. You can be a little less cynical and ask yourself, “Will we go out of business if I do this?”... or “Will we lose client X if I do this?”
Then ask yourself, “Is it unreasonable for me to do this?” If the answer to, “will we lose client X if I do this?” and this don’t match up, you might want to re-evaluating your client roster. If your clients are reasonable people, they’ll see that there is value in this that will benefit both parties. As I mentioned, just remind them that they can call you if there an urgent request. If they abuse this, straighten them out or it’s time to re-evaluate your client roster.
It’s not unreasonable to protect your time as much as possible, despite how much they pay you.
Set a Time (use a calendar reminder)
You can’t just say, “I’m only going to check my email twice a day.” There isn’t any way that I would have been able to honor such a commitment. “When exactly?,” is the obvious response to that.
I set a scheduled event on my calendar that happens everyday at 10am and 4pm. I have a 15 minute notice on that event so that I’m reminded that it’s time to wrap up what I’m working on. When I have a conflicting meeting, I will just reschedule my email for another time of the day. The time is visible to all of my teammates and my clients know when I’ll be catching up on email.
Why did I chose 10am and 4pm? Well, I start my day at the studio at 7am. This allows me to have up to three hours of time to focus on getting other things done before tackling email. Why 4pm? This is a hour or so before I leave for the day. Email isn’t the first or the last thing on my mind at each ends of my workday.
Communicate the Change
This will not work if you don’t set peoples expectations. If people are accustomed to you being extremely quick to respond to emails and you change your behavior all of a sudden, you’re going to freak them out. Let them know what you’re doing, why you’re doing it, and you might even encourage them to consider it too. More often than not, everyone you work with is feeling overwhelmed and wants more control over their day. Send them a link to this post. ;-)
It all comes back to managing their expectations.
Quit Your Email application
Seriously, quit that application when you’re not using it. In fact, quit any program that is open when it’s not related to the activity that you’re focused on. For email, we use Gmail for domains and I run it through Fluid. This means that at 10am and 4pm, I launch the Fluid app and start working my way through emails. Once I get through my inbox and finish what I need to handle right now, I quit it.
Also… disable email notifications. They aren’t worth it.
Inbox Zero
I’ve been practicing the habit of keeping my INBOX empty for nearly a year. Everything gets labelled, organized, and archived properly once I open up each email. Some stuff gets sent to Highrise to respond to later while some emails get an immediate response.
One of my favorite things about maintaining Inbox Zero and checking my email twice daily is that when I open up my email client, I’m faced with a list of nothing but unread emails. Since I know they’re all unread, I can start at the oldest and move my way through them, one by one. When I get to the end of that list, I’m almost done. I then fire up Highrise to see if there is anybody to get back to today. If so, I fire off those emails and close off those tasks. Once I have both lists completed, I’m done.
No Cheating
The one thing that I’m working on the hardest right now is not cheating. I’ve caught myself a few times. I’m waiting in line at the coffee shop and I pull out my iPhone. Out of habit, I launch the Mail.app and find myself looking at incoming emails. You might argue that if you’re not in the middle of something, it’s a good way to feel useful, but I’m sure that there are other things you can be tackling. Your email will be there at 10am… I promise.
The biggest problem with cheating is that if you see that someone responded to something you sent in your previous email, it’ll force you to make a decision. a) do you look now? or b) look later? If you choose b, your brain is going to be wondering what she said. It’s can really bug you for a few hours. Trust me. :-)
In Summary..
It’s only been three weeks since I adopted this and I know it’s far from perfect. However, I assure you… it’s been worth the self-proclaimed risks. I enjoy my email time more than I used to. As I mentioned earlier, I like being presented with a healthy list of unread emails to work my way through. Sometimes it takes only five minutes to get through them all, sometimes a hour or more if I have a lot of people to follow up with.
It’s been a fun ride so far and I’m sure that there are many more challenges ahead, but I am planning to stay on course. Who knows, maybe I can move to once daily after a few months?
Estimating versus Timeboxing, part 1
As if delivering projects wasn’t hard enough. Delivering projects on time is even harder. As practitioners, we’re all responsible for measuring up the obstacles in front of us and are accountable to those measurements. At least, we should be.
One of those measurements is time. Time is a funny thing. People have a lot of interesting things to say about time. Some say that it’s one of the most valuable things that we have… but I’ll avoid diving into a philosophical discussion for now.
What I wanted to talk about was project estimation. Specifically, estimates for deliverables. For the past several years, our team has put a lot of effort into becoming more accurate in our time estimating skills. Despite analyzing how often we over and/or underestimate the time each of us believes it’ll take to complete a task, we find ourselves coming back to the drawing board.
A few things that we’ve learned.
- Tasks that we believe will take a few days/week/more to complete are often underestimated
- Tasks that we believe will take less than a few hours are often more accurate or overestimated
- Too many tasks were completed with a bigger budget than was necessary (lower ROI)
- A lot of time was spent working on requirements refining to get better estimates
When we began to step back from this and look for patterns, we found that several of the tasks that we would budget hours for (versus estimate hours for) were proving to be more accurate. This approach is most commonly known as timeboxing. With timeboxing, we can place a dollar value on a specific task and work within that constraint. For example, with our clients, both parties can come to the conclusion that, “we believe that it’s worth up to $800 to implement this new functionality.” With that, we’re able take that dollar amount and figure out how many hours to box ourselves within.
The underlying question to our client with each change/feature request is, “How valuable is this to your business at this point in time?” Whereas, with a typical approach to time estimates, a client comes to you with a list of changes/features and you provide them with time estimates. “We estimate that it’ll take 6 hours at $200/hour for feature X and we’d do it like this…” The client will have to evaluate your estimate and figure out if it’s worth $1200 and make a decision. They can respond with, “no, that’s too expensive, can we do it for less?” The following steps would entail your team trying to find ways to reduce your estimate.
While these two paths might seem very similar, it’s been my experience that the standard approach to estimating takes more time for negotiating the terms of the agreement.
However, with timeboxing, you are asking your client to provide you with an initial budget. This will completely change how you respond to the feature request. When you have a timebox, from the moment that you begin to evaluate the request, your brain will add the necessary constraints to keep things within scope.
Through this process, we’ve revamped our estimating process so that as we’re building our iteration costs for clients. For each deliverable, we break down a series of objectives/tasks and apply timeboxes to each of those while knowing what the budget is for the deliverable as a whole. Usually, the deliverable is directly related to the request that came from our client with a budget. The process is completely transparent and our team is responsible for working within those constraints.
..and as we’ve learned from Ruby on Rails, constraints can be extremely beneficial.
While I don’t have all the answers yet, my goal is to share some of my experiences and lessons on the topic. I’d love to hear about how you’re adopting timeboxing in your project planning and estimating process.
Anyhow, just some thoughts that I wanted to share. More to come…
Read Related Articles
Hello, HeyBrainstormr.com
If you follow me on twitter, you might have heard that we launched a little project that we’ve been cooking up at Planet Argon. (news post)
HeyBrainstormr is a lightweight web application that we created so that we could start a brainstorm on a specific topic and solicit ideas from each other. That’s all it does. Nothing more. Nothing less.
We know that having an open brainstorming session requires there to be zero criticism and opted to keep the process anonymous so that even the quiet people could share their ideas. :-)
We’ll be posting more details about it on our blog in the near future, but wanted to invite all of my readers to give it a whirl.
I have a few topics that I started (and tweeted about). Feel free to share your ideas on them. :-)
- I need some music suggestions. Help?
- I have writers block. Help me come up with some blog topic ideas?
- what can i do right now?
We hope that you find it as fun as we have.
What can we do right now?
Last month I picked up a new kindle from Amazon and have been reading a handful of books. One book that I’ve been really impressed with is Chad Fowler’s new book, The Passionate Programmer.
I plan to post some more thoughts in upcoming articles, but wanted to share this gem.
“If you treat your projects like a race, you’ll get to the end a lot faster than if you treat them like a prison cell. Create movement. Be the one who pushes. Don’t get comfortable. Always be the one to ask, “But what can we do right now?”” - Chad Fowler, The Passionate Programmer
Sometimes we feel stuck, but that doesn’t stop us from stepping to the side and assessing the situation. There is always something useful that we could be doing right now.
Building a prototype? Bring some rope.
While scanning through Allison’s copy of Designing for the Digital Age: How to Create Human-Centered Products and Services
The problem with software prototypes
It seems to be widely understood that industrial design and mechanical engineering prototypes—from paperclips and tape to polished appearance models—are disposable learning tools. Prototyping is clearly distinct from manufacturing, so it would be ludicrous to think that even a late-stage prototype could be reused as part of the final product. In software, however, the tools used for anything other than paper prototyping are generally the same tools used for “manufacturing” (i.e., writing production code). For this reason, many stakeholders can’t see why a detailed prototype that appears functional is still many months away from completion.
It immediately reminded me of a few posts that I had written about three years ago on the topic of developing prototypes and NOT keeping them.
The author continues with…
It’s important to educate stakeholders that prototype code is kind of like the illusion of automatic doors on Star Trek—it looks like it’s working, but it’s really a guy standing behind the wall pulling a rope.
I completely agree that education is the most important aspect to managing client expectations. With regard to the amount of work that you put into a prototype, we need to be careful on how much time and energy is put into them. If we can get away with a guy (or some quick Javascript hacks) to demonstrate possible functionality, make sure we aren’t using much more than rope. Rope is cheap. Prototypes should be too.
Related Posts
Lessons through failure. Episode 1
I fucked up this last week.
On Monday, our primary contact for a large client sent over some last minute requirements and deadlines that were needed by end-of-day Wednesday. I didn’t have a lot of time to collect requirements and execute it without having to rearrange my priorities. But, I accepted the challenge.
The big change involved was that we were going to be supplied with a ton of data to be imported in to the database and approximately 20% of the data provided was new records, while the rest were duplicates. However, the other 80% wasn’t to be discarded as there were a few attributes that needed to be updated from the data file (which was supplied from the client’s parent company). In my haste to get the task done on time (didn’t get proper export file to be imported in our system until Wednesday morning)... I ended up running a few tests locally and pushed it out to production.
I managed to get the import file to run in production before leaving on Wednesday afternoon. The following morning, I came into the office to find out that my import process didn’t match up records properly and resulted in nearly all of the 80% side of that to be duplicated in the system. This resulted in lost productivity for our client, their vendors, and our team over a 12 hour period as people were confused about why reports were running weird, online transactions didn’t account for the duplicated, etc.
It took me most of Thursday and Friday to clean up the data that got skewed due to that oversight. Hi ho.
So, the take away from this? Sure, I could have blamed it on a lack of sufficient time to properly test things, but that’s bullshit. I should have had at least one other developer from our team review the problem and evaluate my proposed solution prior to me attempting to push into production.
Luckily, the client was happy that we were able to finish the last minute tasks, despite the unexpected headaches that cropped up.
If anything, I was just disappointed in myself, but Alex reminded me how important it was to fail early, fail often. It didn’t kill me (or anybody else for that matter), cost us the project, nor was it irreparable.
In the real world, deadlines and requirements change on a moments notice and it’s experiences like this that will make ourselves more confident that we can quickly respond to and execute.
What was your latest failure?
