Email Overload? Reclaim Your Inbox, Don’t Banish It

I recently read two articles while riding the bus[1]. The first one was in Forbes Magazine. Thierry Breton, the CEO of Atos Global, has decreed that since he “believes that only 20 out of every 200 emails received by his staff every day turn out to be important,” within eighteen months the use of email will be eradicated company wide, replacing it with social media, phone calls and in person meetings.

Contrast this with the second article I read, Don’t blame the information for your bad habits, an interview with Clay Johnson by Mac Slocum in the O’Reilly Radar. Clay states that “[w]e don’t need to manage the information. We need to manage the consumption of it.” According to his new book The Information Diet, just as a binge eater cannot blame the food he eats a person suffering from the poorly-named “Information Overload” cannot blame the information.

To some extent I agree with both of these men. Excessive information (including email) is a danger to productivity. It diverts attention, derails trains of thought and increases stress. However, considering Mr. Breton’s concern over the reported high level of distraction caused by reading unnecessary email messages, I’m rather surprised at the alternatives being proposed. While unnecessary emails are distracting, I find it difficult to believe they are more so than social networking, phone calls or meetings (which we all know I believe can be improved). These routes of communication all tend to be highly impromptu and interuptive. Rather than improve the signal to noise ratio of the emails sent within Atos Global (or the email handling of the employees), he instead blames the email itself and chooses to cut off the service. I dunno… I just feel this may be one of those “Farewell bathwater! Baby? What baby?” sort of situations.

I agree with Clay Johnson: email is not to blame here. Rather than taking the somewhat drastic move of banning email, perhaps Atos Global would first consider applying these suggestions:

  1. Eliminate or filter most automated messages. We all get them. Output reports from cron, record update notifications from the CRM software, escalation warnings for issues on projects we haven’t worked on for months. These emails either need to stop or should be filtered out of inboxes.
  2. Refactor internal aliases and/or mailing lists. I mean refactor in its most technical sense here. Like code, so often the contents of these things evolve over the years. Cruft accumulates and is never cleaned up, leading to a lot of unnecessary emails. Each internal alias and mailing list membership should be examined. What is the purpose of the list? Remove any recipient who does not contribute to that purpose. Don’t forget to run some tests to be sure you haven’t broken anything (removed someone you shouldn’t have, for example).
  3. Suggest new internal email handling policies. Request that each staff member change his or her email client settings, downloading email only twice a day and disabling any desktop/taskbar/etc. notifications. This is a tough one as people get very attached to their personal workflows, but these relatively small changes can lead to a lot more undisturbed contiguous moments in everyone’s day. You can always find some technology which enforces it but, really, that’s a bit too Big Brother-y for my tastes. My preference would be some form of firm but gentle social engineering, starting with telling everyone precisely why they are being asked to make the changes requested. The people with whom you work are incredibly intelligent and they’re adults. Treat them that way and most of them will see the good sense in the suggested changes.
  4. Selectively change communication media. Thierry Breton is correct: email is not always the right tool for the job. What sort of information is being exchanged via email at your organization? Do an email survey and try to categorize the communication that’s happening. Would any categories be better suited to a different medium? Could those long emails explaining the database architecture perhaps be written into the wiki instead? That “anyone for lunch?” message to the team would undoubtedly be better on the IRC channel, wouldn’t it? Perhaps the company could roll out Google Docs rather than emailing around a Word file for document collaboration.

You’d be surprised just how far you can get with these changes. I keep my own inbox at or hovering just above zero thanks to some of these suggestions. I got 99 problems but an inbox ain’t one.

If anyone has tried any of them at their company or on their project I’d love to hear about it in the comments. I’d be particularly interested if you have any metrics you could share.

[1] Using Spool, a new online app which is changing my online reading habits for the better. Think Instapaper but better (for instance: offline viewing of videos). No, they didn’t ask me to say this. I honestly do love and use the service. 🙂 [Back to Reading!]

Take The Red Pill: 8 non-programming books you should probably read

