Was bedeutet 10X Engineering für technische Programmmanager?

Galen Low: Von technischen Programmmanagern wird normalerweise nicht erwartet, dass sie Code schreiben. Aber heutzutage gilt das auch für Softwareingenieure nicht mehr – jedenfalls nicht von Hand. Die Frage ist also nicht unbedingt, ob technische Programmmanager programmieren können sollten. Die Frage lautet: Welche Tiefe an Verständnis ist erforderlich, damit technische Programmmanager ihre Wertschöpfung in einer Welt verlagern können, in der die Teams um sie herum mithilfe von KI fünf-, zehn- oder manchmal sogar fünfzigmal schneller arbeiten als noch vor wenigen Jahren?

Um zu untersuchen, wie sich die Rolle eines technischen Programmmanagers in der heutigen Softwarebranche verändert, habe ich einen VP für Bereitstellung und Engineering Operations eingeladen, der Teams technischer Programmmanager bei Organisationen wie Dell und Google sowie in anderen schnelllebigen, stark wachsenden Softwareumgebungen geleitet hat. Gemeinsam werden wir alles erkunden – von den Fähigkeiten, die heute von technischen Programmmanagern verlangt werden, bis hin zur Frage, wie Leiter der Bereitstellung den Wert ihres Teams vertreten können, wenn es Veränderungen in der Führungsebene gibt.

Wir werden außerdem darüber sprechen, wie Personalverantwortliche Kandidaten für technische Programmmanagement-Positionen während des Einstellungsprozesses beurteilen können und welche Auswirkungen es hätte, wenn die Rolle des technischen Programmmanagers den Weg des Dodos gehen würde. Ich hoffe, euch gefällt diese Episode.

Willkommen beim Podcast des Digital Project Manager – der Sendung, die Führungskräften in der Bereitstellung hilft, im Zeitalter der KI intelligenter zu arbeiten, reibungsloser zu liefern und ihre Teams selbstbewusst zu führen. Ich bin Galen, und jede Woche beschäftigen wir uns mit Strategien aus der Praxis, aufkommenden Trends, bewährten Rahmenwerken und gelegentlich auch mit einer Kriegsgeschichte von der Projektfront. Ganz gleich, ob du große Transformationsprojekte steuerst, KI-Workflows koordinierst oder einfach versuchst, das Chaos unter Kontrolle zu halten – du bist hier genau richtig.

Und wenn dir gefällt, was du in letzter Zeit von uns gehört hast, folge uns bitte auf der Plattform, auf der du uns findest, und hinterlasse uns vielleicht sogar eine Bewertung. Gut, dann legen wir los.

Heute bei mir ist Satish Menon, eine Führungskraft für technisches Programmmanagement und Engineering Operations, der die Bereitstellung bei Technologieriesen wie Google und Dell sowie bei Softwareunternehmen wie Tenable, Cohesity und Seismic geleitet hat.

Die Programme in Satish’ Verantwortungsbereich reichten von Hardware- und Softwareeinführungen bis hin zu Cloud-Infrastruktur- und Rechenzentrumsoptimierungsprodukten. Dabei stützten sie sich auf Satish’ Fähigkeit, Entscheidungen auf Vorstandsebene zu navigieren, organisatorische Führung zu übernehmen, Betriebsstrategien zu entwickeln und umzusetzen, Prozesse zu transformieren und die Produktentwicklung zu beraten.

Heute unterstützt Satish Teams technischer Programmmanager dabei, sich in der Welt der KI-gestützten Softwareentwicklung und des Programmmanagements zurechtzufinden. Gleichzeitig setzt er sich für den Wert ein, den die Rolle des technischen Programmmanagers in technologieorientierten Organisationen bietet.

Satish, vielen Dank, dass du heute dabei bist.

Satish Menon: Hey, Galen. Danke für die Gelegenheit. Ich freue mich, hier zu sein.

Galen Low: Hier ist der kleine Fahrplan, den ich für uns aufgestellt habe. Zunächst möchte ich dir eine etwas kontroverse Frage stellen, auf deren Beantwortung meine Zuhörer sicherlich gespannt sind. Danach möchte ich diese Frage als Perspektive nutzen, um drei Dinge zu betrachten.

Erstens möchte ich untersuchen, wie sich die Rolle des technischen Programmmanagers verändert – insbesondere im Softwarebereich. Wir könnten darüber sprechen, wie Abteilungsleiter und Teamleiter den Wert ihrer technischen Programmmanager verteidigen können. Außerdem möchte ich darauf eingehen, welche Auswirkungen die zunehmende Vermischung der Rollen von Softwareteamleitern und technischen Programmmanagern hat.

Wie klingt das für dich?

Satish Menon: Wunderbar. Ich freue mich darauf.

Galen Low: Großartig. Beginnen wir mit meiner provokanten Frage. Technische Programmmanager sagen, dass sie nicht programmieren können müssen, um Mehrwert zu liefern. Gleichzeitig scheinen viele Führungskräfte in der Technologiebranche anderer Meinung zu sein. Sie sagen, dass Softwareteamleiter und technische Programmmanager durch KI nun ein und dasselbe sind.

