The Corrosive Effect of E‑Mail

In com­plex social sys­tems, tech­nol­o­gy always unfolds unex­pect­ed side effects. When IBM intro­duced an inter­nal e‑mail sys­tem in the 1980s, the very high cost of com­put­ing pow­er at the time made it nec­es­sary to ana­lyze very pre­cise­ly how peo­ple were com­mu­ni­cat­ing with mem­os and phone calls. It was assumed that this com­mu­ni­ca­tion would shift to the e‑mail sys­tem and, based on this, the main­frame com­put­er was gen­er­ous­ly sized. Nev­er­the­less, the sys­tem was already mas­sive­ly over­loaded in the first weeks. (Cal New­port, When Tech­nol­o­gy Goes Awry. In: Com­mu­ni­ca­tions of the ACM, May 2020, Vol. 63 No.5).

Because it was so much eas­i­er to com­mu­ni­cate via e‑mail, employ­ees obvi­ous­ly used this tech­nol­o­gy much more than one would have expect­ed for their actu­al work. This would also be under­stand­able if this addi­tion­al com­mu­ni­ca­tion had been nec­es­sary or at least ben­e­fi­cial for their actu­al work. Unfor­tu­nate­ly this was not the case. In his arti­cle, Cal New­port quotes Adri­an Stone, an engi­neer on the team respon­si­ble for intro­duc­ing the e‑mail sys­tem at IBM: “Thus — in a mere week or so — was gained and blown the poten­tial pro­duc­tiv­i­ty gain of email.”

Most knowl­edge work­ers believe that email is a pas­sive tool they choose to use to make their real work eas­i­er. But […] this tech­nol­o­gy is not pas­sive; it instead active­ly changes what we mean by “real work.”

Cal New­port. A Mod­est Pro­pos­al: Elim­i­nate Email. In: Har­vard Busi­ness Review, Feb­ru­ary 18, 2016.

And that was just the begin­ning of a major mis­un­der­stand­ing, to which we still owe immense pro­duc­tiv­i­ty loss­es. Most knowl­edge work­ers see e‑mail pri­mar­i­ly as a tool that sup­ports them in their actu­al work. In fact, e‑mail has changed the way we col­lab­o­rate sig­nif­i­cant­ly. Where­as in the past, work­flows had to be planned more pre­cise­ly, today all it takes is to send an e‑mail quick­ly to get rid of the prob­lem. The unin­tend­ed side effect of this tech­nol­o­gy is there­fore an unstruc­tured work­flow. To a large extent, every­day life now con­sists of send­ing, check­ing and reply­ing to an ever-increas­ing flood of mes­sages so that the work some­how progresses.

What was orig­i­nal­ly intend­ed to sup­port the work, thus unin­ten­tion­al­ly became the very essence of work for many knowl­edge work­ers. In this respect, new­er tech­nolo­gies such as group chats in Slack and Co. should also be treat­ed with cau­tion, because they fur­ther fuel the struc­tur­al loss in work orga­ni­za­tion by mak­ing com­mu­ni­ca­tion even easier.

Meet­ings are by def­i­n­i­tion a con­ces­sion to defi­cient orga­ni­za­tion. For one either meets or one works.

Peter F. Druck­er. The Effec­tive Excec­u­tive, S. 44

Sim­i­lar­ly, with the sec­ond plague of large orga­ni­za­tions, name­ly cal­en­dars stuffed to burst­ing with meet­ings. Of course, meet­ings are not new tech­nol­o­gy per se, but cal­en­dar soft­ware like Out­look and shared cal­en­dars have made it much eas­i­er to set up a meet­ing for every­one. What used to require a lot of plan­ning and phone calls from assis­tants is now done at the touch of a but­ton and is there­fore used exces­sive­ly. Now, with the increased amount of dis­trib­uted work in the home office due to the pan­dem­ic, this is even more so because video con­fer­enc­ing no longer requires phys­i­cal presence.

Nei­ther e‑mail nor meet­ings are a prob­lem per se, but rather their cor­ro­sive effect on struc­tured work­flows. Their sim­plic­i­ty leads to a col­lab­o­ra­tion that essen­tial­ly works by call­ing out. So it does­n’t real­ly help to start with these symp­toms, but rather with the ques­tion of how col­lab­o­ra­tion can be bet­ter orga­nized than through sta­tus meet­ings and e‑mail ping-pong.

One answer to this is pro­vid­ed by meth­ods from agile soft­ware devel­op­ment, in par­tic­u­lar Scrum. Work is clear­ly struc­tured in back­log items, which are either phys­i­cal­ly described on cards or man­aged vir­tu­al­ly in tools like JIRA. Which of these items are actu­al­ly worked on in the next sprint is decid­ed in the sprint plan­ning. What is to be done in detail is described in indi­vid­ual tasks per back­log item and record­ed on a Kan­ban board (phys­i­cal­ly or dig­i­tal­ly). Every day in the Dai­ly, the team talks in front of this board about which tasks have been com­plet­ed and who does what next and who needs help with what.

In my opin­ion part of the suc­cess of Scrum is due to the fact that the work­flow is struc­tured quite rigid­ly and much less to how this is done. When you get into it, this struc­tured work­flow elim­i­nates many e‑mails and many meet­ings. And that leaves more time for what soft­ware devel­op­ers, like all oth­er knowl­edge work­ers, need to do a good job: focus and concentration.