Click Here

Wie Eine Pod-struktur Unsere Forschung Und Entwicklung Vom Überleben Zum Prosperieren Brachte

monsterid
Von Ido Yana

Was ist die ultimative Struktur für Technik-Teams? Dies ist eine Frage, die sich viele der heutigen Wirtschaftsführer stellen.

Der Betrieb einer Forschungs- und Entwicklungsabteilung (F&E-Abteilung) ist mit erheblichen Kosten verbunden – nicht nur in Form von Gehältern, sondern auch in Bezug auf das Ergebnis des Produkts selbst. Eine ineffektive Organisationsstruktur kann zu langsamen Releases, Fehlern und organisatorischen Verzögerungen führen, was letztlich dem ROI des Unternehmens und sogar dem Vertrauen der Kunden schadet.

Aus diesem Grund hat die F&E-Abteilung von WalkMe im vergangenen Jahr den Sprung von der Teamstruktur zur POD-Struktur vollzogen. Als POD-Besitzer, der das Unternehmen während dieses gesamten Prozesses begleitet hat, kann ich mit Zuversicht sagen: PODs erhöhen das allgemeine Qualitätsniveau innerhalb der technischen Teams und erzeugen einen Welleneffekt im gesamten Unternehmen.

Heute werde ich den Unterschied zwischen Teams und PODs aufschlüsseln, die Vorteile, die die POD-Struktur für Ihr Unternehmen haben kann, und bewährte Verfahren für den Übergang.

Teams vs. PODs

R&D team structure

Um zu beschreiben, wie ein POD funktioniert, müssen wir zunächst eine traditionelle F&E-Teamstruktur definieren.

Traditionelle Teams verwenden die Top-Down-Hierarchie, mit der die meisten Leute vertraut sind. Das Management priorisiert die Aufgaben, überwacht die Fristen und sorgt für einen optimalen Arbeitsablauf innerhalb des Teams.

Teams bestehen aus Mitgliedern mit ähnlichen Fachkenntnissen. Zum Beispiel können Front-End-Entwickler in einem Team zusammengefasst werden, während jeder an einem anderen Aspekt des Produkts arbeitet.

PODs sind mehr als eine Struktur, sie sind ein mentaler Schalter

Das Hauptunterscheidungsmerkmal besteht darin, dass die PODs autonom und selbstverwaltet sind, wobei jeder POD als eine unabhängige Einheit operiert.

PODs haben keinen formellen Manager, stattdessen gibt es einen POD-Eigentümer – den Unterschied, den dies für das Management ausmacht, werden wir später in diesem Beitrag behandeln. Jedes Mitglied eines POD ist auch insofern individuell autonom, als es für die Koordinierung seines eigenen Arbeitsablaufs von der Aufgabenpriorisierung bis zu den Fristen verantwortlich ist.

Diese Art von Einsatz erfordert von den Teams eine neue Denkweise, an die man sich erst gewöhnen muss, die aber letztendlich zu einer produktiveren, effektiveren und engagierteren Abteilung führt.

managing teams

Wie funktionieren PODs?

  • PODs bestehen aus einer kleinen Gruppe von Personen mit sich ergänzenden Fähigkeiten (vom Full-Stack bis zur Qualitätssicherung).
  • POD-Mitglieder sind um einen gemeinsamen Zweck herum gruppiert. Jeder POD ist für einen bestimmten Aspekt des Produkts verantwortlich. Sie besitzen alle damit verbundenen Aufgaben, von der Entwicklung über die Leistung bis hin zu Fehlern.
  • Jedes POD-Mitglied ist auch ein „Domain-Besitzer“. Domains repräsentieren ein spezifisches Fachgebiet, für das sie nicht nur verantwortlich, sondern auch am sachkundigsten sind. Die täglichen Aufgaben eines Entwicklers liegen nicht unbedingt in seinem Bereich. Stattdessen arbeiten sie an externen Projekten und fungieren als Berater für den in ihrem Bereich tätigen Entwickler.
  • Für jeden Domaininhaber gibt es einen Subdomain-Inhaber – jemanden, der die Lücke schließen kann, wenn ein Domaininhaber krank wird oder in Urlaub fährt.
  • Für jede anfallende Aufgabe wird ein Feature-Besitzer definiert. Während der Domain-Besitz statisch bleibt, werden die Feature-Eigentümer ständig geändert und definiert. Domaineigentümer A wird immer für die Domain A verantwortlich sein. Es ist jedoch denkbar, dass er/sie ein Feature-Eigentümer innerhalb von Domain B sein wird.

