Wie Engineering-Leadership in einem Team von 14 wirklich aussieht

Bei der Entstehung dieses Beitrags wurde kein Organigramm neu gezeichnet.

Es gibt einen Beitrag aus dem Software-Leads-Newsletter über die täglichen Aktivitäten von Engineering-Leads, den wir intern herumgereicht haben. Seine These: Managementarbeit wirkt neben dem Schreiben von Code unsichtbar, ist aber nicht formlos. Sie ist ein Zyklus aus sechs Aktivitäten, der sich den ganzen Tag wiederholt: Informationen sammeln, sie teilen, Entscheidungen treffen, Entscheidungen beeinflussen, die man nicht selbst verantwortet, Richtung vorgeben und planen.

Wir haben jede einzelne davon wiedererkannt. Uns ist aber auch aufgefallen, dass wir fast keine davon so machen, wie das Framework es stillschweigend voraussetzt, denn das Framework ist für eine Führungskraft in einer größeren Organisation geschrieben. Wir sind 14 Entwickler und Designer, seit 2023 vollständig remote, und wir liefern neben Kundenprojekten eigene Produkte aus.

Im Folgenden also dieselben sechs Aktivitäten und wie sie in unserer Größe tatsächlich aussehen. Einige werden leichter. Ein paar werden auf eine Weise schwerer, vor der Sie niemand warnt.

Informationen sammeln

Einen Punkt aus dem Artikel würden wir doppelt unterstreichen: Alles Weitere ist nur so gut wie das, was Sie zuerst sammeln. Schlechte Eingaben, schlechte Entscheidungen – und Sie merken es wochenlang nicht.

In einem größeren Unternehmen ist das eine echte Aufgabe. Sie ziehen Kontext aus Skip-Level-Gesprächen, Dashboards, Incident-Reviews und drei Teams, die dasselbe Problem jeweils anders beschreiben.

In unserer Größe kommt das meiste von allein. Wir haben darüber geschrieben, wie wir unsere Stand-ups halten, und dieses Meeting leistet hier mehr als alles andere, was wir tun. Fünfzehn Minuten am Tag, in denen Leute teilen, was interessant ist, statt Status zu berichten. Daraus entsteht ein laufendes Bild vom Team, das Ihnen kein Dashboard liefert. Sie hören das Zögern, bevor jemand sagt: „Passt schon.“

Der Haken: Das funktioniert nur, weil wir klein genug für einen Raum sind. Es skaliert nicht, und das wissen wir. Wir haben Kunden dabei zugesehen, wie sie die Größe erreichten, ab der informeller Kontext nicht mehr von allein ankommt, und ein Quartal lang merkt es niemand, weil sich das Fehlen von Information nicht ankündigt. Wenn in Ihrem Stand-up 25 Leute sitzen, haben Sie das nicht mehr. Sie haben ein Statusmeeting, das sich Stand-up nennt.

Informationen teilen

Hier hört Kleinsein auf zu helfen und fängt an, Sie aktiv zu belügen.

Wenn alle alles hören, gehen Sie davon aus, dass alle alles wissen. Tun sie nicht. Jemand war im Urlaub. Jemand steckte zwei Wochen lang bis über beide Ohren in einer Migration. Jemand ist letzten Monat dazugekommen und hat keine Ahnung, dass das, was Sie alle „das alte Abrechnungsding“ nennen, eine bewusste Entscheidung war und kein Unfall.

Unsere Regel aus dem Stand-up-Beitrag deckt das ab: Es ist flüchtig, und alles Kritische muss schriftlich wiederholt werden. Diese Regel gibt es, weil wir es falsch gemacht haben. Wir hatten Entscheidungen, auf die sich alle Anwesenden geeinigt hatten, die niemand aufschrieb und die einen Monat später von Leuten neu aufgerollt wurden, die schlicht nicht im Raum waren. Zweimal.

Mehr Meetings helfen nicht. Was hilft: akzeptieren, dass mündlicher Kontext nach etwa einer Woche verfällt, und die wenigen Dinge aufschreiben, die länger halten müssen.

Entscheidungen treffen

Der schärfste Satz des Artikels: Auf Gewissheit zu warten ist selbst eine Entscheidung, und sie hat ihren eigenen Preis.

Wir würden die Kleinteam-Version ergänzen. Mit 14 Leuten sind die Kosten einer falschen, umkehrbaren Entscheidung wirklich gering. Sie können etwas ausprobieren, es hassen und innerhalb eines Sprints rückgängig machen. Die Kosten einer langsamen Entscheidung sind viel höher, als sie aussehen, weil das ganze Team davon blockiert ist und es keinen anderen Arbeitsstrang gibt, der die Verzögerung auffängt.

Also neigen wir stark dazu, alles Umkehrbare schnell zu entscheiden und alles andere langsam. Datenbankschema, Framework-Wahl, alles, was Kundendaten berührt: langsam, schriftlich, ausdiskutiert. Welche Library, welche Ordnerstruktur, wie wir Dinge benennen: im Stand-up entscheiden, weitermachen, neu ansehen, wenn es wehtut.

