Vor drei Jahren begann ich als Engineering Manager bei einem aufstrebenden Startup namens PagerDuty . Nach der Finanzierungsrunde A im Jahr 2013 befand sich das Unternehmen in einem rasanten Wachstumsmodus und stellte in allen Bereichen aggressiv ein. Das Engineering-Team bestand damals aus weniger als 30 Mitarbeitern, und ein großer Anreiz für mich war (und ist es immer noch), die strukturellen Herausforderungen eines schnell wachsenden Unternehmens kennenzulernen. Da wir uns der Marke von 100 „Dutonians“ im Engineering nähern, erscheint es mir angebracht, zurückzublicken und die bisherigen Veränderungen zu reflektieren.

Die Entwicklung von Organisationsstrukturen ist ein faszinierender Prozess – voller Fehler, Sackgassen, Neuerfindungen und hoffentlich auch gewonnener Erkenntnisse. Es gibt zahlreiche Veröffentlichungen zu technischen Organisationen, die sich meist auf abstrakte Pro- und Kontra-Listen oder Blogbeiträge beschränken, die den jeweils aktuellen Prozess des Unternehmens loben. Ich möchte einen anderen Ansatz verfolgen 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 Ereignisse und Details wurden der Erzählung zuliebe vereinfacht dargestellt – viele davon sind eigene Beiträge wert. Setzen Sie ein Lesezeichen für diesen Blog, um über neue Inhalte informiert zu bleiben.

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 Datenaufnahme und Benachrichtigungsübermittlung verantwortlich (aufgeteilt in gemeinsam in SF und Toronto ansässige Teams) und entwickelte hauptsächlich mit Scala und Cassandra.
• Die DevOps-Richtlinien wurden nur teilweise eingehalten – das Operations-Team war für Warnmeldungen zur Infrastrukturüberwachung auf Abruf bereit, andere Teams Bereitschaft für den von ihnen bereitgestellten Code .

Während die Entwicklungsabteilung innerhalb kürzester Zeit von einer kleinen Handvoll Mitarbeiter auf mehrere verteilte Teams anwuchs, blieb der Produktentwicklungsprozess eher unausgereift. Trotz oberflächlicher Agilität mit Stand-ups und Sprints nutzten wir im Wesentlichen die Wasserfallmodell Die Unternehmensleitung definierte die zu bearbeitenden Projekte, teilte die einzelnen Ingenieure diesen Projekten zu und legte die geplanten Liefertermine fest. Wie vorherzusehen war, wurden diese Termine selten eingehalten, und die Tabellen zur Projektverfolgung befanden sich in einem ständigen Zustand der Vernachlässigung und wurden schließlich nicht mehr genutzt.

In der Praxis sah es nicht viel besser aus. Produktmanager starteten neue Projekte mit der Erstellung langer funktionaler Designspezifikationen und versuchten, mögliche Fragen zu antizipieren – eine Folge der geringen Interaktion zwischen Produkt- und Entwicklungsabteilung während der Entwicklung! Die Spezifikation wurde den Teams für Webanwendungen und Backend-Services präsentiert, die dann unabhängig voneinander an den benutzerorientierten und Backend-Aspekten arbeiteten. Neue Infrastrukturanfragen mussten bereits Wochen im Voraus an das Operations-Team gerichtet werden.

Die Integration all dieser Einzelanstrengungen in eine schlüssige Funktionsversion war ein Albtraum. Wir hatten fehlende oder unvollständige Infrastruktur, heikle Probleme, Funktionslücken (jedes Team glaubte, das andere kümmere sich darum), mangelnde Eigenverantwortung und Verantwortungsbewusstsein sowohl der Ingenieure als auch der Produktverantwortlichen, 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 weigerten, die Produktspezifikationen anzupassen.

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

• Webanwendung vs. Backend-Dienste. Zwischen den beiden Gruppen herrschte eine spürbare Spannung. Keine von beiden 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, weil das Ops-Team einen Engpass bei der Bereitstellung aller Server darstellte. Auch der Betrieb stand 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 anderen“-Stimmung. Beide Seiten fanden Grund zur Beschwerde.

