In letzter Zeit habe ich immer wieder über zwei Themen nachgedacht, die ein ähnliches Thema haben. Das erste Thema hat mit der öffentlichen Infrastruktur des Staates Kalifornien zu tun und wie ineffizient sie im Laufe der Jahre geworden ist. Das zweite ist das Versagen großer Technologieunternehmen, schneller zu innovieren und umzusetzen als etablierte Start-ups. Lassen Sie mich einige Perspektiven aufzeigen, warum diese Themen zusammenhängen, indem ich Ihnen zunächst zwei Beispiele gebe, über die Sie nachdenken sollten:

• Infrastruktur : Der Bau der Golden Gate Bridge dauerte etwa vier Jahre (1933–1937) und kostete uns nach heutigem Wert etwa 500 Millionen Dollar. Im Gegensatz dazu wird das SDS ( Suicide Deterrent System ), das im Grunde ein Netz um die Brücke herum hinzufügt, fünf Jahre dauern (2017–2023) und uns voraussichtlich ~ 217 Millionen US-Dollar kosten. Wenn Sie sich große Infrastrukturprojekte in Kalifornien ansehen, werden Sie feststellen, dass die Arbeiten bei Projekten, die vor den 1950er Jahren abgeschlossen wurden, um mindestens das Fünffache schneller, billiger und mit höherer Qualität als heute erledigt wurden, obwohl dies heute der Fall ist Wir haben mehr Kapital, bessere Technologie, bessere Rohstoffe und eine höhere absolute Zahl von Bauingenieuren und Architekten.
• Technologieunternehmen : Adobe sieht sich trotz all seiner finanziellen und personellen Ressourcen gezwungen, einen Konkurrenten für 20 Milliarden US-Dollar zu erwerben. Ob Adobe für Figma zu viel bezahlt hat, bleibt abzuwarten, aber die interessantere Frage ist, warum ein Unternehmen mit 100-mal so viel Personal, 100-mal so viel Erfahrung in Designwerkzeugen und 100-mal so viel Finanzkapital nicht gewinnen konnte?

Wenn Sie einen Blick in Unternehmen werfen, stellen Sie möglicherweise fest, dass sich Prozesse und Aufblähen in alles einschleichen und echte Arbeit und Innovation ersticken, wenn sie wachsen. In diesem Umfeld finden die Mitarbeiter, die am eifrigsten Dinge erschaffen, die Macher, dass es einfach attraktiver ist, an einen kleineren Ort zu springen, wo ihre Arbeit eine Möglichkeit hat, sich zu verwirklichen. Sowohl Infrastrukturausfälle als auch Innovationsausfälle von Unternehmen sind zumindest teilweise auf Blähungen und Prozessschleichen zurückzuführen.

Warum kommt es zu Prozesskriechen?

Jeder Prozess beginnt mit guten Vorsätzen.

• „Wir möchten sicherstellen, dass alle Beteiligten einen Beitrag zur endgültigen Arbeit leisten, daher müssen alle eingereichten Projektvorschläge von Rechts-, Design-, Produkt- und Ingenieurteams überprüft werden.“
• „Wir wollen sicherstellen, dass große Infrastrukturprojekte keinen Schaden anrichten, deshalb müssen wir gründliche Umweltstudien durchführen, bevor wir mit den Arbeiten beginnen.“
• „Wir wollen Datenschutzverletzungen minimieren, daher muss jede Anfrage nach Daten über die IT- und Sicherheitsteams gestellt werden.“

Der Weg zum Perfektionismus

Ich erinnere mich, wie ein wohlmeinender Manager seinen direkten Untergebenen sagte, sie sollten Software schreiben, als ob sie 100 Jahre halten würde. Obwohl die Bemerkung übertrieben war, spiegelt der Rat etwas wider, das ich oft in der Technologiebranche durch Sprichwörter wie „zweimal messen und einmal schreiben“ oder „wenn Sie keine Zeit haben, es richtig zu machen, haben Sie Zeit dafür“ gehört habe es zweimal?.“ Das ist kein schlechter Rat. In manchen Situationen muss man Code so schreiben, als würde er 100 Jahre halten, und ohne Planung kopfüber in die Ausführung zu gehen, ist verschwenderisch. Nichtsdestotrotz kann eine extreme Betonung der Planung zu Lähmungen führen und dazu führen, dass die Vorteile des Lernens durch Iteration nicht erkannt werden. Ich würde lieber in einer Welt leben, in der die Software jedes Jahr neu geschrieben wird, weil es eine starke Erkenntnis gibt, dass Perfektion nicht existiert und dass die Voraussetzung für Evolution Veränderung ist, anstatt in einer Welt, in der die Dinge auf „ 50 Jahre alten Codebasen “ laufen.

Zu viel Kleber