Wie entscheidet der POD, wie Aufgaben zu priorisieren sind?

Dies ist ein komplizierter und technischer Prozess, aber um es einfach auszudrücken – PODs basieren auf einer Demokratie.

Die Aufgaben kommen aus den unterschiedlichsten Quellen – Vorschläge von POD-Mitgliedern, Produktmanagern, von Kunden oder aus unternehmensübergreifenden KPIs. Alle Aufgaben werden in einen virtuellen Eimer geworfen.

Der nächste Schritt ist die Brainstorming-Sitzung: Alle 4 Wochen setzt sich die Gruppe zusammen, und wählt die wichtigsten Aufgaben aus und priorisiert sie in der Warteschlange. Jedes POD-Mitglied hat eine Stimme und kann über die Aufgaben abstimmen, die es als vorrangig erachtet.

product development

Als POD-Besitzer entscheide ich für jede Aufgabe in der Warteschlange, wer der Besitzer der Funktion sein wird. Mein Ziel ist es nicht nur, Aufgaben an Personen zu vergeben, deren Erfahrung relevant ist, sondern auch POD-Mitgliedern die Möglichkeit zu geben, etwas Neues zu tun. Ich ändere ständig, wer an was arbeitet, wobei ich darauf achte, erfahrene und weniger erfahrene Personen zusammenzubringen, um das Lernen innerhalb des POD zu erleichtern.

Natürlich können unerwartete Probleme auftreten – es gibt technische Fehler und zeitkritische Kundenlösungen. Wenn etwas in dieser Art auftaucht, arbeitet der Produktmanager eng mit dem Eigentümer der Funktion zusammen und erhält Aktualisierungen über den Fortschritt direkt von ihm/ihr.

Ich bin auch in der Lage, mit der Struktur zu spielen, wer an was arbeitet, und kann Entwickler von einer Aufgabe zur anderen versetzen. Falls nötig, kann ich einen Entwickler als Backup beauftragen, um eine Aufgabe rechtzeitig zu erledigen. Diese Flexibilität ermöglicht es uns, agiler zu sein, schnellere Lösungen und eine bessere Qualitätskontrolle anzubieten.

Ich könnte den ganzen Tag über die Vorteile von PODs sprechen, daher hier nur einige wenige

pods vs. teams

Die POD-Struktur wird seit langem von Technologie-Giganten wie Google und Hubspot genutzt, Unternehmen, die sich mit Innovation auskennen. Sie dient in erster Linie dazu, Effizienz und Flexibilität zu fördern, aber das ist noch nicht alles.

Meine persönliche Erfahrung mit PODs ist phänomenal. Hatte ich früher das Gefühl, dass unsere Arbeit darin bestand, ständig „Brände zu löschen“, so sind wir jetzt in der Lage, unsere Ziele proaktiv anzugehen. Als Abteilung blühen wir auf, anstatt nur zu überleben.

pod organizational structure

1. Die Erfahrung der Mitarbeiter wurde bereichert

Eine der am wenigsten diskutierten, aber nichtsdestotrotz sehr wichtigen Fragen ist, wie sich diese Verschiebung auf die alltägliche Erfahrung der Mitarbeiter auswirkt.

Die Umstellung auf PODs gab meinem Team die Möglichkeit, auf eine Art und Weise zu den Geschäftszielen beizutragen, die sie zuvor nicht so akut empfunden hatten. Die erhöhte Verantwortung schuf Selbstvertrauen, wenn es darum ging, wichtige Geschäftsentscheidungen zu treffen. Die Eigenverantwortung und die Freiheit, autonom zu arbeiten, hat die Arbeitszufriedenheit gesteigert.

effecient productive workflow

2. Minimale Abhängigkeit von externen Ressourcen

