Zusammenarbeit ist nutzlos
(newsletter.posthog.com)- „Allein kommt man schnell voran, gemeinsam kommt man weit“ ist ein Sprichwort, das Startups zugrunde richten kann
- Effiziente Zusammenarbeit sollte höchstens dem Beistand eines Navigationssystems beim Fahren entsprechen, doch die meisten Unternehmen verlieren durch zu viel Feedback und verteilte Rollen an Tempo
- PostHog betont unter dem Wert „You’re the Driver“ Autonomie und hohe Ownership und minimiert unnötige Zusammenarbeit
- Als Ursachen übermäßiger Zusammenarbeit werden der Wunsch zu helfen, inklusive Kultur, unklare Feedback-Anfragen, inflationäres „let’s discuss“ und Verantwortungsvermeidung genannt
- Die Lösung ist ein praktischer Ansatz: sofortiges Ausliefern priorisieren, Verantwortliche klar benennen, nur die nötigen Personen um Feedback bitten, Feedback nach dem Launch und unnötige Zusammenarbeit sofort unterbinden
Die Falle der Zusammenarbeit
- „Wenn du schnell gehen willst, geh allein; wenn du weit gehen willst, geh gemeinsam“ ist ein Satz, der ein Unternehmen langsam tötet
- Er ist eine Falle, die übermäßige Zusammenarbeit rechtfertigt
- Sinnvolle Zusammenarbeit entspricht höchstens einer Wegweisung oder dem Hinweis auf die Umgebung während der Fahrt
- Doch die meisten Organisationen verfallen in ineffiziente Zusammenarbeit, bei der man sich bildlich gesprochen ständig das Lenkrad aus der Hand nimmt
- Passendes Feedback hilft, das Ziel schneller zu erreichen, aber zu viel Feedback verlangsamt und erhöht das Risiko, das gewünschte Ziel gar nicht zu erreichen
Das Paradox des Feedbacks: Wer gut Feedback gibt, weiß auch, wann man keines geben sollte
- Auch bei PostHog nahm mit dem Wachstum Zusammenarbeit zu, die keinen Mehrwert schafft oder im Verhältnis zum Zeitaufwand zu wenig Wert liefert
- In einem kürzlichen All-Hands-Meeting war das Thema: „Zusammenarbeit ist schlecht“
- „You’re the driver“ ist ein zentraler Wert von PostHog: „Wir stellen großartige Leute ein und stehen ihnen nicht im Weg“
- Keine Deadlines, minimale Abstimmung, Manager geben keine Anweisungen
- Im Gegenzug wird extrem hohe Ownership und die Fähigkeit, allein sehr viel zu schaffen, erwartet
- Marketer deployen Code, Vertriebsmitarbeitende beantworten technische Fragen ohne Rückversicherung, Product Engineers arbeiten über den gesamten Stack hinweg
- Fast immer gibt es jemanden, der etwas besser kann als man selbst, und die Versuchung zur Zusammenarbeit ist groß; Zusammenarbeit zwingt den Driver jedoch dazu, langsamer zu werden und Hintergrund, Kontext und Gedanken zu erklären
- Diese Tendenz zeigt sich in einigen typischen Formulierungen
- „Ich frage mich, was X dazu denkt“
- „Ich würde gern Ys Meinung hören“
- „Du solltest mit Z daran arbeiten“
- Das führt manchmal zu wertvollen Einsichten, verlangsamt aber immer den Driver
- Es untergräbt Motivation, Selbstvertrauen und Effizienz des Drivers und führt am Ende zu weniger Releases
Wenn Zusammenarbeit schlecht ist, warum tun es die Leute dann?
- Alle tragen dazu bei
- Menschen wollen helfen: Wenn jemand etwas in Arbeit auf Slack teilt, haben andere wegen der Feedback-Kultur das Gefühl, dass sie Feedback geben sollten
- Umgekehrt wirkt es manchmal nicht inklusiv, gezielt einzelne Personen um Feedback zu bitten, daher tut man es nicht – obwohl es in Wirklichkeit hilfreich wäre
- Oft ist nicht konkret genug, welches Feedback gebraucht wird: So entsteht Raum für unnötige Einmischung. Eine Diskussion über den Bau einer bestimmten Funktion kann sich zu einer Neubewertung der gesamten Produkt-Roadmap ausweiten
- Wenn jemand eine gute Idee hat, lautet die Standardreaktion nicht „Mach das“, sondern „Lass uns darüber sprechen“
- Als Beleg wird auf Slack unzählige Male „let's discuss“ geschrieben
- Das verschiebt den Fokus von Ausführung auf Diskussion
- Menschen sind zu beschäftigt, um selbst umzusetzen, oder zu bequem und wollen einfach nur darüber reden
- PR → Issue/RFC → Slack (derzeit findet das meiste hier statt) → „lass uns darüber sprechen“
- Es ist nicht klar, wem etwas gehört (oder niemand will das Diskutierte besitzen)
- So frustrierend es ist: Manchmal kann eine einzelne Person nicht von Anfang bis Ende in ausreichend hoher Qualität shippen, und man kann nicht einfach shippen und iterieren
- Kaputten Code kann man reparieren, aber einen Newsletter kann man nicht noch einmal versenden
Wie man Zusammenarbeit zerschlägt (und schneller und weiter kommt)
- Wenn Zusammenarbeit der Feind ist, wie besiegt man sie?
- Standardmäßig Ausführung priorisieren: Pull request > Issue > Slack-Nachricht
- Wenn Zusammenarbeit ausufert, klar Grenzen ziehen mit: „Du bist der Driver, entscheide du“
- Beim Feedback konkret Personen taggen und genau sagen, was man von ihnen will, statt es vage in den Raum zu werfen
- Lieber Feedback nach dem Launch (vor der nächsten Iteration) als Reviews vor dem Launch: Vorab-Feedback kann sich in einen quasiformalen Freigabeprozess verwandeln
- Führungskräfte sollten sich mit Feedback zurückhalten und die Haltung „you can just do stuff“ beibehalten
- Jede Person ist ein „informed captain“
- Feedback kann man anhören, aber die Entscheidung trifft man selbst
Fazit
- Nicht jede Zusammenarbeit lässt sich ausrotten, und manche Zusammenarbeit ist nützlich (diesen Newsletter haben Ian und Andy redigiert)
- Dennoch braucht es eine grundsätzliche Anstrengung, Zusammenarbeit zu reduzieren
- Wenn man nicht aktiv versucht, Zusammenarbeit zu verringern, arbeitet man sehr wahrscheinlich standardmäßig zu viel zusammen
- Weil Zusammenarbeit das Tempo grundsätzlich senkt,
kommt man mit weniger Zusammenarbeit weiter und schneller
- Verfasst von Charles Cook, der Sprudelwasser hasst (weil Blasen zu kooperativ sind)
12 Kommentare
Zusammenzuarbeiten ist richtig.
Wenn diese Person ausfällt (Tod, Krankheit, Urlaub), reagieren Sie dann nicht auf den Kunden?
Ich arbeite in einem so kleinen Unternehmen, dass ich der einzige Mitarbeiter bin. Deshalb mache ich die Wartung allein und entwickle auch allein ... Nach so langer Zeit in diesem Zustand kommt bei mir auch das Gefühl auf, mit anderen Menschen zusammenarbeiten zu wollen. Allein zu arbeiten ist einfach zu einsam ...
Das ist ein ziemlich provokanter Artikel.
Ist die Persönlichkeit des Autors vielleicht so stark ausgeprägt, dass er nicht gut mit anderen zusammenarbeiten kann?
Um eine einzelne Funktion zu entwickeln,
braucht man in der Regel zwingend Rollen wie Designer, Planung, Projektmanager, Frontend, Backend, QA usw.
Es wirkt, als würde hier eine überzogene Behauptung aufgestellt, um ein Problem sichtbar zu machen, das man selbst wahrnimmt.
Mit Zusammenarbeit ist doch wohl kaum gemeint, dass sie nach Art einer Agora abläuft.
Allerdings sind diese beiden Punkte definitiv problematisch: das inflationäre Verwenden von „let’s discuss“ und das Abschieben von Verantwortung.
Oft entsteht das aber vor allem deshalb, weil es an Führungskräften oder Verantwortlichen mit echten Insights fehlt.
Genau dafür forscht man ja, entwickelt Menschen weiter, stellt neue Leute ein oder kauft Lösungen ein.
Wenn man ein Team nur aus Mitgliedern zusammenstellt, die gut gehorchen, wird das eher noch verstärkt.
Ich glaube nicht, dass das ein Problem ist, das durch Zusammenarbeit oder durch Alleinarbeit entsteht.
Bitte beachtet, dass Posthog immer Texte mit einer so starken Wortwahl schreibt.
Weil der Ton so scharf ist, wirken manche Artikel gelegentlich so, als würden sie etwas am Thema vorbeigehen.
(Sprudelwasser ist doch großartig!!!)
Ist Sprudelwasser nicht so etwas wie eine Highball-Startrampe? räusper
Hacker-News-Kommentare
Es gab den Rat, jedes Mal, wenn Zusammenarbeit aufkommt, zu sagen: „Zu viele Leute, X ist der Driver, also entscheide du.“
Wenn ein Manager aber sagt „Entscheide du“, dann nicht zu Meetings kommt und später mit „Ich hätte das anders gemacht“ Änderungen verlangt, kündigen Mitarbeiter am Ende.
Der Manager meines Managers hat ständig so gesprochen, und wenn ich ein PR eingereicht habe, hat er am Ende doch ein komplettes Redesign verlangt.
Irgendwann hatte ich Angst vor der Arbeit selbst, weil ich wusste, dass jedes Projekt am Ende von vorn neu geschrieben werden musste.
Wenn ein Vorgesetzter seine Entscheidungen zu oft umwirft, schieben Teammitglieder absichtlich jede Entscheidung an ihn ab.
Am Ende erstickt der Chef an seinem eigenen Kontrollbedürfnis.
Im Kontext von „Manager sollen keine Anweisungen geben“ bleibt er aber konsistent.
Der Grund waren endlose Pixel-Anpassungen, Layout-Änderungen und Vorschläge für komplette Stack-Reworks.
Ich denke, der Kern des Problems ist nicht Zusammenarbeit, sondern die Entscheidungsstruktur.
Feedback ist eine Chance zum Lernen, aber wenn unklar ist, wer die endgültige Entscheidung trifft, wird alles langsamer.
Für schnelle Entscheidungen muss der Entscheidungsträger klar benannt sein, und man sollte davon ausgehen, dass die meisten Entscheidungen reversibel sind.
Wenn Zusammenarbeit abnimmt, gibt es auch weniger Gelegenheiten zu lernen.
Entscheidungsträger müssen klar benannt sein, sollten aber Feedback aufmerksam anhören.
Außerdem ist es besser, reversible Entscheidungen schnell zu treffen.
Man sagt zwar, Zusammenarbeit verlangsame das Tempo, aber tatsächlich steigt in diesem Prozess oft die Qualität.
Manche widersprechen nur des Widerspruchs willen und versuchen am Ende, die Ownership der Idee an sich zu ziehen.
Selbst wenn der finale Entscheider klar ist, läuft es bei zu schwacher Position am Ende auf Mehrheitskonsens hinaus.
Wenn sie „Änderungen anfordern“ gesetzt haben, mussten sich alle daran halten, und am Ende wurde die Code-Qualität schlechter.
Ich denke, es ist viel besser, gute Leute einzustellen und Entscheidungsbefugnis zu delegieren.
Sie sollten Richtung, Prioritäten und Framework vorgeben, damit das Team selbst urteilen kann.
Der Abneigung gegen Sprudelwasser des Autors stimme ich zwar nicht zu, aber ich finde es gut, dass das Problem von Zusammenarbeit offen angesprochen wird.
In mehreren Unternehmen habe ich bei Code-Reviews wegen kleinlicher Stilhinweise dreimal so viel Zeit verloren wie für die eigentliche Implementierung.
Meine Haltung ist: „Wenn es dir nicht gefällt, ändere es selbst und sag mir dann Bescheid.“
Dazu wurde auch ein passendes Video geteilt.
Im Code-Review darüber zu diskutieren, ist viel zu spät.
Das Problem sind Leute, die sich nicht am Stil des umgebenden Codes orientieren.
Das sollte durch Linter oder durch Kultur gelöst werden.
Ein Feature, das ohne Zusammenarbeit allein gebaut wurde, ist bei der Wartung ein großes Risiko.
Wenn das System ausfällt, sobald ich nicht da bin, zeigt sich darin das Problem fehlender Zusammenarbeit.
Der Autor betont zwar einen Bias zum Handeln, aber wenn man Zusammenarbeit ausschließt, entstehen Silos und Selbstüberschätzung.
Eine Slack-Kultur nach dem Muster „Ich habe vor, X zu machen, gibt es starke Einwände?“ war sehr effektiv.
So kommen Dinge tatsächlich voran.
Ich habe früher im Zuge von Interviews für ein Buch über GitHub erfahren, dass manche Teams vor dem Schreiben von Code ein leeres PR anlegen und sich erst das Design absegnen lassen.
Das ist keine Zusammenarbeit während der Umsetzung, sondern Zusammenarbeit in der Planungsphase.
Mit guter schriftlicher Kommunikation und gutem Austausch kann Zusammenarbeit schnell und effektiv sein.
Im Zeitalter von AI wird diese Fähigkeit noch wichtiger werden.
Ohne Meetings und geteilte Updates ist Leistung nicht sichtbar.
Wenn man Probleme verhindert, merkt es niemand, und deshalb gibt es sogar Kulturen, in denen man Probleme absichtlich erst entstehen lässt.
Nur mit Planung kann ich mir die Implementierung schwer vorstellen.
Wie im letzten Satz des Artikels: „Gute Zusammenarbeit existiert.“
Der Titel ist Clickbait, aber PostHog ist für genau diesen Stil ohnehin bekannt.
Das bringt einen dazu, das Meme „Zusammenarbeit“ kritischer zu betrachten.
Dieser Artikel ist ein falsches Gedankenexperiment.
Das Problem ist nicht Zusammenarbeit, sondern das Fehlen von Entscheidungsbefugnis.
Eine Person muss klar entscheiden, und je weiter diese Befugnis nach unten delegiert wird, desto schneller wird alles.
Solche Texte verzerren Sprache und haben die toxische Wirkung, notwendige Konzepte zu entwerten.
Auch eine Kultur, in der bei jedem Hindernis sofort gesagt wird „Frag Bob“, ist problematisch.
Kurzfristig geht es schneller, langfristig führt es aber zu verpassten Lernchancen und Überlastung.
Ich mag es, wenn Kollegen Interesse an meiner Arbeit zeigen.
„Mach einfach, wie du meinst“ bedeutet in Wirklichkeit oft „Ist mir egal“.
Das Problem ist nicht Zusammenarbeit, sondern ineffiziente Zusammenarbeit.
PRs haben einen konkreten Output, dadurch wird die Diskussion klarer.
Ich habe den Eindruck, dass Zusammenarbeit mit zwei Personen am besten funktioniert.
Zwei Menschen können die Codebase gemeinsam verstehen und gegenseitig ihre PRs reviewen.
Aber ab drei Personen explodiert die kombinatorische Komplexität.
Deshalb würde ich Projekte gern als Zweierteam-Struktur aufbauen.
Referenzlink
Wie in der Metapher des Artikels ist F1-Rennsport ein extrem kollaborativer Sport.
Der Fahrer steht während des gesamten Rennens mit dem Coach in Funkkontakt.
Ich frage mich, ob es in Software ein ähnliches Beispiel gibt.
Die Kommentare sind seltsam. Wenn man sich die Zusammenfassung des Artikels ansieht, scheint es nicht darum zu gehen, allein zu arbeiten oder dass man keine Teammitglieder braucht, sondern eher darum, übermäßige Zusammenarbeit im Team zu reduzieren.
Ich stimme zu.
Das wirkt wie das Ergebnis aus einem reißerischen Titel und einem Leser, der den Text nicht sorgfältig gelesen hat.
Nicht nur bei solchen Artikeln, sondern sogar auf YouTube gibt es viele Leute, die Kommentare schreiben, nachdem sie nur den Titel gesehen haben.
Wenn man etwas Neues beginnt, kann man aus dem Wunsch nach zu viel Sicherheit übermäßig viele Menschen in der Umgebung um Reviews bitten. Tatsächlich kennen die Leute oder das Team um einen herum das Thema vielleicht gar nicht gut genug, um gutes Feedback zu geben. Letztlich scheint die Aussage zu sein, dass man insgesamt Zeit sparen kann, wenn man erst einmal etwas baut und dann, selbst wenn es in die falsche Richtung geht, anschließend konkretes Feedback erhält und weiterarbeitet.