Vor drei Jahren begann ich als Engineering Manager bei einem aufstrebenden Startup namens PagerDuty . Nachdem das Unternehmen 2013 die Finanzierungsrunde A erhalten hatte, befand es sich im Hyperwachstumsmodus und stellte in allen Bereichen aggressiv neue Mitarbeiter ein. Das Engineering-Team bestand damals aus weniger als 30 Personen, und ein großer Anreiz für mich war (und ist es immer noch), etwas über die strukturellen Herausforderungen zu erfahren, denen eine schnell wachsende Organisation gegenübersteht. Da wir uns der 100-köpfigen Dutonianer-Marke im Engineering nähern, scheint es angebracht, zurückzublicken und über die bisherigen Veränderungen nachzudenken.

Die Entwicklung von Organisationsstrukturen ist ein faszinierender Prozess – voller Fehler, Sackgassen, Neuerfindungen des Rades und hoffentlich auch gewonnener Erkenntnisse. Es gibt jede Menge Literatur zu technischen Organisationen, die sich größtenteils auf abstrakte Listen von Vor- und Nachteilen oder Blogbeiträge beschränkt, die den Prozess lobpreisen, den das Unternehmen zum Zeitpunkt des Schreibens dieses Artikels gerade eingeführt hat. Ich möchte einen anderen Ansatz wählen und die historischen Gründe untersuchen, die unser Entwicklungsteam dazu veranlasst haben, kontinuierlich mit unserer Struktur zu experimentieren und sie weiterzuentwickeln, mit all den damit verbundenen Fehltritten und Erkenntnissen.

Hinweis: Einige der Ereignisse und Details wurden der Erzählung zuliebe vereinfacht – viele davon sind eigene Beiträge wert. Setzen Sie ein Lesezeichen für diesen Blog, um nach neuen Inhalten Ausschau zu halten.

Die isolierte Organisation

PagerDuty sah Anfang 2014 ungefähr so ​​aus:

• Die Engineering-Organisation wurde auf die Büros in San Francisco und Toronto aufgeteilt.
• Das Betriebsteam war für die Automatisierung, Sicherheit und Persistenz der Infrastruktur (nur SF) verantwortlich.
• Das Web Application Team war für die kundenorientierten Aspekte von PagerDuty (nur SF) verantwortlich und entwickelte hauptsächlich mit Ruby on Rails und MySQL.
• Die Backend Services Group war für die zuverlässige Datenübertragung und Benachrichtigungsübermittlung verantwortlich (aufgeteilt auf kolokalisierte Teams in SF und Toronto) und entwickelte hauptsächlich mit Scala und Cassandra.
• Die DevOps-Regeln wurden nur teilweise eingehalten. Das Operations-Team war für Warnmeldungen zur Infrastrukturüberwachung auf Abruf bereit, andere Teams Bereitschaft für den Code, den sie bereitgestellt haben .

Während die Entwicklungsabteilung in kürzester Zeit von einer Handvoll Leute auf mehrere verteilte Teams anwuchs, blieb der Produktentwicklungsprozess ziemlich unausgereift. Trotz oberflächlicher Anzeichen von Agilität mit Stand-ups und Sprints nutzten wir im Wesentlichen die Wasserfall-Modell . Die Unternehmensleitung definierte die zu bearbeitenden Projekte, teilte die einzelnen Ingenieure diesen Projekten zu und legte die Zieltermine für die Lieferung fest. Wie vorherzusehen war, wurden die Termine selten eingehalten und die Tabellen zur Projektverfolgung befanden sich in einem ständigen Zustand der Verwahrlosung und wurden schließlich nicht mehr verwendet.

In der Praxis sah es nicht viel besser aus. Produktmanager starteten neue Projekte mit dem Entwurf langer funktionaler Designspezifikationen und taten ihr Bestes, um eventuell auftretende Fragen vorwegzunehmen – eine Folge der Tatsache, dass Produkt und Entwicklung während der Entwicklung kaum miteinander interagierten! Die Spezifikation wurde den Teams für Webanwendungen und Backend-Dienste vorgelegt, die dann unabhängig voneinander an den benutzerorientierten und Backend-Aspekten arbeiteten. Neue Infrastrukturanforderungen mussten schon Wochen im Voraus an das Betriebsteam gestellt werden.

