- Wenn man in einem kleinen Unternehmen Aufgaben innerhalb des eigenen Zuständigkeitsbereichs vorantreibt, kann es die Umsetzung beschleunigen, statt auf eine Erlaubnis zu warten lieber eine Gelegenheit zum Widerspruch mit Frist zu geben
- Genehmigungsanfragen wie „Darf ich action X installieren?“ können der Führungskraft die Prüfung des Problems, die Beurteilung des Lösungswegs und sogar die Priorisierung aufbürden, wodurch sich die Antwort verzögern kann
- Wenn man sagt: „Ich werde am Montag action X installieren. Wenn Sie das anders sehen, sagen Sie mir bitte Bescheid“, zeigt man Umsetzungswillen und lässt der Führungskraft trotzdem Raum, einzugreifen
- Dieser Ansatz eignet sich, wenn die Aufgabe innerhalb der eigenen Rolle liegt, Feedback willkommen ist, man aber auch ohne Antwort sicher genug ist, weiterzumachen
- Wenn man zugleich eine nahe Frist nennt, reagieren die relevanten Personen eher schneller, und man kann die Umsetzung fortsetzen, ohne sie aus dem Tritt zu bringen, während man die Beteiligten weiter informiert
Gelegenheit zum Widerspruch geben, statt auf Erlaubnis zu warten
- Ein Bias zur Umsetzung, selbst in sehr kleinen Schritten, hilft dabei, festgefahrene Situationen zu durchbrechen
- Die zentrale Gewohnheit besteht darin, nicht um ein „Ja“ zu bitten, sondern um ein „Nein“
- Die Erfahrung dahinter stammt aus kleinen Unternehmen mit weniger als 200 Mitarbeitenden
- Ob derselbe Ansatz auch in großen Unternehmen, Non-Profits oder Behörden funktioniert, ist nicht sicher
- Wenn man etwas tun will, das man noch im eigenen Aufgabenbereich sieht, aber Rückversicherung möchte oder die Führungskraft informieren will, bittet man normalerweise zuerst um Erlaubnis
- Stattdessen gibt man der Führungskraft die Gelegenheit zum Widerspruch und nennt zugleich eine klare Frist, bis wann diese Entscheidung fallen kann
Der Unterschied am Beispiel einer GitHub Action
- Das Beispiel ist die Situation, in der man ein neues GitHub Action im Repository installieren möchte, weil man glaubt, dass es zur Verbesserung der Softwarequalität beiträgt
- Es handelt sich nicht um eine spontane Laune, sondern um etwas, das bereits recherchiert und lokal getestet wurde
- Möglicherweise hat man auch frühere Kolleg:innen nach ihren Erfahrungen mit dieser GitHub Action gefragt
- Die Frage „Darf ich action X installieren? Sie hilft bei dem XYZ-Problem, das wir haben“ zwingt die Führungskraft dazu, vor einem „Ja“ zusätzliche Arbeit zu leisten
- Das XYZ-Problem muss erneut geprüft werden
- Es muss beurteilt werden, wie X das Problem lösen würde
- Möglicherweise müssen Prioritäten gegenüber anderen Aufgaben abgewogen werden, oder die verantwortliche Person möchte zunächst eigenes Wissen dazu teilen
- Bei einer beschäftigten Führungskraft kann das leicht nach hinten rutschen, und man muss vielleicht mehrfach nachfassen
- Die Alternative ist eine Formulierung wie: „Ich werde action X installieren, um das XYZ-Problem zu lösen. Wenn Sie das anders sehen, sagen Sie mir bitte Bescheid, andernfalls erledige ich es am Montag.“
- Das signalisiert, dass die zuständige Person das Problem selbst anpacken wird
- Die Führungskraft kann sich einschalten, wenn sie möchte, steht aber weniger unter dem Druck, zwingend antworten zu müssen
- Selbst wenn die Führungskraft es vergisst oder etwas anderes dazwischenkommt, stoppt der Fortschritt nicht
- Dieser Ansatz lässt sich nicht nur auf Einzelpersonen anwenden, sondern auch auf Gruppen aus mehreren Personen
Wie Fristen Reaktionsdruck erzeugen
- Die Frist ist ein Kernelement dieses Ansatzes
- Aus Sicht des 15. Januar kann „Ich werde task X erledigen“ weniger Reaktion auslösen als „Ich werde task X am 17. Januar erledigen“
- Eine nahe Frist in der Zukunft kann eher eine sofortige Reaktion hervorrufen als eine weiter entfernte wie „Ich werde task X am 15. Februar erledigen“
- Am besten passt dieser Ansatz, wenn man Raum für Feedback lässt, aber zugleich sicher genug in der Richtung ist, auch ohne Feedback zu handeln
1 Kommentare
Meinungen auf Hacker News
In Großunternehmen, wo alle beschäftigt sind und Dinge leicht untergehen, ist das eine Kernkompetenz.
Man erklärt das Problem in einer E-Mail und schreibt dann: „Wenn es innerhalb von [N] Tagen keine Antwort gibt, werde ich am [N. Tag] XYZ tun.“ Statt um Freigabe zu bitten und dann hilflos zu warten oder nachzuhaken, hinterlässt man also die Mitteilung, dass XYZ weiterläuft, wenn niemand reagiert.
Gelegentlich taucht ein paar Wochen später jemand auf und ist wütend, warum man das ohne Absprache gemacht habe, aber dann kann man jedes Mal auf den übersehenen Verlauf verweisen.
Es reicht völlig, etwas zu sagen wie: „Aus diesen Gründen möchte ich XYZ tun und werde am [Datum] damit fortfahren. Bitte melden Sie sich, wenn es Einwände oder Bedenken gibt.“
Dieser Ansatz zwingt einen dazu, vorab eine solide Begründung zu liefern, und ermöglicht Feedback, um Einschränkungen, die man nicht kennt, oder eigene Fehler zu vermeiden.
Seltsam ist auch dieses Cargo-Cult-Verhalten, bei dem Amazons Leadership Principles wie eine Problemlösung nachgeahmt werden. Dass „Bias for Action“ bei Amazon funktioniert, liegt daran, dass Leute, die eigenmächtig handeln und scheitern, zu Sündenböcken gemacht und entlassen werden – und solche Leute schreiben keine Blogposts über die Tugend des Bias for Action.
Etwa so: „Ich plane, am 1. März das thingamajig zu defragmentieren. Ich melde mich vorab bei allen, für die diese Arbeit Probleme verursachen könnte. Bitte geben Sie Bescheid, wenn es Bedenken gibt. Wenn bis zum 1. März keine Antwort kommt, wird das thingamajig defragmentiert“?
„Wenn es innerhalb von 5 Tagen keine Antwort gibt, mache ich X“ ist keinerlei Absicherung, wenn man etwas getan hat, wofür man disziplinarisch belangt werden kann.
Funktionieren dürfte das höchstens, wenn man eine interne Designentscheidung missachtet, die nichts mit dem Geschäft zu tun hat.
Wenn jemand sagt, er mache das „immer“, und dann eine magische Formulierung wie eine Vorlage hinschreibt, frage ich mich, ob das wirklich eigene Erfahrung ist – oder eher eine Projektion davon, wie er gern arbeiten würde, wie im Artikel.
Wenn ich mir die Szene vorstelle, wie man wütenden Kollegen den Verlauf zeigt und gewinnt, schlägt mein Bullshit-Detektor bis in den roten Bereich aus.
Ich nenne das „nicht fragen, sondern informieren“, und es ist innerhalb wie außerhalb von Unternehmen sehr nützlich.
Es ist eine grundlegende Kommunikationsfähigkeit und macht Ergebnisse knapp und verbindlich.
Mit meiner Frau führe ich solche Gespräche oft: Sie neigt dazu, in einer Gruppenchat mit 8 Leuten offene Fragen zu schicken wie „Um wie viel Uhr kommt ihr an?“. Weil wir wegen der Kinderbetreuung wussten, dass wir eine Stunde früher ankommen, sagte ich ihr, sie solle einfach mitteilen: „Wir kommen um diese Uhrzeit an, und wer vorher etwas trinken will, findet uns an der Bar.“
Niemand musste antworten, alle kamen früh, und mit minimaler Kommunikation lief es gut.
Das hat ein wenig mit „Bitte lieber um Vergebung als um Erlaubnis“ zu tun, aber ein Ort wie ein GitHub-Repository, in dem mehrere Leute zusammenarbeiten, ist kein guter Platz, um große Änderungen, die andere betreffen, einfach hineinzuwerfen.
Statt in einem Zustand zu sein, in dem man nur Spaß haben kann, wenn andere alles mit einem abstimmen, fängt man mit dem an, was man tun möchte, und teilt anderen mit, dass sie sich anschließen können.
Wenn Kollegen mich fragen, wie sie ihre Vorschläge genehmigt bekommen, gebe ich ähnlichen Rat: „Mach es der anderen Person so leicht wie möglich, Ja zu sagen.“
Man sollte niemandem 14 Absätze hinwerfen und erwarten, dass die Person sofort auf dem Stand ist, den man selbst nach stundenlangem Einarbeiten in das Problem erreicht hat.
Wenn man von seinem Ansatz überzeugt ist, sollte man kurz erklären, warum Problem und Lösung zusammenpassen, und einen Link zu einem Dokument hinzufügen, für alle, die tiefer einsteigen wollen. Von Teammitgliedern oder Product Ownern sollte man sich möglichst schon vorher Zustimmung holen.
Beispiel: „Ich möchte X mit Y lösen. Das Team ist einverstanden. Das ausführliche Vorschlagsdokument liegt unter [link]. Wenn es kein weiteres Feedback gibt, das wir berücksichtigen müssen, starte ich am Dienstag.“
Manager haben keine Zeit, sich alle Details anzusehen, und sind dankbar, wenn die Arbeit einschließlich breiter Unterstützung im Team so aufbereitet ist, dass sie nur noch zustimmen müssen.
Wenn die Erfolgswahrscheinlichkeit 10 % beträgt, es aber Gründe für den Versuch gibt, sage ich das so, statt es als Quatsch-Präsentation zu verpacken, in der ich angeblich sicher bin, dass es klappt. Wenn die Erfolgswahrscheinlichkeit 80 % beträgt, verschweige ich die 20 % nicht; und wenn ich 98 % sage, heißt das, dass es tatsächlich ungefähr so wahrscheinlich ist.
Die Aufgabe eines Managers ist es, mit solchen Statistiken umzugehen und Risiken abzusichern. Hedgefonds tun das mit Geld, Manager mit Menschen und Ressourcen.
Leider bevorzugt der typische Unternehmensmanager jemanden, der zu 100 % behauptet, dass es klappt, obwohl es in Wirklichkeit in 50 % der Fälle scheitert.
Als ähnlichen Ausdruck mag ich Absicht ausstrahlen (radiating intent).
Dabei informiert man breit, was man wann tun will, und gibt Stakeholdern Raum, ausdrücklich zu widersprechen, ohne jeder einzelnen Einigung, Abstimmung oder Freigabe hinterherzulaufen.
In manchen Situationen funktioniert das gut, und in der Regel muss man sich zunächst ein Grundmaß an Vertrauen erarbeitet haben.
https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...
Mir gefiel auch die Nuance, die Eliz Ayer hinzufügte: „Fairerweise kann man mit radiating intent auch weniger erledigen, weil man Leuten, die blockieren oder sich einmischen, einen Einstiegspunkt gibt. Außerdem hängt dieser Rat stark von Situation und Organisation ab und ist daher nicht immer passend.“
Diese Art der Kommunikation scheint die andere Person sofort als Risikofaktor erscheinen zu lassen.
Oberflächlich wirkt es, als würde man ihr Zeit sparen, tatsächlich signalisiert man aber: Wenn die Führungskraft nicht ständig im Blick behält, was diese Person tut, könnte sie unerwünschte Dinge machen.
Der Text behandelt das wie eine Benachrichtigung, aber selbst bei bester Absicht und gegenseitigem Verständnis gehen Benachrichtigungen leicht im Rauschen der Signale unter, und keine Antwort bedeutet nicht Zustimmung. Es kann auch heißen, dass die Nachricht nicht angekommen ist.
Wenn Mitarbeitende und Führungskraft das Problem bereits besprochen haben und es nun darum geht, die Lösung umzusetzen, kann das in Ordnung sein. Aber wenn man ein Problem zum ersten Mal anspricht, über das die andere Person noch nicht einmal nachgedacht hat, ist es das Schlimmste. Es ist egoistisch und das genaue Gegenteil von Teamwork.
Es wirkt auch so, als hätte jemand einen legendären 10x-Rockstar-Engineer gesehen, der so vorgeht, und es dann nachgeahmt. Dieser Engineer liefert immer gute Arbeit, weiß, was zu tun ist, und hat mit dem Management gegenseitiges Verständnis und Respekt, sodass man ihm Selbststeuerung anvertrauen kann. Jemand hat das beobachtet und offenbar nicht verstanden, warum diese Person so behandelt wird und wie man sich das selbst erarbeitet, sondern angenommen, es gelte auch für ihn.
Wenn man das dreimal hintereinander so macht und als Antwort „Bitte aufhören“ bekommt, läuft etwas schief. Wenn man dreimal hintereinander Lob bekommt, sollte man weitermachen.
Wirklich gefährlich ist jemand, der trotz eines Neins das meiste irgendwie trotzdem umsetzt und später nach einem Ja sucht. Beim nächsten Thema macht er es genauso und reagiert nicht auf Feedback.
Entscheidend ist also weniger die Methode selbst als die Arbeitsbeziehung. In einem Umfeld mit hohem Vertrauen und viel Auslastung bei allen kann man es ausprobieren.
Wenn wir bereits zusammengearbeitet haben, Vertrauen besteht und ich weiß, dass es aus Respekt vor meiner Zeit geschieht, ist das eine ganz andere Sache.
Sobald dadurch zum ersten Mal etwas kaputtgeht, wird es zum Rezept für eine Katastrophe.
Ein Ja oder Nein bekommen zu haben bedeutet, dass die vorgesetzte Person Bescheid wusste. Wenn etwas schiefgeht und die Frage „Wer hat das genehmigt?“ kommt, lautet die ehrliche Antwort: niemand hat es genehmigt.
Wenn es in einer Organisation niemanden gibt, der so handeln kann, ist das ein Zeichen dafür, dass das Führungsteam bei der Delegation versagt.
Zum Beispiel in einer Situation, in der X aus Team Y gegen etwas ist.
Wenn die Führungskraft 1) sagt, dass etwas getan werden muss, und 2) keinen Plan genehmigt, dann macht man es eben nicht. In diesem Fall liegt die Verantwortung, arbeitsfähige Anweisungen zu geben, bei der Führungskraft.
Zu sagen „Ich werde das tun“ ist in Ordnung, aber ohne Prozesse wie Review und automatisierte Tests sollte nichts in Production gelangen.
Natürlich entstehen dadurch Engpässe. Wenn man einen Merge Request erstellt und niemand ihn rechtzeitig reviewt, passiert gar nichts. In solchen Fällen sollte auf Teamlead-Ebene vereinbart werden, dass innerhalb einer bestimmten Zeit geprüft und reviewt wird.
Dieser Ansatz scheint nur bei US-Unternehmen oder bei Führungskräften zu funktionieren, die mit US-amerikanischer Business-Kultur vertraut sind.
Wenn die Führungskraft das nicht mag, kann es massiv nach hinten losgehen. Bei der Leistungsbeurteilung kann sie es leicht als Ungehorsam abstempeln, und man hat ihr die nötigen Belege selbst auf dem Silbertablett geliefert.
Manchmal ist es auch in den USA wirklich am besten, um Erlaubnis zu bitten, insbesondere wenn es um Ressourcen geht.
In skandinavischen Kulturräumen zum Beispiel hält sich Management oft ziemlich zurück, und es wird häufig erwartet, dass Mitarbeitende viele Entscheidungen eigenständig oder in Abstimmung miteinander treffen.
Allerdings waren diese Führungskräfte alle stark von US-Kultur geprägt.
Selbst effektive militärische Entscheidungsfindung hängt stark davon ab, dass Einheiten vor Ort sich anpassen können, ohne jedes Mal im Hauptquartier anzurufen.
Ich nenne das vernünftige Defaults schaffen.
Statt Menschen für jedes Detail eine Entscheidung abzuverlangen, legt man ein Bündel vernünftiger Defaults fest, das zeigt, dass man die Situation versteht, und teilt mit, dass man entsprechend vorgehen wird.
So entsteht Vertrauen, und wenn wirklich Aufmerksamkeit nötig ist, schauen die Leute eher hin, weil sie wissen, dass man ihre Zeit normalerweise nicht verschwendet.
Diese Kommunikationsweise ist gut, aber der Teil mit der Deadline gefällt mir weniger.
Wenn ein Mitarbeiter etwas tut, gegen das ich möglicherweise ein Vetorecht habe, soll er mich einfach informieren. Denn vielleicht kenne ich mehr Kontext und kann einschätzen, dass es Zeitverschwendung ist oder keine Priorität hat.
Einer Führungskraft eine Deadline zu setzen ist seltsam und klingt unterschwellig wie eine nervige Drohung.
Bei Kleinigkeiten wie einer GitHub Action möchte ich glauben, dass ich dem Teammitglied genug Autonomie gegeben habe, um selbst zu entscheiden.
Aber wenn man „Ich mache das an diesem Datum, sofern ich nichts anderes höre“ anhängt, wirkt es etwas aggressiv.
Man könnte auch nur den Zeitpunkt der Arbeit erwähnen und es bei „Ich denke, ich werde es etwa dann fertigstellen“ belassen; das lässt Raum dafür, dass jemand zu dem Schluss kommt, dass man besser nicht fortfährt.
Trotzdem war es schon lange das Ziel, bestimmter aufzutreten. Sich nur kleinzumachen hat Grenzen.
Man hält einen Tag für ausreichend und macht weiter, aber wenn die andere Person zwei Tage später antwortet, hat man bereits gegen die Anweisung gehandelt.
Mit einem Datum lässt sich das vermeiden: „Ich werde am Mittwoch (dem 26.) das Build-System migrieren. Bitte sag Bescheid, wenn es Bedenken gibt.“
Ich habe es erst nach dem Lesen des Beispiels verstanden; eigentlich ist es keine Deadline, sondern eher ein geplanter Arbeitstermin.
Denn sie gibt der anderen Person eine Benachrichtigungsfrist und hilft jemandem, der eine alte E-Mail später liest, einzuschätzen, ob sie noch relevant ist.
Normalerweise bedeutet eine Deadline: „Wir haben bereits entschieden, das zu tun, und Genehmigung oder Einigung liegen vor; jetzt informiere ich nur noch über die Umsetzung.“
Ein Teil des Tricks bei „Wenn du mir nichts anderes sagst, mache ich das so“ besteht darin, es nicht wie eine Frage zu formulieren und dadurch Kommunikationskosten zu senken.
Dann muss der Empfänger keine Antwort schreiben, und auch ich oder die Personen in CC müssen keine weitere E-Mail lesen.
In diesem Sinne sind Funktionen wie Emoji-Reaktionen in GitHub oder Google Docs gut, mit denen man per Daumen hoch markieren kann, dass man etwas gelesen hat und zustimmt. In Teilen von HN sind sie seltsamerweise unbeliebt, aber es ist eine leichtgewichtige Form der Kommunikation, bei der man nicht jedes Mal einen Kommentar wie „Klingt gut, ergibt Sinn!“ schreiben muss. Ähnlich wie ein Upvote.