Die starr definierten Verantwortlichkeiten ließen den Teams kaum Raum für funktionsübergreifende Zusammenarbeit. Wir experimentierten kurz mit dem Konzept von „Arbeitsgruppen“ – kleinen, temporären, vielfältigen Teams aus den bestehenden Teams, die an übergreifenden Projekten mit begrenztem Umfang und zeitlichem Rahmen arbeiten sollten. Diese Gruppen führten jedoch zu noch mehr Chaos, da sie die Hauptteams destabilisierten, und so wurde das Experiment abgebrochen.

Dennoch war die Notwendigkeit, zusammenzuarbeiten und konsistenter und vorhersehbarer zu liefern, von größter Bedeutung. Alle hatten die Silobildung satt, also musste sie abgeschafft werden. Wir hatten viel zu tun.

Die Matrixorganisation

Anfang 2015 erreichten die Unzufriedenheit mit dem Stand der Dinge und 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 spezifische Produktausrichtungen konzentrierten. Sie folgten dem Scrum-Prozess und bestanden aus Entwicklern der Webanwendungs- und Backend-Services-Teams sowie Produktbesitzern, Scrum-Mastern und UX-Designern.

Angesichts der nicht optimalen Produktentwicklung im Vorjahr wurden die neuen Teams für die Produktauslieferung 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 Bereitschaftspflichten . Darüber hinaus wurden die Produktteams von Basisteams versorgt – die Ingenieure wechselten von einem Team zum anderen, als die Arbeit an den Produkten intensiviert wurde.

Das 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 erschwerte natürlich das Leben aller enorm, da wir nun eine duale Berichtsstruktur hatten, 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 aufgelöst und nie wieder gesehen wurden. Web Application Engineers, die eng mit Backend Services Engineers zusammenarbeiteten, konnten über ihre Unterschiede hinwegsehen und gemeinsame Ziele verfolgen. Die meisten Teams waren nun auch geografisch verteilt, was die Zusammenführung der beiden Büros enorm erleichterte.

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

• Es war sehr schwierig, ein Team für die technische Wartung zusammenzustellen. Die Basisteams hatten Schwierigkeiten, langfristige Roadmaps zu entwickeln und sich mit der operativen Verantwortung für alle Produktionsdienste auseinanderzusetzen.
• Das Feeder-Modell hatte einen sehr realen Einfluss auf den Teamzusammenhalt . Es stellt sich heraus, 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 Transparenz hinsichtlich der täglichen Aktivitäten eines direkten Untergebenen, es gab zusätzlichen Kommunikationsaufwand zwischen Personalmanagern und Funktionsmanagern und allgemeine Verwirrung hinsichtlich 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 zur Softwarebereitstellung hat sich jedoch nicht geändert – Feature-Releases waren weiterhin Big-Bang-Angelegenheiten mit fragwürdigem Nutzen.
• Mehr Teams bedeuteten eine höhere Belastung für die Betriebsleute. Angesichts häufiger Infrastrukturanforderungen und zusätzlicher Bereitschaftsaufgaben für jeden neuen Dienst war dieser Ansatz offensichtlich nicht skalierbar.

Alles in allem waren wir immer noch in einer deutlich besseren Verfassung als vor einem Jahr. Aber es war noch ein weiter Weg.

Die agile Organisation

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

Anfang 2016 haben wir erneut umstrukturiert. „Vertikale“ Scrum-Teams waren nun für bestimmte Produktbereiche verantwortlich. „Horizontale“ Teams waren für übergreifende Produkt- oder Infrastrukturbelange zuständig und sollten Best Practices festlegen und anderen Teams schnelles Handeln ermöglichen. 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 programmieren 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 deutlich besser mit der Einstellung und Verwaltung von Remote-Ingenieuren vertraut gemacht. Da die räumliche Distanz kein Hindernis mehr darstellte, konnten wir Manager Teams ohne Dotted-Line-Beziehungen zuordnen.
• 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, in sich zu gehen 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 investiert, um die Produktlieferteams zu stärken, einschließlich der Bereitstellung von 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 operativen Bereich in die entsprechenden Teams, die die eigentlichen Hosts verwalten (und die Probleme ohnehin schneller lösen können).