As techies we tend to suffer from a fair bit of professional tunnel vision. Like Neo, often all we see is the code. However there’s an entire world on the other side of the digital rain. A world of managers and users and TPS reports.

In order to do our jobs better we need to take the time to understand some of the other human and business elements with which we must interact. There are many ways to do this but one of the easiest and most efficient is diving into a few choice books.

There are, quite literally [pun intended], countless books which you could pick up to further this education and many of them are very good…if you’re already a business and management wonk. If you’re a hardworking geek who’s just looking to get informed, get a different perspective and use it to do better work then you don’t have time to waste with buzzwords and business jargon.

Lucky for you I’m here with the red pill.

The books below have all proved invaluable to me in my years in software engineering. Most of them are not only easy to read they’re also enjoyable as well, providing an astounding amount of information in a way which isn’t going to send you screaming back to the Matrix.

Management

There is undoubtedly some form of management in place on your project|team|life. You can’t (and probably shouldn’t) avoid it, so you’d best learn to understand it better. It’s not a matter of “know your enemy” since, believe it or not, management is on your side. It’s more a matter of knowing how to understand a different dialect and point of view.

  • The Practice of Management by Peter Drucker
    This is where it all started. Peter Drucker is the Father of Modern Management and this is the book which earned him that title. Since it was originally published in 1954 you’ll find that many of its stories are dated and border on quaint. That said, it’s still stunningly applicable to modern businesses and organizations. I recommend you read the entire thing, but if you just want to sample the contents then have a look at the outline I created when I first read it. (No, I don’t usually do that for books; that’s how special this one is.)
  • Land the Tech Job You Love by Andy Lester
    I know what you’re thinking: “VM, have you thrown a rod? Why is this in the Management section?” Well, lemme tell ya: I’ve yet to find many books which do as good of a job of presenting what’s going through the mind of a hiring tech manager as this one. Andy doesn’t just tell you what to do to land a good tech job. He also tells you why you should do those things. As a tech manager myself I absolutely love the approach which Andy has taken here and wish more applicants had read this book and had the perspective which it provides. I feel so strongly about this that I’ve given away four copies of this book over the past few years and fully intend to give away more. (Full disclosure: Andy is a friend of mine but I had read/loved his book before the friendship.)

Business and Process

Even if you’re working on an open source project there’s still a lot of process and business logic which needs to come into play. Sometimes you can survive without knowing these details. Sometimes you can use a framework without reading the documentation, but you’re setting yourself up for a world of hurt if you do. The same stands for process and business logic. You at least have to skim the documentation to understand the framework within which you’re operating.

  • Rework by Jason Fried and David Heinemeier Hansson
    I don’t care who you are. I don’t care what company or organization you work for. Read This Book. It’s probably the quickest read in this list but it’s also one of the most thought provoking. Rework is a collection of essays based upon posts on Signal vs. Noise, the 37signals blog. Each essay states the 37signals answer to a particular question or need. Since these answers are coming from a 37signals perspective it’s possible (likely) that they won’t apply to your company|organization|project. That’s fine. It’s not important that their answers work for you. What’s important is that you think about the problems they faced and come up with your own answers.
  • Process Improvement Essentials by James R. Persse, PhD
    I’m only halfway through this book and I’m already finding it to be incredibly useful. While I currently have no intentions of implementing CMMI, Six Sigma or any other formal process it’s very thought provoking to read about the problems which these methodologies were created to solve and consider the different ways they could be approached in a software development team. This is another one of those books which is really good for getting the wheels turning, even if you don’t end up rolling down the same path as it takes.
  • Getting Things Done: The Art of Stress-Free Productivity by David Allen
    “GTD? Really? Way to be original.” Yeah, OK, so maybe this one is becoming cliché at this point. I mean, everyone in tech knows about GTD by this point, right? Sure, maybe they do. Still, I’ve read this book three times and get something new out of it each time and not just for my own personal productivity processes. Reading GTD presents me with yet another opportunity to look at the big picture for everything in my life and that includes how my company, team and projects are functioning. While I don’t subscribe to or apply the entire GTD method I still highly value how it helps me step back and think about why I and my team are doing what we are.

