Staff Quality Deserves the Same Care as Software Quality

The Wikipedia definition of Continuous Integration (aka CI):

Continuous Integration aims to improve the quality of software…by replacing the traditional practice of applying quality control after completing all development.

The CI gurus in the audience will hopefully forgive me for criminally over-simplifying, but the process basically boils down to:

  • Commit early, commit often.
  • Automate tests, build and deployment.
  • You break it? You fix it. RIGHT NOW.

The key motivator in CI is right there in the definition: quality. Rather than waiting for the end of the production cycle to do all of the testing you do it in smaller increments throughout the project. The sooner you locate and correct potential issues the higher the quality of the finished product. This approach is proven for developing software, so why aren’t we also doing it when developing staff?

A typical methodology for managing professional development for a technical staff member is much more old school waterfall in nature:

Yearly review and feedback
  set yearly goals
    procrastination until just before next yearly review
      race to complete goals
        verification of goals in yearly review
repeat

OK, perhaps that was a somewhat snarky summary but I think we all recognize it as Standard Operating Procedure. How, really, does this process help anyone? No, don’t answer that; I’ll answer it for you: IT DOESN’T. By the time you get to the annual review, any sort of feedback is so much water under the bridge and far from actionable. Yearly professional development goals are reduced to the effectiveness of an open book midterm: crammed in at the last moment and generating a good grade but with no lasting value, either for employee, team or company.

Instead we should be approaching staff development and management with an approach incorporating the ideas of accepted software development methods like Agile and Continuous Integration:

  • Agile Professional Development:
    • Employee review cycles should be short sprints of a matter of weeks rather than months.
    • Professional development goals should be attainable and meaningful, each subsequent goal building upon the ones which came before.
    • Meetings for checking progress and providing feedback should be frequent, brief and informal. They also should be open, honest and egalitarian (managers need feedback as much as anyone).
  • Continuous Staff Integration:
    • New knowledge and skills gained through professional development should be committed back to the trunk (the team) for integration.
    • Staff development should be automated through empowerment, support, policy and culture rather than dictated by managerial fiat.
    • Notification of potential issues should be immediate and methods of correction should ideally be evident and obvious.

There are, of course, some potential drawbacks in rolling out a staff development process of this sort. The current “waterfall” model has been the standard for a great many years and has become ingrained in the operating manuals for many companies, affecting the ways budgets are written, compensation packages are structured, Human Resources offices are run, etc. It’s difficult to overcome this sort of institutional momentum.

In addition, this process has the potential to impose a hefty burden on tech managerial staff. The impact of yearly reviews for each staff member can be severe enough on a manager’s time. Without proper planning an agile and continuously integrated professional development method could become a fulltime job in its own right.

These drawbacks are not inconsiderable but they’re also solvable and worth the time to do so. It will take a lot of planning to be sure this process is rolled out in a way which makes the most sense for your organization, but as with any worthwhile change (say, to using Agile and a rapid release cycle), if done mindfully the benefits reaped more than repay the effort.

Rant: I Am Not a Cat Herder

Cat Herding image CC-BY courtesy of carterse on Flickr; click to view originalIt’s a no-brainer. It’ll happen. If I were the betting kind I’d lay good money on it. Any time I’m mingling at some social event (cocktail party, BBQ, conference hallway track or pub outing, etc.) there will be at least one conversation which proceeds thusly:

Them: So, what do you do?
Me: Oh, I’m a software engineering manager.
Them: Ah! You herd cats! <insert self-satisfied chuckle at their oh-so-original witticism>

My typical response is to grit my teeth, smile wanly and change the subject. But ya know what? I don’t think I’m going to do that anymore. I’m rather fed up with the all-too-common misconception that managing software engineers is as chaotic and fruitless as wrangling a passel of felines. Seriously, if you’re a dev manager who describes his/her job as “Cat Herder” then just get the hell out of the business now. You don’t respect your staff and you’ve entirely missed the point of your job.