Meine Frage lautet also: Wer hat recht? Hat KI die Voraussetzungen geschaffen, unter denen es für Organisationen sinnvoll ist, von Softwareteamleitern zu erwarten, dass sie auch technische Programmmanager sind – und umgekehrt?

Satish Menon: Du stimmst mir sicher zu, dass sich die Rolle des Softwareingenieurs in letzter Zeit stark verändert hat, richtig?

Sie sind davon übergegangen, den Code selbst zu schreiben – was früher der Engpass war – und nutzen heute viel sogenanntes Vibe Coding und KI-Werkzeuge, um Code zehnmal oder sogar hundertmal schneller zu erzeugen. Dadurch hat sich das Problem nun in den Prüfzyklus verlagert, etwa in den Prüfzyklus von Pull Requests. Die Größe der Pull Requests ist gestiegen. Die Belastung bei der menschlichen Kontrolle dessen, was die KI in der Software erzeugt, liegt nun dort.

Ähnlich wie bei der Veränderung des Softwareentwicklungs-Workflows, der Geschwindigkeit und der Aufgaben von Softwareingenieuren muss es auch auf der Seite der technischen Programmmanager eine entsprechende Anpassung geben. Vor drei bis fünf Jahren bestand ein großer Teil der Arbeit darin, den Status manuell einzusammeln: Das ist der Plan – aber wie ist der Stand? Wo stehen die Dinge? Wie passen die Abhängigkeiten zusammen? Welche Risiken gibt es und wie mindern wir sie? Wie arbeitet die Qualitätssicherung? Ist der Qualitätssicherungsaspekt unseres Projekts auf Kurs, oder gibt es dort ein Risiko? Außerdem wurden Fehler und deren Reduzierung sowie die Testabdeckung überwacht.

Diese Aufgaben wurden damals von technischen Programmmanagern größtenteils manuell oder halbmanuell erledigt. Dann begann vor vier oder fünf Jahren die Umwandlung durch Jira und Atlassian. Sobald der Plan eingerichtet war, wurde der Status automatisch sichtbar. Die technischen Programmmanager konnten sich die Dashboards ansehen und bewerten, was rot oder gelb war, und sich anschließend an der Problemlösung beteiligen.

Die Rolle veränderte sich also. Es ging nicht mehr nur darum, einen Plan zu erstellen, Statusinformationen zu sammeln, Berichte zu erstellen, Risiken zu melden und deren Minderung zu koordinieren. Stattdessen beobachteten die technischen Programmmanager aktuelle Dashboards, die den Status anzeigten, und koordinierten bei roten und gelben Signalen die lösungsorientierte Problembearbeitung.

Jetzt bietet KI noch mehr Möglichkeiten. Wenn man sich die heute verwendeten Werkzeuge ansieht, gibt es beispielsweise Jira, in dem Planung und Aufgabenverwaltung stattfinden, GitHub, in dem der Code geschrieben wird, und BrowserStack, über den Qualitätssicherung und Bereitstellung verwaltet werden.

Wenn man diese drei oder andere eingesetzte Werkzeuge miteinander abgleicht, erhält man umfassendere Dashboards, reichhaltigere Daten und eine bessere Analyse von Risiken und Problemen. Die Rolle des technischen Programmmanagers entwickelt sich auf diese Weise weiter. Wir müssen nicht mehr manuell herausfinden, was rot oder gelb ist. Wir können KI verwenden, um mehrere Werkzeuge miteinander abzugleichen und die richtigen Signale zu erkennen, damit wir rote und gelbe Bereiche deutlich besser identifizieren können als je zuvor.

Galen Low: Das gefällt mir sehr. Ich mag die Vorstellung, dass sich der Engpass verlagert – aber dass es tatsächlich zwei verschiedene Engpässe sind.

Auf der Engineering-Seite verbringen Programmierer also weniger Zeit damit, Code manuell zu schreiben. Sie arbeiten mit Cursor und können schneller arbeiten. Dadurch verlagert sich der Engpass in die Prüfung. Wenn du von einem Leiter eines Engineering-Teams sprichst, bedeutet das für ihn tatsächlich mehr Prüfaufwand, richtig?

Der Engpass verschiebt sich. Es gibt wahrscheinlich mehr Prüfungen und mehr Code, der überwacht werden muss. Auf der Code-Seite liefern sie Mehrwert, indem sie die Pipeline am Laufen halten und Probleme schnell lösen. Aber das bedeutet nicht, dass dadurch zusätzliche Kapazität entsteht, um anschließend auch technisches Programmmanagement zu übernehmen.

Auf der anderen Seite liegt der andere Engpass darin, dass es früher vor allem um das Sammeln von Informationen und Statusaktualisierungen ging. Jetzt verändert sich auch unsere Rolle. Wir nutzen andere Werkzeuge wie Jira und KI, und ein Teil dieser Automatisierung bringt uns näher an die Problemlösung heran, anstatt uns den ganzen Tag die Daumen drehen zu lassen und plötzlich Kapazität für die Leitung eines Softwareentwicklungsteams zu haben.

Ja, dieses Bild gefällt mir. Die Veränderungen finden auf beiden Seiten statt, aber daraus wird nicht ein einziger Kuchen. Es handelt sich um zwei getrennte Dinge.

