Umstrukturierung des Braze-Produktteams

Die wichtigste treibende Kraft hinter jedem Softwareprodukt ist die Gruppe von Menschen, die es entwickeln – und ihre Beziehungen untereinander. Daher ist es wichtig, Teams so zusammenzustellen, dass sie so viel Einfluss und Einfluss wie möglich haben.

Bei Braze haben wir ausführlich darüber nachgedacht, wie unsere Produkt- und Entwicklungsorganisation aufgebaut ist, und möchten unsere Erkenntnisse aus einer umfassenden Umstrukturierung der Abteilungen teilen, die uns geholfen hat, die Priorisierung von Funktionen, die Entwicklung von Team-Expertise und die effizientere Entwicklung unseres Produkts erheblich zu verbessern.

Frühe Struktur: Product/Market Fit und darüber hinaus

Die Suche nach Produkt-/Marktpassung – und deren Nutzung für das Wachstum eines Unternehmens – ist ein Schmelztiegel, den alle Startups durchlaufen müssen. In dieser Phase der Entwicklung eines Startups sind Experimentiergeschwindigkeit und die Fähigkeit, Chancen schnell zu nutzen, von entscheidender Bedeutung. Zu diesem Zweck sah unsere ursprüngliche Produktteamstruktur folgendermaßen aus:

Diese Struktur, die unser Team nach funktionalen Fachgebieten aufteilt, hat aus mehreren Gründen gut funktioniert.

Erstens ermöglichte es uns, transformative Produktänderungen auf dem Weg zum Product/Market Fit effizient anzugehen – Experten konnten große Teile unserer Codebasis besitzen und die Sprachen, Frameworks und Designentscheidungen verwenden, mit denen sie am vertrautesten waren. Angetrieben von enormen Mengen an Koffein, nahmen „Armee-aus-Einem“-Projekt-„Teams“ regelmäßig große Unternehmungen in Angriff. Dazu gehörten der Aufbau unserer kundenorientierten öffentlichen API und die Überarbeitung unserer gesamten Infrastruktur zum Senden von Nachrichten, wobei wir häufig die Rolle des alleinigen Ingenieurs, Produktmanagers und Designers übernahmen. Solche extremen Maßnahmen wären in einem großen Unternehmen Wahnsinn, sind aber im frühen Wachstum notwendig und fast schon Routine.

Darüber hinaus half uns diese Struktur, mit einem Team von nur 10 bis 15 Personen bestimmte technische Bereiche tiefgreifend zu beherrschen. Viele Elemente unserer Kernprodukte – z. B. die Model-View-Controller-Schicht unseres Front-Ends, APIs und Nachrichtensendecode mit hohem Durchsatz – wurden nur von wenigen Personen vollständig verstanden.

Damals war es einfach und alles, was wir brauchten. Wenn Geschwindigkeit alles ist, half die Organisation auf der Grundlage einfacher Richtlinien, den kognitiven Overhead zu reduzieren, und ermöglichte es uns, die Aufmerksamkeit darauf zu lenken, wo sie am meisten bewirken könnte.

Spätere Struktur: Wachstum und Skalierung

Als unser Team jedoch über 30 oder 40 wuchs, begann diese Struktur aufzubrechen. Letztendlich haben wir die Reorganisation unseres Produktteams als Lösung für einige unserer größten Herausforderungen identifiziert. Wir haben unhaltbare Anstrengungen unternommen, um mit Fähigkeiten und Zeitplänen zu jonglieren, um Teams für strategische Projekte zusammenzustellen. Wir verbrachten auch übermäßig viel Zeit mit der Priorisierung und fanden uns oft dabei, alle Produktprioritäten im gesamten Unternehmen zu erzwingen, da unsere technologiebasierte Teamstruktur nicht direkt auf die wichtigsten Produktanforderungen abgestimmt war. Und schließlich hatten wir nur wenige Möglichkeiten für Teammitglieder, tiefgreifende Erfahrungen mit bestimmten Kundenanwendungsfällen zu sammeln.

Wir wechselten schließlich zu einer Organisation, die um agile, funktionsübergreifende Teams herum strukturiert ist, ähnlich dem von Spotify populären Squad/Tribe-Modell. Unsere neue Organisationsstruktur sieht folgendermaßen aus:

Die Mehrheit unseres Teams arbeitet in „Produktvertikalen“, die einem Schlüsselbereich unseres Produkts oder Geschäfts entsprechen. Zum Beispiel:

• Unser E-Mail- und Enterprise-Team betreibt E-Mail von oben nach unten sowie bestimmte Produktbereiche wie die Berechtigungsverwaltung, die für viele unserer größten Kunden von entscheidender Bedeutung sind.
• Unser Messaging- und Automatisierungsteam besitzt mehrere Produktbereiche in Bezug auf Benutzersegmentierung, Messaging und unser Flaggschiff-Orchestrierungsprodukt Canvas.

Innerhalb einer Branche erwarten wir, dass die Priorisierung (relativ) einfach ist, da jede Branche einem bestimmten Satz von Kundenanforderungen entspricht. Bestimmte Teams wie Visual Design, DevOps und unsere Infrastructure Engineering-Gruppen umfassen die gesamte Plattform und sorgen für Konsistenz in Schlüsselbereichen.

Auswirkungen

