Email Quotas Aren't Stupid
I recently heard a project manager lamenting their "limited" email. How big is our limit? Well, I assume that for the normal peons in my company it’s about a Compact Disc's worth: 600MB. That’s almost as much as Gmail’s (current) 65GB allotment for their free account, right?!? It’s only 2 orders of magnitude difference, no big deal.
Clearly, storage isn’t THAT expensive, and it wouldn’t take much effort to make everyone's email have more room to breathe. Considering the cost for storage vs the cost of time and mental capacity for your workforce, it would seem like giving larger email quotas would be a no-brainer.
While this line of reasoning could be fleshed out on its own, I’m not going down that road. Too easy. I’ll go ahead and make the argument AGAINST larger quotas.
Software professionals love to joke that 640K should be enough for everybody, even if the whole thing is apocryphal. Working with systems having finite resources is part of the work that we do. That said, I cannot quite figure out why one’s work email would need to be so large. Could you imagine what the physical equivalent would look like? How many folders and stacks of paper would be needed to keep track of that much data IN EMAIL FORM? I think the larger problem is that you’re using email wrong.
It’s fair to say that we all have emails from long ago that we keep around too long. Sure, you’ll never need your 1040EZ from the summer after high school graduation. How much space does it take up? Well, as a proportion of the size of your home filing system? Probably a fraction of a percent. Still, when you come across it while looking for your birth certificate for the 17th time, you need to throw that thing out. It’s just clutter.
Why do we keep old, even ancient emails?
You remember that email Bob sent in October of 2011 about the TPS reports needing a cover sheet? Guess who forgot their cover letter this week?!? Boo-Yaa!
This is an overly petty example, but something which I hear fairly often.
Archived emails are a sea of broken promises, failed commitments, squashed aspirations, and bureaucratic creep.
None of this is particularly useful due to its negative nature.
Yes, Julius said we were going to do quarterly team-building activities in the summer of '09 and it never materialized.
If you care to hang it over his head, even if he denies it, the email isn’t going to help.
You know he botched that one, there’s no point bringing it up unless you want to make a change anyway.
Take a line from Elsa:
Let It Go
Every quarter we have to do X, Y, and Z before running the TPS reports, aggregating the results to the KPI roster, and updating the “SnowFrost” system with "Plinkr" data…
Tribal knowledge needs to live somewhere else. When you get hit by the proverbial bus, having this stored in your archive makes it useless to your (former) team. You should have a team site, and individual project sites with documentation you and your colleagues need. This includes handy SQLs, references to commonly-used libraries, "How To"s, project setup instructions, build procedures, etc.
Tori decided that the ICP process is dumb and unnecessary, so we’re not doing it anymore. Now 6 months later Tori wants to know why we haven’t been following the ICP process!
In a dynamic business where things are often in flux, it’s easy to lose track of new procedures or forget that changes were consciously made. More important than having a collection of these changes, having the reasons behind these changes allows you to not only keep the history, but understand the context in which decisions are made. Who was involved in making the decision, when, why, and how it was communicated is best stored somewhere else. It shouldn’t clog up your email to keep track of information which other members of the team will need to review or re-evaluate those decisions.
I have to keep all my emails because I work in so-and-so department
If the business actually requires that you keep emails for traceability or compliance, that is THEIR responsibility, not yours. When the proverbial dookie hits the fan, yes, you may get fired, but that’s because the company will be far more responsible for the damage than you are personally. You end up with this demand to both keep everything and deal with a limited email size. The next step after you fill your quota is to archive, and this is typically to your local PC. That means if ANYTHING happens to your box that data is toast. If you’re lucky, your employer MIGHT backup your work laptop, but in the end THEY STILL HAVE YOUR DATA STORED ON SOME SERVERS. What’s the difference if you have it as email storage vs. backup storage? I would think that if they truly require all emails to be kept that THEY would manage this. If they really need an email that you wrote 3 years ago, the proper place to look is in the corporate email archive, with the processes in place to prevent inappropriate accesses.
Not just old emails
If we eliminate the truly out-of-date and inane, and we’re still looking at our email as fairly full, you probably have used email wrong. That is to say, email was the closest tool at hand, but isn’t the “right” tool.
Are you using email to share spreadsheets among team members or across teams? You’re using the wrong tool. The silly part is that you probably KNOW this, but continue to do this because it is easy. Is a tool like SharePoint completely straightforward? Not exactly, but that’s no excuse. Figure out where the friction is (typically permissions) and eliminate it. Setup a Wiki / HipChat / Slack. Excel has advanced far enough that simultaneous editing is now possible, so do that instead. Figure out how your organization deals with living documents, because as much as you may think otherwise, ALL documents should be living (Corollary: dead documents get deleted)
Are you sending code snippets or in-progress code changes for review or further edits? Maybe you’re transitioning to a new team and have half-baked code that needs to be handed off. Sure, you could zip up the entire codebase and email it. Perhaps if you’re a bit more clever you might make a patch/diff and just send the changes. The right™ thing to do would be to USE YOUR VCS to deal with the code. If your changes are small, just describe the changes to your colleague and move on. If they’re large, make a branch and let your colleague merge things back in appropriately. You don’t lose history, changes make sense, and all will be right with the world. Any VCS processes which get in the way of this are an anti-pattern.
Dailies / Periodicals
Creating or receiving daily reports via email instead of a dashboard? You’re using the wrong tool. Managers and executives should be able to SHOP for information that they need to make decisions, especially on a daily basis. How many reports get created which are NEVER read. How would you know? Can you reliably gather usage metrics on emailed spreadsheets? Can users analyze the data easily to gain insights? Visualizations? Please, stop emailing these things.
We all love cute pictures of small creatures doing adorable things. Business email is not the place for that. Yes, even the one with the cat in a hoodie with the witty Kanye West quote. Stop it!