Satish Menon: Es gibt noch einen weiteren Aspekt. Ein Leiter oder Direktor für Softwareentwicklung ist dafür verantwortlich, dass seine Teams qualitativ hochwertigen, sicheren, zugänglichen und leistungsfähigen Code mit einer guten Geschwindigkeit liefern.

Wenn man von ihnen zusätzlich erwartet, dass sie auch für die funktionsübergreifenden Aspekte der Bereitstellung verantwortlich sind – etwa Abhängigkeiten von anderen Softwareteams, eine hohe Testabdeckung, Leistungstests, Skalierung, Systemintegrationstests und die termingerechte Auslieferung an Kunden –, entsteht eine zusätzliche Belastung.

Auch die Ergebnisse der Infrastruktur-, Verzweigungs- und DevOps-Teams sowie die Erwartungen der Außendienstorganisation müssen berücksichtigt werden. Wer kümmert sich um technische Dokumentation und um die Kommunikation an den Außendienst? Es gibt so viele funktionsübergreifende Aspekte. Jemand muss sich um all das kümmern. Technische Programmmanager können dies mithilfe all dieser Werkzeuge wesentlich effizienter und schneller erledigen – aber es muss getan werden.

Wenn man von Softwareentwicklungsdirektoren und -leitern erwartet, dass sie dies ebenfalls übernehmen, ist das eine zusätzliche Belastung. Es ist wie bei der Sicherheit im Straßenverkehr: Wir haben eine Behörde, die Führerscheine ausstellt, Fahrzeuge registriert und sicherstellt, dass die Verkehrsregeln bekannt sind. Gleichzeitig gibt es aber auch die Verkehrspolizei, die Strafzettel ausstellt und durch stichprobenartige oder systematische Kontrollen dafür sorgt, dass Regelverstöße geahndet werden.

Für ein funktionierendes System braucht man beides. Man kann nicht einfach Führerscheine ausstellen, jedes Auto registrieren, den Menschen beibringen, sicher zu fahren, und anschließend ein gutes Ergebnis erwarten. Man braucht Kontrollen und ein System gegenseitiger Ausgleichsmechanismen.

Galen Low: Das gefällt mir sehr, denn derzeit findet in vielen verschiedenen Rollen eine enorme Automatisierung statt – insbesondere im technischen Programmmanagement und in der Softwareentwicklung. Manchmal höre ich, wie Menschen davon sprechen, dass sie mithilfe von Rahmenwerken automatisieren, sodass alle Regeln für die Menschen festgelegt sind und diese ihnen einfach folgen.

Aber genau wie du sagst: Das ist nicht das, was Menschen gut können. Es wird immer Menschen geben, die auf Probleme stoßen, die vielleicht absichtlich gegen Regeln verstoßen oder die Prioritäten nicht verstehen. Grundsätzlich braucht es jemanden, der den Prozess begleitet.

Weniger als früher, aber dieser Wert ist weiterhin vorhanden. Und du hast einen wichtigen Punkt angesprochen: Für die Bereitstellung eines Softwareprodukts müssen viele Puzzleteile zusammenpassen. Nur ein Teil davon ist die Codequalität. Der Rest ist eine funktionsübergreifende Koordination, damit alles zum richtigen Zeitpunkt zusammenkommt.

Wenn du durch die Leitung eines Softwareentwicklungsteams abgelenkt bist – durch Einzelgespräche, Karriereentwicklung, die Prüfung der Codequalität und die Lösung technischer Probleme –, ist das zwar wichtig, kann aber die Bereitstellung beeinträchtigen. Die Priorisierung zwischen diesen beiden Aufgaben wäre sehr schwierig.

Vielleicht können wir etwas herauszoomen. Du hast Teams technischer Programmmanager bei Unternehmen wie Dell und Google sowie bei anderen großen Softwarefirmen geleitet. Wir sprechen über Problemlösung. Ein Softwareteamleiter löst möglicherweise technische Probleme, während ein technischer Programmmanager ebenfalls Probleme löst, insbesondere weil die verfügbaren Berichte und Dashboards eine proaktivere Vorgehensweise ermöglichen.

Aber dazwischen scheint eine Kluft zu bestehen. Welche Probleme kann ein technischer Programmmanager lösen, wenn er keinen Programmierhintergrund hat? Welche technische Sprachkompetenz erwartest du von deinen technischen Programmmanagern? Welche Konzepte sollte jeder technische Programmmanager, der mit Softwareingenieuren arbeitet, verstehen – und warum?

Satish Menon: Das führt mich zu einem Punkt, den ich im Zusammenhang mit unserer bisherigen Diskussion ansprechen möchte. Ein Softwaremanager oder Softwaredirektor kann Projekte verwalten, die vollständig innerhalb seiner Organisation liegen. Wenn es jedoch um eine größere Bereitstellung mit Abhängigkeiten zu anderen Teams geht, kommt der technische Programmmanager ins Spiel.

Das betrifft nicht nur die funktionsübergreifende Zusammenarbeit von Engineering, Produktmanagement, Design, Außendienst, Markteinführung und technischer Dokumentation. Es betrifft auch die Abhängigkeiten innerhalb der Softwarebereitstellung selbst, die sich über mehrere Teams erstrecken.

