Engineering Leadership
Kimmo Myllyviita
Ich gestalte, wie Teams Software liefern, wenn Agenten Teil des Teams sind.
20+ Jahre in der Softwareentwicklung, vom Code bis zur Führung von Engineering-Teams
Mitgründer eines Healthtech-Startups. Mitglied von Leitungsteams. Transformation vorangetrieben.
Aufbau von und Beratung zu agentic Engineering, Mensch-Agent-Zusammenarbeit und Teamtransformation.
„Entwicklungssilos gehören der Vergangenheit an. Die Zukunft braucht kollaborative Arbeitsmodelle: Mensch-zu-Agent, Mensch-zu-Mensch und Agent-zu-Agent."
Engineering Leadership
Agentic AI
Human-AI Workflow Design
SDLC-Transformation
Teamaufbau
Problem. Lösung. Warum ich.
Problem
KI wird nicht als transformative Fähigkeit verstanden.
Die meisten Führungsteams behandeln KI als Produktivitätswerkzeug: Copiloten, Chat-Assistenten, schnellere Tickets. Nur wenige verstehen sie als Verschiebung dessen, was eine Organisation bauen kann und wie Arbeit strukturiert sein sollte. Deshalb bleiben die Gewinne individuell, während sich an der Delivery nichts ändert – und deshalb stagnieren die meisten Organisationen zwischen L1-Tool-Adoption und L3-orchestrierter Delivery. Die Tools sind nicht die Lücke. Das Verständnis ist es.
Lösung
Die Pipeline so gestalten, dass sie Agenten Kontext by Design liefert.
Agenten brauchen keine besseren Prompts. Sie brauchen Requirements, Epics, Stories und Architektur-Spezifikationen, die so strukturiert sind, dass die Pipeline selbst den Kontext liefert. Das ist ein SDLC-Redesign, kein Tooling-Kauf. Es braucht jemanden, der sowohl das Leitungs-Operating-Model als auch den Engineering-Alltag versteht.
Warum ich
Ich sitze seit über 20 Jahren auf beiden Seiten des Tisches.
Ich habe in Leitungsteams gesessen und selbst "Millionen Zeilen" Produktionscode geschrieben. Ich habe ein Healthtech-Startup mitgegründet und Multi-Team-Engineering bei einem Telco geleitet. Ich betreibe agentic Development heute selbst, statt nur darüber zu lesen. Und ich habe gelernt: Transformation scheitert, wenn die Engineers ihr nicht vertrauen. Dieses Vertrauen entsteht durch Erfahrung – die ich habe.
Für Software Delivery im KI-Zeitalter gibt es noch kein Playbook, aber es gibt Prinzipien, die generell gelten.
Ich helfe Teams und Organisationen, ihre Transformationsreise zu gestalten – massgeschneidert, basierend auf ihrem eigenen Kontext und ihren Zielen.
Ansatz
Wie ich das Problem angehe
Engineering Leadership im KI-Zeitalter ist kein technisches Problem. Es ist ein organisatorisches, kulturelles und Workflow-Problem, das zufällig viel Technologie mit sich bringt.
Grundlagen zuerst
Testabdeckung, CI/CD, klare Verantwortlichkeiten, sinnvolle Backlogs. Das ist nicht glamourös, aber Organisationen, die das überspringen, können KI-Tooling nicht wirksam aufnehmen. Jede ernsthafte Transformation, die ich geleitet habe, begann hier.
Zwei Ebenen gleichzeitig
Glaubwürdig sein beim Leitungsteam bei Operating-Model-Entscheidungen und gleichzeitig nah genug an den Engineers bleiben, um zu wissen, was wirklich passiert. Ich agiere auf beiden Ebenen gleichzeitig, und das ist es, was Transformation nachhaltig macht.
Engineers als der limitierende Faktor
Gute Engineers sind rar und leicht zu demotivieren. Tools lösen das nicht. Kultur, Autonomie und sinnvolle Arbeit tun es. KI-Adoption scheitert, wenn sie sich aufgezwungen anfühlt. Sie funktioniert, wenn Engineers das Gefühl haben, Fähigkeiten zu gewinnen, statt ersetzt zu werden.
Kontext by Design, nicht per Prompt
Agenten erhalten Kontext nicht aus Runtime-Prompts. Sie erhalten ihn aus der SDLC-Pipeline: Requirements, Epics, User Stories, Architektur-Spezifikationen. Die Organisation, die ihre Pipeline so strukturiert, dass sie Agenten korrekt versorgt, ist diejenige, die zuverlässige Ergebnisse erhält. Dieses Redesign ist ein Führungsproblem, kein Tooling-Problem.
Architektur
Intent → Build → Run
Auf sehr hoher Ebene ist die agentic Pipeline eine Trilogie: drei Stufen, gleichwertige Teile des Ganzen, die eine agentic Schleife bilden. Human-in-the-loop ist eine Design-Entscheidung an jedem Übergang, keine feste Rolle. Sie wird bewusst eingebaut oder ganz weggelassen – von Fall zu Fall.
01 · Intent
Requirements & Issues
Typischerweise Produkt-Territorium. In diesem Modell ist es ein essenzieller Teil der agentic Pipeline selbst, kein Input, der über die Mauer ans Engineering gereicht wird – und es umfasst Issues genauso wie neue Requirements. Ohne es bricht die Schleife.
02 · Build
Implementierung und Verifikation
Hier wird Code geschrieben, getestet und gegen den Intent geprüft. Die Stufe, die Engineers am besten kennen – aber sie funktioniert nur so gut wie der Intent, der sie speist.
03 · Run
System-Monitoring und Self-Heal
Beobachtet, was in Produktion gebaut wurde, und speist die Erkenntnisse als neue Issues zurück in Intent – die Schleife schliesst sich. Ob diese Rückgabe einen menschlichen Blick braucht oder direkt durchläuft, ist eine Design-Entscheidung, von Fall zu Fall getroffen.
Agentic SDLC ist kein Engineering-Framework, sondern ein vollständiges End-to-End-Produktlebenszyklus-Design. Es massgeschneidert zu bauen, zu betreiben und zu verbessern, ist der Ort, an dem die besten Engineers sich weiterhin auszeichnen. Experten werden immer gebraucht, aber der Fokus verschiebt sich möglicherweise von tiefer Spezialisierung hin zu Value Thinking und Domänenwissen.
Methode
Der Weg dahin
Der Workflow wird zu Ihrer Software-Fabrik, vielleicht sogar zu einer autonomen – aber es gibt keine Abkürzung dorthin: Es gibt kein "Agentic Scrum"-Playbook. Jede Organisation braucht ihr eigenes Redesign, und weil sich die Technologie ständig weiterentwickelt, ist es keine einmalige Transformation, sondern eine sich entwickelnde.
Pilotprojekte sind leicht zu starten und leicht wieder aufzugeben: Eine aktuelle MIT-Studie (
08/25) fand heraus, dass 95 % von ihnen nie in Produktion gehen. Nicht weil die Tools nicht funktionieren, sondern weil niemand den Workflow darum herum neu gestaltet hat.
1
Die Baseline anerkennen — wie wir heute arbeiten, technologisch und menschlich
3
Grenzen, Risiken und Governance verstehen
4
Die Agenten-Grundlage bauen — eine Single Source of Truth für Kontext
5
Den ersten agentic Workflow gestalten — bei Crawl beginnen. KPIs definieren, bevor skaliert wird.
6
Walk, dann Run — die Schleife, die dorthin führt: beobachten, messen, verbessern (Durchlaufzeit, Kosten, Qualität, Vertrauen)
Lässt man diese Schleife lange genug laufen, wird Delivery selbst zur Commodity. Was knapp und wertvoll bleibt, ist menschliches Urteilsvermögen: zu wissen, was gebaut werden soll, was gestrichen wird, und wo Vertrauen noch verdient werden muss.
Reifegradmodell
Wo Teams heute stehen
Die meisten Organisationen befinden sich auf L1 oder L2: ad-hoc KI-Tool-Adoption ohne systemisches Redesign. Die Transformation passiert nicht automatisch – sie erfordert bewusste Führung an der kritischen Schwelle und darüber hinaus.
Die Lücke zwischen L2 und L3 ist der Punkt, an dem die meisten Transformationen stecken bleiben. Sie zu überwinden erfordert die Neugestaltung von Workflows, Governance und Teamstruktur — nicht nur den Kauf weiterer Tools.
Organisationsmodell
Von Silos zur Onion-Layer-Organisation
Das Silo-Modell wurde für eine Welt entworfen, in der Übergaben unvermeidlich waren. In einer agentic Pipeline ist der Kontextverlust bei jeder Übergabe genau das, was die Delivery bricht. Das Onion-Modell leitet Kontext von der Strategie bis zur Ausführung nach innen, mit Menschen eingebettet an jeder Schichtgrenze.
Kontext fliesst nach innen durch die Pipeline, nicht aus Runtime-Prompts. Die Organisation ist so strukturiert, dass sie Delivery optimiert — nicht umgekehrt.