Unsere Reorganisation hat die teamübergreifenden Abhängigkeiten deutlich reduziert. Früher hatten wir mit dem Sudoku-ähnlichen Planungsproblem zu kämpfen, das richtige Gleichgewicht zwischen spezialisierten Fähigkeiten (Engineering, Design, Produktmanagement usw.) für ein bestimmtes Projekt zu einem bestimmten Zeitpunkt zu finden. Es stimmte auch kurzfristige Anreize ab – vor der Umstellung mussten sich Teams oft auf Gegenparteien verlassen, die nicht zusammenhängende Ziele anstrebten. Mit unserer neuen Struktur sind Produktteams unabhängig, haben viel mehr Kontrolle über Zeitpläne und sind vollständig auf Ziele ausgerichtet, was die Produktivität und Moral erhöht.

Das neue Organisationsdesign verbesserte auch die Priorisierung. Beispielsweise muss sich unser E-Mail- und Unternehmensteam möglicherweise entscheiden, ob Sie unsere E-Mail-Infrastruktur aktualisieren, eine zentrale E-Mail-Funktion erstellen oder ein Problem mit der Benutzerfreundlichkeit des Unternehmens beheben möchten – eine unkomplizierte und leicht quantifizierbare Entscheidung, da sich alle drei auf ähnliche Weise auf die Bedürfnisse unserer Kunden beziehen .

Ein Team, das mit zu vielen Anforderungen mit hoher Priorität zu kämpfen hat, ist auch ein Indikator dafür, dass sein Produktbereich mehr Ressourcen benötigt. Dies ermöglicht es uns, schwierige Priorisierungsprobleme in Personalbedarf umzuwandeln, der immer noch eine Herausforderung darstellt, aber konzeptionell einfach zu lösen ist.

Schließlich hat die Fokussierung der meisten Teams auf einen bestimmten Produktbereich es Einzelpersonen ermöglicht, im Laufe der Zeit fundiertes Fachwissen und hochproduktive Arbeitsbeziehungen aufzubauen. Anfangs, in den ersten Jahren des Aufbaus, konnten Einzelpersonen im Wesentlichen das gesamte Produkt und die Codebasis in ihren Köpfen behalten, aber als wir wuchsen, wurde dies unmöglich. Produktprobleme sind fraktal: Jedes Mal, wenn Sie genauer hinsehen, finden Sie mehr Nuancen und Tiefe. Viele Stunden in einem bestimmten Bereich eines Produkts oder einer Codebasis zu verbringen und seine Geschäftsanforderungen genau zu verstehen, ist daher eine der besten Möglichkeiten, um echte Produktdurchbrüche zu erzielen. Darüber hinaus baut die Bildung fokussierter langfristiger Teams Eigenverantwortung und Beziehung auf und ermöglicht es, dass unausgesprochene Arbeitsbeziehungen zwischen einer konsistenten Gruppe von Mitarbeitern entstehen.

Natürlich ist kein System perfekt. Mit einem Fokus auf produktorientierte Säulen haben wir das Potenzial für Teams erhöht, auf Kosten ganzheitlicher Prioritäten für lokale Bedürfnisse zu optimieren. Beispielsweise könnte man sich auf lokalisierte Technologieschulden konzentrieren („dieser Controller ist umständlich“) anstatt auf globale Probleme („eine Änderung unseres Front-End-Frameworks würde die allgemeine Entwicklungsgeschwindigkeit erhöhen“). In Erwartung dieses Bedarfs haben wir Schritte unternommen, um die oben erwähnten Querschnittsteams einzurichten, und haben spezielle Komitees für andere umfassende Projekte eingesetzt – zum Beispiel ein Komitee zum Aufbau eines ganzheitlichen Produkt-/Designsystems aus Front-End-Komponenten und Designmustern .

Unsere neue Struktur bringt auch eine höhere Aktivierungsenergie für ganzheitliche, transformative Produktänderungen. Einige Bereiche unseres Produkts, wie z. B. unsere Back-End-APIs, befinden sich im gemeinsamen Besitz mehrerer Teams. Die Schwelle für umfassende Änderungen an breiten, bereichsübergreifenden Bereichen unserer Codebasis ist höher, daher funktioniert diese Art von Struktur am besten, sobald das Skelett Ihres Produkts weitgehend gebildet ist.

Imbiss

Insgesamt sind wir mit unserer neu gestalteten Produktorganisationsstruktur zufrieden: Wir haben unsere Herausforderungen in Bezug auf Teamabhängigkeiten, Priorisierung und den Aufbau langfristiger Produktexpertise gelöst oder erheblich verbessert und verfügen außerdem über einen hilfreichen Fahrplan für unsere Skalierung. Insbesondere haben wir Folgendes gelernt:

• Die Beseitigung von Abhängigkeiten und die Ausrichtung von Anreizen führt zu enormen Effizienzgewinnen.
• Die Priorisierung von Äpfeln zu Äpfeln ist sowohl einfacher als auch effektiver.
• Tiefes Fachwissen über einen bestimmten Kunden- oder Geschäftsbedarf führt zu besseren Produktergebnissen.
• Die Zusammenarbeit mit denselben Teammitgliedern über einen längeren Zeitraum ist entscheidend für den Aufbau großartiger Arbeitsbeziehungen.

Ich würde diese Struktur jedem Team empfehlen, das bestimmte Schlüsselmerkmale teilt: eine funktionsübergreifende Organisation, in der Funktionsexperten wie Produktmanager, Designer und Ingenieure gleichberechtigte Interessengruppen sind; mehr als etwa 15–20 Personen im kombinierten Produktentwicklungsteam; und, was am wichtigsten ist, ein fester Produkt-Market-Fit. Und wenn diese Art von Teamstruktur für Sie attraktiv klingt, stellen wir ein!