Die Integration all dieser Einzelbemühungen in eine zusammenhängende Funktionsfreigabe war ein Alptraum. Wir hatten eine fehlende oder unvollständige Infrastruktur, Hot-Potato-Bugs, Funktionslücken (jedes Team glaubt, das andere kümmert sich darum), mangelnde Eigenverantwortung oder Ermächtigung der Ingenieure und Produktleute, verpasste Termine und organisatorische Silos. Der Wunsch, Termine einzuhalten, führte dazu, dass wir weniger Risiken eingingen und bei unseren Implementierungen konservativer wurden und uns davor scheuten, die Produktspezifikationen anzupassen.

Diese Kombination aus Abteilungsstruktur und Entwicklungsprozessen rückte das Thema Silobildung in diesem Jahr in den Mittelpunkt aller anderen Diskussionen innerhalb der Entwicklungsabteilung. Und Junge, hatten wir Silos:

• Webanwendung vs. Backend-Dienste. Zwischen den beiden Gruppen herrschte eine spürbare Spannung. Keine von ihnen verstand wirklich, woran die andere Gruppe arbeitete, und beide waren frustriert.
• Ruby vs. Scala. Ähnliche Konfliktlinien wie oben, mit viel Bikeshedding und Identitätsbildung rund um bestimmte Sprachen.
• Betriebs- vs. Entwicklungsteams. Beide Seiten waren frustriert darüber, dass das Ops-Team einen Engpass bei der Bereitstellung aller Server darstellte. Auch die operativen Abteilungen standen aufgrund drohender Fristen unter großem Druck.
• San Francisco gegen Toronto. Da die Teams geografisch am selben Standort untergebracht waren, entwickelte sich zwischen den Ingenieuren an beiden Standorten eine deutliche „Wir gegen die“-Stimmung. Beide Seiten fanden Grund zum Meckern.

Die starr definierten Zuständigkeitsbereiche ließen den Teams nicht viel Spielraum für eine abteilungsübergreifende Zusammenarbeit. Wir experimentierten kurz mit dem Konzept von „Arbeitsgruppen“ – kleinen, temporären, vielfältigen Gruppen, die Leute aus den bestehenden Teams zusammenstellten, um an bereichs- und zeitbegrenzten, übergreifenden Projekten zu arbeiten. Diese Gruppen destabilisierten die Hauptteams und sorgten letztendlich für noch mehr Chaos. Daher wurde das Experiment abgebrochen.

Dennoch war die Notwendigkeit, zusammenzuarbeiten und mit besserer Konsistenz und Vorhersehbarkeit zu liefern, von größter Bedeutung. Alle hatten die Silobildung satt, also musste sie weg. Wir hatten eine Menge Arbeit vor uns.

Die Matrix-Organisation

Anfang 2015 erreichten die Unzufriedenheit mit dem Stand der Dinge sowie das steigende Interesse an agilen Methoden eine kritische Masse und führten zu einer Umstrukturierung der Abteilung. Es wurden mehrere neue Teams gebildet, die sich auf bestimmte Produktrichtungen konzentrierten. Sie folgten dem Scrum-Prozess und bestanden aus Ingenieuren sowohl der Web Application- als auch der Backend Services-Teams sowie aus Produktbesitzern, Scrum-Mastern und UX-Designern.

Angesichts des nicht gerade optimalen Fortschritts bei der Produktentwicklung im vergangenen Jahr wurden die neuen Teams für die Produktlieferung optimiert. Um sicherzustellen, dass sie 100 Prozent ihrer Zeit für die Entwicklung neuer Funktionen verwenden konnten, wurden Wartungsarbeiten an die Backend Services-Teams delegiert. Diese wurden als „Basisteams“ bezeichnet, da sie Kanban-Methodik und übernahm die Verantwortung für alle Dienstleistungen in der Produktion, einschließlich aller Produkt Bereitschaftsaufgaben . Darüber hinaus wurden die Produktteams von Basisteams unterstützt – die Ingenieure wechselten von einem Team zum anderen, als die Arbeit am Produkt intensiviert wurde.

