Kleine ungenaue Anfragen verschwenden massiv Zeit im Team
(staysaasy.com)- Vage Anfragen von Managern und Führungskräften können, auch wenn sie wie kleine Fragen wirken, die Zeit des Teams, Prioritäten und die Ausführungsrichtung stark durcheinanderbringen
- Formulierungen wie „Bitte prüfen“ oder „Das muss modern sein“ weiten sich leicht zu überzogenen Reaktionen aus, etwa Berichten, Foliensätzen, Wochenendarbeit oder umfassenden Upgrades
- Wer eine Anfrage stellt, sollte auch den erwarteten Zeitaufwand, die Auswirkung auf Prioritäten, ob vorhandenes Material geprüft werden soll oder neue Arbeit nötig ist, und wofür das Ergebnis verwendet wird, klar benennen
- Auch die Person, die die Anfrage erhält, sollte nach dem erwarteten Aufwand fragen und Unklarheiten klären; man darf nicht annehmen, dass eine Führungskraft zu beschäftigt ist, um zu antworten
- Wenn man am Anfang so konkret spricht, dass es fast etwas unangenehm wirkt, lassen sich spätere Verwirrung, falsche Arbeit und verschwendete Kosten deutlich reduzieren
Wie kleine Anfragen zu großer Arbeit werden
- In Organisationen passiert es immer wieder, dass kurze und leicht wirkende Anfragen zu deutlich größeren Aufgaben anwachsen als erwartet
- Wenn ein Manager fragt: „Kannst du X machen?“, kann es vorkommen, dass die direkt unterstellte Person zehnmal mehr Zeit investiert als erwartet und der Manager dann reagiert: „Ich wollte nicht, dass du so viel Zeit darauf verwendest“
- Wenn eine Führungskraft in einer Besprechung kurz sagt: „Kannst du das bitte prüfen?“, kann das dazu führen, dass 24 Personen vier Versionen eines Foliendecks erstellen und bis zum Wochenende arbeiten
- Im eigentlichen Meeting kann es dann sein, dass die Führungskraft nur die Zusammenfassung im ersten Satz der ersten Folie sieht und sagt: „Die komplette Präsentation ist nicht nötig“
- Auch die Aussage „Es muss ohne Ausreden modern sein“ kann, wenn die Bedeutung nicht geklärt wird, als umfassendes technisches Upgrade verstanden werden
- Die tatsächliche Absicht kann nur darin bestehen, über einige Jahre hinweg in neuen Versionen die API-Syntax zu aktualisieren
- In der Zwischenzeit kann die Veröffentlichung wichtiger Projekte ins Stocken geraten
Was die anfragende Person zuerst festlegen sollte
- Führungskräfte sollten bei einer Anfrage die erwartete zeitliche Obergrenze direkt benennen
- Beispiel: „Bitte verwende nicht mehr als 20 Minuten und bring nach 20 Minuten einfach das mit, was du bis dahin hast“
- Sie sollten auch festlegen, wie sich das auf Prioritäten auswirken soll
- Beispiel: „Ich rechne mit etwa 2 Wochen, und die Priorität anderer wichtiger Aufgaben sollte dadurch nicht stark sinken“
- Man sollte auch sagen, dass man sofort informiert werden möchte, wenn der tatsächliche Zeitplan anders aussieht oder mit anderer Arbeit kollidiert
- Es sollte unterschieden werden, ob nur vorhandenes Material geprüft werden soll oder ob etwas neu analysiert oder erstellt werden muss
- Beispiel: „Sag mir nur, ob wir zu diesem Thema bereits etwas haben. Wenn noch nie darüber nachgedacht wurde, reicht mir auch diese Information“
- Wenn man den Verwendungszweck des Ergebnisses nennt, kann die andere Person den angemessenen Aufwand leichter einschätzen
- Beispiel: eine Antwort an einen potenziellen Vertriebskunden, Vorbereitung auf Q&A beim nächsten All Hands oder ein Kernthema der nächsten Vorstandssitzung
Was die angefragte Person klären sollte
- Die Person, die die Anfrage erhält, sollte Rückfragen zur Klärung stellen
- Man sollte den erwarteten Aufwand prüfen, etwa mit: „Erwarten Sie ein sehr gründliches Ergebnis, das mehrere Stunden braucht, oder eher eine kurze Zusammenfassung?“
- Durch Nachfragen wirkt man nicht dumm; gefährlicher ist es, nicht zu fragen und dann etwas völlig Falsches zu tun
- Statt Zeit damit zu verbringen, E-Mails oder Messenger-Nachrichten von Führungskräften wie antike Artefakte zu interpretieren, ist es besser, direkt bei der anfragenden Führungskraft nachzufragen
- Wenn eine Führungskraft Zeit hat, eine Anfrage zu stellen, hat sie auch Zeit, diese Anfrage zu präzisieren
1 Kommentare
Meinungen auf Hacker News
Am meisten stört es mich, wenn eine nichttechnische Führungskraft ein oder zwei Ebenen überspringt und direkt mit Junior-Technikern spricht, statt mit erfahrenen Senior-Technikern, die Erfahrung damit haben, klärende Fragen zu stellen oder Zeitpläne und Deliverables zu definieren.
Das ist ein Muster, das ich häufig in verschiedenen Kampagnenorganisationen oder politischen Tech-Organisationen gesehen habe.
Auch Junior-Techniker verstehen die Befehlskette; wenn jemand sie durchbricht, ob beabsichtigt oder nicht, entstehen Verwirrung und Chaos.
Die Person, die die eigentliche praktische Arbeit erledigt, ist oft ein Junior Engineer und kann bestimmte Fragen besser beantworten als jemand, der auf einer höheren Ebene draufschaut.
Warum sollte man unbedingt stille Post spielen?
Wenn ein unerfahrener Projektkoordinator eines Anbieters, Techniker eines Anbieters, die daran gewöhnt sind, dass der Koordinator die Dinge regelt, und ein Kunde, für den das alles neu ist, zusammenkommen, kann das für ziemlich große Verwirrung sorgen.
Zu den Aussagen „Wenn man keine Fragen stellt und dann etwas völlig Falsches macht, sieht man natürlich dumm aus“ und „Gehe niemals davon aus, dass die andere Person zu beschäftigt ist, um während der Arbeit klärende Fragen zu beantworten“ frage ich mich, wie man das handhabt, wenn man remote arbeitet und nicht einmal Online-Chat verfügbar ist.
Vor Ort ist es leicht, viele kleine, schnelle und grob formulierte Fragen zu stellen, aber E-Mails fühlen sich formeller und störender an, sodass man mehr Zeit damit verbringt, zu erklären, was unklar ist, und mögliche Antworten vorwegzunehmen.
Videocalls zu vereinbaren dauert seine Zeit und bringt ebenfalls hohe Nebenkosten mit sich.
Bei Kundenprojekten ergänze ich jedes Mal, wenn eine kleine Frage auftaucht, ein Google Doc und benachrichtige den Kunden gelegentlich, dass er das Dokument prüfen soll, oder lasse ihn Änderungsbenachrichtigungen abonnieren.
Der Kunde schreibt die Antworten direkt ins Dokument, und während die Arbeit voranschreitet, wiederholt sich dieser Prozess.
Die Vorteile sind: Der Kunde muss nicht alles auf einmal beantworten, es gibt weniger Benachrichtigungen, beide Seiten können weniger formell schreiben, es fühlt sich kollaborativ an, Anschlussfragen lassen sich leicht neben den relevanten Abschnitt setzen, kurze Diskussionen oder kleine Arbeitszuweisungen und deren Nachverfolgung sind über Dokumentkommentare möglich, und andere können es leichter lesen und beitragen.
Ich denke hier an Situationen mit vielen kleinen Fragen, etwa Auftragsarbeiten mit wenig bekannten, nichttechnischen Kunden.
Andere Menschen legen E-Mails nicht solche Einschränkungen auf.
Wenn du nicht gerade an den CEO schreibst, kannst du deine Fragen so aufschreiben, wie sie dir einfallen, und sie direkt abschicken.
Du musst auch keine Angst davor haben, sofort eine zweite Mail zu schicken wie: „Ach, diese Frage habe ich auch vergessen. Danke! $QUESTION“
Wenn man sich auf https://twitter.com/TechEmails E-Mails von Top-Führungskräften ansieht, sind die meisten sehr informell.
Manche alten Mails zwischen Bill Gates und Microsoft-Führungskräften sind kaum geordneter als Textnachrichten von Oberschülern.
Das heißt nicht, dass du Emojis an den Chef des Chefs des Chefs deines Chefs schicken solltest, aber schnelle informelle E-Mails beenden nicht deine Karriere.
Ich verstehe, dass es sich für viele Menschen schwerwiegender anfühlt, aber ich weiß nicht, ob es für beide Seiten tatsächlich lästiger ist.
Wenn das Klären einer Frage einen Dialog hin und her erfordert, dann sollte man das so machen.
Die Methode mit einem geteilten Dokument ist ebenfalls eine gute Idee und hat zwei zusätzliche Vorteile.
Das Aufschreiben ist ein zusätzlicher Schritt, der die Frage klarer macht, und Frage und Antwort werden für später dokumentiert.
Beides sind große Vorteile gegenüber einem schnellen Gespräch, das man später wieder aufschreiben muss.
Du kannst die kognitive Last an die andere Person weitergeben.
Denn einmal zu unterbrechen ist besser, als mehrmals am Tag zu unterbrechen.
Wenn ich ein neues Issue bekomme, überfliege ich es zuerst, plane, was zu tun ist, denke mich in mögliche Probleme oder Konflikte hinein und erstelle manchmal eine riesige Fragenliste; danach teile ich auf, wer welche Fragen wahrscheinlich beantworten kann, und starte dann die Online-Unterhaltung.
Innerhalb eines Unternehmens kann man normalerweise über einen internen Messenger wie Slack um einen kurzen 5-Minuten-Videocall bitten.
Bei engen Kollegen rufe ich auch direkt ohne Vorankündigung an.
Mit externen Kunden kann man Ähnliches über eine echte Telefonnummer oder einen Videocall machen, wenn es vorher vereinbart wurde.
Zum Beispiel kann man im Kickoff-Meeting festlegen, welche Kontaktfrequenz der Kunde wünscht und welche Fragen sofort besprochen werden müssen und bei welchen eine langsamere asynchrone Kommunikation ausreicht.
Zeit ist ein sehr schlechter Indikator für Aufwand, Substanz und Umfang.
Wenn man zum Beispiel die Bitte betrachtet: „Schau dir das nur 20 Minuten an und bring mir danach mit, was du hast“, dann schafft jede Person in 20 Minuten etwas unterschiedlich viel.
Selbst wenn man diesen Unterschied ignoriert, gibt es keine Garantie, dass die Führungskraft, die die Anfrage gestellt hat, aus diesen 20 Minuten Aufwand das bekommt, was sie braucht.
In agilen Umgebungen sieht man oft, dass Discovery- und Recherchearbeiten „Spikes“ genannt und mit einer „Timebox“ versehen werden. Fragt man aber: „Was passiert, wenn man in dieser Zeit nicht findet, was man wollte?“, gibt es meist keine gute Antwort.
In der Praxis wird die Timebox verlängert, bis man herausgefunden hat, was man braucht.
Deshalb ist Zeit ein schlechter Proxy für Aufwand, Substanz oder Umfang.
Ich halte das Beispiel weiter hinten im Text für besser: „Erwarten Sie etwas sehr Gründliches, in das mehrere Stunden fließen, oder reicht eine schnelle Zusammenfassung?“
Denn hier geht es nicht um die benötigte Zeit, sondern um den Arbeitsumfang.
Misst man in Zeit, gibt es keine Garantie, innerhalb dieser Zeit das Gewünschte zu bekommen, und am Ende hängt man einfach mehr Zeit dran.
Die Antwort auf „Was, wenn man in dieser Zeit nicht findet, was man wollte?“ lautet: Man erfährt, dass die Antwort nicht innerhalb der erwarteten Zeit gefunden werden konnte, und passt die Erwartungen an den für diese Untersuchung nötigen Aufwand an.
Aus Sicht einer Führungskraft ist genau diese Information eine der zentralen Informationen, die man haben möchte.
Deshalb braucht im Grunde alles eine Timebox, wenn man verhindern will, dass ein Projekt entgleist und im Mülleimer landet.
Das gilt auch für individuelle Arbeit oder Arbeit allein.
Man kann sich an allem ewig festbeißen; deshalb ist es viel besser, einen Stopp-Punkt zu erzwingen, Feedback einzuholen oder zu veröffentlichen und dann zu entscheiden, ob es sich lohnt weiterzumachen.
Der Mechanismus, der hier wirkt, besteht darin, Menschen zu Priorisierung zu zwingen.
Wenn man sehr gut im Priorisieren ist, braucht man Timeboxes vielleicht weniger; aber selbst dann kann es ohne Timebox schwer sein, der Versuchung zu widerstehen, weiter an einer höheren Qualität zu arbeiten, als tatsächlich nötig ist.
Dieses Arbeitsmuster ist nützlich, wenn es viel mehr gibt, was man nicht weiß, als was man weiß.
Ziel ist es, den Anteil dessen, „was man weiß“, schrittweise so weit zu erhöhen, dass man keine wilden Vermutungen mehr anstellt, sondern informierte Vermutungen.
Angenommen zum Beispiel, es gibt einen Bug in einer Legacy-Codebasis, das Ersatzsystem ist fast fertig und soll in zwei Monaten veröffentlicht werden: Wie geht man mit diesem Bug um?
Man könnte ihn ignorieren oder jemandem sagen: „Fix das um jeden Preis“, aber beides ist nicht gut.
Also sagt man: „Untersuche diesen Bug, aber nicht länger als eine Stunde, und sag mir, wie weit du gekommen bist.“
Danach kennt man die Form des Problems besser.
Wenn die Person zurückkommt mit: „Ich habe den Problembereich gefunden, aber ich kann es nur beheben, wenn ich es zusammen mit jemandem löse, der die Business-Logik gut kennt“, dann kann man die passenden Ressourcen dazugeben und mit dem Fix weitermachen.
Wenn sie sagt: „Es ist dieser Teil des Codes, er ist ziemlich aufgeräumt, aber ich habe es noch nicht ganz nachverfolgt“, kann man auf Basis des Vertrauens, dass es keine riesige Sache wird, mehr Zeit geben.
Wenn sie dagegen sagt: „Es steckt irgendwo in diesem bizarren Spaghetti-Code, und als ich hineinsah, blickte der Abgrund zurück, mir lief es kalt den Rücken hinunter und die Bilder an den Wänden weinten Blut; bitte schick mich nicht noch einmal dorthin“, dann wird klar, dass es sich nicht lohnt, weiter nachzuforschen, und man kann es fallenlassen.
Ich glaube dir, dass du die Erfahrung gemacht hast, dass mehr Zeit drangehängt wurde, wenn das Gewünschte nicht in der Zeit erreicht wurde, aber das ist nicht universell.
Das Problem liegt darin, „das Gewünschte“ selbst als Endziel zu behandeln.
Deshalb sagt der Text auch: „Sag, warum du es brauchst.“
„Unser größter Kunde muss es vor der Vertragsverlängerung wissen“ ist es wert, mehr Geld und mehr Arbeitszeit von Mitarbeitenden zu investieren als „Ich war nur neugierig“.
Auf Leadership-Ebene muss man erkennen, dass man nicht jeden Nutzen verfolgen kann, und sich strategisch auf das konzentrieren, was das beste Kosten-Nutzen-Verhältnis hat.
Das bedeutet nicht nur, jemanden auf eine Aufgabe zu setzen, sondern auch, die passende Arbeit an die Person mit den passenden Fähigkeiten zu vergeben.
Ein Startup-CEO bat um etwas; die Anfrage war, glaube ich, nur ein oder zwei Sätze lang.
Das Ergebnis war ein 14-seitiger Bericht, für den ich mehrere Stunden aufgewendet habe, größtenteils in meiner Freizeit.
Ich schickte den Bericht an den CEO, bekam danach aber nie eine Antwort, und es passierte nichts.
Danach stellte ich für mich eine neue Regel auf.
Die Kosten einer Anfrage sollten proportional zu den Kosten sein, diese Anfrage zu übermitteln.
Wenn ich jetzt eine teure Anfrage bekomme, warte ich, verzögere und verlange eine Eskalation.
Die Person, die die Anfrage stellt, muss ihre Due Diligence machen und sich die Zustimmung einer höheren Ebene holen, um zu zeigen, dass es sich lohnt, diese Kosten zu tragen.
Wenn es eine Bullshit-Anfrage ist, wird man nie wieder davon hören; wenn es eine wertvolle Anfrage ist, wird sie bearbeitet. Als zusätzlichen Vorteil geschieht dieser Aufwand dann nicht heimlich ohne angemessene Sichtbarkeit.
Erstens: Auf die erste Anfrage hin mache ich grundsätzlich gar nichts.
Wenn es wichtig ist, wird sie erneut fragen, und dann denke ich darüber nach.
Zweitens: Wenn ich Überstunden machen muss, muss die andere Person auch Überstunden machen.
Wenn sie keine Überstunden machen will, war es entsprechend nicht wichtig genug.
Ich habe ein paar Dinge gelernt, weil ich im Engineering mehrere Ebenen erlebt habe, von Junior bis C-Level.
Erstens müssen alle in gutem Glauben handeln.
Ich habe gesehen, wie ein Leader ohne fünf Sekunden Nachdenken spontan jemanden direkt unter ihm um etwas bittet, und umgekehrt habe ich gesehen, wie direkte Mitarbeitende sich wie eine „menschliche Kommandozeile“ verhalten, die sich nur bewegt, wenn die exakte Syntax vorgegeben ist.
Beides darf nicht passieren.
Zweitens gibt es für Manager oder Leader keine „einmaligen Anfragen“.
Jede Anfrage bekommt implizit Vorrang vor allem anderen.
Man muss sich innerhalb des gesamten Systems und Umfelds bewegen; andernfalls wälzt man diese Entscheidung auf das Team ab.
Drittens: Wenn man die Anfrage erhält, muss man der anfragenden Person helfen zu verstehen, was sie braucht.
Implizite Annahmen müssen beseitigt werden, denn genau dort verstecken sich die Drachen.
Man muss kommunizieren, informieren, lehren und klären, was die anfragende Person will, damit bestätigt ist, dass beide Seiten einverstanden sind.
Solche Dinge entstehen oft aus Effizienzgründen, weil man keine Zeit verschwenden will, wenn es nicht nötig ist. Aber wenn anfragende und empfangende Person versuchen, einander zu helfen, wird das Leben im Allgemeinen deutlich erträglicher.
Zwischen einem Leader, der austestet, wie weit er gehen kann, und einem Leader, der eine wohlwollende Beziehung zum Team aufbauen will, besteht ein krasser Unterschied.
Manager, die ständig gedankenlose Forderungen stellen, verlieren kontinuierlich ihre besten Mitarbeitenden.
Meiner Erfahrung nach bleiben unter solchen Leadern nach genügend Zeit nur Juniors übrig, weil erfahrene Leute dieses Team meiden.
Ein Teammitglied vom Typ „menschliche Kommandozeile“ ist ebenfalls ein gutes Beispiel für Handeln in schlechtem Glauben.
Ich habe mit Leuten gearbeitet, die selbst bei winzigen Anfragen verlangen, dass man erst ein von ihnen erstelltes Formular oder Dokument ausfüllt, und die dann tagelang diskutieren, kritisieren oder es herumreichen, bevor sie über eine kleine Aufgabe überhaupt nachdenken.
Sie glauben, sie hätten sich vor kleinen Anfragen geschützt, indem sie dafür gesorgt haben, dass niemand mehr die Mühe auf sich nehmen will, eine Frage exakt zu stellen. Mit der Zeit bauen sie sich aber den Ruf auf, schwer in der Zusammenarbeit zu sein.
Eine weitere Variante sind Menschen, die jede Mehrdeutigkeit in Anfragen ausnutzen.
Obwohl sie im Großen und Ganzen wissen, was von ihnen verlangt wurde, liefern sie „um eine Lektion zu erteilen“ ein Ergebnis ab, das dem Wortlaut der Anfrage zwar entspricht, von dem aber alle wissen, dass es weder gebraucht noch gewünscht war.
Nicht zufällig wurden die meisten Leute, die solche Spielchen gespielt haben, im vergangenen Jahr entlassen.
Menschen können schlechte Kolleginnen und Kollegen, die immerhin in gewissem Maß Arbeit erledigen, eine Weile ertragen. Bei Kürzungen stehen sie aber ganz oben auf der Streichliste.
Vor einem Monat habe ich erkannt, welchen Fehler ich als Leader gemacht hatte.
Nach außen hin wollte ich dem Team Ownership geben und habe viele Dinge, die erledigt werden mussten, hineingekippt. Tatsächlich habe ich aber den Stress der Frage „Was muss genau jetzt getan werden?“ auf das Team abgewälzt.
Das ist eine tückische Falle, weil man leicht denkt: „Ich delegiere enorm viel Verantwortung an das Team!“ In Wirklichkeit stresst man das Team und verringert dessen Fokus.
Laut OED begann die Substantivierung in der australischen Umgangssprache.
https://www.oed.com/search/dictionary/?q=ask
Wir alle wissen, dass Sprache ein sich ständig veränderndes biosoziales kognitives Produkt ist und es daher keine echten Regeln gibt. Aber wenn es bereits völlig brauchbare gute Synonyme gibt, fühlt sich diese Verwendung störend an, als würde man Sand kauen.
Ich wollte nicht, dass diese Information die Entscheidung beeinflusst.
Ich dachte, wir sollten das tun, was für das Business und die Endnutzer am besten ist, nicht das, was für mich einfach ist.
Die andere Person wählte jedoch die längere und schwierigere Option. Später stellte sich heraus, dass sie eigentlich die andere wollte, aber dachte, diese wäre für mich schwieriger.
Dasselbe passiert auch im echten Leben.
Als ich neue Küchenschränke baute, gab ich meiner Frau zwei Optionen für die obere Leiste der Türen. Eine war schwieriger, aber ich sagte es nicht, weil ich wollte, dass sie auswählt, was ihr gefällt.
Natürlich wählte sie die schwierigere, und es stellte sich heraus, dass sie dachte, diese sei einfacher, und dass ihr die andere eigentlich besser gefiel.
Deshalb sollte man der anderen Person immer alle Informationen geben.
Warum kann man nicht sagen, dass eine Frage aus dem Management keinen Sinn ergibt?
Die Antwort ist natürlich, dass man sich der Hierarchie nicht widersetzt.
Aber diese Hierarchiekonformität hilft dem Business tatsächlich nicht.
Sie wirkt wie ein Wert, den man leichter aufgeben können sollte.
Die Frage „Erwarten Sie etwas sehr Gründliches, oder reicht eine schnelle Zusammenfassung?“ ist lustig.
Wenn ein Engineer einer Nicht-Engineering-Person ehrlich sagt, wie lange etwas dauern wird, ist die Nicht-Engineering-Person schockiert und sagt Nein.
Die Bitte „Verbringe nicht mehr als 20 Minuten damit und bring mir nach 20 Minuten, was du hast“ klingt verrückt.
Es gibt keine Arbeit, die 20 Minuten dauert.
Besser wäre: „Schau dir das nicht an, trink einen Kaffee und gib mir danach eine grobe Schätzung.“
Wir erledigen komplexe Aufgaben und brauchen Zeit zum Nachdenken.
Wenn man nicht will, dass Denkzeit aufgewendet wird, sollte man einfach nicht fragen.
Ein Teil des Problems ist, dass man dem Chef weder sagen will, er solle sich verziehen, noch sagen will, dass man sechs Stunden für etwas aufgewendet hat, das er für eine 20-Minuten-Sache hielt.
Deshalb verschiebt sich stattdessen alles andere.
Genau deshalb hält gutes Engineering-Management Engineers so weit wie möglich von Leuten fern, die unbeabsichtigt Techniker an sich reißen würden.
Ein typisches Zeichen schwachen Managements ist es, Berichte anzufordern oder Aufgaben zu vergeben, deren volle Tragweite man selbst nicht versteht.
Ein typisches Zeichen schwachen Engineerings ist es, auf solche Anfragen mit „Ja“ zu antworten.
Wenn ein schwacher Manager etwas verlangt, das über den Rahmen einer trivialen Erledigung hinausgeht, sollte die ausführende Person je nach technischem und sozialem Kontext eines von drei Dingen tun:
A) Fragen: „Wie soll das gemacht werden?“
Das funktioniert, wenn der Manager technisch versiert ist, aber Aufgaben vage abwirft, um die eigene technische Unfähigkeit zu kaschieren.
Wenn man den Unsinn einfach zurückspielt, muss er sich mit dem tatsächlichen Umfang und der mechanischen Realität seiner Forderung auseinandersetzen.
B) Sagen: „Diese Aufgabe erfordert X Ressourcen. Was sind die Erwartungen?“
X kann dabei alles Mögliche sein: enorm viele Personenstunden, Geld, Old-School-RuneScape-GP usw.
Das ist für nichttechnische Manager geeignet und zwingt sie, ähnlich wie A, anzuerkennen, dass es sich um eine große Anfrage handelt, die nicht spontan genehmigt werden sollte, sondern den normalen Prozess durchlaufen muss.
C) „Nein“ sagen
Das ist nicht in jeder Organisation oder jedem sozialen Kontext möglich, aber leistungsstarke Organisationen machen es möglich.
In leistungsstarken Engineering-Umgebungen hat die Engineering-Organisation ein starkes Vetorecht gegen unsinnige Beschäftigungstherapie, das nur auf C-Level-Ebene überstimmt werden kann.
Zu wissen, wann und wie man dieses Vetorecht ausübt, ist ebenfalls eine wichtige Fähigkeit, die Engineering entwickeln muss.
Deshalb konnte alles, was man dazu sagte, am Ende dazu führen, dass man sich selbst Richtung Tür schob.
Jedes Mal, wenn ich sehe, dass „ask“ als Substantiv verwendet wird, juckt mein Sprachgefühl; ich habe nachgeschlagen und diesen Beitrag gefunden:
https://english.stackexchange.com/questions/4246/can-or-shou...
Könnte für Leute hilfreich sein, die das ähnlich stört.
Einer der größten Zeitfresser ist, wenn einer Anfrage der Kontext fehlt.
Es wirkt, als wolle man Zeit sparen, indem man nur denjenigen informiert, der es braucht, aber das „Warum“ und der Kontext sind wirklich entscheidend, um eine gute Lösung zu finden.
Ohne das weiß man nicht, was die andere Person bereits durchdacht hat.
Wenn es zum Beispiel heißt: „Wir müssen Anfragen aus Land X blockieren“, ist das mit den meisten Firewall-Diensten nicht besonders schwierig.
Aber warum muss das gemacht werden?
Wenn es darum geht, eine vertragliche Zusicherung zu geben, dass aus einem bestimmten Land kein Traffic entsteht, funktioniert dieser Ansatz nicht, weil jeder mit einem VPN die Ländercode-Erkennung in zwei Minuten umgehen kann.
Der Nutzer will X tun, weiß aber nicht wie, glaubt, Y würde funktionieren, und bittet um Hilfe bei Y; andere sind dann verwirrt, weil Y seltsam wirkt.
https://xyproblem.info/
Auf diesem Hügel sind schon viele gestorben, und trotzdem wurde es umgesetzt.
Es ist besser, nicht das nächste Opfer zu werden.
Am Ende hängt es stark von der Unternehmenskultur ab und davon, wie wohl sich Menschen dabei fühlen, Senior Leaders zu widersprechen.
Die Verantwortung liegt bei den Senior Leaders, die es den Leuten unter ihnen leichter machen müssen, zu widersprechen.
Meiner Erfahrung nach sind die besten Führungskräfte demütig und bereit zuzuhören.
Allerdings gehört es manchmal auch zum Job, sinnlose Arbeit zu erledigen.
Wenn es zu viel wird, sollte man sich natürlich etwas anderes suchen, aber es ist besser, nicht zu der Person zu werden, die dem Management immer misstraut und alles infrage stellt.