Der Paradigmenwechsel im DevOps: Führungslektionen eines CTOs
F: Haben Sie eine Mentorin oder einen Mentor, die/der Ihre berufliche Laufbahn bisher inspiriert oder unterstützt hat?
Es gibt sehr viele. Teil der Startup-Community in Raleigh, North Carolina zu sein, war großartig, und es gibt Dutzende Menschen, die mich auf eine Weise unterstützt haben, deren Bedeutung ihnen vielleicht gar nicht bewusst ist. Während ich einzelne Namen nennen könnte, haben einige wichtige Geschichten mein Weltbild geprägt.
Eine Geschichte stammt von einer Vertriebsleiterin, die in einem meiner Entrepreneurship-Kurse im Grundstudium einen Vortrag hielt. Als Ingenieurstudent, der sich auf das Schreiben von Code und die Entwicklung technischer Fähigkeiten konzentrierte, war Vertrieb für mich sowohl fremd als auch uninteressant. Doch diese Person erzählte eine Geschichte, die mir eine andere Sichtweise eröffnete.
Sie erinnerte sich an ein Gespräch mit einem ihrer technischen Kollegen. Der Kollege sagte: „Ich weiß nicht, wie du das machst.“ Die Vertrieblerin erwiderte: „Was meinst du?“ Der Kollege antwortete: „Mit dieser Vorgabe leben zu müssen. Es muss sehr stressig sein, so verkaufen zu müssen, um deinen Lebensunterhalt zu verdienen.“ Sie dachte einen Moment darüber nach und antwortete ganz einfach: „Ja, das ist es. Aber wenn ich nicht verkaufe, kannst du auch nicht essen.“
Diese Geschichte half mir wirklich, das Ingenieurwesen in den richtigen Kontext zu setzen.
Du kannst das coolste Produkt oder den besten Service entwickeln – wenn du den Mehrwert aber nicht denen aufzeigen kannst, denen es helfen soll, dann entwickelst du einfach im luftleeren Raum.
Eine weitere Person, die mich unterstützt hat, war ein Mentor, der bereits Engineering-Unternehmen und -Abteilungen geleitet hatte und dann seinen Karriereweg so ausrichtete, anderen Menschen bei der Umsetzung ihrer Ideen zu helfen und sie an verschiedene Startups zu vermitteln. Er coachte mich in vielen Situationen, aber ein wichtiger Rat, den ich von ihm mitgenommen habe, war, dass die meisten Führungskräfte in technischen Organisationen in einem von drei Bereichen besonders gut sind:
Der „Head Geek“, der herausragende Manager oder die Schlüsselfigur im Produktbereich. Er sagte weiter, dass ein erfolgreiches Unternehmen alle drei braucht – und eine großartige Führungskraft muss erkennen, in welchem Bereich sie oder er selbst glänzt, und dann gezielt Leute für die anderen Kompetenzen einstellen. Das hat mir geholfen, meine eigene Entwicklung als Führungsperson in der Technik besser zu verstehen und zu wissen, wann ich mich mehr einbringen oder auch zurücknehmen sollte.
F: Können Sie drei Stärken oder Fähigkeiten nennen, die für Ihren Werdegang entscheidend waren?
Ein Motto, dem ich folge, ist: „Füge dich ein, dann falle auf.“ Es klingt zwar schlagfertig, erinnert mich aber daran, dass ich in einem neuen Team zunächst das Team und seine Dynamik kennenlernen muss. Zu verstehen, warum Dinge so sind, wie sie sind, ist entscheidend, um Vertrauen aufzubauen.
Wenn ich zum Beispiel an meinem ersten Tag einfach versuche, große Änderungen einzuführen oder mich dafür stark zu machen, wird das auf natürlichen Widerstand stoßen und meine Aufgabe zukünftig erschweren. Es ist daher wichtig, bei einem neuen Team zunächst Gemeinsamkeiten und Übereinstimmungen zu suchen, bevor man den Status quo in Frage stellt oder große Veränderungen bewirkt. Dieser Ansatz lässt sich auf das Knüpfen neuer Beziehungen in jedem Lebensbereich übertragen.
Ein weiteres Prinzip, das mich leitet, ist: „Was Menschen sagen und tun, steht nur in gewissem Zusammenhang mit dem, was sie denken und fühlen.“ Auch wenn das vielleicht pessimistisch klingt, gefällt mir die Vorstellung, dass Menschen oft unter erheblichem Druck stehen, sich auf eine bestimmte Art zu verhalten oder zu äußern.
Wenn man zum Beispiel jemanden fragt, wie es ihm geht, antwortet er fast immer: „Gut“, anstatt wirklich offen zu sagen, wie es ihm ergeht. In der Arbeit mit Teams und Gruppen ist es wichtig, auf diese äußeren Zwänge zu achten, um wirklich zu verstehen und empathisch zu sein. Wenn Ihnen beispielsweise jemand unterstellt ist, fällt es dieser Person schwerer, Verantwortung für Fehler zu übernehmen, wenn sie Angst vor negativen Konsequenzen hat.
Für eine Führungskraft ist es essenziell, das Umfeld so zu gestalten und regelmäßig zu reflektieren, dass Offenheit möglich ist. Andernfalls besteht die Gefahr, dass sich Themen im Team aufstauen und nicht angesprochen werden.
Was das Führen von Teams betrifft, müssen Menschen beständig introspektiv und rückblickend arbeiten, um starke Kompetenzen zu entwickeln. „In sich gehen“ hilft mir persönlich weiter – aber das ist nicht für jeden die beste Methode. Eine gute Führungsperson erkennt die unterschiedlichen Wege, wie verschiedene Menschen lernen und wachsen.
Eine effektive Führungskraft konzentriert sich darauf, Leistung und Empathie auszubalancieren, reflektiert ständig die eigenen Stärken und Schwächen sowie die des weiteren Teams.
F: An welchen Fähigkeiten arbeiten Sie derzeit noch, um sich weiterzuentwickeln?
Zurückgehend auf den Rat eines meiner Mentoren, arbeite ich ständig an der Säule des Managements innerhalb der drei Rollen einer technischen Führungskraft. Ich hatte das Glück, mit einem Kollegen zusammenzuarbeiten, der in dieser Hinsicht bemerkenswert ist und mir entscheidende Wege aufgezeigt hat, wie ich wachsen und mich verbessern kann.
Als Mitgründer eines Tech-Start-ups habe ich mich stark auf Technologie und Produkte konzentriert und mit kleinen Teams gearbeitet. Jetzt, da unsere Organisation wächst, muss ich mich ebenfalls weiterentwickeln. Die Kunst des Managements ist genauso eine Fähigkeit wie die Software-Entwicklung.
F: Lassen Sie uns über erfolgreiche DevOps-Teams sprechen. Welche zentralen Ziele könnte ein DevOps-Team für eine digitale Transformationsreise identifizieren?
Eines der wichtigsten Dinge, die ich von anderen Führungskräften höre, ist das gemeinsame Verständnis davon, was DevOps für die eigene Organisation bedeutet. Ich habe Organisationen gesehen, in denen „DevOps“ bedeutet, einen SRE einzustellen, diesen DevOps Engineer zu nennen und dies zu feiern.
Die Kernelemente des DevOps-Zyklus zu nehmen und zu identifizieren, wie Arbeit und Ideen durch den Entwicklungsprozess fließen, ist ein wichtiger Ausgangspunkt. Wenn Sie ein einzelnes Entwicklungsticket von der Entstehung bis zur nächsten Ticketgenerierung verfolgen, können Sie entscheidende Lücken erkennen.
Sie stellen zum Beispiel vielleicht fest, dass Ihr QA-Team isoliert ist und Sie eine „Über-den-Zaun-werfen“-Mentalität haben, die Ihre Geschwindigkeit beeinträchtigt. Sobald Sie diesen Prozessfluss in Ihrer Organisation definiert haben, können Sie nach unterstützenden Tools suchen.
Viele Organisationen beginnen mit Tools und treiben von dort aus den organisatorischen Wandel langsam und schmerzhaft voran. Das ist ein umgekehrter Ansatz für den Einstieg.
F: Gibt es Herausforderungen oder typische Fallstricke, die DevOps-Teams beachten sollten?
DevOps ist eine Arbeitsweise. In vielerlei Hinsicht ist es eine Fortsetzung der agilen Transformation, die vor Jahrzehnten die Softwareentwicklungsbranche durchdrungen hat. Es ist wichtig, dies so zu betrachten. Viele Organisationen hatten Schwierigkeiten mit der agilen Transformation, weil es an Verständnis und Rückhalt seitens der Führung fehlte. Führungskräfte dachten, wir würden mit Stand-ups beginnen und 50 Prozent mehr Tickets erledigen. Im Nachhinein war das natürlich falsch.
Ähnlich glauben heute Führungskräfte, wir bräuchten nur eine CI/CD-Pipeline, um bei Dora-Metriken die Konkurrenz zu übertreffen, und schon erzielen wir 50 Prozent mehr Produktivität. Der Wandel in der Denkweise ist entscheidend. DevOps ermöglicht die vollständige Verantwortung für den gesamten Software-Lieferzyklus, wodurch Teams bessere Systeme bauen können. DevOps befähigt Teams, Wege zur Verbesserung zu erkennen und umzusetzen – Führungskräfte müssen dafür den Raum und die Unterstützung schaffen, um die Auswirkungen im Unternehmen wirklich zu sehen.
F: Wie können effektive Zusammenarbeit und Kommunikation zwischen Teammitgliedern die Produktivität und den Erfolg eines DevOps-Teams steigern und welche Praktiken fördern dies?
Kommunikation ist im Ingenieurwesen entscheidend. Fast jedes Problem lässt sich auf mangelnde Kommunikation zurückführen – und bei DevOps ist das nicht anders. Zurückgehend auf das gemeinsame Verständnis, was DevOps für die eigene Organisation bedeutet – man muss wirklich verstehen, wohin man will, und diese gemeinsame Vision haben, um erfolgreich sein zu können.
Zu den wichtigsten Praktiken, die ich gesehen habe, zählt die Definition einfacher Stage-Gates im Prozess. Diese müssen sich auf die Arbeit selbst beziehen, nicht auf die handelnden Personen. Definierte Abläufe für den Informations- und Aufgabenfluss im Team ermöglichen effizientes Umschalten, insbesondere wenn unterbrochene Arbeiten auftreten, und erlauben es, Bereiche des Teams unabhängig voneinander zu skalieren.
Jedes Team und jedes Produkt hat leicht unterschiedliche Anforderungen. Das Definieren dieser Gates und der notwendigen Schritte an jedem einzelnen hilft Ihnen zu erkennen, wo Ihre Ineffizienzen liegen.
F: Welche Rolle spielt CI/CD in DevOps und welche Best Practices gibt es zur Implementierung von CI/CD-Pipelines, um einen nahtlosen und zuverlässigen Software-Auslieferungsprozess zu gewährleisten?
Es ist entscheidend, Software-Änderungen so schnell wie möglich von der Idee in die Produktion zu bringen. Manuelle Prozesse sind äußerst langsam und von Menschen abhängig. Menschen sind zwar bei Problemlösungen und Kreativität hervorragend, aber oft weniger darin, Checklisten hunderte Male am Tag vollständig abzuarbeiten. Die Automatisierung der mühsamen Aufgaben ermöglicht es Ihrem Team, sich auf deren Stärken zu konzentrieren. Zusätzlich sind Computer außergewöhnlich schnell und skalierbar. Eine Pipeline zu erstellen, die diese Fähigkeiten nutzt, ist der Hauptvorteil bei der Einführung von CI/CD-Prozessen.
Ein wichtiger Aspekt beim Aufbau eines solchen Prozesses ist es, Geschwindigkeit und Sicherheit in Einklang zu bringen. Sie könnten zwar jede Änderung eines Entwicklers vollständig automatisiert direkt in die Produktion überführen, doch das bietet keinerlei Sicherheit. Wenn Sie Ihre Pipeline so gestalten, dass dieses Tempo möglich ist und dann nach und nach Kontrollmechanismen hinzufügen, kann das in Zukunft hilfreich sein. Vielleicht muss am Anfang jede Änderung explizit von einem QA-Ingenieur sowie einem Release-Ingenieur abgenommen werden, aber der eigentliche Prozess besteht nur noch aus einem Knopfdruck.
Sobald Sie automatisierte Tests eingeführt haben, können Sie möglicherweise auf die QA-Abnahme verzichten.
F: Wie trägt die Förderung einer DevOps-Kultur und -Denkweise zum Gesamterfolg eines DevOps-Teams bei und welche Strategien können Organisationen einsetzen, um diese Kultur in ihren Entwicklungs- und Betriebsteams zu etablieren?
Die Hauptaufgabe bei dieser Transformation ist, gegen die „über den Zaun werfen“-Mentalität zu kämpfen. Wenn Sie neu auf dieser Reise sind, haben Sie vielleicht fünf oder sechs Teams, die an jedem Arbeitsstück beteiligt sind, bevor es in die Produktion gelangt. Mit dem Wechsel zu DevOps fördern Sie eine gemeinsame Verantwortung für den gesamten Lebenszyklus des Produkts.
Dies kann erhebliche Veränderungen darin erfordern, wie Sie Lösungen entwerfen, entwickeln und bereitstellen. Auch wenn viele mit der Entwicklung besser testbarer Software vertraut sind, verlangt die Einführung einer DevOps-Kultur, dass Systeme und Plattformen so aufgebaut werden, dass sie von kleinen Teams vollständig verantwortet werden.
F: Was sind die "5 wesentlichen Bestandteile eines erfolgreichen DevOps-Teams"? Bitte teilen Sie zu jedem ein Beispiel oder eine Geschichte.
1. Ein gemeinsames Verständnis davon, was DevOps für Ihre Organisation bedeutet. – Eines der kontraproduktivsten DevOps-Vorhaben ist es, wenn Management und Team bei den Ergebnissen nicht auf einer Linie sind. DevOps ist viel mehr als nur das Anstellen von „DevOps“-Ingenieuren und das Kaufen eines CI/CD-Tools. Sobald Sie sich darüber einig sind, dass es eine Denkweisenänderung ist, geben Sie den Teams die Möglichkeit, die komplette End-to-End-Auslieferung von Kundennutzen zu übernehmen.
2. Freiraum und Unterstützung für die Identifikation und Umsetzung von Veränderungen – DevOps-Teams erkennen oft viele Möglichkeiten, die Auslieferung sowie die Effizienz des Teams zu verbessern. Wenn dieser Freiraum für Erkundungen nicht geschaffen wird, wird das Potenzial des Teams, Veränderungen zu bewirken, stark eingeschränkt.
3. Möglichkeiten, Erfolg über Daten zu messen und zu identifizieren – Jeder kennt die DORA-Metriken und die vier zentralen Kennzahlen, mit denen Sie die DevOps-Reife Ihrer Entwicklungsorganisation messen. Das ist ein guter Anfang, aber Sie müssen identifizieren, was es für Ihr Unternehmen bedeutet, eine DevOps-Organisation zu sein – und das sollten Sie mit Daten untermauern.
4. Ein Produkt, das die Übernahme und Weiterentwicklung dieser Philosophie unterstützt – DevOps ist eine großartige Philosophie für viele Organisationen, doch häufig sind Unternehmen noch nicht bereit für die Transformation. Sie müssen sicherstellen, dass Ihr Produkt von einem gemeinsamen Entwicklungs- und Betriebsteam unterstützt werden kann. On-Premise-Produkte, Produkte mit starren Releasezyklen oder Produkte, die noch nicht die nötige Reife besitzen, erfüllen diese Voraussetzungen oft nicht. Ihr Team nimmt beim Übergang zu einem operativeren Mindset zwar einige Verbesserungen wahr, aber die Auswirkungen bleiben begrenzt.
5. Automatisierung und Werkzeuge – Dinge müssen konsistent und schnell ablaufen, und die Verantwortlichkeit für Arbeitsvereinbarungen muss sichergestellt werden. Einer der zentralen Änderungen in einer DevOps-Organisation sind die Arbeitsvereinbarungen innerhalb und zwischen Ihren Teams. Wenn Sie beispielsweise einen Testprozess einführen, bei dem jeglicher Code vor der Bereitstellung einem Regressionstest unterzogen wird, sollten Sie diesen automatisieren. Sie sollten automatisierte Überprüfungen und Schranken etablieren, um das sicherzustellen. Wenn Sie diese Werkzeuge und Praktiken eingeführt haben, sind ambitionierte Ziele wie Continuous Deployment oft nur noch ein paar Schritte entfernt.
Stellen Sie sicher, dass das Testen nicht nur durchläuft, sondern auch Ihren Qualitätsstandards entspricht.
F: Welche aufkommenden Trends sehen Sie, die die Strategien für digitale Transformation in Zukunft wesentlich beeinflussen könnten?
Viele der großen Versprechen von Konzepten wie DevOps basieren auf hochaggregierten Daten und breit gefassten Ergebnissen. Häufig sind diese Schlagzeilenzahlen wie „Ihre Organisation ist 50 Prozent effizienter“ nahezu unmöglich zu messen, und es kann schwierig sein, zu verifizieren, dass Sie diese Ergebnisse wirklich erreichen.
Ich erwarte, dass es gezieltere Bemühungen geben wird, vor Beginn einer jahrelangen digitalen Transformationsreise konkrete Resultate für jede Organisation zu identifizieren. Dies entspricht nicht nur dem verstärkten Fokus auf Geschäftseffizienz der letzten Jahre, sondern stellt auch den Erfolg sicher. Anstelle von allgemeinen Zielen wie den genannten sind spezifische (aber wirkungsvolle) Ziele wie „Wir lösen Kundenanfragen 25 Prozent schneller“ wesentlich zielgerichteter.
Wachstum durch Mentoring fördern
Die Kraft von Mentoring und offener Kommunikation zeigt sich in Jeremy Freemans Weg. Indem Führungskräfte aktiv von anderen lernen und eine kollaborative Umgebung fördern, können sie ihre DevOps-Teams dazu befähigen, Großartiges zu leisten.
Abonnieren Sie den CTO Club Newsletter für weitere Interviews, DevOps-Insights und Mentoring-Tipps!
