Die Bedeutung der schriftlichen Kommunikation für Ingenieurteams

Während gute technische Manager programmieren können, können großartige auch kommunizieren.

Insbesondere die schriftliche Kommunikation ist ein wesentlicher Bestandteil des Managements und der Skalierung von Ingenieurteams, sagt Juan Pablo Buritica, der mehrere erfolgreiche Ingenieurteams geleitet hat, zuletzt als VP of Engineering beim Musikunternehmen Splice.

Experten wie Buritica wissen, dass sich mit wachsendem Engineering-Team auch die Arbeitsabläufe, Prozesse, Entscheidungsrhythmen – sogar die Projektstrategien – ändern. Die Systeme, die für ein Team von zwei Personen funktionieren, funktionieren nicht unbedingt für ein Team von 40 Personen, und die Prozesse, die für ein Team am selben Ort effizient sind, funktionieren möglicherweise nicht für ein verteiltes Team.

Um Engineering-Teams erfolgreich zu vergrößern und zu skalieren, schlägt Buritica vor, eine Bibliothek mit Praktiken zu erstellen, die an einem für alle zugänglichen Ort geschrieben und gespeichert werden, sei es auf Google Drive oder einem Wissensmanagement-Tool wie Confluence oder Guru.

Durch die Erstellung dieser Dokumente – und die Ermutigung seiner Teammitglieder, ihre eigenen Ideen hinzuzufügen – konnte Buritica nicht nur sein Team bei Splice in 18 Monaten von fünf auf 50 Mitarbeiter vergrößern, sondern auch seine Produktlieferzeit von sechs Monaten auf sechs Wochen verkürzen.

Hier ist seine dreistufige Strategie zur Nutzung schriftlicher Kommunikation zur Verbesserung der Leistung des Ingenieurteams:

1. Schaffen Sie vom ersten Tag an Kommunikations- und Entscheidungsrahmen

Kommunikations- und Entscheidungsrahmen sind Dokumente, die festlegen, wie ein Team arbeiten wird. Sie können je nach Art des Problems einfach oder komplex sein. Dokumente zur Kommunikation können beispielsweise einfach sein, aber diejenigen, die eine Strategie skizzieren, können ausführlicher sein. In jedem Fall ist es wichtig, sie zu erstellen, egal wie klein das Team ist, damit die Prozesse und Richtlinien aufgezeichnet werden, bevor die Gruppe zu groß wird.

Eines der grundlegenden Dokumente ist das, was Buritica eine Kommunikationsarchitektur nennt: Regeln darüber, wie das Team kommuniziert – ob über Slack, Microsoft Teams, E-Mail, Telefonanrufe und/oder Zoom – und Erwartungen bezüglich der Antwortzeiten.

Nehmen wir zum Beispiel an, ein Entwicklerteam findet nächtliche Nachrichten auf Slack störend. In der Kommunikationsarchitektur würde Buritica detailliert beschreiben, wie Ingenieure reagieren sollten, wenn jemand sie nach Feierabend anpingt. Vielleicht ist vereinbart, dass niemand nach 18:00 Uhr auf eine Slack-Nachricht antworten soll. Wenn es sich um einen Notfall handelt, kann das Protokoll einen Text- oder Telefonanruf empfehlen.

Um zu dieser Lösung zu kommen, so Buritica, sei der erste Schritt, das Team zu dem Thema zu befragen: „Wie sollen wir miteinander reden? Wie sollen wir unsere Verfügbarkeit kommunizieren? Was funktioniert nicht? Was kann besser funktionieren? Wie sollen wir mit Notfällen umgehen?“

„Jeder hat die Möglichkeit, Vorschläge zu machen, und ich werde mit einem Entwurf konsolidierter Vorschläge zurückkommen“, sagt er. „Dann besprechen wir es als Team, führen es ein und testen es.“