Wir sollten aus diesem Gespräch nicht mitnehmen, dass ein Softwaremanager oder Softwaredirektor kein Projektmanagement betreibt. Das tun sie sehr wohl – allerdings für Bereitstellungen, die vollständig innerhalb ihrer Organisation liegen. Bei funktionsübergreifenden Themen ist es besser, einen technischen Programmmanager aus einer neutralen Perspektive einzusetzen.

Was die erforderliche technische Kompetenz betrifft, bevorzuge ich grundsätzlich technische Programmmanager, die früher selbst programmiert haben oder viel Erfahrung mit Programmierung besitzen. Dadurch verstehen sie die Sprache der Ingenieure, gewinnen deren Respekt und können besser mit ihnen zusammenarbeiten. Wenn man ihre Sprache nicht versteht, verliert man Respekt.

Man sollte verstehen, was Eincheckvorgänge, Commits, Pull-Request-Prüfungen, Prüfzyklen, Code-Analyse und statische Analyse bedeuten. Ebenso sollte man den Unterschied zwischen Unit-Tests, Systemtests, Integrationstests, Leistungstests und Bereitstellung kennen. Man muss die Feinheiten des Programmierlebenszyklus verstehen.

Nach fünf bis zehn Jahren als guter technischer Programmmanager und mit zunehmender Verantwortung für komplexere Aufgaben ist das Programmieren vielleicht etwas eingerostet. Trotzdem sollte man den Lebenszyklus von Code und die Abläufe außerhalb des Codes verstehen: Anforderungen, Programmierung, Tests, Pilotierung und schließlich die allgemeine Verfügbarkeit sowie die Checkliste dafür und die Auslieferung.

Die zweite technische Ebene besteht darin, das Produkt zu verstehen, das man ausliefert. Ich habe technische Programmmanager erlebt, die lediglich einen Prozess über den technischen Workflow legten, aber nicht wussten, welche Software genau entwickelt wurde oder was sie tut.

Viele System- und SaaS-Produkte sind in ihrer Nutzung durch den Endkunden komplex. Wenn man das versteht, kann man neue Funktionen besser einordnen, bessere Gespräche mit Produktmanagern, Designern, Softwareingenieuren, Customer-Success-Managern und Systemingenieuren führen und als neutraler, gleichberechtigter Partner funktionsübergreifend moderieren.

Die dritte technische Ebene besteht darin, eigene Skripte schreiben und eigene Dashboards erzeugen zu können – beispielsweise aktuelle Dashboards in Jira, Tableau, Sisense oder anderen Werkzeugen. Wer Skripte erstellen, Dashboards generieren, die richtigen Signale erkennen und feststellen kann, was zusätzlich gemessen werden muss, ist deutlich hilfreicher.

Das sind technische Fähigkeiten, aber nicht in dem Sinne, dass man tatsächlich Softwarecode als Hauptaufgabe schreiben muss. Das ist meine Sichtweise; andere Menschen sehen das vielleicht anders.

Galen Low: Nein, das gefällt mir sehr. Ich komme auf deinen ersten Punkt zurück, denn der ist wirklich wichtig: Es ist keine binäre Frage. Es ist nicht so, dass nur Programmmanager Programmmanagement betreiben können. Und es ist auch nicht so, dass Programmmanager verschwinden, weil Softwareteamleiter künftig das Programmmanagement übernehmen.

Es ist nicht so schwarz und weiß. Dazwischen gibt es ein Spektrum, und eine Variable ist die Komplexität. Wenn man Software innerhalb eines Teams bereitstellt, es nicht viele bewegliche Teile gibt, man sein Team sehr gut kennt und ein etabliertes System besitzt, ist ein Teil dieser Bereitstellung weniger komplex.

Selbst wenn sie kompliziert ist, ist sie weniger komplex, weil man die Dinge kennt. Im Gegensatz dazu können hochkomplexe Projektökosysteme Anbieter, Marketing und verschiedene Produktverantwortliche umfassen. Dann besteht der Wert darin, alles miteinander zu verbinden und diese Komplexität zu navigieren, damit das Ergebnis dennoch geliefert wird.

Mir gefällt auch dein Schwerpunkt auf besseren Gesprächen: Tieferes Verständnis und ein gemeinsamer Wortschatz ermöglichen eine bessere Zusammenarbeit. Gleichzeitig gibt es heute in fast allen Rollen eine technische Komponente – auch in der Rolle des technischen Programmmanagers. Man muss in der Lage sein, einen Bericht oder ein Dashboard zu erstellen oder einen Prozess zu automatisieren.

Für Führungskräfte stellt sich die Frage nach dem Ertrag eines tieferen Verständnisses und besserer Gespräche. Was bedeutet das für dich?

Satish Menon: Bessere Gespräche führen zu größerem Respekt. Größerer Respekt bedeutet, dass man zu strategischeren Diskussionen eingeladen wird und als strategischer Partner für die Umsetzung sowie dafür wahrgenommen wird, Strategien in gute Pläne zu übersetzen.