At no point in the management process should there be anything resembling “herding.” If your team requires herding then the problem is not the typically independent and outspoken nature of the software developers that comprise it. The problem is you. You don’t know how to be a manager. Communication, negotiation, mentoring, prioritization, leadership… These are the skills of a successful dev manager. Failure to learn, employ and constantly improve these skills leads to a team full of cats, loose cannons, powder kegs, prima donnas…choose your favorite negative descriptor.

It’s possible to learn these skills but only if you realize that it’s necessary. A good first step toward that is to stop implying your staff are unmanageable by calling them cats. Respect them as the intelligent people that they are, listen to what they have to say and clearly communicate the direction the company needs them to go and why. You’ll find that what you end up with looks a lot more like a functional and efficient team than cantankerous felines.

Book Review: “The Information Diet” by Clay Johnson from O’Reilly Media

Book cover for The Information Diet

“Much as a poor diet gives us a variety of diseases, poor information diets give us new forms of ignorance—ignorance that comes not from a lack of information, but from overconsumption of it, and sicknesses and delusions that don’t affect the underinformed but the hyperinformed and the well educated.”

This is the general thesis of The Information Diet, a new book by Clay A. Johnson, published by O’Reilly Media. In it Johnson explores the state of information production and consumption in our society, how he perceives it has changed (for the worse), the cultural, emotional and neurological reasons why this is the case, what may happen if the pattern continues unabated, and how we can work to reverse the trend.

The analogy of information as food is maintained throughout the work. I knew this going into it and anticipated the comparison would wear thin rather quickly. Aside from being personally bored by the first chapter—which summarizes the history of food industrialization and the obesity epidemic, subjects into which I’ve delved for years—the analogy works surprisingly well for the entirety of the book. Through this strong parallel to such a well-covered and -publicized public health issue Johnson is able to engage the attention and sympathies of the reader more or less immediately.

Unlike many of the more conventional “diet” books on the market, The Information Diet does not spend most of its pages on a detailed plan you could follow to reduce your intake of junk information. Johnson does, of course, give some tips on how to do this, but most of them are summed up in his Pollan-esque statement of “Consume deliberately. Take in information over affirmation.” Instead, the majority of the book is concerned with the dangers of our current information diets. It is, to maintain the food metaphor, more manifesto than menu. Those of you who read the title then pick up this book hoping to see detailed steps to achieve Inbox Zero may be disappointed on that front. However, if you’re looking for motivation to make a more fundamental shift in your attitude toward information intake you may have come to the right place.

I am myself someone who already keeps her inbox hovering at or just above zero, who regularly scrubs her RSS subscriptions of feeds which were added more for whim than value and who filters her Twitter and Google+ to raise the signal to noise ratio. In this way I’m not really the appropriate audience for this book. I am the choir to Johnson’s preacher.

However there’s a stronger reason why I am not the audience for this book: I am neither political nor activist. The final chapter of the book is pure manifesto, enlisting reader assistance in using their newly-reformed information diets to effect governmental and political change. Considering the author’s background his concern with changing government is no surprise, however I admit that I was as turned off by it as I am by most other forms of activist outreach (political or otherwise). This isn’t Johnson’s fault. It’s my own hang up.

To be entirely clear: this is a good book. It’s well-researched, well-written and covers topics with which I believe more people should be familiar. It’s a good book, just not good for me personally. I recommend that anyone with an interest in any form of information consumption pick up a copy and make up their own minds.

Disclaimer: I received my copy of this book for free via the O’Reilly Blogger Review Program.

Technical Job Postings: Know Your Audience

Spotted in a job posting for a technical position:

$Company is a values-based, social change platform that leverages individual and institutional leadership and investment to positively impact local and global communities. $Company pursues multiple, related strategies to promote this mission. From green nonprofit centers to programmatic consulting, donor advised funds to fiscal sponsorship, grants management to risk management and more, $Company gives members of the nonprofit and philanthropic community freedom to focus on the change it wants to see. For more information, please visit www.domain.tld.

A panel from Gary Larson's Far Side comic: What dogs hear blah blah blahI don’t know about you, but my eyes slid right off that description right around the word “leverages.” After investigating $Company more I can see that it’s a very respectable organization with a long history of assisting non-profits, both organizationally and financially. And, yes, if you take the time to play through the buzzword bingo in their description, it does actually tell you that. So…uh…why couldn’t they just tell us that?