Vor vielen Jahren las ich Tanya Reillys Blogbeitrag über Being Glue (sehr empfehlenswerte Lektüre, übrigens). Zu diesem Zeitpunkt in meiner Karriere haben die Inhalte wirklich gewirkt, weil ich es mit einigen Kollegen zu tun hatte, die zwar fachlich kompetent waren, aber einfach nicht an den richtigen Dingen arbeiteten. Glue People engagieren sich in einem Prozess der technischen Führung und Betreuung, der dazu führt, dass andere Mitarbeiter im Team produktiver werden. Eine gewisse Menge Klebstoff ist notwendig, dennoch habe ich festgestellt, dass zu viel Klebstoff eine Reihe anderer Probleme verursacht:

• Leute, die Klebearbeiten ausführen, hindern andere daran, ihre nicht-technischen Fähigkeiten zu verbessern. Zum Beispiel nimmt ein Tech Lead, der sein Team nicht über seine Arbeit sprechen lässt oder oft als „Puffer“ fungiert, den ICs im Grunde genommen die Möglichkeit, sich zu wehren und schließlich ihre Kommunikationsfähigkeiten zu verbessern.
• Extreme und toxische Versionen des Glue-Verhaltens manifestieren sich manchmal darin, Anerkennung für die Arbeit anderer Leute anzuerkennen oder stark übertriebene Zuschreibungen zu erzeugen („zB ohne mich als Vermittler zu fungieren, würde das Projekt nicht gelingen“). Während Tanya über die Situationen spricht, in denen Glue-Leute oft nicht anerkannt werden, ist meine Erfahrung genau das Gegenteil. Weil Glue-Leute gute Kommunikatoren sind, wissen sie, wie man für ihre Arbeit Werbung macht und gut Politik macht. Im Gegenzug erhalten sie eine höhere Sichtbarkeit und mehr Beförderungsmöglichkeiten, während der Ingenieur, der an Implementierungsdetails arbeitet, oft eine symbolische Bestätigung oder überhaupt keine Anerkennung erhält.
• Zu guter Letzt reduziert das Hinzufügen zu vieler Leimleute die Eigenverantwortung und Verantwortlichkeit für einzelne Ingenieure. Anstatt ein technisch kompetentes Team mit Leimleuten zu leiten, würde ich einfach Ingenieure loslassen, die anscheinend keine Geschäftsintuition haben, denen es an Kommunikationsfähigkeiten mangelt oder die keinen Absatz zusammenstellen können, der beschreibt, warum ihre Arbeit wirkungsvoll ist. Die Behauptung, dass Sie mehr Leim brauchen, um Ingenieure zu managen, verwirft das allgemeine Muster, dass technisch brillante Leute auch ein hohes Maß an allgemeiner Intelligenz haben, viel lesen, lebenslang lernen und sehr gut im Geschäft und nicht nur im Programmieren sind.

Als ich bei Novell war, hatte ich gelernt, dass es Leute gibt, die ich „Kleber“ nenne. Die Leimmenschen sind unglaublich nette Leute, die an den Zwischengrenzen zwischen Gruppen sitzen und bei Aktivitäten helfen. Und sie sind sehr, sehr loyal, und die Leute lieben sie, und du brauchst sie überhaupt nicht.

Bei Novell habe ich immer wieder versucht, diese Klebeleute loszuwerden, weil sie im Weg waren, weil sie alles verlangsamt haben. Und jedes Mal, wenn ich sie in einer Gruppe losgeworden bin, tauchten sie in einer anderen Gruppe auf, wechselten und wurden wieder eingestellt und so weiter.

Entropie

Wenn Organisationen wachsen, nehmen das institutionelle Wissen, die Anzahl der Stakeholder, die Codebasen und die Entropie zu. Erhöhte Entropie führt zu hoher Verschwendung, hoher kognitiver Belastung, Desorganisation und Chaos.

Als Software-Ingenieure haben wir meines Erachtens beim Umgang mit Komplexität einen schlechten Job gemacht. Beispielsweise haben wir seit Jahren gehört, dass Monolithen schlecht sind, weil sie aufgeblähte Codebasen generieren, Bereitstellungen erschweren oder Probleme mit der Skalierbarkeit verursachen. Auf der anderen Seite, wo wir in einer Welt von Microservices operieren müssen, finde ich, dass ich, um grundlegende Dinge auszuliefern, über mehrere Codebasen hinweg arbeiten muss, die in verschiedenen Sprachen geschrieben sind, wobei jede ihre Deployment-Macken und Architekturmuster hat, mit dem Ganzen Paradigma verwandelt sich in Lambda-Spaghetti . Innezuhalten und sich auf das Wesentliche zu konzentrieren, hat einen großen Einfluss auf die Verringerung der Entropie. Auf einer niedrigen, handlungsorientierten Ebene kann es sich wie folgt manifestieren:

