Eine der wichtigsten Aufgaben eines Engineering Managers besteht darin, anderen die Möglichkeit zu geben, größere und bessere Dinge zu tun.
Die häufig verwendete Analogie besteht darin, sich selbst als Multiplikator zu betrachten. Stellen Sie sich vor, Sie haben 5 Entwickler in Ihrem Team. Wenn jeder von ihnen eine Arbeitseinheit pro Tag erledigt und Sie nichts tun, um ihnen zu helfen, haben Sie als Team am Ende des Tages 5 Arbeitseinheiten erledigt.
In diesem Baum steht Dunya in der Mitte. Sie hat einen direkten Untergebenen und ihr Kollege ( Michael ) hat zwei direkte Untergebene. Sowohl Dunya als auch Michael berichten an Allan, der selbst drei weitere Engineering-Manager leitet. Diese Manager leiten viele andere individuelle Mitarbeiter ( IC ).
Wir verwenden einen Farbcode, um den Grad Ihres Einflusses auszudrücken. Die Personen, zu denen Sie eine direkte Verbindung haben, sind L1 . Diese Personen können Sie am meisten beeinflussen. Schließlich ist es einfacher, Kollegen oder Teammitglieder um Hilfe zu bitten, als den CEO des Unternehmens zu fragen.
Die Leute, die zwei Linien von Ihnen entfernt sind, sind L2 . Es ist auch möglich, sie zu beeinflussen, allerdings würde dies mehr Aufwand erfordern. Im obigen Beispiel könnte Dunya Ivan beeinflussen, allerdings würde dies mehr Arbeit erfordern, da sie nicht durchsetzen kann, was sie gerne anders sehen würde. Sie müsste Ivan überzeugen (mit Überredungskunst, Daten oder Ähnlichem), um ihn dazu bringen zu können, das zu tun, was sie möchte.
Ebenso sind diejenigen, die drei Linien entfernt sind, ein L3 . L3 ist immer noch beeinflussbar, es würde jedoch deutlich mehr Arbeit erfordern, als es bräuchte, um L2 zu überzeugen. Meiner bescheidenen Meinung nach lohnt es sich nicht, auf diesen Ebenen viel Aufwand zu betreiben, da der Return on Investment erheblich sinken würde.
Was wir bisher gesehen haben, unterscheidet sich nicht von einem . Der einzige Unterschied ist der Kreis mit der Markierung „Projekt“. Sehr oft interagieren Menschen in Unternehmen über Projekte miteinander, anstatt über Berichtslinien. Es gibt viele Projekte, Migrationen, Handwerksarbeiten, Arbeitskreise usw., an denen Menschen aus verschiedenen Teams zusammenarbeiten. Wir stellen solche Initiativen mithilfe der Ellipse dar (im obigen Diagramm), wobei wir verschiedene Mitglieder durch diese Blase verbinden. So können wir sehen, wie groß der Einflussbereich einer Person über Teams hinweg ist. Im obigen Beispiel können wir sehen, dass Bruno ein L2 für Dunya ist, da sie am selben Projekt zusammenarbeiten. Also zählen wir wieder nur die Anzahl der Linien, die die beiden verbinden.
Diese Denkweise hilft uns auch, die Wirkung zu verstehen, die jemand auf seine Kollegen hat. Denken Sie an die Leistung: Jemand, der es geschafft hat, die Kennzahlen für seine L1 , L2 und L3 zu verbessern, hat offensichtlich einen großen Einfluss auf einen größeren Bereich gehabt. Jemand, der nur seiner L3 geholfen hat, konzentriert sich möglicherweise auf die falschen Dinge (da er tatsächlich nicht seinem eigenen Team hilft, sondern anderen). Und jemand, der nur seine L1 beeinflusst hat, ist möglicherweise immer noch ein Ingenieur der mittleren Ebene und müsste seinen Einflussbereich erweitern, um eine größere Wirkung zu erzielen.
Nachdem wir nun wissen, wo wir in der Organisation positioniert sind und wie unsere Interaktionen aussehen, ist es an der Zeit, Daten zu sammeln und zu versuchen, die Schwachstellen zu verstehen , bei denen Ihr Fachwissen zum Tragen kommen könnte.
Welche Dinge nerven Sie am meisten oder bremsen Sie am meisten aus?
Nachdem ich alle Probleme gesammelt habe, füge ich sie in eine ein. Es wird viele Probleme geben, von denen Sie immer wieder von verschiedenen Ingenieuren hören werden, und das ist in Ordnung. Dann fügen wir dieser Datenbank drei Spalten namens Kategorie , Reporter und Ebene hinzu. Die Spalte Kategorie hilft uns dabei, die Probleme in logische Kategorien zu gruppieren. Ein Problem kann in mehrere Kategorien fallen. Nachdem alle Probleme kategorisiert wurden, können wir die Kategorien danach sortieren, wie oft wir von Problemen in dieser Kategorie gehört haben. Die Spalte Ebene zeigt uns, aus welcher Einflusssphäre wir von diesem Problem gehört haben. Die Spalte Reporter hilft uns dabei, uns zu merken, von wem wir das Problem erhalten haben.
Der nächste Schritt bei Observe besteht darin, die Kategorien aufzuschreiben und für jede einzelne eine ( RCA ) durchzuführen. Sie können jede beliebige Methode zur Durchführung der RCA verwenden, ich würde jedoch dringend empfehlen, etwas Einfaches wie die 5 Warums zu verwenden. Die Idee bei den 5 Warums besteht darin, fünfmal „Warum“ zu fragen (eher so oft wie nötig, um die Grundursache zu finden), um zu verstehen, was die Grundursache eines Problems sein könnte. Es wäre besser, wenn Sie diese Übung mit den Personen aus Ihrer Datenbank durchführen. Zum Glück haben wir dies in unserer Reporterkolumne behalten.
Diese Visualisierung hilft uns nicht nur, die Probleme und ihre Grundursachen zu verstehen, sondern auch die Wechselwirkungen zwischen den Problemen. Im obigen Beispiel können wir sehen, dass die „ übermäßige Verwendung von Integrations- oder End-to-End-Tests “ zwei verschiedene Zweige des Baums beeinflusst. Das bedeutet, dass das Entfernen dieser Grundursache einige Symptome beheben wird.
Nachdem wir nun unseren Einflussbereich verstanden und mehrere Grundursachen gesammelt haben, können wir mit der Auswahl der zu bearbeitenden Probleme beginnen. Dazu werden wir alle Grundursachen in der bekannten -Matrix darstellen. Diese würde folgendermaßen aussehen:
Dies hilft uns zu verstehen, was wir priorisieren müssen. Wir sollten auch nicht vergessen, die Farbcodierung zu verwenden, die wir in der Übung „Sehen“ hatten, da wir die Matrix im Grunde um eine dritte Dimension anreichern würden.
Betrachtet man die resultierende Matrix, könnte man zu dem Schluss kommen, dass es besser ist, mit den beiden Tickets ganz links zu beginnen , da der Aufwand für sie sehr gering ist, sie eine gewisse Auswirkung haben, aber auch einen Einflussbereich mittlerer Ebene betreffen, als mit dem Ticket ganz rechts zu beginnen.
Zu diesem Zeitpunkt wissen wir, was wir tun können, um unseren Ingenieuren zu helfen. Wir wissen auch, welche Auswirkungen die Lösung dieser Probleme auf das Unternehmen hätte. Und schließlich haben wir auch ein klares Verständnis davon, wer von einer solchen Verbesserung betroffen sein wird.
Jetzt, wo alle Teile an ihrem Platz sind, bleibt nur noch eines zu tun: Handeln !