Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

Email. Twice daily. No more, no less.

Posted by Thu, 11 Jun 2009 01:24:00 GMT

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.

planet argon - Calendar

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?

1 How to Check E-mail Twice a Day… or Once Every 10 Days

Berkun introduces ADD

Posted by Tue, 19 Jun 2007 22:22:00 GMT

Author of The Art of Project Management, Scott Berkun, introduces Asshole Driven development.

“Asshole Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.”

Read the rest…

Please Make Fun of the Boss

Posted by Fri, 02 Mar 2007 06:26:00 GMT

While reviewing some articles related to small business management, I came across the following post… titled, Note From Boss to Employees, by Michael Wade. As a young business owner, who only 16 months ago was working in his attic… to now trying to figure out how to run a company with over ten employees (and growing), posts like this remind me that we all have so much to learn. :-)

Here are a few that I appreciated…

“I may not have been given a huge amount of training before being named to a supervisory position. As a result, I’ve had to learn through trial and error. That’s not always bad. Many of my responsibilities can only be learned through practice.”

Yep… that’s me! The only difference is that I promoted myself instead of being promoted by someone else. I’m still not sure what I got myself into sometimes. ;-)

“I will make mistakes. Please give me the same understanding that you’d like me to give you when you blunder.”

This reminded me of a blog post from last year, titled, Avoiding the most common software development goofs, which points out that things like ignorance and stress are often to blame for mistakes in development. I feel like these are reasons for goofs in just about any environment, especially business. Let’s face it. We’re not perfect and we’re going to make a lot of mistakes. Once we’ve agreed on this, let’s take the next step and see what happens.

“If I do something dumb or am on the verge of doing so, please tell me. Don’t hint. Tell me.”

Perhaps this is a common problem for most small business owners. Are employees afraid to tell me that I’m doing something dumb?

“If either of us has a problem with the other’s performance, let’s talk about it.”

As they say, real friends will be honest with you about your faults. Not because they want to make you look bad, but because they care.

Each of the points that I have listed here are pointing to is… healthier Dialogue, which is always a challenge to accomplish… in any relationship… whether with clients, coworkers, bosses, or employees.

I’d like to add a few to this list.

  • It’s easier to ask for forgiveness, than to ask for permission.
  • I’m still trying to get the hang of this GTD stuff, so.. you might remind me if I forgot something.
  • Ask yourself on a regular basis, “Am I having fun?” If not, make time for some.
  • Please make fun of the boss! :-)

DDD (d3) is the new conversational software development

Posted by Fri, 04 Aug 2006 03:28:00 GMT

I’m not sure how I missed this recent post on Martin Fowler’s bliki last week on Customer Affinity. In this post he references when the term “agile” first came about and mentioned that, “one of Kent’s suggested names for ‘Agile’ was conversational software development – the point being that it’s a two way communication. “

Conversational Software Development.

This doesn’t sound so different than what Brian Ford and I are calling, Dialogue-Driven Development. ;-)

Fowler goes on to say, “This isn’t something like a telecoms protocol that you can define, but the back and forth discussions about how software can enhance the business are where the real value lives. Much of this conversation is of half-baked ideas, some of which grow into valuable features – often ones that aren’t things that the customer originally thought of.”

If you didn’t follow the thread of comments on my recent post on Dialogue-Driven Development, you might not know that this name came up during Martin Fowler’s keynote at RailsConf when Brian and I were sitting next to each other and Martin kept reusing the word “dialogue.” Brian and I can’t seem to agree if I said, “Dialogue-Driven Development” out loud or if he wrote it down on a piece of paper first… so we’re going to have to share the credit. What made this so fascinating at the time was that for the entire trip from Portland to Chicago on the Argon Express, Brian and I had been discussing a lot of what we’re planning to change and define with our approach to Client/Project/Development Collaboration & Management… and in the end… we left Chicago with DDD d3.

Thank you, Martin for being part of this process.

Like all things, this approach is open to discussion dialogue.

UPDATE

Brian has written an article called, It’s all about the dialogue. (digg.it)

Dialogue-Driven Development

Posted by Thu, 03 Aug 2006 02:55:00 GMT

13 comments Latest by Pat Wed, 09 Aug 2006 03:24:52 GMT

Just a few months ago, I wrote a short article called, The Art of Delivery, which outlined how we at PLANET ARGON approach iterative development and how it relates to quicker release cycles. I wanted to follow up with this and add some more thoughts to that and what we’ve been trying and learning since that point in time.

With iterative development cycles, we’re able to focus our attention on very specific and well-defined goals while we work with the client to organize the other goals that they’d like us to help develop solutions for.

An End to the Product Backlog