When writing up a technical job posting (or any job posting, for that matter), keep your audience in mind. You are going to get better responses to a posting which uses clear, direct language than one which reads like it was written by a marketing intern looking to impress. Frankly, this sort of thing just scares technical people away. They read it and think, “Wow…is the entirety of $Company that stuffy and corporate? Is it one of those places where everyone wears suits and Casual Friday means a polo shirt instead of button-down? No flip-flops? Hrm… There are postings for other companies which sound more my style. I’ll put my effort into applying for those instead.”

In this case, I’d rewrite the description above to make it more casual:

Since $year, $Company has been helping non-profits with organization, logistics and finances, freeing them up to be the change they want to see in the world. There are $number non-profits of all sizes using our tools, including $np1, $np2, and $np3. We’re looking for a socially-minded $position to join our team.

That’s just a first pass and undoubtedly isn’t the best description possible but I’ll wager you a pint of good beer that you read it and found it more appealing than the original. Aside from improving on the stuffy tone, this version accomplishes a few things the first doesn’t:

  • Tells you up front how long $Company has been around, establishing credibility and stability.
  • As a programmer you now know that there are tools to be built. This gives you an idea of what you’d probably be working on. Also, who doesn’t like good tools?
  • Gives you an idea of the extent and nature of the clientele of $Company, helping establish $Company’s identity and philosophies. For instance, if $np1, $np2, and $np3 are all institutions with which you strongly agree then you can be more confident in fitting in at $Company, which is willing to be publicly identified with these institutions.
  • States outright that they’re looking for socially-minded people. If you’re just looking for a paycheck you probably should look elsewhere.

Bottom Line: Never forget that when you write one of these things you’re advertising that job position. Take the same care in audience discovery and wording as you would with any other marketing outreach. Be honest, be direct and use the language your audience expects to hear.

Book Review: “Process Improvement Essentials” by James R. Persse, PhD

tl;dr: A well-written book I’d recommend to all in the IT field who have any interest in working smarter rather than harder to bring their projects in on time, on budget and to customer spec.

Cover of Process Improvement EssentialsProcess Improvement Essentials, written by James R. Persse, PhD, delivers on its title. The field of process improvement is large, detailed and complicated—much more so than I would have expected before reading this book—yet Persse manages to curate, condense and present the topic in a highly effective and approachable manner. Which, I suppose, is to be expected considering the subject matter in question.

One method Persse uses to curate and condense is by limiting his target audience to IT professionals. The entire book is presented from the point of view of improving the quality of IT deliverables in whatever form they may take so, as a techie yourself, you can pick up this book without fear of getting mired in descriptions of processes (billing, accounting, manufacturing, marketing, sales, etc.) in which you may have little direct interest.

The book itself is organized into two sections. The first discusses process improvement in a more general sense and was the part of the book which I most enjoyed. The philosophies of process improvement resonated well with me, however that’s no surprise as I’m already predisposed toward the concept. Persse’s writing is clear, engaging and filled with quotes which struck me enough to write them down. Some examples:

From my experience, technology industries—corporate software, systems development, and operations—have been somewhat immune from the cleansing light of public failure.

Companies that are doing well are rarely motivated to initiate process improvement programs or quality initiatives.

…everything we do should be somehow traceable to satisfying the customer.

After all, if you hire competent people, you should probably get out of their way and let them do their jobs.

The second section of the book is a fairly in-depth overview of three process improvement methodologies: ISO 9000, CMMI, and Six Sigma. While moderately interesting, I recommend initially only skimming this half of the book then returning to it more in depth when/if your team decides to undertake one of the methods detailed here. This half of the book will be valuable both in aiding selection of the best method for your team as well as for basic reference while implementing it.

In a profession fraught with projects which are over budget, overdue or outright canceled more often than they’re successfully concluded, I would recommend that every IT professional pick up and read a copy of this book at least once in their career. Even if they only read the first half, the raised awareness of quality and process can only help improve the overall IT project success record.

