Eine Reorganisation, die gut lief
Ich habe kürzlich eine Reorganisation einer IT-Abteilung für einen Kunden abgeschlossen. Diese Reorg verlief überraschend gut.
Schauen wir uns einige mögliche Gründe dafür an.
Der Status quo
Der Kunde befand sich im Wachstumsmodus. Die gesamte Abteilung betrachtete sich noch als ein Team, hatte aber 40 Engineers. Der Kunde schuf dann vier Teams. Ein Bugfixing-Team. Und drei Entwicklungsteams. Die drei Entwicklungsteams hatten keine eigene Domäne, sondern arbeiteten eine Woche an Feature A, nächste Woche an Feature B und so weiter.
Alle in der Organisation waren wirklich motiviert. Aber kleine Risse begannen sich zu zeigen:
- Das Bugfixing-Team beschwerte sich, dass es nicht an coolen Sachen arbeiten konnte. Es war langweilig.
- Product Manager beklagten, dass es unmöglich war, eine langfristige Produktstrategie zu etablieren: Das lag daran, dass sie keinen Fokus auf einen bestimmten Teil der Software hatten (oder den Kunden oder den Value Stream).
- Entwickler hatten es schwer, eine langfristige Tech-Strategie zu etablieren: Die Teams besaßen nichts. Einfach das Feature erledigen und weitergehen. Im Falle von Bugs waren sie nicht einmal für die Behebung verantwortlich - dafür gab es schließlich das Bugfixing-Team. Aber das erzeugte technische Schulden, die niemand wirklich besaß. Das wiederum begann die Entwicklungsgeschwindigkeit zu verlangsamen.
Unsere Ziele
Viele Reorgs haben keine wirklichen Ziele im Sinn. Aber um mit einer Reorganisation erfolgreich zu sein, brauchen Sie messbare Ziele.
Wir definierten drei Ziele für unsere Reorg:
- Das zukünftige Wachstum des Unternehmens unterstützen (Onboarding und Aufteilung in neue Domänen sollte einfach sein)
- Teams Fokus und Ownership geben (verringerte Bug-Anzahl)
- Struktur etablieren, die mehrere Releases pro Tag und Team ermöglicht (schnellere Zykluszeit)
Wir haben auch den Employee NPS während des gesamten Veränderungsprozesses gemessen, um sicherzustellen, dass wir die Motivation der Teams nicht zerstörten.
Wie man die Domäne der Teams bestimmt
Es ist oft einfach, natürliche Teams zu identifizieren, wenn man sich die Benutzeroberfläche der betreffenden Software ansieht. Sie werden einige größere Bereiche als Menüpunkte haben. Denken Sie an Google Workplace. Sie haben 5 große Menüpunkte: Google Sheets, Google Documents und so weiter. Jeder Menüpunkt bekommt ein Team mit einer klaren Domäne. Das ist natürlich vereinfacht, aber Sie verstehen die Idee.
Ihr erstes Domänenmodell ist möglicherweise nicht ideal, und Sie sollten Ihre Organisationsstruktur immer hinterfragen, ob ein Team wirklich direkt Geschäfts- und Kundenwert liefern kann. Trotzdem könnte ein Team pro Menüpunkt ein guter Ausgangspunkt sein.
Wir entwickelten den Plan gemeinsam mit den Product Managern und den wichtigsten Entwicklern. Die große Überraschung war, dass - sobald der Plan vereinbart war - die Reorg von den Teams ohne jegliche Management-Beteiligung umgesetzt wurde. Ich musste nur den anfänglichen Anstoß geben, aber dann übernahmen die Teams und setzten alles um. Das war extrem zufriedenstellend zu beobachten und unterstrich die Qualität und Motivation der Belegschaft.
Am Ende waren alle zufrieden - was bei Reorgs nicht immer der Fall ist…
Das Ergebnis
Fünf Teams mit klarem Ownership über einen Teil der Software. Jedes Team hatte Kundenkontakt und war für alles verantwortlich (aka Fullstack): Frontend, Backend, Datenbank.
Wir gaben auch den Product Managern mehr Befugnisse. Vor der Reorganisation waren sie bloße Ausführende von Plänen. Nach der Reorganisation erwarteten wir von ihnen, zu experimentieren, und gaben ihnen die Freiheit, (fast) eigenständig über die Richtung ihrer Domäne zu entscheiden. Wir benannten die Rolle von Product Manager in Product Owner um.
Was hätten wir besser machen können?
Einige Mitarbeiter beschwerten sich, dass wir nicht genug kommuniziert hatten. Der Plan wurde besprochen - aber nur mit den Product Managern und den wichtigsten Entwicklern - nicht mit allen. Das ist etwas, das wir in Zukunft verbessern könnten. Über-Kommunikation fühlt sich seltsam an - aber sie ist eine Notwendigkeit. Beim nächsten Mal würde ich in Abteilungs-All-Hands-Meetings regelmäßige Updates im Zwei-Wochen-Rhythmus geben.
Fazit
Abgesehen von der Kommunikation hat es gut funktioniert und wir haben unsere Ziele messbar erreicht. Das Unternehmen stellte in den Monaten nach der Reorg viele Leute ein - und die neue Struktur konnte neue Mitarbeiter problemlos gut integrieren.
Behalten Sie bei einer Reorg in Ihrer Abteilung die folgenden drei Punkte im Kopf:
- Definieren Sie die Ziele Ihrer Reorg und messen Sie, ob Sie diese erreichen.
- Kommunizieren Sie und holen Sie Feedback während des Prozesses ein.
- Delegieren Sie und haben Sie gute Leute, die Sie unterstützen!
Das war’s. Viel Erfolg bei Ihrer nächsten Reorg!
Mehr:
- Casey Winters über Reorgs bei Eventbrite: https://caseyaccidental.com/alternative-approach-re-orgs/
- Foto oben von der großartigen Laura Rivera