Wenn man diesen Respekt nicht gewinnt und nicht über den notwendigen Wortschatz und die nötige Tiefe verfügt, werden Produktmanagement und Engineering die Strategie unter sich klären, ohne dass man am Tisch sitzt. Anschließend erstellen sie einen Plan und übergeben ihn mit der Bitte, ihn zu verfolgen. Dann wird man auf die Rolle eines Protokollführers reduziert.

Ein wichtiger Grundsatz ist: Das Leben in der Softwareentwicklung begann nicht mit technischen Programmmanagern. Es begann mit Ingenieuren und Produktmanagern. Produktmanager haben Ideen, Ingenieure arbeiten mit ihnen zusammen und setzen diese um.

Wenn ein Unternehmen wächst, mehrere Engineering-Teams entstehen und eine gemeinsame Plattform benötigt wird, bilden sich Abhängigkeiten zwischen den Teams. Dann entsteht der Bedarf an einem technischen Programmmanager, der diese Abhängigkeiten verfolgt.

Die Funktion des technischen Programmmanagements kommt also später ins Spiel, nicht am Anfang. Als erster technischer Programmmanager einer Organisation wird man zunächst erfahren, was zu tun ist, wie es zu tun ist und welches Ergebnis erwartet wird. Erst allmählich kann man Einfluss nehmen.

Produktmanager und Ingenieure haben bereits lange miteinander gesprochen, Strategien entwickelt und Pläne erstellt. Man selbst ist neu. Um als gleichberechtigter Partner akzeptiert zu werden, muss man daher die entsprechende Sprache beherrschen. So erhält man einen Platz am Tisch.

Galen Low: Das gefällt mir, weil darin zwei Dinge stecken. Erstens: Man kommt wahrscheinlich spät zur Party und muss sich Respekt verdienen. Man sollte bescheiden auftreten und verstehen, wie die anderen lange vor der eigenen Ankunft gearbeitet haben.

Der zweite Punkt ist sehr ermutigend: Ohne dich können sie nicht skalieren. Dein Wert besteht darin, dass du ihnen einen Wachstumshebel bietest, wenn die Dinge komplexer werden, mehr Teams beteiligt sind und mehr schiefgehen kann.

Du hast früher den Begriff strategischer Partner verwendet. Man muss die Sprache aller Teams sprechen, mit denen man funktionsübergreifend arbeitet, einschließlich des Produktbereichs. Für Führungskräfte bedeutet ein strategischer Partner jemand, der versteht, worum es geht, die Vision der Bereitstellung vertreten und die Lieferstrategie so ausrichten kann, dass möglichst viel Wert entsteht.

Das ist mehr als administrative Arbeit, das Abhaken von Aufgaben, das Prüfen von Jira-Tickets oder die Überwachung eines Burndown-Diagramms. Es geht darum, das Problem besser zu verstehen und nicht einfach nur einen Plan auszuführen, sondern Varianten dieses Plans zu entwickeln, um vielleicht noch mehr Wert zu schaffen als ursprünglich vorgesehen.

Satish Menon: In der heutigen KI-Welt können wir mit sogenanntem Vibe Coding schnell eine Demo eines Konzepts erstellen. Diese Demo kann man ausgewählten Kunden zeigen und deren Feedback einholen.

Früher musste man sehr viel Code schreiben, bevor man eine Demo für Kunden hatte. Dieser Rückkopplungszyklus war langsam und wenig effektiv. Heute kann man schnell eine Demo erzeugen. Bei Seismic nannten wir das eine Forschungsvorschau.

Technische Programmmanager können den Prozess der Forschungsvorschau fördern, damit vor der allgemeinen Verfügbarkeit eines Produkts mehr Wert geschaffen und die Anforderungen besser verfeinert werden.

Der strategische Wert wird außerdem deutlich, wenn man mit der Führungsebene abgestimmt ist. Bei einem Wechsel in der Führung entstehen jedoch oft Unsicherheit und unterschiedliche Vorstellungen vom Wert des technischen Programmmanagements. Manche neuen Führungskräfte fragen sich möglicherweise, warum es diese Personen gibt und welchen Wert sie beitragen.

Manchmal bekommt man die Möglichkeit, den eigenen Wert zu erklären und beispielsweise drei Monate zu erhalten, um ihn zu demonstrieren. Manchmal gibt es diese Möglichkeit nicht. Solche Situationen müssen wir akzeptieren. Manchmal können wir gegen vorgefasste Meinungen ankämpfen, manchmal sind wir ihnen ausgeliefert.

Galen Low: Dieser Abschnitt wird von Fingerprint präsentiert. Jeder Besucher deiner Plattform sieht zunächst gleich aus. Kannst du ihm vertrauen oder stellt er eine Bedrohung dar? Fingerprint erkennt Bots, KI-Agenten, VPNs, Manipulationen und mehr als 100 weitere eindeutige Signale, um in Echtzeit dauerhafte Risikobewertungen und Bedrohungserkennung bereitzustellen. Auch wenn menschliche und agentenbasierte Aktivitäten miteinander verschmelzen, kannst du verdächtigen Datenverkehr schneller identifizieren und sicherere Websites und Apps entwickeln.

Mehr als 6.000 Unternehmen verlassen sich täglich auf Fingerprint. Sei jetzt dabei unter fingerprint.com. Und nun zurück zur Sendung.