Die POD-Struktur ist so aufgebaut, dass jedes Projekt vor Ort in Angriff genommen werden kann. Vorbei sind die Zeiten, in denen man auf die Beteiligung Dritter warten musste. Mein POD ist in der Lage, alle ihre Projekte von Anfang bis Ende in Angriff zu nehmen, ein Konzept, das vorher undenkbar war.

tips for technical team managers

3. Gelegenheit zum Wissensaustausch und zur Entwicklung von Fähigkeiten innerhalb des POD

Die Art und Weise, wie die PODs aufgebaut sind, ermöglicht es dem Einzelnen, sich an verschiedenen Arten von Projekten zu versuchen. Der Domaininhaber bleibt zwar immer in der gleichen Domäne, aber er fungiert meist als Berater oder nimmt Feinabstimmungen innerhalb seiner Domäne vor. Den Rest seiner Zeit verbringt er damit, sich in neue Bereiche zu verzweigen. Die Besitzer der Features werden alle paar Wochen neu definiert, was bedeutet, dass es immer etwas Neues gibt.

In der Teamstruktur neigen Entwickler dazu, in einem Trott stecken zu bleiben, sich zu langweilen oder sogar zu kündigen. In PODs hingegen werden die Mitarbeiter regelmäßig durch neue und aufregende Projekte herausgefordert. Sie sind in der Lage, ihre Fähigkeiten zu erweitern und von ihren Kollegen zu lernen, während sie gleichzeitig die Monotonie ihrer Rolle durchbrechen. Dies hat enorme Auswirkungen, von der Motivation bis zur Weiterbeschäftigung.

flexibiity

4. Hyper-Flexibilität: Die PODs können innerhalb der PODs neu angeordnet werden

Ein weiterer großer Vorteil der POD-Struktur ist, wie einfach es ist, vorübergehende Umstrukturierungen innerhalb der PODS durchzuführen. Wenn ein Feature-Eigentümer ein wenig zusätzliche Hilfe benötigt, kann dies einfach und schnell geschehen, ohne den gesamten Arbeitsablauf zu sehr zu stören.

better product

5. Es gab einen Sprung in der Qualität des Produkts

Sobald die POD-Struktur stand und funktionierte, geschah etwas Erstaunliches. Kleine, scheinbar unbedeutende Ineffizienzen, die jahrelang ignoriert worden waren, waren plötzlich verschwunden. Dies geschah organisch, ohne jegliche Anfragen von oben nach unten. Sobald die Mitarbeiter für bestimmte Aspekte des Produkts verantwortlich waren, hatten sie ein persönliches Interesse daran, diese zu perfektionieren.

teamwork in pods

6. Wir sahen bessere Arbeitsabläufe und Reife innerhalb der PODs

Aus dem gleichen Grund, aus dem wir Verbesserungen in der Produktqualität sahen, begannen wir auch bessere Arbeitsabläufe innerhalb des Teams zu sehen. Die Struktur der PODs fördert die Teamarbeit, und die Realität in meiner POD spiegelt dies wider.
Da alle von Anfang bis Ende beteiligt sind, gibt es eine enorme Verbesserung in der Kommunikation und Ausrichtung. Die POD-Mitglieder arbeiteten flüssiger zusammen, es gab weniger Informationssilos, und die Interaktionen zwischen Entwicklern, QS und Produkt waren geradezu inspirierend.

good management

7. Dem Management steht es frei, die großen geschäftlichen Herausforderungen anzugehen

Als ich ein Teamleiter war, klingelte mein Telefon ununterbrochen. Diese Abhängigkeit ist nicht einzigartig – in den meisten Organisationsstrukturen gibt es eine Art Engpass, wenn es um die zeitlichen Anforderungen an das Management geht. Früher habe ich meine Zeit damit verbracht, offene Projekte zu überprüfen, Zeitpläne zu arrangieren und Besprechungen ein- und auszuplanen.

Die POD-Struktur hat meine Zeit freigesetzt, um mich auf die Schulung neuer Mitglieder und die Entwicklung einer langfristigen Strategie zu konzentrieren. Als POD-Eigentümer bin ich nicht in die tägliche Arbeit meines PODs involviert, aber ich bin in der Lage, Unterstützung für vorrangige Aufgaben einzubringen, die unsere Endziele vorantreiben werden. Nur meine Mutter ruft mich jetzt an.