Dies waren offensichtlich große Veränderungen. Um die Auswirkungen der Teamumstrukturierung auf einzelne Ingenieure zu minimieren (und die Arbeit mit Remote-Berichten hinauszuzögern), wurden die Berichtsbeziehungen nicht angetastet. Dies hat natürlich das Leben aller enorm kompliziert, denn jetzt hatten wir eine duale Berichtsstruktur, auch bekannt als Matrixorganisation ! Viele Ingenieure landeten in Teams, die nicht ihrem direkten Vorgesetzten zugeordnet waren, und Manager spielten nun die Rolle des „Personalmanagers“ (verantwortlich für Leute, von denen einige in anderen Teams waren) und des „Funktionsmanagers“ (verantwortlich für Teams, in denen einige Ingenieure woanders unterstellt waren).

Die gute Nachricht war, dass die alten Silos größtenteils zerstört und nie wieder gesehen wurden. Web Application Engineers, die eng mit Backend Services Engineers zusammenarbeiteten, konnten über die Unterschiede der anderen hinwegsehen und gemeinsame Ziele anstreben. Die meisten Teams waren jetzt auch geographisch verteilt, was bei der Zusammenführung der beiden Büros Wunder bewirkte.

Die schlechte Nachricht war, dass eine ganze Reihe neuer Probleme auftraten:

• Es war sehr schwierig, ein Team für die technische Wartung zusammenzustellen. Den Basisteams fiel es schwer, langfristige Roadmaps zu entwickeln und die operative Verantwortung für alle Produktionsdienste zu klären.
• Das Feeder-Modell hatte einen sehr realen Einfluss auf den Teamzusammenhalt . Es hat sich gezeigt, dass sich eine ständige Änderung der Teamzusammensetzung nicht besonders positiv auf die Moral auswirkt.
• Die duale Berichtsstruktur führte zu zahlreichen Ineffizienzen. Es fehlte an Einblicken in die täglichen Aktivitäten eines direkten Untergebenen, es entstand zusätzlicher Kommunikationsaufwand zwischen Personalmanagern und Funktionsmanagern und es herrschte allgemeine Verwirrung bezüglich der Verantwortlichkeiten.
• Wir haben Agile-Prozesse eingeführt, statt Agilität . Scrum hat sicherlich bei der Überspezifikation, Integration und Einbindung der Produktbesitzer geholfen. Unser Ansatz bei der Softwarebereitstellung hat sich jedoch nicht geändert – Feature-Releases waren immer noch Big-Bang-Angelegenheiten, deren Wert fragwürdig war.
• Mehr Teams bedeuteten eine höhere Belastung für die Betriebsleute. Angesichts häufiger Infrastrukturanforderungen und zusätzlicher Bereitschaftspflichten für jeden neuen Dienst war dieser Ansatz offensichtlich nicht skalierbar.

Insgesamt waren wir zwar immer noch in einer deutlich besseren Verfassung als vor einem Jahr, aber der Weg war noch weit.

Die agile Organisation

Nachdem wir ein Jahr lang mit der neuen Organisationsstruktur gelebt hatten, hatten wir eine Menge gelernt. Agile war gut (aber wir haben es nicht genug gemacht), DevOps war gut (aber wir haben es nicht genug gemacht), Matrixmanagement war nicht so gut (und wir hatten genug davon).

Anfang 2016 haben wir uns erneut umstrukturiert. „Vertikale“ Produkt-Scrum-Teams waren nun für bestimmte Bereiche des Produkts verantwortlich. „Horizontale“ Teams waren für übergreifende Produkt- oder Infrastrukturbelange verantwortlich und hatten die Aufgabe, Best Practices festzulegen und anderen Teams zu ermöglichen, schnell voranzukommen. Die Produktlieferteams waren für ihre Roadmap, Anforderungsdefinition, Implementierung, Bereitstellung und Wartung ihres Codes und ihrer Infrastruktur (!) in der Produktion verantwortlich. Wir hatten ein echtes DevOps-Konzept eingeführt. Sie codieren es, es gehört Ihnen ' Ansatz.

Wie wurden dadurch unsere bisherigen Bedenken gelöst?