Users

User-centric software development is a big thing for me. I mean, if what you’re working on doesn’t have users then…uh…why the hell are you doing it? Software without users is just a technical étude. If you’re not listening to your users then, I’m sorry, but your project will fail. Maybe not today and maybe not dramatically but it will fail nevertheless.

John McCarthy once said:

Program designers have a tendency to think of the users as idiots who need to be controlled. They should rather think of their program as a servant, whose master, the user, should be able to control it.

The books below help to shift away from this controlling mindset into a more productive one of cooperation and assistance.

  • Delivering Happiness by Tony Hsieh
    Tony Hsieh is not a writer, he’s an entrepreneur. This book reads like it was written by one of your coworkers while you two were sitting at the pub. It’s conversational, anecdotal and entirely infectious in its enthusiasm for building one of the most successful and user-centric companies on the internet, Zappos. Tony takes you through the entire roller coaster ride which was the evolution of Zappos, including the decision to focus entirely upon customer satisfaction. It’s incredibly interesting reading out the philosophical and business reasons for making this move. It’s also very inspiring to see the open and honest manner with which Tony handles the discussion.
  • Design of Everyday Things by Donald Norman
    While Design of Everyday Things has nothing whatsoever to do with software design, after reading it you’ll find that it has absolutely everything to do with software design. You will never look at a set of instructions, a UI widget, an API the same way again. You will also never again feel like a moron for pulling instead of pushing when trying to walk through a door (&!%#@* inaccurate affordances).

Communication

Be it API documentation, a commit log message or a lengthy soapbox session on the listserv, communication is a critical skill for techies. And one which is lamentably neglected. For this section I have but one suggestion…

  • The Elements of Style by William Strunk, Jr. and E. B. White
    I don’t care whether you’re a grammar snob or not (I am), you need to know what’s contained in this book. Feel free to break the rules if you need or want but please do us all the favor of knowing that there are rules before you do so. Seriously. I mean, there’s a reason why this book has been in continuous publication since 1918: it’s English as she is spoke. Knowledge of what’s contained between its covers ensures you’ll be better equipped to communicate with everyone with whom you interact, from CEO to six year-old nephew. Improved communication skills will get you as far in this world as being able to make Ruby on Rails sit up and beg. The combination of the two? You’d be a force with which to be reckoned.

There certainly are other books which I could add to this list, but these are the eight which are currently at the top of my list. Have any you think should be here? Put ’em in the comments!

It’s About Needs.

Cards I’ve been doing various bits of writing lately, both for my blogs and for other purposes. This morning I was sitting at a cafe, scrawling ideas in my notebook, and decided I needed to take a step back and follow the oft-mentioned advice of “one card, one idea, arrange, write.”

“I need some index cards!” declared my Front Brain.

“No, you don’t need index cards,” interrupted my Back Brain, “you need small bits of paper large enough for capturing ideas and easy to arrange. There is more than one way to do it.

“Oh…yeah, I guess you’re right,” Front Brain conceded.

This internal dialog—aided by knowledge gained by working in a printshop for five years during college—led me to the independent printer down the street. $2.00 later and I have a stack of around eight hundred small bits of paper, perfect for my purposes and cheaper than index cards. As an extra bonus the printer made two bucks on something which he otherwise would have chucked into recycling. I’m happy, the printer is happy and nary an index card is in sight.

“If I had asked people what they wanted, they would have said faster horses.”
― Henry Ford

We in the tech industry are in the business of fulfilling needs. Accounting needs to process expense reports more quickly. IT needs log monitoring and notifications for potential issues. Your grandparents need to see pictures of their new great grandchild. I need to buy a four pound bag of cat food every month.

Please note: These needs are not “Logon to internal financial system integrated with payroll processor,” or “Implement Nagios or Splunk” or “Teach grandparents to use email so they can view Flickr links” or “Order cat food through Amazon Subscriptions.” These are all very valid implementation options but they’re not needs.

It’s so easy to get caught up in expectations and experiences, jumping straight to a possible implementation rather than slowing down and taking a moment to look at the bigger picture. Let’s take my index card problem as an example. What I initially said to myself:

Darn, but there has to be an easier way to organize these thoughts.

Conventional wisdom (and an army of high school English Comp teachers) says that the response to the problem of thought organization is “index cards.” However that answer doesn’t take into consideration my personal constraints:

  1. Minimal expense
  2. Minimal material waste
  3. Minimal space usage

Would index cards have met these needs? Yes, they would have. That said, my local-printer-supplied option meets those needs even better. These cards are cheaper, would otherwise have been scrapped, and are smaller than commercial index cards. As a user, I am much more “delighted” (an adjective which I deplore but which I must admit applies here). I am now much more likely to use these cards because I am happier with the end product.

The key to generating this “delight” (I still hate that word) was not my prior knowledge of printshop operations though that was, admittedly, helpful for the final product. No, the key was knowing to ask myself, “Yes, but what are you really trying to accomplish?” and then surveying the potential options.

For the record: getting to the root of user needs is not usually as simple as having them answer a single question. There are very good reasons why there are people who do nothing but determine user needs. That said, the question is important enough for everyone on a team to keep it in mind throughout the design and development process. If at any point you cannot answer the questions “What?” and “Why?” then you should circle the wagons and start the process of getting these matters clarified. You’ll be doing the team a favor. Nothing is as effective as a team that understands not only what they’re trying to produce but, most importantly, why they are trying to do it.

Unsuck Your Meeting

Yeah, that’s right: your meetings suck. Don’t deny it. No, don’t you dare even try to deny it. Can you seriously look me in the eye and tell me that you enjoy going to meetings? That you aren’t sitting there with a glazed look in your eyes as you mull your lunch options or that optimization that was interrupted for this Momentous Event or whether you remembered to set a new season pass on your TiVo or, really, anything aside from the purported meeting topic? Can you? No, I didn’t think so.

In truth I don’t buy into the whole meetings are toxic thing. That’s rather a generalization, wouldn’t you say? Meetings in general aren’t toxic. SHIT[1] meetings are.

  • Selfish.
    “Well, I’ve kinda been sitting on this project and I’m not ready to move forward on it but people are starting to talk so if I bring everyone together for a meeting then it’ll look like I’m making progress. Brilliant!” The best part is that a selfish CYA meeting begets yet more selfish CYA meetings as everyone’s schedule is pushed back in order to attend them. Genius!
  • Haphazard.
    Everyone knows that a free range meeting is the most responsible choice, right? A meeting that’s allowed to live out its natural life scratching at and chasing after random topics rather than being cooped up in a specific agenda is the best sort of meeting, isn’t it?
  • Informational.
    Ooh, here’s an idea! Let’s get everyone into a room for sixty or even ninety minutes every week just so they can feel uncomfortable trying to verbalize nebulous but considerable progress in front of their peers for two minutes and then zone out for the remainder of the time! Or, even better, collect the team so you can give a dramatic reading of the text you really should have posted to the wiki! Man, everyone’s gonna love that. And what a great use of time!
  • Tardy.
    My personal favorite use of company time: calling a meeting for, say, 10am then not starting it until 10:15. Similarly: calling a meeting for 10am and then not notifying the attendees until 10:15 that the meeting needs to be rescheduled.

It’s easy to see why your meetings suck when so many of them share these characteristics. It boggles the mind why businesses allow this sort of shoddy practice to continue, especially considering the expense that these meetings reflect both in lost productivity and in basic employee compensation simply for the time to attend them.

The sad fact is that it is so very easy to avoid SHIT meetings yet disturbingly few people make an effort to do so. Here are some of the criteria I use to make sure my meetings don’t go to SHIT:

  1. Don’t have a meeting at all.
    Do I need to communicate some information? Rather than interrupting everyone’s workflow by collecting them into a room I’d prefer to send the information via email. Or, better yet, write up the information in the $project_tracker since five’ll get you ten it belongs there anyway. May as well get it into the tracker immediately so there are no excuses later when the information goes AWOL. You can then easily email a link to the information in order to call attention to it to the team.

    For this approach to work you need to foster a culture which does not abuse email[2]. Once you’ve reduced the inbox noise and drek everyone needs to understand that (s)he is responsible for the information sent via that channel.

  2. Have an agenda and stick to it, dammit.
    Each meeting ought to have a purpose, a goal, a question which needs answering. If you’re thinking of scheduling a meeting and you can’t express the goal of the meeting in fifty words or less then perhaps you’re not really ready to have a meeting yet.

    An unfocused meeting is an inefficient meeting. Ideally you would send a brief agenda along with the meeting invitation so everyone knows what they’re getting into. This allows people to prepare (if necessary) so the question can be answered and the meeting completed as quickly as possible. Which leads me to the next point…

  3. Start on time, end early.
    If you’re running the meeting, get there early to be sure everything is set up. If you’re attending it, arrive on time. Regardless, everyone is expected to come prepared and the meeting always starts exactly on time. Failure to do so is disrespecting the valuable time of every person in the room[3].

    Because you have an agenda you know exactly what the meeting is meant to accomplish. If that goal is met then do not sit around simply because you have the room booked for an entire hour. Recap the meeting so everyone understands what was decided and then let ’em get the heck out of there. Everyone will be happy: the attendees will think you’re super swell for ending the meeting early and you’ll have what you need.

  4. Recap Recap Recap.
    This was briefly mentioned in the prior point but is important enough to call out on its own. At the end of the meeting it is paramount that someone (ideally the person who called the meeting) recap the decisions and action items which were generated. You’d be surprised how often you do this and have someone in the room be startled out of their daydream to say, “Wait…what? That’s not what we decided…” Everyone must end the meeting on the same page. They don’t need to agree with what’s written on that page, they just need to be on it and know that they’re on it. In addition, anyone in the room who has action items as a result of the meeting needs to confirm that they’re aware of this fact and are ready, willing and able to undertake the assigned tasks.

While there are many other methods and details which could be applied for unsucking your meeting these are the ones which will get you the most bang for your buck and which apply to most every meeting. Applying them to your team’s meetings will improve productivity and, most importantly, make you all much happier people.

[1] Contrived and excessively vulgar acronym? Guilty as charged. Still, a spade is a spade and meetings like this truly are shit. [back to reading!]
[2] Proper care and feeding of a healthy email inbox is an entire post in itself, but suffice it to say that the signal to noise ratio in the average email inbox could bear more than a little improvement. [back to reading!]
[3] Unsatisfactory excuses for arriving to a meeting late: another meeting ran late (stand up, politely excuse yourself and leave), on the phone (send to VM or set call duration expectations at the start), just slipped your mind (really? your time management skills and tools are that bad?). OK excuses: system/service crisis (all hands on deck; screw meetings), family emergency (always more important), zombie attack (Re: Your Brains). Regardless of the reason, you must find a way to notify at least one other attendee that you are going to be late. Email, IM, IRC, SMS, phone call, send a message via the office dog. It doesn’t matter how you do it just do it. Don’t be so arrogant as to expect everyone to seek you out retrieve you for the meeting. From housekeeper on up to CEO, the time of the other meeting attendees is as important as yours else the company wouldn’t be paying them to be there in the first place. Do not disrespect them by thinking otherwise. [back to reading!]

Watch this space

Sixteen months ago I made the choice to stop posting to this blog as a way to reduce obligations on my time and free up some mental space for other personal projects.

Since that point I’ve left one job, started another and then been laid off so all and all it’s been interesting times (in a Confucian sort of way).

Finding myself with a sudden surfeit of time I intend to get back to posting to {anonymous => ‘hash’}. I’ve been accumulating a goodly list of topics, mostly drawn from various experiences in the past sixteen months. These topics range all over the board: tech management, open [source|data|access], hiring, software development, user experience… Pretty much anything which happens to tickle my professional fancy. So watch this space for looooong-overdue new content!