{"id":2852,"date":"2026-06-17T17:10:24","date_gmt":"2026-06-17T17:10:24","guid":{"rendered":"https:\/\/jamalnichols.com\/?p=2852"},"modified":"2026-06-17T17:31:18","modified_gmt":"2026-06-17T17:31:18","slug":"ambiguity","status":"publish","type":"post","link":"https:\/\/jamalnichols.com\/de\/ambiguity\/","title":{"rendered":"N\u00fctzlich bleiben, w\u00e4hrend die Arbeit unklar ist"},"content":{"rendered":"

Fr\u00fcher habe ich den Satz in Stellenbeschreibungen oft nur \u00fcberflogen: \u201eMuss mit Ambiguit\u00e4t umgehen k\u00f6nnen.\u201c Es klang wie eine dieser h\u00f6flichen Unternehmensanforderungen, die alles bedeuten k\u00f6nnten. Vielleicht wusste das Unternehmen nicht, was es wollte. Vielleicht wollte der Manager eine Ausrede f\u00fcr schlechte Planung. Vielleicht haben auch alle einfach denselben Text aus der Anzeige von jemand anderem kopiert, weil es erwachsen klang.<\/p>\n\n\n\n

Jetzt verstehe ich es besser. In meinen letzten Positionen habe ich mit genug Leuten zusammengearbeitet, die erwarteten, dass der Plan ein f\u00fcr alle Mal feststeht, als w\u00e4re eine Entscheidung eine notariell beglaubigte Wahrheit und nicht die beste Antwort, die wir in dieser Woche hatten. Wenn sich der Plan \u00e4nderte, behandelten sie die \u00c4nderung nicht als neue Information. Sie behandelten es wie Verrat: Jemand hatte die Torpfosten verschoben! Jemand hatte beim ersten Mal nicht gr\u00fcndlich genug nachgedacht! Jemand hatte die Abmachung gebrochen!<\/p>\n\n\n\n

Manchmal ist diese Reaktion berechtigt: Ambiguit\u00e4t kann zu einem Versteck f\u00fcr schwache F\u00fchrung werden, und kein Team sollte in einer Nebelmaschine leben m\u00fcssen, nur weil niemand eine Entscheidung treffen will. <\/p>\n\n\n\n

Aber es gibt noch eine andere Art von Ambiguit\u00e4t, die nicht durch Faulheit verursacht wird. Sie entsteht, weil die Realit\u00e4t sp\u00e4t eintrifft, was oft der Fall ist, wenn man etwas Neues erschafft.<\/p>\n\n\n\n

Lernen, was der Satz eigentlich bedeutet<\/h2>\n\n\n\n

Mit Ambiguit\u00e4t umzugehen bedeutet nicht, Chaos zu genie\u00dfen. Es bedeutet, n\u00fctzlich zu bleiben, wenn die Arbeit noch nicht klar definiert ist. Das ist eine andere F\u00e4higkeit als das Befolgen von Anweisungen, und es ist schwieriger als es klingt, weil Ver\u00e4nderungen dazu neigen, dass sich Erwachsene peinlich ber\u00fchrt f\u00fchlen. Eine Person kann Unsicherheit in der Theorie akzeptieren und trotzdem w\u00fctend werden, sobald sich ein Design \u00e4ndert, eine Kundenerkenntnis unangenehm ausf\u00e4llt oder eine technische Einschr\u00e4nkung das Team zwingt, die Route neu zu planen.<\/p>\n\n\n\n

Das ist wahrscheinlich der Grund, warum Arbeitgeber immer wieder zu W\u00f6rtern wie Anpassungsf\u00e4higkeit, Flexibilit\u00e4t und Agilit\u00e4t greifen. Im Future of Jobs Report 2025 des Weltwirtschaftsforums<\/a>, gaben Arbeitgeber an, dass sie erwarten, dass sich 39% der Kernkompetenzen von Arbeitnehmern bis 2030 \u00e4ndern werden, und Resilienz, Flexibilit\u00e4t und Agilit\u00e4t standen ganz oben auf der Liste der F\u00e4higkeiten, die sie f\u00fcr wichtig hielten. NACE fand etwas \u00c4hnliches in seinem Job Outlook 2025<\/a>: Mehr als zwei Drittel der befragten Arbeitgeber gaben an, dass sie bei Kandidaten nach Flexibilit\u00e4t oder Anpassungsf\u00e4higkeit suchen. Die Menschen, die auch dann noch gut arbeiten, wenn sich der Boden unter ihnen bewegt, sind wertvoll, weil sie nicht jede neue Tatsache in ein teamweites emotionales Ereignis verwandeln.<\/p>\n\n\n\n

Zusehen, wie Gewissheit zur Falle wird<\/h2>\n\n\n\n

Eine Sache, die mich \u00fcberrascht hat, ist, wie viele Menschen einen ge\u00e4nderten Plan als Beweis daf\u00fcr ansehen, dass der urspr\u00fcngliche Plan eine T\u00e4uschung war. Ich verstehe das: Ein Plan verschafft den Leuten Erleichterung. Er l\u00e4sst alle f\u00fcr eine Weile aufh\u00f6ren zu diskutieren und mit der Arbeit beginnen. Er gibt der Woche Struktur. Er l\u00e4sst ein Team sagen: \u201eOkay, das ist es, was wir bauen.\u201c<\/p>\n\n\n\n

Aber ein Plan ist immer noch nur eine Wette, die mit den zu diesem Zeitpunkt verf\u00fcgbaren Informationen abgeschlossen wurde. Je origineller das ist, was Sie zu erschaffen versuchen, desto wahrscheinlicher ist es, dass ein Teil Ihrer anf\u00e4nglichen Zuversicht nur geliehen ist. Sie denken, Sie wissen, was der Kunde braucht, bis Sie ihm etwas vorlegen. Sie denken, der technische Weg ist sauber, bis jemand die Codebasis \u00f6ffnet und die alte Annahme findet, die sich unter den Dielen versteckt. Sie denken, das Ziel ist offensichtlich, bis drei vern\u00fcnftige Personen drei verschiedene Versionen von Erfolg erkl\u00e4ren.<\/p>\n\n\n\n

Der PMI Pulse of the Profession 2026<\/a> -Bericht ist hier n\u00fctzlich, weil er dies als gew\u00f6hnlichen Projektalltag und nicht als besondere Fehlfunktion benennt. PMI fand heraus, dass 97% der Projektprofis im vergangenen Jahr mindestens ein komplexes Projekt geleitet haben, und mehr als die H\u00e4lfte bezeichnete diese Projekte als signifikant komplex. Der Bericht beschreibt, dass Komplexit\u00e4t auf sehr normale Weise auftritt: Anforderungen verschieben sich mittendrin, Stakeholder sind sich \u00fcber Priorit\u00e4ten uneinig, Anbieter haben Schwierigkeiten bei der Integration, Sponsoren lenken ihre Aufmerksamkeit woanders hin.<\/p>\n\n\n\n

Das klingt nach der meisten echten Arbeit, die ich gesehen habe. Es kann chaotisch sein, ohne ein Skandal zu sein. Der Skandal ist, wenn ein Team sich weigert zu lernen, weil Lernen erfordern w\u00fcrde, zuzugeben, dass die Gewissheit von gestern unvollst\u00e4ndig war.<\/p>\n\n\n\n

Bauen, bevor die Antwort da ist<\/h2>\n\n\n\n

Das wird in kleinen Teams sehr deutlich, besonders wenn Leute anfangen, in Code zu bauen, bevor die grundlegenden Fragen beantwortet wurden. Code l\u00e4sst eine Vermutung real erscheinen. Ein Prototyp hat Bildschirme. Ein Ticket hat einen Eigent\u00fcmer. Ein Pull Request hat Gewicht. Sobald die Sache existiert, selbst in einer groben Form, fangen die Leute an, sie als Beweis daf\u00fcr zu behandeln, dass die zugrunde liegende Frage bereits gekl\u00e4rt ist.<\/p>\n\n\n\n

Aber Code kann nur beweisen, dass etwas gebaut werden kann. Er kann nicht beweisen, dass die Sache das Ziel erreicht. Ein Team kann Wochen damit verbringen, die falsche Idee zunehmend ausgefeilt wirken zu lassen, und jede Woche des Feinschliffs macht es ein wenig schmerzhafter zu fragen, ob die Idee \u00fcberhaupt existieren sollte.<\/p>\n\n\n\n

Das ist nicht nur ein philosophisches Anliegen. CB Insights analysierte in seinem Startup-Failure-Bericht 2026 Schlie\u00dfungen von VC-finanzierten Unternehmen und stellte fest, dass ein schlechter Product-Market-Fit bei 43% der Unternehmen auftrat, bei denen Fehlergr\u00fcnde identifiziert werden konnten, direkt hinter dem Ausgehen von Kapital. Ihr Punkt war nicht, dass Gr\u00fcnder sich niemals schnell bewegen sollten. Es war, dass das Ausgehen von Geld oft das Ende der Geschichte ist, w\u00e4hrend das tiefere Problem fr\u00fcher begann: Das Unternehmen fand nie einen Markt, der wirklich wollte, was es baute.<\/p>\n\n\n\n

Ich habe eine kleinere Version davon in der Produktarbeit gesp\u00fcrt. Ein Team kann ewig \u00fcber den besten Weg streiten, ein Feature zu bauen, bevor es die grundlegendere Frage beantwortet hat: Wenn dies genau wie entworfen funktioniert, l\u00f6st es dann tats\u00e4chlich das Problem, um das wir uns angeblich k\u00fcmmern wollten? Wenn diese Frage noch offen ist, dann ist Ver\u00e4nderung keine St\u00f6rung der Arbeit. Ver\u00e4nderung ist die Arbeit, die versucht, ehrlich zu werden.<\/p>\n\n\n\n

Ordnung halten ohne etwas vorzut\u00e4uschen<\/h2>\n\n\n\n

Nichts davon entschuldigt schlampige Kommunikation. Tats\u00e4chlich macht Ambiguit\u00e4t Kommunikation wichtiger, nicht unwichtiger. Wenn die Arbeit ungewiss ist, brauchen die Menschen eine klare aktuelle Richtung, eine Aufzeichnung dessen, was entschieden wurde, und ein gemeinsames Verst\u00e4ndnis dar\u00fcber, welche Annahmen sich \u00e4ndern k\u00f6nnten. Sie m\u00fcssen wissen, ob eine Entscheidung endg\u00fcltig, vorl\u00e4ufig oder einfach der beste Weg f\u00fcr die n\u00e4chsten zwei Wochen ist.<\/p>\n\n\n\n

Die agile Welt sagt schon lange eine Version davon. Das Agile Manifest<\/a> sch\u00e4tzt das Reagieren auf Ver\u00e4nderungen mehr als das Befolgen eines Plans, erkennt aber dennoch den Wert des Plans an. Der Scrum Guide<\/a> beschreibt Arbeit als empirisch: Teams \u00fcberpr\u00fcfen, was passiert ist, passen sich an und wiederholen es. Das ist der Teil, den die Leute oft abflachen. Agil bedeutet nicht, ziellos umherzuwandern. Es bedeutet, genug Struktur zu schaffen, damit das Lernen die Arbeit ver\u00e4ndern kann, bevor die Arbeit zu teuer wird, um sie zu \u00e4ndern.<\/p>\n\n\n\n

Googles Forschung zur Teameffektivit\u00e4t weist von der menschlichen Seite in die gleiche Richtung. In seiner Arbeit an Projekt Aristoteles<\/a>, fand Google heraus, dass effektive Teams weniger davon abhingen, wer im Team war, sondern mehr davon, wie das Team zusammenarbeitete, wobei psychologische Sicherheit unter den identifizierten Dynamiken an erster Stelle stand. Menschen m\u00fcssen in der Lage sein, grundlegende Fragen zu stellen, Fehler zuzugeben und neue Ideen anzubieten, ohne daf\u00fcr bestraft zu werden, dass sie unwissend oder st\u00f6rend klingen.<\/p>\n\n\n\n

Das ist wichtig, weil Ambiguit\u00e4t die Menschen ohnehin schon defensiv macht. Wenn der Raum Fragen bestraft, werden sich die Menschen sch\u00fctzen, indem sie so tun, als w\u00e4re der Plan klarer, als er ist. Dann bekommt das Team die schlechteste Version beider Welten: falsche Gewissheit am Anfang und eine teure \u00dcberraschung am Ende.<\/p>\n\n\n\n

N\u00fctzlich bleiben in der chaotischen Mitte<\/h2>\n\n\n\n

Ich finde es immer noch nervig, mit Leuten zusammenzuarbeiten, die zusammenbrechen, wann immer sich die Realit\u00e4t \u00e4ndert. Ich spreche nicht von Leuten, die nach Klarheit fragen, schlechte Entscheidungen in Frage stellen oder F\u00fchrungskr\u00e4fte dazu dr\u00e4ngen, besser zu kommunizieren. Diese Leute tun dem Team oft einen Gefallen. Ich spreche von der Person, die jede Anpassung als Beleidigung empfindet und dann das Team dazu bringt, ihre Entt\u00e4uschung zus\u00e4tzlich zum urspr\u00fcnglichen Problem zu bew\u00e4ltigen.<\/p>\n\n\n\n

Diese Art von Reaktion ist st\u00f6rend. Sie kommt mir auch unreif vor, nicht weil reife Menschen Unsicherheit genie\u00dfen, sondern weil reife Menschen Unbehagen von Ungerechtigkeit unterscheiden k\u00f6nnen. Sie k\u00f6nnen sagen: \u201eMir gef\u00e4llt nicht, dass sich das ge\u00e4ndert hat\u201c, ohne so zu tun, als ob die Ver\u00e4nderung selbst beweist, dass jemand etwas falsch gemacht hat.<\/p>\n\n\n\n

Kommunikation ist schon schwer, wenn alle gut darin sind. Meistens sind nicht alle gut darin. Menschen h\u00f6ren im selben Meeting unterschiedliche Dinge. Sie f\u00fcllen L\u00fccken mit privaten Annahmen. Sie nicken zustimmend, wenn sie noch eine Frage stellen sollten. F\u00fcgen Sie ein neues Produkt, ein kleines Team, technische Einschr\u00e4nkungen, Kundenunsicherheit und eine Deadline hinzu, und das Ganze wird schwieriger, als jede Stellenbeschreibung h\u00f6flich zugeben kann.<\/p>\n\n\n\n

Das ist der Teil, von dem ich w\u00fcnschte, dass ihn mehr Menschen verstehen w\u00fcrden. Etwas Neues in die Welt zu bringen, ist schwierig und schmerzhaft. Man kann die Verwirrung reduzieren. Man kann bessere Notizen schreiben, sauberere Entscheidungen treffen, bessere Erwartungen setzen und Annahmen fr\u00fcher testen. Man kann die chaotische Mitte nicht vollst\u00e4ndig beseitigen.<\/p>\n\n\n\n

Irgendwann wird die Karte versagen. Das Team wird etwas sp\u00e4t lernen. Die Entscheidung, die am Montag noch Sinn ergab, wird am Donnerstag schw\u00e4cher aussehen. Wenn das passiert, ist die n\u00fctzliche Person nicht diejenige, die darauf besteht, dass der erste Plan den Kontakt mit der Realit\u00e4t h\u00e4tte \u00fcberleben sollen. Die n\u00fctzliche Person hilft dem Team zu erkennen, was sich ge\u00e4ndert hat, zu entscheiden, was noch wichtig ist, und sich weiterzubewegen, ohne die Unsicherheit in ein zweites Projekt zu verwandeln.<\/p>\n\n\n\n

Quellen<\/h2>\n\n\n\n