While everyone at PLANET ARGON has been doing some research on modern Agile-related methodologies, we’ve been throwing a lot of ideas back and forth… and often times we end up cherry-picking individual practices and throwing it into our evolving processes.

The problem that we’ve seen with most examples of using a standard Scrum Product Backlog is that it focuses too much on tasks rather than providing solutions for goals that are central to the success of the project. It also requires that someone maintain, on a regular basis, a well-defined list of tasks, which often times the client (Product Owner) dictates. We’ve seen many situations where a client has more feature requests than is necessary in order to attain the goal that was originally set. If we had a nickel for every time we heard someone say, “wouldn’t it be cool if it did this?”

I’ve personally worked on many projects that fell into this routine too early in the development cycle. Most clients that we work with are trying to provide a solution for their users and aren’t always the best Domain Expert. Taking the whole less is more approach, it’s vital that the earlier you can get your users in front of your application, the sooner you can get them to generate feedback, which aids in you making educated decisions about what to add to the project later on.

Features are Expensive

Aside from the monetary costs of adding new features and functionality, it is important to remember that as you add new code to an application you increase the maintainability and overall scope of the project. With each new feature, the requirements change, complexity increases, and as far as your users are concerned, they are now being exposed to something new, which may or may not be what they want or need. For example, I was in a sales meeting yesterday and our potential client mentioned that at a former job during the dot-com era, their web team added e-Cards to their web site and it had nothing to do with their business model. The users did however use this new feature but they later went out of business. Perhaps they should have been an e-Card business instead. Imagine if BaseCamp added a local weather feature… I might use it… but it doesn’t help me manage our projects any better.

When clients approach us with a new feature that wasn’t previously discussed, we have to ask them they Why, What, and How? What goal is this feature providing a solution for? Do we already have a solution implemented that solves this problem? Is this a new goal and how (and why) did this goal come about? What are the costs of implementing such a feature and how will it affect the current stability of the user base and application? If we put it off 3 months, would it cause the project to come to a grinding halt? What about 6 months?

It’s important to always remember that one of the biggest problems in software development is feature creep. Many projects fail due to this and as a project manager, developer, or client… please consider the consequences and benefits of each new feature. Focus on the goals and connect the dots from there.

Get the goals clearly defined and provide clear and simple solutions for them.

Just Say NO to Bloat!

Start with a Mission Statement

One of the new things that we’ve begun doing with a few new clients is assigning them with an initial task of providing us with a Mission Statement. From the Mission Statement we can ask how each goal that the client and we outline relates to it. If one of the key goals of the Mission Statement is, “to provide gorillas with easy access to basketballs”... we will have to question any goals that imply that we might also need to provide access to soccer balls, car batteries, or scissors… or that when a gorilla is getting their basketball we might want to provide them access to stock reports. We’re not trying to solve all the gorilla’s problems and it would be naive for us to think that we know what they want before we’ve had a chance to really engage in that dialogue.

Users are the Domain Experts

Very rarely do we get a chance to interact with users before we’ve begun coding a project and getting an alpha release in front of a subset of users. Brian and I just got back from a few days in Washington DC, where we worked with a new client. They have an existing GUI application that began development in the mid-90s and we’re being contracted to help build a new solution to the problem that they began to solve ten years ago. The application has suffered from a lot of feature creep as many evolving products do. As they gave us a demonstration of their existing product, we saw first hand how it was even difficult for them to remember why Feature X was in the system. “Most customers don’t use that anyways.”

So, why is it there? Of course, nobody remembers why everything is there now. As developers come and go projects get managed by various people over the course of their life, many of different opinions and features get injected into the application. It’s a common problem and it takes a lot for a company to finally admit that it’s time to throw it out the door and start fresh.

The old rules don’t apply anymore. *

One of the first things that we did in our meetings was discuss what goals their product was aiming to provide solutions for. What do they believe that their users want and need? To get this answer, we scheduled a few conference calls with real users of their existing software! I cannot describe how helpful those interviews were and we saw a lot of consistency in their goals as users of such a system. It became apparent that they were the Domain Experts and as we move forward with the project we are going to have access to interact with those users.

Rethinking the Dialogue

When thinking about delivery, we must consider the major obstacles to overcome during the course of an iteration or release cycle. More important than having well-defined deliverables is having well-defined expectations. If you’re delivering a prototype, be clear about what a prototype is and what is it not. Schedule regular meetings with your client throughout the process. Keep the client updated as much as possible. Ask questions as soon as you can… and be sure to ask them the right questions.

There is an art to it and it’s important that you keep this process lightweight and agile like you do your development process. Perhaps we need to think of development and project management under a new heading… *Dialogue-Driven Development? DDD? ...just what we need… another acronym. ;-)

UPDATE

We’re not going to call it DDD… just d3.