Vor einiger Zeit habe ich damit begonnen, ein Experiment zu machen. Ich war mir nicht sicher, wie viele Aufgaben ich übernehmen kann, bis ich vor einem Problem stehe. Zum einen fühlte ich mich nicht überlastet, zum anderen hatte ich die das Gefühl, noch mehr übernehmen zu können. Ein paar Monate später, und ich fand mich überfordert. Ein paar Wochen später, und ich kann drüber reflektieren. Hier sind die Lektionen, die ich davontrage.

Zunächst einmal ist das Problem nicht das Problem, sondern meine Reaktion auf das Problem. Das bedeutet, dass ich mich nicht hinsetzen kann, und darüber grübeln, warum ich in diese Situation gekommen bin. Stattdessen ist es wichtiger, dass ich nicht in einer Paralyse ende, sondern weiter mache. Ein Vorgesetzter sagte mir einmal: „Machen, Herr Gärtner!“ Und das ist genau die Reaktion, die eine Überlastungssituation erstmal auslösen sollte. Zeit zum Reflektieren hat man, wenn sich die Wogen wieder geglättet haben. Als ich anfing, das umzusetzen, habe ich schnell bemerkt, dass einige Dinge kürzer dauern, als vorher befürchtet. Im Englischen bedeutet „F.E.A.R.“ nichts anderes als „Fantasy Experienced As Reality“. Genau dieses Phänomen traf mich hier anscheinend.

Doch ich hatte schon vorher darüber gelesen, wie Leute auf Überlastung reagieren, und worauf man achten sollte. Doch darüber zu lesen genügt leider nicht. Das bringt mich zur zweiten Lektion. Wie Jerry Weinberg in „Becoming a Technical Leader“ erklärt, ist das erste Hindernis für Innovation Blindheit gegenüber sich selbst. Dem entgegen steht, dass innovativen Ideen aus eigenen Fehlern entsteht – sofern man daraus lernt. Dieser Blogeintrag ist Teil meiner eigenen Reflektion. Doch, wie schütze ich mich vor Selbstblindheit? Ein Kollege sagte mir mehrfach, dass ich überfordert sei. Zunächst habe ich nicht darauf gehört, aber seine Worte schon gehört. Doch ich habe bewußt nicht darauf reagiert, da mich die Aussage an sich erstmal nicht weiterbringt. Stattdessen habe ich nach Signalen gesucht, die diese These bestätigen oder widerlegen. Über die Zeit mußte ich dann aber auch einsehen, dass er anscheinend Recht hatte – und ich danke ihm dafür, dass er so hartnäckig dabei war.

In der dritten Lektion habe ich gelernt, dass ich öfter mal „nein“ sagen muss. Jedes Mal, wenn ein Kollege mit einer neuen Anfrage auf mich zukommt, muss ich energisch und unwidersprüchlich „nein“ sagen. Das kann bedeuten, dass ich E-Mails kurz angebunden mit einem einzelnen Satz beantworte, oder dass ich wie aus der Pistole geschossen mit „nein“ auf eine direkte Frage antworte. Nur so kann sich mittelfristig eine Verbesserung einstellen. Bei mir konkret war außerdem noch wichtig, dass ich einen sog. Addicition Cycle durchbreche. Dabei geht es darum, dass sich kurzfristig Verbesserungen einstellen, aber langfristig mehr Schaden genommen wird. Das Prinzip funktioniert bei allen möglichen Suchtverhalten genauso wie bei einem Entwicklungsteam, welches schlechten Code ständig ausliefert. Durch das „nein“ Sagen, habe ich bewußt die kurzfristigen Verbesserungen für mich verboten, und so bewußt den Teufelskreis durchbrochen.

Über eine finale Lektion bin ich in einem Buch aus dem Jahr 1961 gestoßen. Dabei war ich überascht, wie sehr diese Lektion in unserer Branche ignoriert wird. Wir hantieren mit unglaublich vielen Regeln in der Softwareentwicklung. Doch immer wieder ignorieren wir, dass wir diejenigen sind, die die Regeln auch wieder verändern sollten. Alle guten Regeln – und auch Lektionen, die wir gelernt haben – sollten nicht mit gedankenlosen Vertrauen angewandt werden. Das trifft vor allem für selbst auferlegte Regeln zu. Diese sollten wir stattdessen in Prinzipien umwandeln, indem wir herausfinden, wann wir uns an die Regeln halten sollten, und wann wir sie bewußt nicht beachten.

Eine große Entschuldigung an alle, die ich in letzter Zeit vernachlässigt habe. Ich arbeite daran, das zu ändern.