Über die zersetzende Wirkung von E‑Mail

Tech­no­lo­gie ent­fal­tet in kom­ple­xen sozia­len Sys­te­men immer auch uner­war­te­te Sei­ten­ef­fek­te. Als IBM in den 1980er Jah­ren ein inter­nes E‑Mail Sys­tem ein­führ­te, wur­de auf­grund der damals noch sehr hohen Kos­ten für Rechen­leis­tung natür­lich sehr genau ana­ly­siert, wie viel die Men­schen bis­her mit Memos und Tele­fo­na­ten kom­mu­ni­zier­ten. Unter der Annah­me, dass sich die­se Kom­mu­ni­ka­ti­on dann in das E‑Mail Sys­tem ver­la­gern wür­de, dimen­sio­nier­te das Team den Groß­rech­ner groß­zü­gig. Trotz­dem war das Sys­tem schon in den ers­ten Wochen mas­siv über­las­tet. (Cal New­port, When Tech­no­lo­gy Goes Awry. In: Com­mu­ni­ca­ti­ons of the ACM, May 2020, Vol. 63 No.5).

Weil es so viel ein­fa­cher war über E‑Mail zu kom­mu­ni­zie­ren, nutz­ten die Mit­ar­bei­ter die­se Tech­no­lo­gie offen­sicht­lich viel mehr als für ihre eigent­li­che Arbeit zu erwar­ten gewe­sen wäre. Das wäre nach­voll­zieh­bar, wenn die­se zusätz­li­che Kom­mu­ni­ka­ti­on für die eigent­li­che Arbeit not­wen­dig oder wenigs­tens för­der­lich gewe­sen wäre. Lei­der war das nicht der Fall. Cal New­port zitiert in sei­nem Arti­kel Adri­an Stone, der als Inge­nieur damals in dem E‑Mail Team arbei­te­te: „Auf die­se Wei­se wur­de in nur einer Woche oder so der poten­zi­el­le Pro­duk­ti­vi­täts­ge­winn durch E‑Mail erzielt und wie­der zunich­te gemacht.“

Most know­ledge workers belie­ve that email is a pas­si­ve tool they choo­se to use to make their real work easier. But […] this tech­no­lo­gy is not pas­si­ve; it ins­tead actively chan­ges what we mean by „real work.“

Cal New­port. A Mode­st Pro­po­sal: Eli­mi­na­te Email. In: Har­vard Busi­ness Review, 18. Febru­ar 2016.

Das war der Anfang eines gro­ßen Miss­ver­ständ­nis­ses, dem wir bis heu­te immense Pro­duk­ti­vi­täts­ver­lus­te ver­dan­ken. Die meis­ten Wis­sens­ar­bei­ter betrach­ten E‑Mail pri­mär als ein Werk­zeug, das sie bei ihrer eigent­li­chen Arbeit unter­stützt. Tat­säch­lich hat E‑Mail aber das, was wir unter eigent­li­cher Arbeit ver­ste­hen deut­lich ver­än­dert. Wo man frü­her Abläu­fe genau­er pla­nen muss­te, reicht es heu­te ein­fach schnell eine E‑Mail zu ver­schi­cken, um das Pro­blem schnell vom Tisch und in die nächs­te Inbox zu bekom­men. Der unbe­ab­sich­tig­te Neben­ef­fekt die­ser Tech­no­lo­gie ist daher ein unstruk­tu­rier­ter Arbeits­ab­lauf. In gro­ßen Tei­len besteht der All­tag von Wis­sens­ar­bei­tern nun dar­in, eine immer grö­ße­re Flut von Nach­rich­ten zu ver­schi­cken, abzu­ru­fen und zu beant­wor­ten, damit die Arbeit irgend­wie fortschreitet.

Was ursprüng­lich der Unter­stüt­zung der Arbeit die­nen soll­te, wur­de damit unbe­ab­sich­tigt zum Kern der Arbeit. In die­ser Hin­sicht sind auch neue­re Tech­no­lo­gien wie Grup­pen­chats in Slack und Co. mit Vor­sicht zu genie­ßen, weil sie den Struk­tur­ver­lust in der Arbeits­or­ga­ni­sa­ti­on durch noch ein­fa­che­re und unmit­tel­ba­re­re Kom­mu­ni­ka­ti­on wei­ter befeuern.