Das Thema GSD ist es wert, etwas tiefer zu vertiefen. Durch die Praxis haben wir uns immer mehr mit den Ideen der Teamautonomie vertraut gemacht, Innovation statt Erfindung und Unternehmen bringen Probleme mit sich, die gelöst werden müssen, statt Lösungen zu implementieren. Es ist nicht leicht, sich von der Vorstellung zu lösen, wir wüssten, was das Beste für die Kunden ist. Ein Laserfokus auf die Bereitstellung der minimal funktionsfähiges Produkt , sofortiges Feedback einzuholen und es in den Entwicklungszyklus zu integrieren, war entscheidend. Dadurch konnten wir schnell iterieren, den Wert maximieren, Goldplating minimieren und die Zeit bis zur Auslieferung eines Prototyps an den Kunden 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 Anzahl 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 eine gemeinsame Mission miteinander verbunden sind. Diese Vereinbarungen haben Vorteile wie geteilte Eigentümerschaft, geteiltes Wissen, eine gemeinsame Roadmap (getrennt von den Backlogs der einzelnen Teams) und eine gemeinsame Vision gebracht. Wir experimentieren noch mit der Organisation von Stammesgruppen – bleiben Sie dran für zukünftige Updates zu unseren Erfahrungen mit Stammesgruppen.

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

Gelernte Lektionen

Wenn ich an einige der Entscheidungen zurückdenke, die wir in der Anfangsphase getroffen haben, und an einige der unangenehmen Zwischenstadien, 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 Mitarbeiter 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 Missstimmungen. Geben Sie Ihren Teams die Möglichkeit, ohne Wartezeiten zu liefern, und Sie werden deutliche Produktivitätssteigerungen feststellen.

• Minimieren Sie Änderungen an der Teamzusammensetzung Die geschäftliche Realität erfordert gelegentlich die Verlagerung von Ressourcen. Überlegen Sie es sich gut, bevor Sie Mitarbeiter versetzen, da dies die Teammoral und Produktivität erheblich beeinträchtigen kann.
• Überbetonte Teamverantwortung und Verantwortlichkeiten nicht vorschreiben Flexibilität führt hier zu längerfristigen Erfolgen. Ermutigen Sie Ihre Teams, ihre Probleme selbst zu lösen, und Sie werden mit den beiden vorherigen Punkten weniger Probleme haben.
• Haben Sie keine Angst vor kontinuierlichem Lernen und Experimentieren Dies gilt für alles – Code, Prozesse, Organisation. Man wird nicht besser, wenn man immer wieder die gleichen Dinge tut.
• Agile Prozesse sind schön, eine agile Kultur ist besser r. Standups und Sprint-Reviews bringen allein keinen großen Mehrwert. Die Konzentration auf ein minimal funktionsfähiges Produkt, schnelle Feedbackschleifen und Zusammenarbeit erfordert einen Kulturwandel, maximiert aber den Kundennutzen.
• 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 eignen sich am besten für die Produktlieferung 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 Projektübergaben durchführen zu müssen. Fachteams haben zwar ihre Berechtigung, sind aber eher im Rahmen der zuvor besprochenen „horizontalen“ Teams anzusiedeln.
• Stellen Sie Generalisten ein, die kann in jeder Umgebung funktionieren. Teammitglieder sollten sich nicht an bestimmte Tools, Frameworks und Stacks binden, wenn sich Technologien und technische Entwicklungen ändern. Die besten Voraussetzungen für ein erfolgreiches Wachstum in einem wachstumsstarken Umfeld sind diejenigen, die sich auf das Lernen und den Einsatz der richtigen Tools konzentrieren. Bieten Sie daher Lern- und Entwicklungsmöglichkeiten.
• 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, dass „ Durch die Bildung eines Remote-Teams können Sie den Kreis der Personen erweitern, die Sie ins Team holen können. Ein Remote-Team ist möglicherweise weniger produktiv als dasselbe Team, das an einem gemeinsamen Standort arbeitet, aber möglicherweise immer noch produktiver als das beste Team, das Sie an einem gemeinsamen Standort bilden können. „Mit anderen Worten: Wenn Sie Mitarbeiter aus der Ferne zulassen, entsteht ein viel größerer Bewerberpool, sodass Sie insgesamt ein stärkeres Team aufbauen können.

Mit dem Wachstum und der Reifung von Organisationen besteht die Tendenz, langsamer zu werden, zu verkrusten und konservativer zu werden. Durch kontinuierliche Verbesserung und Weiterentwicklung unserer Praktiken ist es uns gelungen, dem Trend entgegenzuwirken und mit der Zeit agiler, pragmatischer und produktiver zu werden – und Sie können das auch.

Auf drei (und viele) weitere Jahre des Lernens!