Die menschliche Seite des Engineerings meistern: Führungslektionen von Apple, Palantir und Slack

• Der Engineering-Leader von Apple, Michael Lopp, betont, dass gerade in einer Zeit, in der Produkte schnell gebaut werden können, menschenzentrierte Abläufe und gutes Urteilsvermögen entscheidend sind
  • „Wer trifft Entscheidungen, und wie werden diese Entscheidungen umgesetzt?“ – darin liegt das eigentliche Wesen des Engineerings
  • Nicht die Fähigkeit, Code zu schreiben, sondern menschenzentrierte Organisation und Führung bestimmen die Leistungsfähigkeit einer Organisation
• Auf Basis seiner Erfahrungen bei Borland, Netscape, Palantir, Slack und in anderen Umgebungen zeigt er konkret Organisationsstrukturen, Zusammenarbeitskultur und zentrale Führungskompetenzen auf
• Im Fokus stehen weniger technische Leadership-Themen als vielmehr Organisationsbetrieb, Zusammenarbeit zwischen Menschen und Verständnis für Menschen
• Dieses Interview ist keine bloße Technikdiskussion, sondern konzentriert sich auf die Gestaltung nachhaltiger und effektiver Engineering-Organisationen und bietet Gründern und technischen Führungskräften praxisnahe Ratschläge zu Themen wie der Beziehung zu Produktteams, menschenzentrierten Fähigkeiten und den Eigenschaften guter Führungskräfte

Wie sollte die Struktur einer Engineering-Organisation gestaltet werden?

• Als gemeinsame Erfolgsfaktoren über verschiedene Branchen hinweg nennt er Vertrauen in das Engineering, schnelles Wachstum und die Gewinnung kluger Talente
• Darauf aufbauend schlägt er drei praktische Tipps für den Aufbau einer erfolgreichen Engineering-Organisation vor

Tipp #1: „Wolf Time“ fördern

• Die Zeit von Engineers wird in 71 % tatsächliche Arbeit / 29 % freie kreative Zeit aufgeteilt
• Die 29 % sind eine „nicht messbare und nicht erklärungsbedürftige Zeit“, ein Raum, in dem Kreativität und Eigeninitiative wachsen können
• Der Versuch, das bei Palantir zu formalisieren, scheiterte → informelle Förderung und Kommunikation sind wirksamer als Formalisierung
• Beispiel: der Vorschlag für eine informelle wöchentliche Zeit zum Teilen von Ideen am Freitag
  > „Wenn Teammitglieder nicht wissen, dass diese Zeit erlaubt ist, machen sie es heimlich zwischen Meetings, und dann wächst gar nichts.“

Tipp #2: Je regelmäßiger gestritten wird, desto besser

• Großartige Produkte entstehen durch die Zusammenarbeit von Engineering, Design und Produkt
• Diese Zusammenarbeit bringt oft Konflikte mit sich, doch genau diese Auseinandersetzungen sind der Schlüssel zu höherer Produktqualität
• Über Fragen wie „Ist das ein Designproblem, ein Produktproblem oder ein Verständnisproblem bei der Funktion?“ sollte im Team lebhaft diskutiert werden
• Führungskräfte sollten Meinungswiderspruch nicht nur Bottom-up, sondern auch Top-down fördern
• Es gibt oft Momente, in denen Debatten zwischen Gründern und Mitarbeitenden die Richtung eines Unternehmens verändern

Tipp #3: Ein skalierbares Betriebssystem aufbauen

• Gutes Urteilsvermögen + operative Stärke sind die Grundlage skalierbarer Produkte
• Urteilsvermögen bedeutet nicht bloß das Ergebnis, sondern die Fähigkeit zu erklären, „warum diese Entscheidung getroffen wurde“
• Accountability bedeutet, „eine Geschichte zu haben, die man berichten kann“
• Damit sich das Urteilsvermögen weniger Menschen auf das gesamte System übertragen lässt, braucht es klare Prozesse
• Schon am Hiring-Prozess zeigt sich die Qualität des Betriebs (Reaktionsgeschwindigkeit, Klarheit bei Terminen usw.)
• Prozesse nicht mit dem Verweis auf ein Startup ignorieren → ein Unternehmen aufzubauen heißt, den Betrieb aufzubauen

Wie lässt sich die Beziehung zwischen Engineering und Produktteam stärken?