Mee­tings are by defi­ni­ti­on a con­ces­si­on to defi­ci­ent orga­niza­ti­on. For one eit­her meets or one works.

Peter F. Dru­cker. The Effec­ti­ve Exce­cu­ti­ve, S. 44

Ähn­lich ver­hält es sich mit der zwei­ten Pla­ge gro­ßer Orga­ni­sa­tio­nen, den zum Bers­ten mit Bespre­chun­gen voll­ge­stopf­ten Kalen­dern. Natür­lich sind Bespre­chun­gen an sich kei­ne neue Tech­no­lo­gie, aber durch Kalen­der­soft­ware wie Out­look und geteil­te Kalen­der wur­de es viel ein­fa­cher, jeman­dem eine Bespre­chung ein­zu­stel­len. Was frü­her viel Pla­nung und Tele­fo­na­te von Assis­ten­ten und Assis­ten­tin­nen erfor­der­te, geht nun auf Knopf­druck und wird damit ent­spre­chend exzes­siv genutzt. Jetzt mit dem durch die Pan­de­mie ver­mehr­ten Auf­kom­men von ver­teil­ter Arbeit im Home­of­fice eher noch mehr, weil durch Video­kon­fe­ren­zen nicht mal mehr phy­si­sche Prä­senz für die Bespre­chung not­wen­dig ist.

Weder E‑Mail noch Bespre­chun­gen sind aber per se das Pro­blem, viel­mehr ist es ihr zer­set­zen­der Effekt auf struk­tu­rier­te Abläu­fe. Ihre Ein­fach­heit ver­lei­tet zu einer Zusam­men­ar­beit, die im Wesent­li­chen durch Zuruf funk­tio­niert. Es hilft daher nicht wirk­lich bei die­sen Sym­pto­men anzu­set­zen, son­dern bei der Fra­ge, wie die Zusam­men­ar­beit bes­ser gestal­tet wer­den kann als durch Sta­tus­mee­tings und E‑Mail Ping-Pong.

Eine Ant­wort dar­auf lie­fern bei­spiels­wei­se Metho­den aus der agi­len Soft­ware­ent­wick­lung, allen vor­an Scrum. Die Arbeit ist klar struk­tu­riert in Back­log-Items, die ent­we­der phy­sisch auf Kar­ten beschrie­ben sind oder vir­tu­ell in Tools wie JIRA ver­wal­tet wer­den. An wel­chen davon kon­kret gear­bei­tet wer­den soll, wird alle zwei bis vier Wochen zu Beginn eines Sprints im Sprint-Plan­ning ent­schie­den. Was dann im Detail zu tun ist, beschreibt das Team dann in ein­zel­nen Tasks je Back­log-Item und hält alles auf einem Kan­ban-Board (phy­sisch oder digi­tal) fest. Jeden Tag im soge­nann­ten Dai­ly trifft sich das Team vor die­sem Board und spricht kurz dar­über, wel­che Tasks abge­schlos­sen wur­den und wer was als nächs­tes macht und wer wobei Hil­fe benötigt.

Ein Teil des Erfolgs von Scrum geht mei­ner Mei­nung nach allein dar­auf zurück, dass Arbeits­ab­lauf und Arbeits­in­hal­te recht rigi­de struk­tu­riert wer­den und viel weni­ger dar­auf, wie das kon­kret pas­siert. Wenn man sich dar­auf ein­lässt, eli­mi­niert die­se Struk­tur vie­le E‑Mails und vie­le Bespre­chun­gen. Und damit bleibt mehr Zeit für das, was Soft­ware-Ent­wick­ler wie alle ande­ren Wis­sens­ar­bei­ter am meis­ten brau­chen, um gute Arbeit zu leis­ten: Fokus und Konzentration.