Bildung/Aufteilung neuer technischer Teams bei FloQast: Die Sichtweise eines Ingenieurs

In meiner kurzen Zeit in dieser runden Welt habe ich zwei Wahrheiten im Leben verstanden.

1. Die Mitochondrien sind das Kraftwerk der Zelle.
2. Phänomene aus der natürlichen Biologie werden zur Beschreibung von Produktentwicklungsteams verwendet.

Bei FloQast hatte ich die Gelegenheit, nicht nur an einem, sondern an zwei Team-Splits teilzunehmen. Hier sind einige spannende Herausforderungen, die ich durch diese natürliche Entwicklung der Teambildung gefunden habe.

A Kleine Kerne

In einem früheren Artikel habe ich über unser Produkt, FloQast ReMind, und die Lernkurve gesprochen, die mit dem Start einer neuen Anwendung in unserem kleinen Team einherging. Mit Zeit, unermüdlichem Einsatz und einer gesunden Feedback-Schleife haben wir etwas geschaffen, das unsere Kunden begeistert hat, und verständlicherweise wollten sie mehr!

Nachdem wir festgestellt hatten, dass unser Produkt zum Markt passt, befassten wir uns eingehender mit dem Feedback unserer Kunden. Wir bemerkten wiederkehrende Trends in der Nachfrage der Nutzer:

"Wann wird diese Funktion integriert sein?" - Kunde A

"Ich möchte das mit ReMind machen, wann wird das verfügbar sein?" - Kunde B

"Das ist ein Muss, bevor ich mich entscheide, dieses Produkt zu verwenden." - Kunde C

Wie Sie sich vorstellen können, führte dies zu einer erheblichen Ausweitung der Produkt-Roadmap. Wir wollen nicht, dass unsere Kunden um unsere Entwicklungszeit konkurrieren. Um dies abzumildern, haben wir unser kleines Team vergrößert.

Neue Teamkollegen, neue Einsichten und andere Herausforderungen

Unser Team hatte in jedem Sprint einen konstanten Output (auch bekannt als Velocity), der uns eine allgemeine Vorstellung davon vermittelte, wann wir mit der Lieferung von Arbeit rechnen konnten. Jeder Sprint belief sich auf etwa 15 Arbeitspunkte. Auch wenn wir in diesem gleichmäßigen, leistungsstarken Tempo arbeiteten, dauerte es Monate, bis wir die Kundeninteressen am Ende der Roadmap in Angriff nehmen konnten.

Wenn man ein kleines Team ist, fühlt es sich an, als sei die Kavallerie eingetroffen, wenn man mehr Ingenieure einstellt. Als wir im letzten Winter drei weitere Ingenieure einstellten, erwartete ich, dass sich unsere Leistung dramatisch beschleunigen würde. Interessanterweise stellte ich fest, dass dies kontraproduktiv für die Verbesserung der Geschwindigkeit unseres Teams war.

Früher, als wir noch zwei Ingenieure hatten, konnten wir den Code an einem einzigen Tag veröffentlichen. Mit fünf Ingenieuren fühlten sich unsere Code-Reviews eher wie eine Stack Overflow-Diskussion an, bei der jeder versuchte, seine Lösungen anzubieten. Wie sich herausstellte, hatte jeder Ingenieur seine eigenen Ideen, wie die Arbeit zu erledigen war. Es dauerte mehrere Tage, bis wir uns auf eine Lösung einigen konnten und der Code schließlich in Produktion ging. Leider wurden dadurch die Probleme unserer Kunden nicht schneller gelöst.

Die Mathematik

Wenn das Team wächst, entsteht auch ein kognitiver Aufwand, um sicherzustellen, dass Wissen und Perspektiven geteilt werden.

Sie können sich das wie einen Algorithmus vorstellen. Jedes Mal, wenn Sie eine neue Person in ein kleines Team aufnehmen, müssen Sie für jedes bestehende Teammitglied eine neue Kommunikationslinie schaffen. Bevor Sie jetzt sagen: "Chris, diese Mathematik macht keinen Sinn", lassen Sie mich das bitte anhand des Codes erklären:

let initialMembers = 0 
let projectedMembers = 5
let totalUniquePairs = 0

while(initialMembers < projectedMembers){
    totalUniquePairs+= initialMembers // establish new pairs with new team member
    initialMembers++ // team member is integrated
}

console.log("Unique pairs:", totalUniquePairs) // 10

Und für meine visuell begabten Mitmenschen:

Das Team wuchs von 2 auf 7 Ingenieure. Dies ermöglichte es uns jedoch nicht, mehr Code zu liefern. Stattdessen hatten wir mehr Meetings und asynchrone Gespräche, um Wissenslücken zu schließen und uns auf die gleiche Seite zu stellen.

Mehr Teammitglieder in einem einzelnen Pod bedeuten nicht unbedingt ein effizienteres Team. Stattdessen gibt es mehr Gespräche darüber, wie wir effizienter und produktiver sein können. Mit mehr Teammitgliedern werden die Vorteile der Aufteilung noch größer.

Aufteilung und Disambiguierung

Rückblickend empfehle ich dringend, ein Engineering Requirement Document (ERD) zu verwenden, um die Aufteilung des Teams zu erleichtern. Ein ERD hilft dabei, wichtige Themen abzudecken, wie z. B.:

• Wer ist Eigentümer dieser bestehenden Datensammlungen?
• Wird es neue Datensammlungen oder APIs geben, um unsere Arbeitsvereinbarung zu erleichtern?
• Wie lauten die Datenverträge zwischen diesen Pods?

Verschiedene Pods, gleiches Team

Die Aufteilung eines Teams geschieht nicht über Nacht. Unsere Pods sind mit unterschiedlichen Aufgaben betraut und haben die Verantwortung für ihre Geschäftsfunktionen, aber die restlichen Funktionen müssen noch geklärt werden. Vor der Aufteilung des Teams hatten wir einen Dienst, der Dokumente erfasst, aber wir haben festgestellt, dass es für den neuen Pod effektiver ist, diese API zu besitzen. Es hat einige Zeit gedauert, bis der neue Pod diese API neu aufgebaut und in die Produktion überführt hat. Wir mussten zusammenarbeiten, um sicherzustellen, dass es zu keinen Ausfällen für den Kunden kommt.

Die neuen Teams haben ein wöchentliches Technical Sync Meeting, um Fortschritte und Entdeckungen zu besprechen. Die Teammitglieder verwenden ein Google-Dokument, um einen Plan mit Diskussionspunkten zu erstellen, und werden ermutigt, diesen vor der Sitzung auszufüllen. Diese Praxis hilft uns, über die gesamte Produktentwicklung informiert zu bleiben.

Meiner Erfahrung nach teilen wir ein Team nicht aus Gründen der Unterscheidung oder der Neuartigkeit auf. Wir teilen Teams auf, damit wir bei der Produktumsetzung agil sein können und die Unterstützung unserer Kunden oberste Priorität hat. Heute können die neuen Teams gleichzeitig verschiedene Kundenbedürfnisse lösen und gleichzeitig einen Beitrag zum größeren Technologie-Ökosystem leisten.

Ich hoffe, dies hat Ihnen einen Einblick gegeben, wie die Teamaufteilung bei FloQast abläuft. In Kürze werden wir einen Artikel veröffentlichen, der beschreibt, wie wir die Team-Mitose in der Praxis durchführen.

Christopher Ngo

Chris ist ein Software-Ingenieur. Er versucht sein Bestes, informative und geschmackvolle Artikel über seine Projekte zu schreiben. Englisch ist seine erste Sprache, aber es lässt noch viel zu wünschen übrig.