Nachdem er den ersten Entwurf veröffentlicht hat, arbeitet das Team einige Wochen lang innerhalb des vorgeschlagenen Rahmens, um zu bewerten, wie der neue Prozess funktioniert. Im Laufe der Zeit integrieren sie weitere notwendige Änderungen in das Dokument, bis es den Standardbetrieb definiert.

Als weiteres Beispiel erstellte Buritica bei Splice ein Strategiedokument, um zu beschreiben, wie das Engineering-Team seine Geschäftsziele erreichen wollte. Das Ziel bestand darin, die Produktlieferung durch schnellere Versandsoftware zu beschleunigen, was bedeutete, dass das Team Reibungsverluste reduzieren musste. Das Strategiedokument skizzierte die notwendigen Schritte, „und wir begannen mit der Pilotierung, dem Testen, dem Berichten und dem Reden über unsere Ideen“, sagt er. „Alle begannen, an dem Dokument mitzuarbeiten, und wurden wirklich motiviert.“ Schließlich erreichte das Team sein Ziel und verkürzte die Lieferzeit von sechs Monaten auf sechs Wochen.

Das Schreiben dieser Prozesse unterscheidet sich nicht so sehr vom Erstellen anderer Arten von Dokumentation, außer dass sie weniger gestelzt sind. „Ich denke, Englisch wird manchmal zu kompliziert, wenn man anfängt, sich formal zu verständigen“, sagt er. „Es geht an Übersichtlichkeit verloren. Prozesse sollten auf sehr brauchbare Weise geschrieben werden: einfache Sprache und kurzsilbige Wörter, mit Aufzählungszeichen, Gliederungen und Listen.“ Am wichtigsten ist, dass es sich um kollaborative Dokumente handelt, die es jedem ermöglichen, Änderungen vorzuschlagen, und die jederzeit für jeden verfügbar sind.

Wie bringt er die Leute dazu, den Dokumenten zu vertrauen? „Ich benutze sie“, sagt er. „Ich durchlebe meinen eigenen Prozess. Wenn ich sie nicht benutze, wie kann ich dann erwarten, dass es jemand anderes tut?“

2. Erlauben Sie dem Team, das Eigentum an den Dokumenten zu übernehmen

Das Team muss nicht nur an der Erstellung der Dokumente, sondern auch an ihrer Entwicklung mitwirken. „Die Ingenieure sind diejenigen, die die Prozesse und Informationen nutzen“, sagt er. „Je näher sie an dem Dokument sind, desto mehr sollten sie es übernehmen.“

Das bedeutet, dass Manager sich damit anfreunden müssen, dass Teams die Informationen in Frage stellen. Dem Team zu erlauben, Änderungen vorzunehmen, stärkt es, baut Vertrauen auf und verbessert die Problemlösung. „Wenn zum Beispiel der Entscheidungsprozess nicht funktioniert, dann müssen wir ihn gemeinsam debuggen“, sagt er. „Als Manager kann ich nicht einfach sagen: ‚Bitte fangen Sie an, bessere Entscheidungen zu treffen.'“

Entscheidend ist, Autorität um der Autorität willen abzubauen und offen für die Ideen des Teams zu sein. „Ich schätze Menschen, die mich in Meetings herausfordern, schwierige Fragen stellen und andere ermutigen, dasselbe zu tun“, sagt er. „Zum Beispiel habe ich in einem Dokument geschrieben, dass wir Pull Requests in 36 Stunden zusammenführen sollten. Einer meiner Ingenieure fragte: „Warum 36 Stunden?“ und er baute ein Argument dafür auf, das zu ändern.“

Während das Team an jedem Dokument zusammenarbeitet, sollte eine Person der Verwalter sein, dessen Aufgabe es ist, einen klaren Zweck und eine klare Vision für dieses Dokument aufrechtzuerhalten. Ein Dokument, das Rekrutierungspraktiken umreißt, würde beispielsweise das Teammitglied, das für die Rekrutierung verantwortlich ist, als Verwalter haben. Der Rest des Teams würde zur Zusammenarbeit eingeladen und bei Bedarf Aktualisierungen vorschlagen.