At Risk: An Online Service is Sometimes Neither Online Nor Serviceable

404 LOLCAT NOT FOUND by GirlieMac on Flickr, CC BY 2.0The down side of relying upon all these online services is that, well, they’re online services [1]. The sad truth of the internet is that these things disappear all the time, often with little or no notice. Some notable examples:

These are just a few of the innumerable internet services which have either seen their final sunset or been very close to it. Each of these companies had users who relied upon their services, users who were left high and dry when the last staff member leaves the building. And in the end this just didn’t matter. The lights went out and the service disappeared.

This is bad enough for your Average Joe User, but what if your own company relies upon someone else’s API? What if you were one of the companies whose offering depended upon the Google Maps API for Flash only to have it end-of-lifed? Or, say, the Amazon cloud is suddenly unreachable? How would your company fare?

In this interconnected world of ours we are all stronger through the cooperation afforded by public APIs and online services of this kind, however that does not mean we’re allowed to be blind to the risks which we take by doing so. As CTOs, architects, managers and programmers we all need to consider these scenarios and prepare for them in order to minimize the impact on our users. Downtime happens to everyone at some point and is excusable but failure to prepare is not. It’s just stupid.

500 LOLCAT INTERNAL SERVER ERROR by GirlieMac on Flickr, CC BY 2.0When designing your project or service, try to build in some failsafes to prevent a crisis in case an external API or online service becomes unavailable. Fail gracefully, don’t flame out. It could even be as simple as disabling certain pages (or even the entire service, if necessary) when an API can’t be reached. This is a far superior user experience to your users seeing a 404 or 500 status page…

When researching this article I came across the post API Half-lives by Gabriel Weinberg of DuckDuckGo. He has a great list of questions for a team to ask itself when considering APIs and services to use in their projects. Go give it a look then sit down with your team and consider whether you’ve put yourselves at risk and, if so, what you can do about it.

[1] I have taken precautions for each of these services to be sure I do not lose important data. All information is sync’d to multiple locations and, in the case of the photos, backed up in multiple locations as well. [back to reading!]
[2] ArchiveTeam’s raison d’être is swooping in to save at risk data. They do great work and could use your help preserving our fragile digital heritage. Check out their wiki or hop on their IRC channel and say howdy. They’re all rogues with hearts of gold who’ll welcome you with open arms. [back to reading!]

Online Services I Find Worth Paying For