• Keine Wartungsteams mehr. Jedes Team besaß einen Teil des Produkts oder der Infrastruktur und war befugt, schnell zu handeln und Innovationen einzuführen.
• Keine Feeder-Teams mehr. Die Personalzählung wurde für bestimmte Teams geöffnet.
• Keine Doppelberichterstattung mehr! Als Unternehmen haben wir uns bei der Einstellung und Verwaltung von Remote-Ingenieuren viel besser eingelebt. Da die physische Distanz kein Hindernis mehr darstellt, konnten wir Manager Teams ohne Dotted-Line-Beziehungen zuweisen.
• Wir konzentrieren uns darauf, Dinge zu erledigen. Das Mantra von GSD (Get Sh*t Done) hat unser kollektives Bewusstsein durchdrungen und fordert die Teams dazu auf, sich zu reflektieren und das Erbe der Überspezifikation und Überentwicklung abzustreifen, um sich zu pragmatischen, produktiven und agilen Liefermaschinen zu entwickeln.
• Wachstum durch Selbstbedienung möglich. Das Operations-Team hat viel Arbeit geleistet, um die Produktlieferteams zu unterstützen, einschließlich der Bereitstellung von schicken ChatOps-Tools zur Selbstbedienung für alle Arten von Infrastrukturanforderungen. Dies war der Schlüssel zur vollständigen Umsetzung von DevOps und zur Verlagerung von Infrastrukturwarnungen aus dem Betrieb in die entsprechenden Teams, die die eigentlichen Hosts besitzen (und die Probleme ohnehin schneller lösen konnten).

Das Thema GSD ist es wert, etwas tiefer zu vertiefen. Durch die Praxis wurden wir immer vertrauter mit den Ideen der Teamautonomie, Innovation statt Erfindung und Unternehmen bringen Probleme mit sich, die gelöst werden müssen, statt Lösungen, die umgesetzt werden müssen. Es ist nicht leicht, die Vorstellung aufzugeben, dass wir wissen, was das Beste für die Kunden ist. Ein Laserfokus auf die Bereitstellung der minimal funktionsfähiges Produkt , sofortiges Feedback einzuholen und es während des Entwicklungszyklus zu integrieren, war der Schlüssel. Dadurch konnten wir schnell iterieren, den Wert maximieren, Gold Plating minimieren und die Zeit, bis ein Prototyp in die Hände des Kunden gelangte, von Monaten auf Tage oder Wochen verkürzen. Mit anderen Worten: Wir haben uns von einer Organisation, die „agilen Prozessen folgt“, zu einer wirklich agilen Organisation gewandelt.

Als die Zahl der Produktlieferteams wuchs, entwickelte sich ein interessantes Phänomen – wir sahen die Entstehung der sogenannten „Stämme“ (Hut ab vor Spotifys Teammodell ); d. h. Gruppen von Teams, die durch gemeinsame Funktionen oder gemeinsame Missionen miteinander verbunden sind. Diese Vereinbarungen haben Vorteile wie geteiltes Eigentum, geteiltes Wissen, geteilte Roadmap (getrennt von den Backlogs der einzelnen Teams) und geteilte Vision gebracht. Die Stammesorganisation ist etwas, mit dem wir noch experimentieren – bleiben Sie dran für zukünftige Updates zu unseren Erfahrungen mit Stämmen.

Wir arbeiten jetzt seit 16 Monaten mit dieser Struktur und sie funktioniert einfach. Natürlich werden sich Teams und zugehörige Eigentumsverhältnisse weiterentwickeln, während das Unternehmen weiterhin schnell wächst, und einige Details werden sich ändern, da wir weiterhin in unsere eigene Verbesserung investieren. Gleichzeitig ist klar, dass wir genug Falsches getan haben, um zu lernen, wie das Richtige aussehen sollte.

gewonnene Erkenntnisse

Wenn ich an einige der Entscheidungen zurückdenke, die zu Beginn getroffen wurden, und an einige der unangenehmen Zwischenzustände, die unsere Organisation durchlebt hat, bin ich versucht, mir selbst an den Kopf zu schlagen und mich zu fragen, warum wir nicht auf die Idee gekommen sind, den offensichtlich besseren Endzustand zu erreichen. Die Realität ist natürlich nie so einfach – diese Entscheidungen waren eine Funktion unseres Zustands, unserer Prioritäten, unserer Leute und unserer Herausforderungen. zu der Zeit . Möglicherweise haben Sie auch einige Ihrer eigenen Herausforderungen erkannt. In diesem Fall hoffe ich, dass Sie aus unserer Erfahrung etwas mitnehmen können.

Wenn ich alles noch einmal machen müsste, würde ich folgende Erkenntnisse mitnehmen:

• Minimieren Sie Abhängigkeiten zwischen Teams . Abhängigkeiten führen zu Blockaden, Fehlern, Missverständnissen und schlechten Gefühlen. Geben Sie Teams die Möglichkeit, zu liefern, ohne auf andere warten zu müssen, und Sie werden erhebliche Produktivitätssteigerungen erleben.

• Minimieren Sie Änderungen an der Teamzusammensetzung . Die geschäftlichen Realitäten erfordern gelegentlich die Verlagerung von Ressourcen von einem Ort zum anderen. Überlegen Sie es sich gut, bevor Sie Mitarbeiter versetzen, denn das kann die Moral und Produktivität des Teams ernsthaft beeinträchtigen.
• Legen Sie Teameigentum und Verantwortlichkeiten nicht zu stark fest . Flexibilität führt hier zu längerfristigen Erfolgen. Ermutigen Sie die Teams, ihre eigenen Probleme zu lösen, und Sie werden weniger Probleme mit den beiden vorherigen Punkten haben.
• Haben Sie keine Angst vor kontinuierlichem Lernen und Experimentieren . Dies gilt für alles – Code, Prozess, Organisation. Man wird nicht besser, wenn man immer wieder dieselben Dinge tut.
• Agile Prozesse sind schön, eine agile Kultur ist besser r. Standups und Sprint Reviews bringen allein nicht viel Wert. Die Konzentration auf ein minimal funktionsfähiges Produkt, schnelle Feedbackschleifen und Zusammenarbeit erfordert einen kulturellen Wandel, maximiert jedoch den gelieferten Kundenwert.
• Betriebsbereit Das Eigentum an dem Code sollte bei den Teams liegen . Dies ist die beste Möglichkeit, Systemzuverlässigkeit, Codequalität und organisatorische Skalierbarkeit in Einklang zu bringen.
• Funktionsübergreifende Full-Stack-Teams sind am besten für die Produktlieferung geeignet . Dies steht im Einklang mit dem oben genannten Punkt zur Abhängigkeitsminimierung. Jedes Team sollte in der Lage sein, von der Anforderungserfassung bis zur Bereitstellung zu gelangen, ohne externe Experten einbeziehen oder Projekte übergeben zu müssen. Spezialisierte Teams haben zwar ihren Platz, aber eher im Bereich der zuvor besprochenen „horizontalen“ Teams.
• Stellen Sie Generalisten ein, die kann in jeder Umgebung funktionieren. Teammitglieder sollten ihre Identität nicht an bestimmte Tools, Frameworks und Stacks knüpfen, wenn sich Technologien und technische Richtungen ändern. Die Menschen, die in einem wachstumsstarken Umfeld am besten Erfolg haben, sind diejenigen, die sich auf das Lernen und die Verwendung des richtigen Tools für die jeweilige Aufgabe konzentrieren. Seien Sie daher bereit, diese Lern- und Wachstumsmöglichkeiten zu bieten.
• Vermeiden Sie Matrixmanagement, wenn es sich vermeiden lässt . Überlegen Sie, ob es andere Möglichkeiten gibt, die Probleme anzugehen, die durch die doppelte Berichterstattung gelöst werden könnten.
• Setzen Sie auf verteilte Teams . Der Aufbau zusammenhängender Teams mit Remote-Mitgliedern ist nicht ohne Herausforderungen, bietet aber zahlreiche Vorteile. Martin Fowler wies darauf hin, „ Indem Sie ein Team remote zusammenstellen, können Sie den Kreis der Personen erweitern, die Sie in das Team einbeziehen können. Ein Remote-Team ist möglicherweise weniger produktiv als dasselbe Team, das am selben Standort arbeitet, aber möglicherweise immer noch produktiver als das beste Team, das Sie am selben Standort bilden können. „Mit anderen Worten: Wenn Sie externe Mitarbeiter zulassen, steht Ihnen ein viel größerer Bewerberpool zur Verfügung, sodass Sie insgesamt ein stärkeres Team aufbauen können.

Wenn Organisationen wachsen und reifen, besteht die Tendenz, langsamer zu werden, zu verhärten und konservativer zu werden. Durch kontinuierliche Verbesserung und Weiterentwicklung unserer Praktiken ist es uns gelungen, uns dem Trend entgegenzustellen und mit der Zeit agiler, pragmatischer und produktiver zu werden – und Sie können das auch tun.

Auf drei (und viele) weitere Jahre des Lernens!