#235 Zwei Pizzen, ein Team und der volle Geschirrspüler im Kopf

Heute geht’s um zwei Pizzen, ein Team – und warum dein Kopf manchmal wie ein überladener Geschirrspüler klingt. Du erfährst, warum Amazons berühmte Two-Pizza-Rule mehr ist als ein Meme und wie Teamgröße, Kommunikation und Tools deinen Cognitive Load heimlich in die Höhe treiben.

Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Anregungen, Gedanken, Themen und Wünsche

Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …

EngKiosk Community: https://engineeringkiosk.dev/join-discord
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Instagram: https://www.instagram.com/engineeringkiosk/

Unterstütze den Engineering Kiosk

Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer

Buy us a coffee: https://engineeringkiosk.dev/kaffee

Sprungmarken

(00:00:00) Zwei Pizzen und ein Geschirrspüler im Kopf

Hosts

Wolfgang Gassler (https://gassler.dev)
Andy Grunwald (https://andygrunwald.com/)

Community

Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:06 - 00:00:31)

Du bist hier im Engineering Kiosk gelandet und zwar im Engineering Kiosk Adventskalender. Leider hat dieser Kalender nichts mit Schokolade zu tun. Doof finde ich auch. Na gut, machst du nix. Als Alternative bieten wir ein wenig Wissen an. Ein Thema kurz und knapp in ein paar Minuten und das Ganze bis Heiligabend. Präsentiert von Knecht Ruprecht und Krampus. Ach, scheiße falsche Zeile. Präsentiert von Wolfi. Los geht's.

Wolfi Gassler (00:00:31 - 00:13:11)

Viel Spaß. Weihnachten ist ja diese ruhige, besinnliche Zeit gefühlt. Zwar irgendwie nicht gerade, aber es hat vielleicht auch damit zu tun, dass wir gerade jeden Tag so eine Episode releasen müssen. Aber auf jeden Fall geht es ja bei Weihnachten auch ganz viel ums Essen. Pizza ist jetzt vielleicht nicht so weihnachtlich, wobei, keine Ahnung, Pizza Hawaii, da denke ich irgendwie an Weihnachten, aber das ist eine andere Diskussion. Aber vielleicht hast du ja schon mal den Satz gehört, kein Team sollte mehr als zwei Pizzen zum Mittagessen brauchen. Das Ganze ist entstanden von Jeff Bezos von Amazon, der hat diesen Spruch so richtig bekannt gemacht. Die Theorie dahinter gibt es natürlich schon lang. Vor allem man muss sich da so amerikanische Pizzen vorstellen, weil die reichen für vier Personen. Und wenn eben zwei Pizzen für ein Team ausreichend sind, dann heißt es, man hat ein effizientes Team mit ungefähr acht Leuten und kann dann eben auch die Agilität leben, wenn man diese Größe hat. Die ganze Theorie dahinter ist natürlich schon viel länger, ist auch bekannt unter dem Ringelmann Effekt. Der hat schon um die ein tausend neun hundert zwanzig herum dazu publiziert. Das Ganze ist dann erst richtig so in den er Jahren rezipiert worden und in die Breite getragen worden. Und was Ringelmann eigentlich beschrieben hat, ist, dass der Koordinationsaufwand, also der Overhead mit der Größe des Teams auch dementsprechend zunimmt. Das heißt, das Ziel ist, dass man die Koordination minimiert und die Agilität im Team beibehält. Warum ist das ein großes Problem? Ich glaube, das kann sich jeder vorstellen in der Kommunikation. Je mehr Leute es gibt, desto mehr Kommunikationsebenen gibt es auch. Das Ganze wächst exponentiell an. Diese Formel, die dahinter liegt, kennen vielleicht einige. Wenn man eben einem Meeting sitzt mit vier Personen zum Beispiel und man überlegt sich, wie viel Kommunikationskanäle kann ich zwischen allen Personen aufbauen, dann ist es n eins, zwei Das heißt, bei vier Personen vier, drei dividiert durch zwei sind sechs solche Ebenen, ist noch überschaubar. Sechs Kommunikationsebenen, eins zu eins Verbindungen, bei zwölf Leuten sind es schon sechs und sechzigste Und da sieht man schon, warum die Kommunikation bzw. Der Overhead exponentiell ansteigt. Und das kennen wahrscheinlich auch viele. Umso größer die Gruppe, umso größer das Team. Irgendwann gibt es so einen Punkt, da verliert man sich und da hat man keinen Überblick mehr. Also keine Ahnung, ob ihr schon mal in irgendeinem Meeting mit zwölf Leuten gesessen seid. Die zwölf Leute zu koordinieren in einem Meeting oder da einen sinnvollen Outcome zu haben, das endet meist im Chaos, außer man hat einen sehr guten Manager oder Moderatorin, die darauf einwirkt. Aber es ist nicht nur in dem Meeting, sondern auch im Alltag. Also dieser Cognitive Float oder diese mentale Last im Team, wenn das Team größer ist, macht die tägliche Arbeit einfach komplexer und komplizierter. Man denkt nur an die ganzen Meinungen, Aufgaben, Interaktionen, die ganzen Entscheidungen, die man fällen muss mit den ganzen vielen Leuten. Kommunikationsoberhard natürlich, aber auch der ganze Informationsfluss ist viel schwieriger. Wenn man zwölf Leute hat und man muss die up to date halten, ist es super schwierig. Und ich kenne das auch von Firmen, mit denen ich zusammenarbeite, gerade im Start up Wesen, Wenn man so diese zehn zwölf Personen Grenze erreicht, das heißt, man hat dann wirklich Entwickler innen Teams von acht Personen, zum Beispiel, weil es noch zwei Founder gibt und zwei Sales Leute, die jetzt nicht so klassisch im Core Team mit dabei sind, dann ist es genau diese Grenze, ab dem sich Leute beschweren. Ich habe nicht mehr alle Informationen, ich werde nicht mehr informiert. Und genau da sieht man dann auch die Grenze, weil der Informationsfluss einfach nicht mehr gegeben ist. Zusätzlich zu dem ganzen Cognitive Float, der mentalen Last, gibt es auch noch ein anderes Phänomen mit größeren Gruppen. Und zwar ist es Social Laughing oder soziales Faulenzen. Auf Deutsch ist auch der Ringelmann Effekt, der besagt, dass in kleineren Teams der Beitrag jedes Einzelnen einfach sichtbarer ist und viel entscheidender ist. Man hat auch die Accountability, also die Verantwortlichkeit gegenüber ein Thema. Und dieses Problem kennt ihr vielleicht auch, Ich nenne es immer gerne das Geschirrspüler Problem. Also wie ich noch an der Uni zum Beispiel gearbeitet habe mit achtzig Leuten, da gab es einen Geschirrspüler und da gab es keine offiziellen Regeln, aber Geschirrspüler muss man einfach einschalten und vor allem ausräumen. Und das Problem war, dass es einfach wirklich nur ein paar einzelne gemacht haben. Man geht einfach in dieser Maße unter und und man fühlt sich nicht mehr verantwortlich für sowas wie den Geschirrspüler. Und das ist der Ringelmann Effekt oder dieses soziale Faulenzen. Jetzt stellt sich natürlich die Wie kann ich jetzt trotzdem Teams skalieren oder wenn ich an diese Grenze komme, wenn zwei Pizzen nicht mehr ausreichen? Ja, ganz klar, man bildet ein zweites Team, man splittet. Das ist gerade für kleine Start ups super schwer natürlich im ersten Moment, weil wo ziehe ich diese Trennlinie? Bisher hat ja alles mit der Chaoskommunikation funktioniert und jetzt muss man plötzlich zwei Teams aufbauen. Und da ist es ganz wichtig, dass man wirklich zwei unabhängige Teams formt, die möglichst wenig Abhängigkeiten haben und End to End Responsibility, also wirklich verantwortlich sind für ein Feature, zum Beispiel von ganz vorne von der UI bis ganz hinten zur Datenbank. Oder man hat ein internes Produkt, zum Beispiel man übernimmt die ganze CI CT Pipeline und bietet eine Plattform für die Teams an. Also es muss klare Schnittstellen geben, wo die Teams dann die Übergabe haben an das nächste Team, um intern dann wieder möglichst frei zu sein und selbstständig agieren zu können. Es gibt ja auch Conways Law, das ist ein sehr bekanntes Prinzip, dass sich die Organisationsstruktur und die Softwarearchitektur eigentlich immer angleichen bzw. Dass die Teams eigentlich so agieren müssen, wie sie organisiert sind. Und wenn man da an Microservices denkt oder an Monolithen, es wird dann nötig sein, dass man irgendwo Schnittstellen bildet, das Ganze schneidet und dann jeweils auf die Teams aufteilt, so wie diese eben auch organisiert sind, damit die möglichst eigenständig arbeiten können und möglichst wenig Abhängigkeiten haben. Und ich würde jetzt fast sagen, das hat sich eigentlich schon ein bisschen so in der Branche herumgesprochen, diese Acht Personen Teams, dass das so die Grenze ist. Acht bis zehn Personen wissen auch die meisten, obwohl ich natürlich auch, muss ich sagen, sehr viel Wachstumsschmerzen sehe bei so Startups und das gar nicht so einfach ist in der Praxis. Was in der Theorie eigentlich klar ist, wo schneide ich diese Teams? Wann starte ich denn mit meinem zweiten Teams, wenn ich so in der Wachstumsphase bin? Und es gibt auch bei größeren Firmen natürlich, ich habe irgendwie ein Team, habe vier Leute und plötzlich habe ich paar Hires dazu, paar Praktikanten und schon explodiert das Ganze und jeder beschwert sich, dass die Informationen fehlen und es kann dann relativ schnell auseinanderbrechen, wenn man das Ganze nicht beachtet von den zwei Bitzen. Und was man oft macht, wenn sich Leute beschweren, dass die Infos fehlen, ja, man führt ein neues tolles Tool ein, irgendein Projektmanagement Tool, Slack Chat, Kommunikationstool, Ticketing System, Jira, was es auch immer ist. Und genau da tut sich ein ganz neues Pizza Problem auf, bzw. Ich würde sagen, das ist das moderne Pizza Problem, weil es haben viele verstanden, acht Personen ist so die Obergrenze, weil die Kommunikation ist schwierig. Aber dass wir durch die ganzen Tools, die wir mittlerweile einführen, ein ganz anderes Problem haben mit dem Kommunikationsoverhead bzw. Mit dem kognitiven Overload durch diese ganzen Tools, die wir einführen, das vergisst man eigentlich sehr oft, weil was dieser Ringelmann Effekt auch sagt, ist, dass wir natürlich ein begrenztes Arbeitsgedächtnis haben oder wie man früher gesagt hat, Kurzzeitgedächtnis. Und wir müssen natürlich mit allem, mit dem wir uns beschäftigen, also die ganzen Tools, alle Tasks, die wir haben, müssen wir natürlich irgendwie in unser Arbeitsgedächtnis hineinbekommen. Und genau das ist der Cognitive Load. Und wenn die ganzen Tools, mit denen wir arbeiten, müssen natürlich ein gewisses Limit erreichen, dann bricht unsere Performance ein. Also unsere mentale CPU ist einfach überfordert. Man denkt nur, wir müssen mittlerweile Frameworks, Intus haben, Libraries, die ganzen Tickets rundherum, wir haben Kommunikationskanäle, wir bekommen ständig Slackpings, wir bekommen Mails, wir bekommen vielleicht sogar noch Anrufe, Fax höchstwahrscheinlich weniger, aber es gibt einfach sehr viele Tools, die wir aktuell im Alltag verwenden müssen. Es gibt auch Studien dazu, dass der durchschnittliche Wissensarbeiter täglich über dreizehn verschiedene Tools verwendet. Und wenn man sich überlegt, wie teuer es ist, solche Kontext Switche zu haben in der Arbeit, dann geht da sehr viel Zeit verloren. Also es gibt da Berechnungen, dass im Schnitt zwei und zwanzig Prozent dieser Wissensarbeit draufgeht, um einfach Anwendungen zu wechseln, Informationen zu suchen oder irgendwelche Status Updates zu pflegen in irgendwelchen Ticketing Systemen zum Beispiel, also zwei und zwanzig Prozent der gesamten Zeit. Und es ist eigentlich ganz klar, dass das so viel ist, weil man überlegt sich nur, wie teuer Kontext Switche sind. Es gibt da auch Berechnungen dazu und Psychologen sagen, dass es ungefähr drei und zwanzig Minuten im Schnitt dauert. Wenn man aus einer Fokusphase herausgerissen wird durch irgendeine Ablenkung, dann braucht man eben diese drei und zwanzig Minuten, bis man wieder im Fokus ist und weiterarbeiten kann. Also jeder Ping auf Slack kann im Prinzip dazu führen, dass ich wieder drei und zwanzig Minuten brauche, um wieder zurück in meine Arbeit zu kommen. Und wenn das Ganze extrem wird, dann spricht man auch von der sogenannten App Fatigue. Also gerade in großen Unternehmen, wo man hunderte von Apps mittlerweile hat, wird man schon fast zum Tool Administrator. Man muss überall Daten duplizieren, hin und her kopieren, man muss irgendwelche Status Updates machen in fünf verschiedenen Tools, womöglich nicht nur in einem Ticketing Tool, sondern auch in dem Projektmanagement Tool. Man muss es noch kommunizieren über einen Slack Channel und so weiter. Da sind wir wieder bei den zwei und zwanzig Prozent, die da gefressen werden. Es gibt da sogar Schätzungen, dass pro Jahr über drei hundert Milliarden Dollar an Produktivität verloren gehen, nur durch so eine App Fatigue, durch diese mentale Last, die wir dadurch mitbekommen. Was sind jetzt aber die wichtigsten Punkte, die man machen kann, um dagegen anzuarbeiten? Also wie besprochen die Zwei Pizza Regel, acht bis zehn Leute sonst das Team aufteilen und zwar mit einer ordentlichen End to End Verantwortlichkeit oder wie es in der Literatur auch oft heiß Stream aligned, also mit möglichst wenig Abhängigkeiten zwischen den Teams. Man sollte wirklich auf diese Tools achten, also Tools rationalisieren, jedes neue Tool wirklich bewerten. Hat es einen Wert? Das muss den Wert auch beweisen. Brauchen wir dieses Tool wirklich? Können wir ein anderes Tool vielleicht dadurch entfernen? Jedes Tool ist anders aufgebaut, andere uis, oft sind diese nicht synchronisiert und da entsteht sofort ein Cognitive Overload. Also konsolidieren, synchronisieren zwischen den Tools, die Workflows und Prozesse in so wenigen Plattformen wie möglich zusammenzufassen. Man kann sich zum Beispiel ganz simpel überlegen, wenn ich ein CI Pipeline Tool habe, kann ich die Notifications zum Beispiel automatisch über eine Pipeline in Slack legen, dass sie die wirklich in Slack bekomme, ohne dass ich ständig in dieses andere Tool wechseln muss. Also auch da wieder die Kommunikationskanäle bündeln. Ich kann auch links und rechts schauen. Großes Problem in Teams not invented. Hier Syndrom hatten wir auch mal eine Episode dazu. Also gibt es vielleicht in der Firma, in anderen Teams schon Tools, Integrationen, Pipelines, die man wiederverwenden kann, die eben etwas bündeln, ohne dass ich wieder alles selber neu entwickle und wieder ein neues Tool hinzufüge. Und natürlich der dritte ganz wichtige Fokuszeit schützen, Also die drei und zwanzig Minuten, die man braucht, um wieder zurückzukommen bei jedem einzelnen Pinguin muss man wirklich im Kopf behalten. Wir hatten unser erstes Interview mit Kirill zu dem Flow State Episode acht und sechzigste Kann man gerne nochmal nachhören. Man braucht sehr lange, bis man in so einen Flow Zustand kommt und wirklich super produktiv ist. Und jedes Mal, wenn wir in irgendeiner Form eine Ablenkung, eine Benachrichtigung bekommen, werden wir herausgerissen. Also auch da wieder Mut zum Stummschalten von Benachrichtigungen, sei es Lag, E Mail oder sonstige Dinge, damit wir einfach möglichst ungestört arbeiten können. Allgemein gesprochen, egal ob Teamgrösse oder ein Tool Stack. Das Motto für Produktivität weniger ist mehr. Und man sollte wirklich den idealen Zustand anpeilen, richtige Teamgrösse, ein Team, das sich schnell bewegen kann und nicht in unnötigen Tools ertrinkt. Und dann kann man auch wirklich Probleme konzentriert lösen. Und falls ihr da mal einen ganz praktischen Test machen wollt, überlegt doch einfach mal, wenn ihr im nächsten Meeting sitzt, das wieder ewig dauert, bestellt einfach zwei Pizzen. Wenn die zwei Pizzen nicht ausreichen, damit alle satt sind, habt ihr wahrscheinlich Probleme und zu viele Leute im Raum. Und besser kann man es dann eigentlich gar nicht mehr demonstrieren. Und damit noch eine besinnliche Zeit im Advent. Lasst euch eure Pizza Hawaii unter dem Weihnachtsbaum schmecken und jetzt ist schon fast Zeit, einen guten Rutsch zu wünschen. Wir können zumindest langsam damit starten.

Andy Grunwald (00:13:13 - 00:13:39)

Danke, Wolfi, für diese Episode. Das war's für heute von uns. Wenn dir das, was du gehört hast, gefallen hat, würden wir uns natürlich immer über Feedback freuen. Entweder über ein positives Review auf der Podcast Plattform deiner Wahl, einen Daumen hoch auf Social Media oder eine Anekdote in unserer Discord Community. Ich bin mir sicher, du findest schon einen Weg. Wir freuen uns auch, wenn du diesen Podcast abonnierst und einfach bei der nächsten Episode wieder einschaltest. Wir hören uns bald. Schöne Weihnachtszeit und tschüss.