Wenn es sich um ein kleines Team handelt, gewährt Buritica allen Bearbeitungsrechte. Wenn es sich um eine größere Gruppe handelt, behält er die Bearbeitungsrechte nur wenigen Teammitgliedern, obwohl jeder Vorschläge machen kann. Bei Konflikten oder widersprüchlichen Meinungen entscheidet der Manager. „Das Dokument soll nicht demokratisch oder ein Konsens sein“, sagt er. „Nicht alle müssen einverstanden sein.“

„Wenn jemand vorschlägt, dass wir nur zwei Stunden am Tag arbeiten, sollte der technische Leiter natürlich nein sagen. Das ist lächerlich“, sagt er. „Die Erstellung und Pflege dieser Dokumente ist ein kollaborativer Prozess, der den Menschen Teilhabe ermöglicht, aber es ist keine Demokratie. Letztendlich ist der Engineering Manager für die Produktivität des Teams, sein Wohlergehen und das ordnungsgemäße Funktionieren verantwortlich. Sie haben das letzte Wort.“

3. Erhöhen Sie die Ausgereiftheit bestehender Frameworks, um Teams zu skalieren

Entscheidungsrahmen sind noch wichtiger, wenn Teams verteilt sind.

„Wenn Sie lernen, aus der Ferne zu arbeiten – sei es physisch oder kulturell – und diese Rahmenbedingungen zu nutzen wissen, ist es einfacher, schneller zu wachsen, selbst wenn Sie Mitarbeiter auf der ganzen Welt einstellen“, sagt Buritica. Die Dokumente können verwendet werden, um schnell mehr Leute anzuwerben und den Erfolg zu replizieren.

„Als wir ein fünfköpfiges Team waren und ich jemanden einstellte, hatte ich ein informelles Dokument mit Informationen über ein Erstgespräch und ein Zweitgespräch“, sagt er. „Es enthielt nicht viele Details, weil ich rannte das Vorstellungsgespräch selbst. Aber als ich einen Manager brauchte, der diese Interviews übernahm, musste ich den Zweck dieses Interviews und den Erfolg besser definieren.“

Also machte er sein Dokument detaillierter. „Dann ging diese Managerin durch den Prozess und versuchte es mit dem Vorstellungsgespräch, und sie änderte schließlich, was ich geschrieben hatte, und notierte, was funktionierte und was nicht. Im Laufe der Zeit war es nicht mehr mein Dokument, sondern das Dokument des Teams. Und es entwickelt sich weiter.“

Heute, als ein Team von 50 Mitarbeitern, ist dieses Dokument gewachsen und umfasst Prozesse rund um das Screening, das Führen technischer Gespräche und das Treffen bestehender Teammitglieder. „Es gibt eine Rubrik, Blindrezensionen und noch mehr Feinschliff“, sagt er. „Es ist das nächste Level. Personen, die außerhalb des Prozesses stehen, können ihn besser verstehen.“

Die Zukunft der Arbeit wird geschrieben

Aus all diesen Gründen priorisiert Buritica schriftliche Kommunikationsfähigkeiten, wenn er ein Team leitet.

„Können Sie gut schriftlich kommunizieren? Ich bewerte nicht die Fähigkeit von jemandem, grammatikalisch korrekt zu sein. Englisch ist nicht einmal meine Muttersprache. Ich möchte wissen, ob ein Kandidat seinen Standpunkt vermitteln und Einfluss nehmen kann“, sagt er. Jedes Teammitglied sollte seine Schreibfähigkeiten verbessern, damit es effektiv zu Kommunikationsrahmen beitragen kann.

„Ich denke, die Zukunft der Arbeit wird nicht nur von der Ferne bestimmt, sondern auch geschrieben, unabhängig davon, ob Sie sich physisch am selben Ort befinden oder nicht“, sagt er. „Ich würde jedes Ingenieurteam ermutigen, mehr zu schreiben. Es kann Ihrem Team helfen, gemeinsam zu denken, als Gruppe zu entscheiden, zu lernen und zu wachsen.“