• Spannungen und Missverständnisse zwischen Produkt- und Engineering-Team sind ein altes Thema,
  doch um qualitativ hochwertige Produkte skalierbar zu machen, ist die sorgfältige Pflege dieser Beziehung unverzichtbar
  • Ein schlechter PM bringt Engineers dazu, dem Produkt ohne Ownership zu folgen,
  • ein guter PM hilft Engineers, vollständig zu verstehen, „warum wir das bauen“
• Lopp definiert Engineers als Menschen des „Wie“ (how) und PMs als Menschen des „Warum“ (why)
  • Das Produktteam sollte die Geschichte der Kunden vermitteln und das Wie der Umsetzung den Engineers und Designern überlassen
• Der Kern ist, das „Warum“ zu teilen
  > Frage nicht den PM, sondern den Engineer direkt: „Warum bauen wir diese Funktion?“
  • Wenn die Antwort lautet „Weil der PM es angeordnet hat“, macht ihn das wütend
  • Das eigentliche Problem ist nicht unbedingt eine falsche Einschätzung des Produktteams, sondern, dass der Engineer den Kontext nicht verstanden hat
    > „Engineers sind die Menschen, die ein Produkt mit den Händen bauen. Eine Organisation, in der sie arbeiten, ohne zu verstehen, warum sie etwas bauen, wird scheitern.“
  • Auf die Frage, warum Slack keine Blockierfunktion habe, erklärte Stewart klar die Philosophie: „Es ist wichtig, dass Informationen für alle sichtbar sind.“
    • Geteilt wird damit die Sichtweise, dass es nicht um eine Funktion, sondern um eine Vision geht
• Gute Produktmanager müssen jede Funktion oder Idee im Kontext der Gesamtvision des Produkts vermitteln können
  • Genau das ist ein Teil des „Why“, auf das sich alle konzentrieren sollten

Was macht eine großartige Führungskraft aus?

• Wirkungsvolle Engineering-Führung geht weit über reine technische Kompetenz hinaus
• „Am Ende ist Führung die Kunst, mit Menschen umzugehen.“

• Führungseigenschaft #1: Sie besitzt Flexibilität (Malleability)

  • Führungskräfte arbeiten mit Menschen unterschiedlichster Prägung und müssen ihren eigenen Stil entsprechend anpassen können
  • Er unterstreicht das mit Beispielen aus seiner eigenen Erfahrung, in denen er Teams bei Pinterest und Slack auf völlig unterschiedliche Weise geführt hat
  • Neuen Managern stellt er immer dieselbe Frage: „Was haben Sie geändert, nachdem Sie Feedback erhalten haben?“
  • Auch die Teamzusammensetzung wird nicht nach starren Kriterien festgelegt, sondern anhand der Stärken und Schwächen, die sich in der tatsächlichen Zusammenarbeit zeigen, neu organisiert
  • Dafür führt er alle 6 Monate Reorganisationsschritte durch

• Führungseigenschaft #2: Sie ist stark im Storytelling

  • Er zeigt eine starke Abneigung gegen Micromanagement: „Es gibt kaum etwas Nervigeres, als Engineers Anweisungen zu geben.“
  • Stattdessen sollten Führungskräfte „Box und Suppe (Soup)“ bereitstellen
    • Box: ein Raum, gefüllt mit Ideen und Kontext
    • Suppe: die Informationsbasis, aus der Teammitglieder frei schöpfen oder Dinge kombinieren können
  • Wenn man statt Anweisungen inspirierende Geschichten vermittelt, urteilen Teammitglieder selbstständig und wachsen
  • Manche sagen zwar: „Sag mir einfach, was ich tun soll“, aber selbst dann interpretieren sie es letztlich auf ihre eigene Weise
    > Die Aufgabe einer Führungskraft ist es, die Suppe zu geben. Ob sie sie trinken und was sie hineinlegen, ist ihre Entscheidung.

• Führungseigenschaft #3: Sie versteht Motivation und Ziele der Mitarbeitenden

  • Führungskräfte müssen wissen, wodurch einzelne Teammitglieder wachsen und motiviert werden
  • Ein Beispiel: Einem Engineer, dessen Lebensantrieb technische Herausforderungen sind, bietet man fortlaufend Gelegenheiten zur Problemlösung
  • Ein anderes Beispiel: Die Assistentin bei Palantir benannte vergütungsorientierte Motivation sehr klar → dadurch gut steuerbar
  • Entscheidend ist, den einen zentralen Antrieb jedes Menschen zu erkennen und kontinuierlich darin zu investieren
  • Dafür sind Neugier (curiosity) und ein ständiges Fragen nach dem „Warum?“ unverzichtbar
    > Führungskräfte sollten Motivationen erkennen, die Mitarbeitenden selbst vielleicht noch nicht kennen, und Wachstumschancen daraus schaffen.