Satish Menon: Im Zeitalter der KI muss ich das Gespräch mit einer neuen Führungskraft anhand eines anderen Maßstabs führen. Früher habe ich erklärt, wie wir organisiert sind, Dashboards automatisieren, Statusübersichten erstellen und aktiv an Problemlösung und Risikominderung beteiligt sind.

Heute muss ich erklären, wie wir diese Arbeit in die KI-Welt übertragen haben: wie wir mehrere Systeme miteinander abgleichen und Frühindikatoren beobachten, um schlechte Ergebnisse zu verhindern, statt nur darauf zu reagieren.

Ich würde zeigen, welche Frühindikatoren wir nutzen, welche Dashboards vorhanden sind, wie wir mehrere Systeme miteinander abgleichen, wie wir KI im technischen Programmmanagement einsetzen, um die KI-Nutzung im Engineering zu ergänzen, und wie wir unser Team an diese Welt angepasst haben.

Galen Low: Manche Auseinandersetzungen sind nicht zu gewinnen, insbesondere wenn eine Führungskraft unter Druck steht, Veränderungen vorzunehmen, die Rentabilität zu beeinflussen oder Stellen abzubauen. Was mir an deiner Sichtweise gefällt, ist der Bildungsaspekt. Die Rolle unterscheidet sich von den vorgefassten Vorstellungen darüber, was ein Programmmanager tut.

Der Wert liegt heute darin, Probleme zu vermeiden, Risiken zu managen und auch bei hoher Geschwindigkeit ein gutes Ergebnis sicherzustellen. Das ist eine bessere Erfolgsgeschichte, als erst nach einer Katastrophe zu erklären, was schiefgelaufen ist.

Satish Menon: Ein gutes technisches Programmmanagementteam kann im Zeitalter der KI Frühindikatoren für Risiken in Programmen, Umsetzungen und betrieblich effizienten Teams identifizieren. Es kann vor einem schlechten Ergebnis warnen und zur Minderung des Risikos beitragen.

Andernfalls gibt es zwar Konsequenzen für schlechte Ergebnisse, aber dann ist es bereits zu spät und teuer.

Galen Low: Die Rolle unterscheidet sich heute. Das liegt an KI und den Veränderungen in der Softwareentwicklung, aber auch daran, dass sich Berufe generell weiterentwickeln. Wie unterscheidet sich die Rolle des technischen Programmmanagers heute von der vor drei oder vier Jahren?

Satish Menon: Softwareingenieure arbeiten heute zehnmal oder hundertmal schneller als früher. Wir müssen dasselbe tun. Wir dürfen keine manuellen Berichte mehr erstellen oder Statusinformationen manuell sammeln. Wir müssen aktuelle automatisierte Dashboards nutzen und rote sowie gelbe Signale bewerten.

Wir sollten rote und gelbe Signale aus einem Werkzeug durch den Abgleich mit anderen Werkzeugen validieren. Wenn Jira meldet, dass etwas kurz vor dem Abschluss steht, die Einschätzungen von GitHub oder Claude dies aber nicht bestätigen, ist das ein Warnsignal.

Auch die Informationen von BrowserStack über Qualität, Cloud-Bereitstellung, Tests und Staging müssen berücksichtigt werden. Durch die Betrachtung dieser Systeme erhält man eine bessere und umfassendere Einschätzung.

Wenn man sich nicht an diese Veränderungen und neuen Denkweisen anpasst, wird die eigene Rolle irgendwann überflüssig. Wer jedoch Schritt hält, gehört zu denjenigen, die bestehen bleiben.

Galen Low: Das führt zurück zu Skalierung und Wertschöpfung. Man sollte kein Engpass sein, nur weil die eigene Arbeitsweise veraltet ist. Gleichzeitig muss man ein aktiver Teil des Prozesses sein und Unterschiede zwischen Systemen erkennen, die Risiken erzeugen können.

Welche Probleme erwartest du, dass technische Programmmanager lösen können? Geht es nur darum, Teams zu koordinieren, gemeinsame Ausrichtung herzustellen und sicherzustellen, dass alle auf demselben Stand sind? Oder geht es tiefer?

Satish Menon: Es gibt ein Spektrum. Bei Google waren technische Programmmanager äußerst technisch und konnten deutlich mehr technische Probleme lösen. Das ist jedoch in der Branche ungewöhnlich.

Typische technische Programmmanager sollten anhand eines Problems erkennen können, dass ein Team zurückliegt und Unterstützung benötigt. Sie sollten wissen, welche Schwesterteams ähnliche Fähigkeiten besitzen und möglicherweise helfen können.

Wenn ein Plattformteam verspätet ist und dadurch die Veröffentlichung eines vertikalen Produkts gefährdet wird, muss man sicherstellen, dass die Arbeit der Plattform innerhalb des Teams priorisiert wird. Man sollte mit dem Engineering-Direktor herausfinden, wer bei der Lösung unterstützen kann.

Wenn man eigene Gedanken und mögliche nächste Schritte einbringt, nimmt man den Führungskräften einen Teil der Denkarbeit ab. Man bringt die richtigen Beteiligten zusammen, findet heraus, aus welchen Teams Ressourcen kommen könnten, formuliert die Frage und strukturiert die nächsten Schritte so, dass der Weg zur Lösung leichter wird.