Teams zu PODS: Beste Praktiken für den Sprung

pod structure vs. team structure

Versuchen Sie, jede Störung der Arbeit der POD-Mitglieder zu vermeiden

Es ist leicht, in alte Gewohnheiten einer teambasierten Hierarchie zu verfallen. Widerstehen Sie dem Drang zum Mikromanagement oder „managen“ Sie einfach nur. Ihre neue Rolle besteht darin, dafür zu sorgen, dass keine großen Hindernisse oder Probleme auftreten, die wichtige Projekte verzögern könnten.

Anstatt das Kommando zu übernehmen, versuchen Sie, einen Platz an der Seitenlinie einzunehmen. Ein POD-Eigentümer sollte derjenige sein, der die POD-Mitglieder instruiert und anleitet, wenn sie Hilfe bei einer kritischen Entscheidung benötigen, anstatt sich in jede einzelne Aufgabe einzumischen.

Lassen Sie Ihre POD-Mitglieder Fehler machen

Es wird eine Weile dauern, bis die Verantwortung vollständig auf Ihre POD übertragen wird, und dies ist eine wichtige Etappe in der Metamorphose. Lassen Sie Ihre POD-Mitglieder ihre neue Rolle und Freiheit ohne Angst vor dem Scheitern ausprobieren. Statt zu tadeln oder einzugreifen, nutzen Sie Fehler als eine Lerngelegenheit für alle im POD.

Wenn der unvermeidliche Ausrutscher eintritt: Verfolgen Sie die ergriffenen Maßnahmen, führen Sie eine Fallstudie über das Geschehene durch und teilen Sie Ihre Erkenntnisse mit der gesamten Gruppe. Der Fehler kann einen Rückschlag verursachen, aber letztendlich wird jeder lernen, seine Arbeit in Zukunft ein wenig besser zu machen.

Achten Sie auf die Sitzordnung

Damit die Kapsel zusammenarbeiten kann, ist es notwendig, dass sie auch in unmittelbarer Nähe sitzen. Ich bin in dieser Theorie noch einen Schritt weiter gegangen.

Einige Leute in der Abteilung dachten, ich hätte den Verstand verloren, als ich anfing, die Sitzplätze meiner POD-Mitglieder zu ordnen und neu zu arrangieren. Ich schuf mehr als 12 Variationen der Sitzordnung innerhalb des Clusters.

best practices for switching to pod structure

Beste Praktiken für den Wechsel zur POD-Struktur

Der Teufel steckt im Detail, und dies war keine Ausnahme. Die Sitzstruktur, die wir schließlich erhielten, hatte einen enormen Einfluss auf die Produktivität. Sie trieb die Zusammenarbeit über den POD hinaus und half, den Übergang zu erleichtern.

Die Strategie des großen Ganzen vermitteln

Es ist unmöglich, die Bedeutung der Kommunikation zu betonen. Kommunizieren Sie mit Ihrem Team über den Übergang, aber am wichtigsten ist es, ihnen die Endziele bewusst zu machen, damit ihre Entscheidungen und Prioritäten dies genau widerspiegeln können.

In der Vergangenheit reichte es aus, wenn das obere Management die Unternehmensziele verstand und sie in Aufgaben umsetzte, die ihr Team dann ausführen würde. Mit der POD-Struktur bilden die einzelnen Personen jedoch ihre eigenen Aufgaben und Ziele. Dazu müssen sie ein solides Verständnis für die Endziele des gesamten Projekts haben und dies auch gut umsetzen.

Seien Sie geduldig, PODs entstehen nicht über Nacht!

Wie wir betont haben, ist dies ein gewaltiger Übergang, nicht nur für die technischen Teams, sondern für das gesamte Unternehmen. Veränderungen können beängstigend sein, besonders für große Unternehmen. Es werden Hindernisse und Herausforderungen auftauchen, aber mit ein wenig Geduld und Übung wird Ihr Team im Handumdrehen ein funktionierender POD sein!

Teilen

monsterid
Ido Yana
Ido Yana has 14 years of experience in the software industry and four with WalkMe where he has filled various management roles since 2016. He enjoys working with people, animals and dabbling with construction in his free time.