Fazit: Das Wesen erfolgreichen Engineerings ist das Verständnis von Menschen

• Erfolgreiche Engineering-Organisationen hängen von gut funktionierender menschlicher Dynamik (Human Dynamics) ab
  • Großartige Produkte entstehen nicht durch herausragende Einzelne, sondern durch Gruppen von Menschen, die gut zusammenarbeiten
  • Die Rolle von Führung beginnt damit, die Menschen zu stärken, aus denen die Organisation besteht
• „Engineering-Teams sind ein großes Gewebe (tapestry) aus komplexen und wunderbaren Menschen“
  • Der Versuch, Struktur und Fluss dieses Gewebes zu verstehen, ist der Schlüssel dazu, dass der Wert eines Produkts wirksam durch die gesamte Organisation vermittelt wird
    > „Wenn Sie den Antrieb entwickeln zu verstehen, wie Menschen miteinander interagieren, ist Ihr Unternehmen bereit, den Wert seines Produkts in großem Maßstab zu vermitteln.“

[xguru]

Es gibt einen Slack für Tech-Führungskräfte, der von Michael Lopp betrieben wird.
RLS - Rands Leadership Slack
Wer Interesse hat, sollte einmal vorbeischauen. Der Slack ist inzwischen riesig und hat mehr als 36.000 Mitglieder.
Um beizutreten, sollte man den Inhalt unter dem obigen Link sorgfältig lesen und Lopp dann eine E-Mail schicken.
Name/Beruf/warum man beitreten möchte/wo man von RLS gehört hat/eigener LinkedIn- oder Twitter-Account

[techiemann]

Wenn man schon teure Engineers eingestellt hat, sollte man ihnen nicht wegen jeder Kleinigkeit vorschreiben, was sie zu tun haben, als wären sie LLMs, die nur auf Befehl wie Doraemon sofort irgendetwas zusammenbasteln, obwohl ihre Arbeit doch nur darin besteht, den Stift zu schwingen. Stattdessen soll man lediglich die eigene Vision teilen und sie den technischen Ansatz zu ihrer Umsetzung selbst bestimmen lassen, denn genau das ist ihr Fachgebiet.

Wenn ich so zuhöre, frage ich mich, warum mir dabei der typische Streit in den Sinn kommt, den Leute auf dem Land hierzulande mit Handwerkern, Baufirmen oder Architekten austragen, wenn sie ein Einfamilienhaus bauen oder eine alte Wohnung renovieren wollen.

[nemorize]

Ist der zweite Fall nicht in einem etwas anderen Kontext?

Die Renovierung eines freistehenden Hauses oder einer älteren Eigentumswohnung ist
zunächst eher ein Bereich der Verwirklichung eines Traums als ein Business,
und zudem passiert es auffallend oft, dass man einem Bau-/Renovierungsunternehmen vertraut und dann übers Ohr gehauen wird...

[groge]

Ich glaube, es wäre dieselbe Situation, wenn der Eigentümer es nicht selbst baut, sondern jemand anderen damit beauftragt.
Egal, wie gut man es erklärt, es kommt zu Missverständnissen, und egal, wie sorgfältig man alles begleitet, es gibt immer Bereiche, an die vorher niemand gedacht hat.
Wenn man beim Bauen jeden einzelnen Punkt nachfragen muss, den der Eigentümer nicht erwähnt hat, kostet das viel Zeit und ist frustrierend. Deshalb gibt es ziemlich viele Dinge, die Fachleute eigenständig erledigen, und genau diese Punkte scheinen alle zum Streitfall zu werden.
Übrigens beneide ich Sie darum, dass Sie offenbar noch nicht so oft von SI-Dienstleistern über den Tisch gezogen wurden.

[nicewook]

Das erinnert mich auch an Modern Software Engineering, das ich kürzlich gelesen habe. Darin geht es nicht nur um die Entwicklung selbst, sondern auch um Teams und Organisationen.

[haejuk99]

Es gibt viele Meinungen und Methoden zur Engineering-Führung, aber im Kern scheinen sich alle darin einig zu sein, dass sie auf dem Verständnis für die Teammitglieder basiert. Dieses Verständnis für die Teammitglieder klingt leicht, aber es scheint ein Bereich zu sein, in dem sich Vertrauen auf der Grundlage von Empathie zwischen Führungskraft und Teammitgliedern durch gegenseitiges Feedback aufbauen muss. Es scheint nichts zu sein, das auf einmal entsteht. Danke für den guten Denkanstoß.