Galen Low: Ein wiederkehrendes Thema ist, dass tieferes Verständnis letztlich mehr Wert schafft. Wenn man weiß, dass ein anderes Team über die richtigen Fähigkeiten verfügt und verfügbar ist, kann man eine konkrete Lösung vorschlagen, statt nur zu sagen: „Das ist euer Problem. Löst es bis Freitag.“

Satish Menon: Wenn man nur ein Problem übergibt und anschließend einen Termin überwacht, verliert man Respekt. Wenn man hingegen über genügend Wissen verfügt, um zumindest zu 70 Prozent mögliche Ressourcen oder kreative Lösungswege vorzuschlagen, wird die eigene Unterstützung geschätzt.

Man kann sagen: „Das ist eine Idee, die mir dazu gekommen ist. Ihr seid dafür verantwortlich, aber vielleicht ist sie hilfreich.“ Dann erkennen die anderen, dass man mit eigenen Vorschlägen zur Lösung beiträgt.

Galen Low: Mir gefällt der Ausdruck „70-Prozent-Lösungen“. Man bringt etwas mit, das noch nicht fertig ist, aber einen Ausgangspunkt bietet. Ich hatte deine Aussage zur Forschungsvorschau zunächst so verstanden, als würden technische Programmmanager dafür Vibe Coding betreiben.

Satish Menon: Nein, das meinte ich nicht. Es geht um eine Prozessveränderung. Produktmanager und erfahrene Ingenieure betreiben das Vibe Coding. Die technischen Programmmanager koordinieren den Prozess, stellen gute Kundendemos sicher und sammeln weitere Anforderungen. Sie überwachen den Ablauf.

Galen Low: Alle arbeiten schneller, besonders auf der Seite der Softwareentwicklung. Aber Zusammenarbeit ist weiterhin wertvoll. Eine Forschungsvorschau entsteht nicht ohne Engineering. Produktmanager können schnell einen Prototyp erstellen, und die Teams können gemeinsam den Wert verstehen, Fortschritt machen und die Ausrichtung mit den Beteiligten sicherstellen.

Satish Menon: Ich habe erlebt, dass Ingenieure Forschungsvorschauen auf Grundlage von Ideen aus Produktmanagement oder Produktdesign erstellt haben. Eine gute Idee kann schnell umgesetzt werden. Wir sind nicht mehr darauf beschränkt, lediglich ein Figma-Design zu zeigen.

Galen Low: Wie gehst du bei Einstellungsentscheidungen vor? Würdest du eher einen ehemaligen Entwickler einstellen, der inzwischen ein hervorragender Programmmanager ist, oder einen langjährigen Programmmanager, der nicht weiß, was eine Zusammenführungsanfrage ist?

Satish Menon: Wie gesagt: Technische Programmmanager mit früherer Programmiererfahrung sind häufig besser geeignet. Es gibt jedoch Ausnahmen. Manche technische Programmmanager haben viel Zeit mit Programmierern verbracht, deren Arbeitsweise verstanden und sich die Kenntnisse auf diesem Weg angeeignet.

Ich prüfe daher das Ergebnis. Können sie effektiv die Sprache der Ingenieure sprechen? Können sie die Sprache von Produktmanagern und Designern sprechen? Wie sie diese Fähigkeiten erworben haben, ist weniger wichtig als die tatsächliche Kompetenz.

Allerdings sind die Chancen für technische Programmmanager ohne Programmierhintergrund heute geringer. Früher konnte ein Hardware-Programmmanager in ein Softwareprojekt wechseln und die Arbeitsweise der Softwareteams kennenlernen. Diese Offenheit war damals verbreiteter. Heute ist die Toleranz für Einarbeitung am Arbeitsplatz sehr gering. Unternehmen suchen eher fertige Kandidaten.

Galen Low: Das ist eine realistische Sichtweise. Man muss nicht zwingend wissen, was eine Zusammenführungsanfrage ist, um eine Stelle zu bekommen. Aber man sollte bereit sein, sich weiterzubilden und jede Gelegenheit zu nutzen, die Sprache der funktionsübergreifenden Teams zu lernen.

Satish Menon: Es gibt Personalverantwortliche, die ausschließlich nichttechnische Situationsfragen stellen. Das tue ich nicht. In meinen Interviews verwende ich einen konkreten Fragenkatalog, mit dem ich die technische Sprachkompetenz in den für die Rolle relevanten Bereichen prüfe.

Ich passe die Fragen an die Erfahrungen des Kandidaten an und bewerte, wie gut er die Produkte kennt, die er ausgeliefert hat, sowie den allgemeinen Workflow von Softwareingenieuren. Zusätzlich stelle ich Situationsfragen zu den zwischenmenschlichen Fähigkeiten und zur emotionalen Intelligenz.

Diese objektive Interviewmethode habe ich bei Google gelernt. Dort wurde sehr wissenschaftlich und objektiv eingestellt. Diesen Prozess wende ich weiterhin an.

Galen Low: Kannst du ein Beispiel für eine Situationsfrage nennen, mit der du das technische Wissen eines bestimmten Kandidatentyps prüfst?

