Power-Leveling im Team

LAN-Party, irgendwann Anfang der 2000er. Diablo 2. Alle sind Level 40+, mitten in Nightmare. Ein Freund kommt später dazu. Level 1, Holzschwert, Act 1.

Was macht man? Man nimmt ihn mit. Höhere Gebiete, geteilte Erfahrungspunkte, ein paar Items aus der Stash – Ausrüstung, die man selbst nicht mehr braucht, die aber auf seinem Level einen riesigen Unterschied macht. Power-Leveling.

Und das funktioniert, weil jeder eine andere Klasse spielt. Der Sorceress nützt die Axt nichts, der Barbar braucht keinen Zauberstab. Jede Klasse hat eigene Stärken, eigene Ausrüstung, eigene Rolle in der Gruppe. Alleine kommt ab einem gewissen Punkt keiner mehr weiter. Erst zusammen – Paladin tankt, Sorceress macht Flächenschaden, Necromancer kontrolliert das Feld – wird es möglich, die höheren Schwierigkeitsgrade zu schaffen.

Das Spiel funktioniert erst, wenn alle mitspielen können.

Die Parallele

Neue Teammitglieder, Quereinsteiger, Kollegen aus anderen Fachbereichen – alle starten auf Level 1 in einem neuen Kontext. Und genau wie in Diablo 2 spielt jeder eine andere Klasse: Backend, UX, Product Management, Customer Support. Jeder bringt andere Stärken mit, braucht anderes Equipment. Und ab einer gewissen Projektkomplexität geht es nur noch zusammen.

Die typische Reaktion: „Lies dich mal ein.“ Dokumentation, Wiki, Confluence-Wüste.

Das ist, als würde man dem Freund auf der LAN-Party sagen: „Spiel halt erstmal alleine bis Level 40.“

Besser: Aktives Power-Leveling. Abkürzungen schaffen, Kontext teilen, gemeinsam durch die schwierigen Stellen gehen.

Sprache als unsichtbare Levelgrenze

Ein Beispiel, das oft übersehen wird: Sprache. In technischen Teams ist Englisch selbstverständlich – Dokumentation, Code-Reviews, Meetings, Slack. Für manche im Team ist das eine echte Hürde. Wer fachlich auf Level 40 ist, aber sprachlich auf Level 10 feststeckt, kann nicht mitspielen.

Auch in RPGs kennt man das: Wer nicht weiß, was DPS, Aggro oder AoE bedeutet, versteht die Gruppenabsprachen nicht – egal wie gut der eigene Charakter ist.

Und Sprache heißt nicht nur Deutsch oder Englisch. Jedes Team entwickelt eine eigene Fachsprache – eine Art Domain Specific Language. Begriffe wie „Bounded Context“, „Spike“, „Regression“ oder projektspezifische Abkürzungen sind für Eingeweihte glasklar. Für alle anderen sind sie eine Mauer. Je schneller jemand diese Begriffe kennt, desto klarer und effizienter die Kommunikation.

Power-Leveling heißt hier: Begriffe erklären statt voraussetzen, aktiv einbeziehen statt abwarten, die gemeinsame Sprachbasis bewusst aufbauen.

Warum wir Wissen zurückhalten

Meistens nicht böswillig. Aber es passiert trotzdem.

„Das muss man sich erarbeiten“ – Gatekeeping als Kultur. Wer es selbst schwer hatte, erwartet das von anderen.
Angst vor Ersetzbarkeit – Wer alles teilt, macht sich vermeintlich überflüssig.
Zeitmangel – „Ich erklär das später.“ Passiert nie.
Unbewusstes Silodenken – Jeder kennt seinen Bereich, keiner den Gesamtkontext.

Was Teams dadurch verpassen

In Diablo 2 verteilen sich Erfahrungspunkte in einer Gruppe. Weniger erfahrene Spieler profitieren überproportional. Die Gruppe ist am Anfang insgesamt etwas langsamer – aber das ist eine bewusste Investition. Und je stärker die Gruppe wird, desto härter werden die Gegner. Normal, Nightmare, Hell – die Schwierigkeitsgrade skalieren mit. Wer da jemanden zurücklässt, hat bald ein echtes Problem.

Im Team ist es genauso:

Weniger Bottlenecks. Nicht eine Person muss alles entscheiden, reviewen, wissen.
Bessere Diskussionen. Wer den Kontext kennt, kann mitdenken statt nur ausführen.
Resilienteres Team. Fällt jemand aus, steht nicht alles still.
Mehr spannende Aufgaben. Je höher der Wissensstand im Team, desto mehr Themen können parallel angegangen werden.

Die stille Wissenslücke

Das Worst-Case-Szenario ist nicht die langsame Einarbeitung. Es ist die Person, der das Wissen fehlt und es niemand mitbekommt. Die sich nicht traut, es anzusprechen. Die sich thematisch so abgehängt fühlt, dass sie das Projekt lieber verlässt.

Man verliert Leute, ohne zu verstehen, warum.

Power-Leveling in der Praxis

In einem meiner Projekte war das Wissen über Java und Spring Boot anfangs dünn verteilt. Statt jeden einzeln durch die Doku zu schicken, haben wir bewusst geteilt: Pair Programming, Architektur-Walkthroughs, gemeinsame Code-Reviews. Innerhalb weniger Wochen war Spring Boot ein verlässlicher Standard-Stack, den alle beherrschen.

Konkret sieht Power-Leveling so aus:

Pair Programming / Mob Programming – Gemeinsam durch den Code, nicht nur gemeinsam im Call.
Architektur-Walkthroughs statt „lies die Doku“ – 30 Minuten erklären spart Tage Einlesen.
Over-Sharing von Kontext – In Tickets, PRs, Slack. Lieber zu viel Kontext als zu wenig.
Onboarding als Teamsport – Nicht als Selbststudium.
„Erkläre mir das in 5 Minuten“ als Kultur – Niedrigschwellig, jederzeit.

Das ist wie die Items in Diablo 2: Erfahrene Spieler haben Equipment rumliegen, das andere sofort nutzen können. Templates, Patterns, Wissen – alles Dinge, die auf Lager liegen und nur geteilt werden müssen.

Es funktioniert in beide Richtungen

Power-Leveling heißt: Wer gerade den Vorsprung hat, teilt ihn. Egal in welche Richtung.

Es gibt einen guten Ratschlag: Sorge dafür, dass du nie die fähigste Person im Raum bist. Das gilt auch hier. Kenne ich ein Thema zu wenig, fehlt mir ein Skill – dann halte ich mich an die Experten in dem Feld und lasse mich mitziehen. Nicht passiv warten, bis es irgendwann klick macht. Aktiv andocken.

In Diablo 2 funktioniert Power-Leveling auch nur, wenn der Low-Level-Charakter mitläuft. Wer in der Stadt stehen bleibt, bekommt keine Erfahrungspunkte.

Gegenargumente

„Manche Dinge muss man selbst erfahren.“ – Stimmt teilweise. Aber Kontextwissen ist kein Skill, den man üben muss. Den kann man abkürzen.
„Das kostet zu viel Zeit.“ – Kurzfristig ja. Langfristig spart es ein Vielfaches.
„Nicht jeder muss alles wissen.“ – Richtig. Aber jeder sollte genug wissen, um mitspielen zu können.