While I appreciate getting something for free [1] as much as the next person, I’m also very willing to shell out cash for online services which I find both useful and valuable. Here are the ones for which I do (or am willing to) plunk down a few shekels on a monthly or yearly basis:

  • Dropbox: I adore Dropbox. This service has saved my ass more times than I care to remember. While the standard service is free for 2GB I pay to upgrade my account to 50GB. While it’s nice to get all that extra space I’ve found that Dropbox has become such an integral part of my workflow that I would pay anyway just to help guarantee it’s around for a good, long time.
  • Evernote: I spend a lot of time online and most of that is spent reading. Back in the day I would bookmarks articles I enjoyed. Back in the day I would also lose the bookmark file any time I switched computers. I also would never look at the site again. I’d remember, “Oh, I read something about $foo once…” but be unable to locate it in the morass of links. Enter Evernote. With one click of the browser plugin any site, any image, any PDF is slurped into my Evernote account, metatagged, indexed and sync’d to all of my devices. Data is no longer lost and I’m a happy camper who’s able to search and locate whatever I need. The basic service is free and more than adequate for most people but, yet again, this is a service which important to my day to day work and therefore worth it to me to support financially.
  • Netflix: Really, does this one even need an explanation? Probably not but it’ll get one anyway. I haven’t had cable for about twelve years now. I’ve been without a TV for two or three years. My entertainment needs are met via the internet, primarily by Netflix (of which I’ve been a subscriber since 1999). Netflix allows me to indulge my desire for cheesy science fiction programming without having to spend money on DVDs which are just going to take up space in my apartment.
  • Github: Github has rapidly established itself as the go-to distributed version control hub on the internet, particularly among open source advocates. Any repository which is open sourced may be hosted for free and includes a project tracker, issue tracker, etc. It’s a brilliant piece of work for which the Githubbers should receive a great many gold stars. I, however, don’t have any open sourced repositories there quite yet. Instead, I pay a small amount every month for the peace of mind which comes from maintaining important files in my own private version-controlled repositories.
  • Remember The Milk: The most important tip I took away from GTD was, “write it down in a trusted location and get it off your mind so you can focus.” Remember The Milk (aka ‘RTM’) is that trusted location for me. Any time I think of something I want to or should do I immediately grab one of my devices, type in a quick to-do item and sync it up. Since I started doing this over a year ago my productivity and organization has increased greatly while my stress level has mostly dropped. When something doesn’t get done it’s invariably because I failed to use the system correctly (like not looking at it; hrm). For a while RTM syncing from iPhone and iPad required paying for a Pro account (I do not believe this is the case now), which is necessary for me to capture items on the fly. However even if that weren’t the case I still would pay for this service simply for all the good things it has done for my quality of life.
  • Flickr: I used to host my own photo albums. That got to be a drag. Not only that, there were new online services which were doing the same thing but better. At the time I joined Flickr was the hot thing and had yet to be acquired by Yahoo!. The user interface was clean and useful, the features were exactly what I needed. Subscribing for a Pro account got me the organizational features I required. Now my account hosts 1,646 of my photos and am well content to stay with them for the next 1,646 and beyond.
  • Spool: This one’s a newcomer to the online service game, so much so that it’s still in private invitation beta. It’s also the only one on the list which currently does not have a fee option for its service and is entirely free. That said, this service has very rapidly become a vital part of my online workflow. While Instapaper enables users to save articles for offline reading, Spool enables its users to save both articles and videos. These are then synced to my iPad and iPhone. I read/watch them on the Muni, in the pub, while waiting in line… The best part is that I no longer have a browser window crowded with “Aspirational Tabs” for things I’d like to get to some day. Click, add to my Spool, close the tab and get around to reading it later. If Spool adds ‘Send to Evernote’ as an option (‘Send to Twitter’ and ‘Send to Google+’ would be nice as well) then I’m a user for life and will pay for the privilege. As they’re still in beta I have great hopes for these features.
[1] Hellooooo, Google Mail, Google Docs, Google Voice, Skype, Twitter… [back to reading!]

It’s Called Marketing for a Reason

Let’s do a little experiment. The next time you’re in a room full of techies, say something along the lines of, “Hey, how about that marketing department, eh?” Now count the number of people in the room who roll their eyes, snort derisively or start otherwise grumbling about how marketing is evil and clueless and a few other unflattering adjectives.

I used to be in that camp. I used to believe that marketing was nothing but advertising and manipulation, getting gullible people to buy stuff they neither want nor need. Then I worked at an online marketing company for six years and took the time learn what this wacky “Marketing” thing is all about.

While advertising is a large (and the most public) facet of marketing I believe it’s one of the least important. Which isn’t to say it’s not important, just that I personally rank it near the bottom of marketing operations.

A hint to the most important marketing operation is right there in the name: Marketing. Before a marketer can do anything else he needs to determine his market. I offer that this is the single most important operation not only in the marketing department but also in the entire organization. Why?

Your market is composed of your users. It’s the people with whom the sales team closes deals, for whom you put code to editor, for whom the customer service reps pick up the phone. These are, as far as your organization is concerned, The Most Interesting People in the World. Before it lifts a finger it must know not only who these people are but also what they need and how to communicate with them.

Do you know your market? Have you ever thought to ask? If not then I strongly suggest the next thing you do after you read this post is schedule a lunch or coffee outing with someone from your Marketing team to do a little learnin’. An understanding of the people for whom you’re writing software will lead to better decisions about design and features, more successful services, better roll-outs… In short, it will make for a more successful project. Not knowing your market means you’re not in sync with the rest of the organization. You’ll waste time adding features which no one will use. You’ll design interfaces which will confuse and frustrate. Sales won’t sell, customer service will be overwhelmed with requests and you’ll have to go back and fix it. No one wants that.