Satish Menon: Wenn jemand behauptet, in einer SaaS-Umgebung gearbeitet und deren Veröffentlichungsumgebung für eine schnellere Bereitstellung optimiert zu haben, frage ich, worin sich die Bereitstellung von SaaS-Software von einer lokalen Bereitstellung unterscheidet und welche Abkürzungen im Vergleich dazu genommen wurden.

Ich stelle vertiefende Nachfragen, um zu prüfen, wie gut die Person die SaaS-Bereitstellung und die Funktionsweise des Produkts tatsächlich verstanden hat. Wenn jemand ein Produkt nennt, das bei Disney oder Salesforce veröffentlicht wurde, recherchiere ich die Produkte des jeweiligen Unternehmens und frage nach konkreten Funktionen, die die Person veröffentlicht hat.

So erkenne ich, ob die Person lediglich einen Prozess über einen bestehenden Softwarelebenszyklus gelegt hat oder ob sie versteht, was der Ausgangspunkt war, was ausgeliefert wurde und welche Veränderung das Produkt für Kunden bewirkt hat.

Außerdem stelle ich grundlegende Fragen zum Softwarelebenszyklus auf der Programmierseite, zu DevOps, zum Unterschied zwischen Staging- und Produktionsumgebung und zu den Sicherheitsvorkehrungen, die verhindern, dass durch Staging in einer Produktionsumgebung Schwachstellen entstehen.

Galen Low: Wir haben mit unterschiedlichen Erwartungen an technische Programmmanager begonnen. Manche glauben, dass sie durch ihre Arbeit Wert schaffen, während manche Führungskräfte die Rolle mit der eines Softwareentwicklungsteamleiters verbinden möchten.

Was wäre, wenn diese hybride Rolle in Zukunft zur dominierenden Teamstruktur der Softwareentwicklung wird? Welche Auswirkungen hätte das auf Führungskräfte wie dich, die der Ansicht sind, dass beide Rollen getrennt bleiben sollten?

Satish Menon: Als Gemeinschaft sollten wir uns auf Dinge konzentrieren, die wir kontrollieren können. Wir müssen bei den Möglichkeiten der heutigen Werkzeuge voraus sein und herausfinden, wie wir weiterhin Wert für die Produktbereitstellung schaffen.

Wir sollten funktionsübergreifend, über mehrere Teams hinweg und interdisziplinär denken. Der größte Wert entsteht an der Schnittstelle mehrerer Funktionen, die gemeinsam ein Produkt bereitstellen.

Das beginnt bei mehreren Engineering-Teams, umfasst anschließend Engineering und Qualitätssicherung, danach Engineering, Qualitätssicherung, DevOps und technische Dokumentation. Auf der nächsten Ebene geht es um die Zusammenarbeit zwischen Produktorganisation, Außendienst, Customer Success, Vertriebsingenieuren, Kundensupport und Premium- oder Platinservices.

Hinzu kommen Produkteinführungen, Marketingbotschaften und Partnerschaften zwischen mehreren Unternehmen. Wenn ein Unternehmen etwas veröffentlicht, das gemeinsam mit einem Partnerprodukt eingeführt wird, entsteht Programmmanagement über Unternehmensgrenzen hinweg.

Man sollte also größer denken: Welche Aufgaben übernehmen die Werkzeuge, und was bleibt in unserer Verantwortung? Im heutigen Umfeld gehören dazu aktuelle automatisierte Dashboards, der Abgleich mehrerer Werkzeuge, der Einsatz von KI und die Beteiligung an Produkt- und Problemlösungsarbeit. Danach sollte man sich immer größeren funktionsübergreifenden Problemen widmen.

Galen Low: Das gefällt mir sehr. Wir sitzen am Knotenpunkt. Wenn man diese Rolle aus dem Zentrum entfernt und sie ausschließlich auf Softwareentwicklung ausrichtet, geht ein großer Teil des Werts verloren. Gerade die Skalierung, die Komplexität, die verschiedenen Partner, Teams und Disziplinen machen den Wert dieser Rolle aus.

Dafür braucht man ein tiefes Verständnis. Man kann nicht einfach Checklisten abhaken und Rahmenwerke über Produkte legen, die man nicht versteht. Man muss wissen, worin der Wert besteht, wie die Produkte entstehen und wie man ihre sinnvolle und wirkungsvolle Bereitstellung unterstützt.

Satish, vielen Dank, dass du dir heute die Zeit genommen hast. Es hat viel Spaß gemacht. Wo können sich die Zuhörer über dich informieren?

Satish Menon: Sucht einfach nach mir auf LinkedIn.

Galen Low: Noch einmal vielen Dank.

Satish Menon: Ich habe unser Gespräch sehr genossen, Galen. Vielen Dank für die Gelegenheit.

Galen Low: Gut, Leute. Das war diese Episode des Podcasts Digital Project Manager. Wenn euch dieses Gespräch gefallen hat, abonniert uns auf der Plattform, auf der ihr zuhört. Wenn ihr noch mehr taktische Einblicke, Fallstudien und Arbeitsvorlagen möchtet, erstellt ein kostenloses Konto bei thedigitalprojectmanager.com.

Bis zum nächsten Mal und danke fürs Zuhören.