Wir liegen nicht immer richtig damit, in welche Schublade etwas gehört. Das Warnsignal ist meist, dass eine „kleine“ Entscheidung immer wieder zurückkommt. Wenn etwas Umkehrbares dreimal neu aufgerollt wird, war es nicht umkehrbar, und wir haben es falsch eingeschätzt.

Entscheidungen beeinflussen, die man nicht selbst verantwortet

Für eine Führungskraft innerhalb eines Unternehmens heißt das: Nachbarteams. Für uns heißt es meist: der Kunde.

Das ist die Aktivität, in die wir die meiste Zeit stecken, und die, in der wir anfangs am schlechtesten waren. Wir gaben eine technisch korrekte Empfehlung ab, sahen zu, wie sie abgelehnt wurde, und schlossen daraus, der Kunde habe es nicht verstanden. Was tatsächlich passierte: Wir beantworteten eine Frage, die niemand gestellt hatte. Den CTO trieb nicht die technische Qualität um, sondern ein Board-Meeting in fünf Wochen.

Der Artikel nennt das: verstehen, welche Ziele, Zwänge und Anreize Ihr Gegenüber hat. Genau darum geht es. Eine Empfehlung, die jemandes tatsächliche Einschränkung ignoriert, ist keine Empfehlung, sondern eine Beschwerde mit angehängtem Diagramm.

Was sich für uns geändert hat: Wir knüpfen das technische Argument an das, woran die Person tatsächlich gemessen wird. „Das fällt uns später auf die Füße“ bewegt niemanden. „Das kostet jetzt zwei Wochen oder etwa sechs Wochen im Q4, wenn Sie gerade die Finanzierungsrunde abschließen wollen“ ist ein Satz, mit dem jemand etwas anfangen kann. Wie eine Variante davon schiefgehen kann, haben wir in der Velocity-Metrik, die unseren Kunden leise kaputtgemacht hat beschrieben.

Richtung vorgeben

Das Framework beschreibt, wie man organisatorische Prioritäten in etwas übersetzt, womit das Team arbeiten kann, und wie man die Standards vorlebt, die man erwartet.

Die erste Hälfte bekommen wir fast geschenkt. Es gibt keine Schicht zwischen denen, die entscheiden, was gebaut wird, und denen, die es bauen, also müssen Prioritäten kaum übersetzt werden. Das ist ein echter Vorteil des Kleinbleibens, und wir haben nicht vor, ihn aufzugeben.

Bei der zweiten Hälfte spielt die Größe keine Rolle. Wenn wir sagen, Zeitpläne seien ehrlich, und dann stillschweigend jede Schätzung aufpolstern, lernen alle die tatsächliche Regel in etwa zwei Wochen. Wenn wir sagen, das Stand-up sei kein Berichtsmeeting, und dann nutzt ein Gründer es, um den Fortschritt zu prüfen, dann ist es jetzt ein Berichtsmeeting, egal, was in der Doku steht.

Arheev zu bauen erwies sich als die direkteste Form davon. Wenn Sie Ihr eigenes Produkt mit Ihrem eigenen Prozess betreiben, wird die Lücke zwischen dem, was Sie behaupten, und dem, was Sie tun, sehr konkret. Wir fanden mehrere Stellen, an denen unser Rat an Kunden besser war als unsere eigene Praxis.

Planen

Von dort, wo Sie stehen, dorthin kommen, wo Sie hinwollen, in konkreten Schritten.

Unsere Version ist bewusst kurzfristig: zweiwöchige Sprints mit funktionierender Software am Ende und eine erste funktionierende Demo nach zwei bis vier Wochen. Nicht, weil langfristige Planung wertlos wäre, sondern weil in unserer Größe die Genauigkeit eines Plans nach etwa einem Monat ins Bodenlose fällt. Wer etwas anderes vorgibt, erzeugt nur ein Dokument, mit dem sich alle organisiert fühlen.

Das Einzige, was wir langfristig planen, sind Menschen. Wer woran arbeitet, wer sich zu langweilen beginnt, wer seit sechs Monaten nichts Neues angefasst hat. Das hat eine viel längere Vorlaufzeit als jede technische Entscheidung, und hier wird Zuspätkommen wirklich teuer.

Was wir daraus mitnehmen würden

Die sechs Aktivitäten halten stand. Wir würden sagen, das Framework beschreibt etwas Reales und weitgehend Unsichtbares, und allein das macht es lesenswert.

Was es nicht sagt und was wir ergänzen würden: In einem kleinen Team werden drei davon von selbst leichter, und Sie sollten das nicht damit verwechseln, sie gelöst zu haben. Informationen kommen von allein – bis sie es nicht mehr tun. Richtung braucht keine Übersetzung – bis es eine Schicht gibt, die sie braucht. Die beiden, die nie leichter werden, egal wie groß das Team ist, sind Entscheidungen zu beeinflussen, die man nicht selbst verantwortet, und den Standard vorzuleben, den man zu halten behauptet.

Das sind auch die beiden, in denen Sie schon morgen besser werden können, ohne irgendetwas umzustrukturieren.

Keine Frameworks kamen zu Schaden. Einigen wurde sanft widersprochen.