It’s possible that you may already have a pretty decent idea of who the users of your software are and for that I heartily applaud you. However I still recommend you take an hour to have that lunch with someone from Marketing to discuss it. As much as you know you can always learn more. Getting a different perspective on your market can only do good for you, your product and your organization. Furthermore you’ll gain a deeper understanding of the operation of the organization and where you fit in it. And let’s not forget that there are two people sitting at that lunch table. Forging a relationship with Marketing helps expand the horizons of both teams and enables the entire organization to be more successful.

Or, to put it into Marketing Speak, embracing a best practice of increasing interdepartmental face-time to leverage a holistic and synergistic approach to market knowledge can increase the core competency of the enterprise for greater return on investment, mindshare and thought leadership.

OK, so maybe sometimes marketing can be a little bit evil.

Rethinking Education Requirements in Tech Job Postings

A few days ago I posted this tweet:

My tweet was prompted by seeing a constant stream of job postings containing lines such as the following (taken from actual postings on craigslist:

  • BSCS or equivalent industry experience
  • Hold a BS or higher degree (or equivalent) in Computer Science/Engineering or related field
  • BS degree in Computer Science, Engineering or equivalent
  • Degree in computer science or similar
  • Four-year degree or Masters in an analytical or technical field (e.g. Economics, Computer Science, Mathematics, Statistics, or Finance)

Between my experiences as a tech manager and participating in open source communities I’ve met a lot of incredibly talented programmers. A few have CS degrees; most have degrees which have nothing whatsoever to do with computer science; some have no college degree to their name at all. Of the most talented and skilled programmers I know the majority are in this last group: they hold no degree and yet *gasp* they are absolutely brilliant. Unfortunately I’ve seen some very good people be discounted (and typically therefore not hired) because they lacked what some on the hiring committees deemed “a proper education.” This inevitably meant that the candidate did not have a degree in computer science or—even more unforgivable—did not have a degree at all.

Since I do know so many excellent and self-educated programmers I found myself becoming exceedingly annoyed on their behalf at these requirements. When the annoyance reached a head I blew off steam by way of the tweet, crying “elitism”.[1]

In the time since the tweet was posted I’ve simmered down a bit and started to think things through a bit more clearly. I came up with a question:

What, really, is the purpose of an education requirement for a tech job posting?

Photo by Flickr user mag3737, Creative Commons BY-NC-SAFrom what I can tell, an education requirement is shorthand for a minimum level of knowledge. “You must be this high to ride this ride.” The expectation is that if a programmer has a degree in computer science she knows data structures and recursion and how to solve the Tower of Hanoi in Java. However I see this as redundant data, at best. The same information is going to be readily apparent from skimming the applicant’s resume and code sample. Seeing a degree listed on an applicant’s resume does not excuse me, as a hiring manager, from reading the remainder of the document.

In addition there is an entire raft of vital skills which aren’t taught in most computer science degree programs. Using source control. Writing tests. Working on a team.[2] I’m sorry to say, but if I see a resume from a new compsci grad I assume he does not know how to do these things. Unless he has experience coding outside of the classroom I’m likely to set his resume aside in preference to the applicant with no degree but with open source experience, who has worked on a team and contributed code which has seen the light of day. I don’t care much for towers—Hanoi, ivory or otherwise; I care about results and that’s not something you can determine from the one line in a resume stating, “Bachelors of Science, Computer Science, Wossamotta University (2003).” It’s all those other lines which matter.

There are definitely times when having a degree requirement makes sense. I don’t mean to imply that they should be entirely banished from tech job postings. However I do believe that we, as an industry, need to put as much thought and care into our job postings as our code design. We would never stand for bullshit requirements for our code. We should not stand for them in our job postings either.

[1]: I admit “bigotry” was a close second but wasn’t chosen due to its intensely negative baggage. “Elitism” is only slightly negative in comparison.[Back to reading!]

[2]: Andy Lester has a great presentation discussing what schools are missing in their CS curricula. [Back to reading!]

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!]