• Löschen von totem Code, der nicht in der Produktion ausgeführt wird. Ich habe mit so vielen Codebasen interagiert, bei denen >50 % des Codes toter Code war und eine kognitive Belastung für Kollegen erzeugte. Ich wünschte, es gäbe etwas im Bereich der Entwicklungsproduktivität, das Codeabdeckung basierend auf in der Produktion ausgeführten Zeilen generiert. Jedes Quartal halten Sie an und überprüfen diese Berichte und löschen einfach Dateien, die keine Ausführung hatten.
• Als Produktmanager denken wir nicht genug darüber nach, welche Funktionen wir beenden oder wiederherstellen sollten. Innezuhalten und darüber nachzudenken, was gelöscht werden sollte, kann jedoch sehr sinnvoll sein, um die Benutzererfahrung zu vereinfachen und zu verbessern. Ich halte mich für technisch versiert, finde aber, dass viele der heute erstellten Produkte für eine Reihe bestehender Benutzer hyperoptimiert wurden, was zu einer überladenen und verwirrenden UX-Erfahrung für neue Benutzer führt. Am Ende des Quartals fragen: „Welche Funktion können wir ausliefern?“ kann nützlich sein, um Unordnung zu reduzieren.

Das Ego ist der Feind

Ryan Holiday schlägt in seinem Buch Ego is the Enemy vor, dass es eine starke „Versuchung gibt, die für alle existiert – für Reden und Hype, um die Aktion zu ersetzen“. Egoismus ist ein wichtiger Grund, warum Fortschritt und Innovation in vielen Institutionen glanzlos sind. So manifestiert sich das Ego:

• Dieselben Leute zu sehen, die ihre Gedanken in eine Gruppendiskussion einbringen wollen, obwohl ihre Ideen keinen oder nur einen sehr geringen marginalen Wert haben.
• Menschen zu haben, die ihre Kollegen nie aktiv sponsern oder versuchen, Sichtbarkeit zu horten. Wenn Sie ein Manager oder ein Manager von Managern sind, können Sie dies feststellen, indem Sie sehen, wie oft Ihr direkter Untergebener in Ihren 1:1-Gesprächen über die Erfolge oder Beiträge anderer Personen spricht. Mangelnde Anerkennung oder selbstloses Sponsoring anderer Leute kann ein Zeichen für ein ungesundes Ego sein.
• Optimierung für das Team statt für das gesamte Unternehmen oder die Organisation. Ich habe das Diagramm aus dem Staff Engineer's Path von Tanya Reilly ausgeliehen und es veranschaulicht perfekt dieses Problem, bei dem Teams für das lokale Maximum optimieren. Wäre es beispielsweise in Ordnung, Ihr Team aufzulösen und Mitarbeiter auf andere Teams umzuverteilen, wenn Sie innerhalb Ihrer Domain in den Wartungsmodus wechseln? Die meisten Manager würden das niemals tun, weil es bedeuten würde, jegliches soziale und politische Kapital innerhalb des Unternehmens zu verlieren.

• Abhängig von Ihrer Rolle gibt es eine sehr starke Dichotomie in Bezug darauf, wie Sie den Wert von Meetings sehen. „ Die mächtigsten Leute stehen auf dem Plan des Managers “. Leider schafft ihre Wahrnehmung des Wertes von Meetings eine kulturelle Übersteuerung, die Menschen betrifft, die es vorziehen, ununterbrochen Zeit zu haben, um über ein Problem und eine Lösung nachzudenken. Selbst für Brainstorming-Zwecke deuten die Beweise darauf hin, dass Gruppen-Brainstorming Zeitverschwendung ist . Doch warum verbringen so viele aufgeblähte Organisationen am Ende die Hälfte der Zeit der ICs mit Meetings?

Fazit

Der Innovationsmotor setzt auf evolutionären Wandel. Wenn eine Institution starr wird und sich nicht an Veränderungen anpasst, wird sie letztendlich einen langsamen Tod sterben. Nach meiner Erfahrung hat die Einführung eines Prozesses oft unbeabsichtigte Kosten, die zu einer verringerten Geschwindigkeit führen. Stattdessen würde ich mich auf Folgendes konzentrieren:

• Bevorzugung von Iteration und Lernen aus Fehlern, anstatt zu versuchen, Perfektionismus zu erreichen.
• Leimleute sind notwendig, aber ihre Anzahl muss begrenzt sein, damit sie mit hoher Hebelwirkung agieren können. Durch die einfache Einstellung von Mitarbeitern, die sowohl technisch kompetent sind als auch über eine gute Geschäftsintuition verfügen, kann die Notwendigkeit der Überbesetzung von Leimrollen gelöst werden.
• Schließlich würde ich mich darauf konzentrieren, die Entropie zu reduzieren, indem ich ständig frage, was verworfen werden kann, und Leute für Verhalten belohnen, das die Einfachheit erhöht.