.svg)
Die Interviewserie Strategy Pattern zeigt, wie Technologieführer in komplexen, sich verändernden Umgebungen wichtige Entscheidungen treffen. Es stützt sich auf Beispiele aus der Praxis und wiederholbare Rahmenbedingungen und liefert umsetzbare Erkenntnisse, um Herausforderungen zu antizipieren und Unternehmen mit Zuversicht zu unterstützen. In der Serie können Sie mehr lesen und sich weitere Interviews ansehen hier.
David Linten, CTO von TrustPortal, stand vor einer Herausforderung, vor der letztlich jeder Technologieführer steht. Sein Team hatte sich mit EY zusammengetan und den Auftrag von Telefónica erhalten, um eine der zu dieser Zeit weltweit größten Implementierungen der robotergestützten Prozessautomatisierung zu leiten. Was sie noch nicht hatten, war eine systematische Herangehensweise an die strukturellen Mängel, die sich fast unmittelbar nach Beginn der Arbeiten häuften würden.
Die Sprint-Zeitlinien weigerten sich, sich zu synchronisieren. Der Umfang schlich sich ein, als der Kunde Probleme umging, anstatt sie zu lösen. Wichtige Mitarbeiter gingen und nahmen kritisches Wissen mit. Dann veröffentlichte die Robotiksoftware ein Versionsupdate, das jeden automatisierten Prozess, den das Team entwickelt hatte, kaputt machte. Das Wissen, das zur Behebung dieses Problems erforderlich war, befand sich in einer Partnerorganisation mit einer inkompatiblen Arbeitsweise. Jeder Checkpoint war eine vertragliche Verpflichtung, die Telefónica bereits gegenüber ihren eigenen Kunden eingegangen war. Das Fehlen eines solchen war keine Unannehmlichkeit bei der Lieferung. Es war ein kaskadierender kommerzieller Misserfolg.
Was Lintens Erfahrung einer Untersuchung wert ist, ist nicht, dass er das Programm gehalten hat. Es ist vielmehr so, dass der Weg dorthin unstrukturiert, kostspielig und wiederholt unterbrochen war, bevor sich ein systematischer Ansatz herauskristallisierte. Dies ist ein Bericht über diese Reise und den Rahmen, den er daraus aufgebaut hat.
TrustPortal wurde 2017 von Chris Lamberton und zwei anderen gegründet, und Chris ist heute als strategischer Berater tätig. David Linten kam als CTO hinzu und brachte einen Hintergrund mit, der von der Physik in die Softwareentwicklung überging.
Das Kernangebot von TrustPortal hat sich von der Integration von Robotic Process Automation (RPA) zu dem weiterentwickelt, was das Unternehmen heute als Agentic HyperAutomation in Echtzeit beschreibt: die gleichzeitige Orchestrierung von Menschen, KI-Agenten und Altsystemen, um komplexe Workflows innerhalb von Sekunden bereitzustellen, ohne die bestehende Infrastruktur zu ersetzen. Der Plattform vertrauen Banken, Versicherungen, Versorgungsunternehmen und Telekommunikationsunternehmen. Zu den Kunden gehören Telefónica, EDF, IBM, OVO Energy und andere.
Eine der wichtigsten Implementierungen ist nach wie vor die Transformation des Kontaktzentrums, bei der die Plattform von TrustPortal eine „Generative UI“ in Echtzeit bereitstellt, die geführte Workflows für Berater bereitstellt, Systemwechsel überflüssig macht, das erneute Eingeben reduziert und die Ergebnisse direkt am Telefon statt in einer Warteschlange abgeschlossen werden.
Das Unternehmen deckt den gesamten Lieferstapel ab, von Backend-Banksystemen bis hin zu Frontend-Kundenschnittstellen, und hat eine über elf Jahre andauernde Lieferpartnerschaft mit Imaginary Cloud aufgebaut.
Von Anfang an lautete Lintens Philosophie: Er arbeitet nicht mit Entwicklern zusammen, er nennt sie lieber Ingenieure, und die Unterscheidung ist ihm wichtig. Ein Entwickler schreibt Code. Ein Ingenieur versteht Architektur. „Wir stellen keine Entwickler ein“, sagt er. „Wir stellen Ingenieure ein. Jeder hat seine Hand in der Architektur, bis hin zum Schreiben von Codezeilen.“
Diese Philosophie prägte jede Entscheidung, die er im Telefónica-Programm traf, auch die, von denen er wünschte, er hätte sie früher getroffen.
Durch das Engagement von Telefónica wurde TrustPortal neben EY als Systemintegrator und Blue Prism als Anbieter von Robotiksoftware in eine Lieferkette aufgenommen. Im Rahmen der Ausschreibung hatten TrustPortal und EY direkt gegen zehn andere Systemintegratoren angetreten. TrustPortal gewann, vor allem, weil sein Entwicklungsteam schneller und mit weniger Fehlern agieren konnte als ein größeres Unternehmen, das auf getrennte Abteilungen und langsamere Feedback-Schleifen angewiesen war.
Was damals niemand sagte, war, dass Sie einen Auftrag gewinnen, indem Sie klein, schnell und architektonisch streng sind, Sie nicht davor schützt, was als nächstes passiert, wenn Sie in einer Struktur arbeiten, die nichts von diesen Dingen ist.
Das Programm war in dreimonatige Checkpoint-Zyklen gegliedert, die jeweils eine harte kommerzielle Verpflichtung gegenüber den B2B-Kunden von Telefónica darstellten. Die Probleme traten fast sofort auf.
Die Sprint-Zeitpläne zwischen Partnern wurden nie auf natürliche Weise synchronisiert. TrustPortal würde seinen Teil eines Zyklus früher als geplant abschließen und dann die verbleibende Zeit damit verbringen, andere Partner zum Checkpoint zu bewegen.
„Wann immer Sie mit Partnern zusammenarbeiten, stimmen die Sprints nie wirklich mit der realen Welt überein“, erklärt Linten. „Man muss viel Zeit einplanen, um einen Rückzieher zu machen und zu versuchen, ihren Teil der Leistung nachzuholen, um das Ende des Dreimonatszyklus zu konsolidieren.“
Es folgte Scope Creep. Telefónica passte im Verlauf des Programms kontinuierlich ihre Anforderungen an. „Viele Unternehmen auf dieser Ebene werden das Problem nicht lösen. Sie werden das Problem umgehen.“ Bei jeder Änderung des Umfangs, die ohne Bewertung gegenüber dem ursprünglichen Auftrag vorgenommen wurde, häuften sich im Hintergrund technische Schulden an, denen eine zukünftige Rechnung beigefügt war. Untersuchungen zu mehr als 5.400 IT-Projekten ergaben, dass die Gesamtkosten bei jedem Projekt um 66 Milliarden $ überschritten wurden zusätzliches Jahr der Projektdauer, wodurch die Überschreitungen um 15 Prozent steigen, ein Muster, das TrustPortal in Echtzeit beobachtete.
Dann kam das Blue Prism Update. Und die Projektmitarbeiter begannen zu gehen.
Jedes Problem sah an der Oberfläche anders aus. Linten würde irgendwann verstehen, dass sie alle dieselbe Ursache hatten.
Der ursprüngliche Ansatz von TrustPortal zur Unterstützung des Programms war logisch. Benennen Sie die Personen mit der größten Fachkompetenz als zentrale Ansprechpartner für jeden Workstream. Diese Leute haben das Projekt am besten verstanden. Sie konnten am effektivsten mit Partnerteams kommunizieren. Sie waren das Bindegewebe der Entbindung.
Das Risiko war erst sichtbar, als es eintrat.
„Während des Projekts haben viele Leute weitergemacht und dieses Fachwissen verloren“, erinnert sich Linten.
Wenn eine wichtige Person das Unternehmen verließ, wurde das Wissen, das sie bei sich trug, nicht an einen Kollegen oder ein Dokument weitergegeben. Es verschwand einfach aus dem Programm.
Seine Reaktion war eher strukturell als prozedural. Er führte die Mindestanforderung ein, dass zwei Personen über fundierte Fachkenntnisse in allen kritischen Bereichen verfügen müssen. Nicht weil es abstrakt eine gute Praxis war, sondern weil er gerade beobachtet hatte, was passiert, wenn diese Redundanz nicht existiert.
„Sobald das erledigt war, fielen unsere Bug-Stacks auf so gut wie nichts.“
Ein Bug-Stack ist mit Kosten verbunden. Wissenskonzentration ist eine Belastung. Zwei Personen für jeden wichtigen Bereich zu benötigen, ist kein Personalaufwand. Es handelt sich um einen Risikokontrollmechanismus mit einer messbaren Rendite. MIT Sloan Management Review identifiziert technische Schulden als Geschäftsverbindlichkeit Das kostet US-Unternehmen jährlich über 2,41 Billionen US-Dollar, eine Zahl, die genau die akkumulierten Kosten erfasst, die Wissenslücken verursachen, wenn sie nicht behoben werden. Was Linten getan hatte, war, ein architektonisches Prinzip anzuwenden und einzelne Fehlerquellen zu eliminieren, und zwar auf das menschliche System des Programms und nicht nur auf seine technischen Komponenten.
Er wusste noch nicht, wie weit ihn dieses Prinzip bringen würde.
Linten stand mitten im Wiederaufbau von Blue Prism und sah die Verbindung, die ihm gefehlt hatte.
Die falsch ausgerichteten Sprints, der Scope Creep, der Wissensverlust, die kaputten Prozesse: Es waren keine separaten Probleme, die separate Lösungen erforderten. Es handelte sich um dasselbe Problem, das auf unterschiedliche Weise ausgedrückt wurde. Jedes von ihnen wurde durch die Distanz zwischen den Menschen, die das Thema verstanden, und den Leuten, die die Lösung entwickelten, verursacht. Die Entfernung zwischen der Organisation, die über das Wissen verfügte, und dem Team, das es benötigte. Entfernung zwischen dem Geschäftsproblem und dem Ingenieur, der mit der Lösung beauftragt wurde.
Das Wissen, um das, was Blue Prism kaputt gemacht hatte, wieder aufzubauen, existierte. Es lag bei den EY-Entwicklern, die an der IVR-Integration arbeiteten. Bei einer normalen Programmverwaltungsstruktur wäre die richtige Reaktion gewesen, das Problem formell anzusprechen, auf die Mobilisierung der Partnerorganisation zu warten und die Verzögerung bis zum Checkpoint abzuwickeln. Linten hat das nicht getan.
„Wir haben die Entscheidung getroffen, diese Leute für TrustPortal zu gewinnen.“
Es gab einen Rückschlag. Es ist nie einfach, die Ressourcen einer anderen Organisation in Anspruch zu nehmen, und Linten räumt ein, dass der Widerstand sofort einsetzte. Doch die kommerzielle Logik war schwer zu widerlegen.
„Diese Leute näher an den Entwicklungsstream und den Entwicklungsprozess heranzuführen, den wir aufgebaut haben, war absolut entscheidend, um die Umsetzung zu beschleunigen.“
Indem Linten die Distanz zwischen dem Wissen und dem Team überwand, beseitigte er die größte Ursache für Verzögerungen im Programm. Die Feedback-Schleife, die bisher über Unternehmensgrenzen hinweg lief, verlief nun innerhalb eines einzigen Teams. Wenn etwas kaputt ging, war die Person, die verstand, warum es kaputt ging, im selben Raum wie die Person, die es reparierte.
Das war die Erkenntnis. Kein Managementprinzip oder eine Teambuilding-Philosophie. Eine strukturelle Beobachtung: Jede Ebene der organisatorischen Distanz zwischen Wissen und Umsetzung ist eine Quelle von Verzögerungen, Fehlern und Risiken. Verringern Sie den Abstand, und die technischen Probleme werden lösbar. Lassen Sie es an Ort und Stelle, und kein noch so großer technischer Aufwand wird das wettmachen.
Repariere zuerst die menschliche Architektur. Die technische Architektur wird folgen.
Was als nächstes bei TrustPortal geschah, war keine einzige Reorganisation. Es war die schrittweise Anwendung desselben Prinzips in allen Bereichen der Arbeitsweise des Unternehmens.
Die erste Änderung war die Regel zur Wissensredundanz, die programmweit angewendet wurde. Mindestens zwei Personen, die für jeden kritischen Bereich zuständig sind. Nicht weil die nächste Person, die das Unternehmen verlässt, zwangsläufig eine Krise auslösen würde, sondern weil das Programm es sich nicht leisten konnte, das herauszufinden.
Die zweite Änderung war radikaler. Nachdem Linten beobachtet hatte, wie TrustPortal sich von einem Startup zu einem Unternehmen entwickelte und die vertrauten Ebenen des mittleren Managements anhäufte, entfernte er sie vollständig. Jeder Entwickler, bis hin zum kleinsten Ingenieur, erhielt direkten Kontakt zu Entscheidungsträgern auf Vorstandsebene. Vertriebsmitarbeiter erfuhren, wie Ingenieure denken. Die Direktoren wurden für jeden, der eine Idee hatte, ansprechbar.
„Jeder Entwickler kann jeden auf der Geschäftsseite fragen, vom Verkäufer bis zum Direktor: Ich habe diese Idee. Können Sie mir sagen, was das eigentliche Geschäftsproblem ist?“
Dies ist keine kulturelle Präferenz. Es ist ein Geschwindigkeitsmechanismus und eine Qualitätskontrolle. Je weiter ein Ingenieur von dem Geschäftsproblem entfernt ist, das er gerade löst, desto wahrscheinlicher ist es, dass er die falsche Version davon löst. Wenn die Ebenen entfernt werden, fühlt sich das Unternehmen nicht nur besser. Dadurch wird die Ausgabe genauer. Untersuchungen von Harvard Business Review In leistungsstarken Teams werden Offenheit und Offenheit zwischen den Ebenen immer wieder als Haupttreiber für Teameffektivität und Durchbrüche auf Marktebene identifiziert — Bedingungen, die von der Managementhierarchie systematisch unterdrückt werden.
Die dritte Änderung war das Onboarding. Neue Mitarbeiter bei TrustPortal verbringen mindestens drei Monate mit der Integration, bevor sie zum Produktionscode beitragen. Der Prozess ist darauf ausgelegt, gegenseitiges Verständnis im gesamten Team aufzubauen und nicht nur die technische Kompetenz des neuen Mitarbeiters. Ingenieure lernen den Geschäftsbereich kennen. Das Unternehmen lernt die Ingenieure. Fragen ohne Qualifikation sind erwünscht.
„Weil Sie die drei Monate hinter sich haben, weil sich alle auf einer persönlichen Ebene kennen und verstehen, wie sie denken, werden die Fragen besser darauf abgestimmt, Ergebnisse zu erzielen.“
Für jeden CTO, der prüft, ob diese Investition gerechtfertigt ist: Teams, die sich gegenseitig und die Geschäftswelt verstehen, produzieren weniger Missverständnisse, weniger Nacharbeitszyklen und weniger Fehler. Die dreimonatige Integration ist nicht langsam. Dies ist der schnellste Weg zu einem Team, das ohne ständiges Eingreifen des Managements arbeiten kann.
Was die Integrationsarchitektur selbst anbelangt, so wurde im Telefónica-Programm ein Prinzip festgelegt, das Linten seither konsequent anwendet. Software für die robotergestützte Prozessautomatisierung definiert Prozesse auf Bildschirm- und Benutzeroberflächenebene: sie scrapiert bestimmte Felder, interpretiert bestimmte Ausgaben, navigiert durch bestimmte Benutzeroberflächen. Als Blue Prism die zugrundeliegende Architektur aktualisierte, ging jede dieser Prozessdefinitionen kaputt. Für den Fix war ein vollständiger Neuaufbau erforderlich, kein Patch.
Die Lektion war, dass Integrationsstabilität, wo immer möglich, die Verantwortung für den gesamten Stack voraussetzt. Jede Ebene der Entfernung zwischen dem Team, das die Automatisierung erstellt, und dem Team, das die Prozesse definiert, die sie automatisiert, ist ein Wartungsrisiko, das in die Architektur selbst eingebettet ist. TrustPortal verfolgt seitdem bewusst ein umfassendes Engineering-Modell, bei dem das Fachwissen auf die Teams verteilt wird und nicht auf einzelne Personen oder Rollen konzentriert ist.
Keine dieser strukturellen Änderungen machte das Telefónica-Programm einfach. Die Integration neuer Teammitglieder von EY in ein Bereitstellungsteam, das bereits unter Druck stand und ein Programm mit vertraglich festgelegten Zeitplänen durchlief, schuf genau die Bedingungen, unter denen sich die Entwicklungsteams zurückzogen.
Lintens Reaktion war diejenige, die die Menschen am meisten überrascht, wenn sie sie hören.
Er schützte zehn Prozent der Arbeitswoche jedes Ingenieurs für eigenverantwortliche Forschung und Entwicklung, und dieses Engagement hielt er auch in den am stärksten beanspruchten Phasen des Programms aufrecht.
Die Begründung war nicht großzügig. Es war betriebsbereit. Ingenieure, die einem anhaltenden Lieferdruck ausgesetzt sind und über keinen Teil ihrer Arbeitswoche autonom verfügen, hören auf, wie Ingenieure zu denken. Sie optimieren für die vor ihnen liegende Kennzahl, die in einem Lieferprogramm die Fertigstellung eines Sprints ist, und nicht für die Qualität und Langlebigkeit dessen, was sie bauen. Die geschützte Zeit verhinderte diese Verengung. Die Forschung von HBR zu unternehmenskritischem Wissen hat Folgendes ergeben Nachhaltiges Wachstum in großem Maßstab hängt davon ab, dass Menschen fundiertes Fachwissen bereichsübergreifend weitergeben, etwas, das nur passiert, wenn Ingenieure den Freiraum haben, über den unmittelbaren Lieferzyklus hinaus zu denken.
„Es gibt nichts Schlimmeres, als jemanden von irgendwoher herzubringen und ihn dann in einen Kanal zu stecken, damit er wie an einer Fabrikstraße arbeitet. So denken Ingenieure nicht wirklich.“
Wie sich dieses Engagement ausgezahlt hat, wurde vor Kurzem konkret sichtbar. In einem geschützten, dreimonatigen Forschungs- und Entwicklungsprojekt wurden die Grundlagen für ein völlig neues TrustPortal-Produkt geschaffen, das von zwei Ingenieuren innerhalb der ihnen zugewiesenen Zeit geliefert wurde.
Linten legte auch Wert darauf, den Ingenieuren die direkten Auswirkungen ihrer Arbeit zu zeigen. Bei einem Programm dieser Größenordnung kann es leicht passieren, dass jemand, der tief in einer einzelnen Komponente steckt, aus den Augen verliert, wozu er beiträgt. Er hat es sich zur Gewohnheit gemacht, Menschen mit dem Ganzen zu verbinden. „Das ist der Teil, den du gemacht hast. Schau dir an, wie es im größten Projekt der Welt funktioniert. Das ist Ihr Beitrag, der tatsächlich einen signifikanten Unterschied macht.“ Das ist keine Motivationstechnik. Es ist Information. Ingenieure müssen das System sehen, um sich architektonisch Gedanken über ihren Teil davon machen zu können.
Dieses Framework arbeitet in drei integrierten Dimensionen.
Die strategische Dimension erfordert vor allem eine Disziplin: die Diagnose in den eigenen Besitz zu nehmen, bevor die Lösung delegiert wird.
Die meisten Lieferfehler beginnen mit Planungsfehlern. Das Problem tritt getarnt als technisches Problem auf. Der Instinkt besteht darin, es an das Ingenieurteam weiterzugeben. Dieser Instinkt ist falsch.
„Der Grund, warum Sie ein Geschäftsproblem haben, ist, dass es von Anfang an nicht richtig geplant wurde. Es ist sehr unfair, dieses Problem dann zu nehmen und eine voraussichtliche Ankunftszeit für eine fiktive Lösung zu erstellen.“
Lintens Reaktion darauf bestand darin, neben der Bereitstellungsarchitektur eine Risikominderungsarchitektur zu entwickeln. Für jeden Workstream existierte ein Notfallplan, bevor der Checkpoint eintraf.
„Sie können niemals ein Geschäftsproblem zu den Ingenieuren bringen und erwarten, dass sie Ihre Arbeit für Sie erledigen. Sie müssen Verantwortung auf der C-Ebene übernehmen.“
Notfallplanung kostet weniger als ein Vertragsbruch. Das ist der Geschäftsszenario. Alles andere folgt daraus.
Die technische Dimension befasst sich mit einer Realität: Jede Ebene der organisatorischen Distanz zwischen Wissen und Ausführung ist ein in die Architektur eingebettetes Wartungsrisiko.
Als Blue Prism mitten im Programm die zugrundeliegende Architektur aktualisierte, ging jede Prozessdefinition kaputt. Das Wissen, um das Problem zu beheben, hatten die IVR-Entwickler von EY in einem parallelen Workstream. Linten wartete nicht auf die übliche Programmsteuerung, um es zu mobilisieren.
Die Feedback-Schleife, die zuvor über Unternehmensgrenzen hinweg lief, verlief nun innerhalb eines einzigen Teams. Wenn etwas kaputt ging, war die Person, die den Grund dafür verstand, im selben Raum wie die Person, die es reparierte.
TrustPortal verfolgt seitdem ein Full-Stack-Engineering-Modell. Jeder Ingenieur trägt neben der Lieferverantwortung auch die Verantwortung für die Architektur. Domänenwissen wird planmäßig verteilt, nicht zufällig.
Die kulturelle Dimension erwies sich als die komplexeste. Strukturelle Veränderungen, die auf dem Papier logisch sinnvoll sind, sorgen für echte Reibung, wenn sie auf Menschen angewendet werden, die unter Lieferdruck stehen.
Linten fand heraus, dass Menschen in erkennbaren Mustern reagieren. Manche passten sich sofort an. Andere brauchten sichtbare Beweise, bevor sie sich verpflichteten. Eine kleinere Zahl hat sich nie vollständig angepasst. Seine Reaktion auf jede Gruppe war strukturell, nicht motivierend. Die Struktur wurde geändert, sodass das neue Modell zu besseren Ergebnissen führte und die Leute von dort aus ihre eigenen Entscheidungen trafen.
Die Verwaltungsebenen wurden vollständig entfernt. Jeder Entwickler erhielt direkten Zugang zu den Personen, die die Geschäftsprobleme definierten.
„Jeder Entwickler kann jeden auf der Geschäftsseite fragen, vom Verkäufer bis zum Direktor: Ich habe diese Idee. Können Sie mir sagen, was das eigentliche Geschäftsproblem ist?“
Neue Mitarbeiter verbringen drei Monate mit der Integration, bevor sie zum Produktionscode beitragen. Zehn Prozent der wöchentlichen Arbeitszeit eines jeden Ingenieurs sind durch eigenverantwortliches R&D abgesichert.
Diese geschützte Zeit bildete die Grundlage für ein völlig neues TrustPortal-Produkt, das von zwei Ingenieuren innerhalb des ihnen zugewiesenen Sprints geliefert wurde. Die Investition war operativ, nicht kulturell bedingt.
Das Strategie-Muster, das seinen Ursprung in der Softwaretechnik hat, definiert eine Familie von Algorithmen, kapselt jeden einzelnen ein und macht sie austauschbar, sodass die Entscheidungslogik unabhängig vom spezifischen zu lösenden Problem variieren kann. Es handelt sich um ein Verhaltensmuster, das auf Flexibilität ausgelegt ist: ein System, das seinen Ansatz zur Laufzeit ändern kann, ohne dass die umgebende Architektur neu aufgebaut werden muss.
Auf die Unternehmensführung angewendet, ist die Logik identisch. Ein Unternehmen sollte genauso wenig an starre, veraltete Strukturen gebunden sein, wie ein gut durchdachtes Softwaresystem an einen einzigen Algorithmus gebunden sein sollte. Wenn sich das Umfeld ändert, ändert sich auch der spezifische Ansatz. Der zugrunde liegende Entscheidungsrahmen tut dies nicht.
Linten verwendete diese Sprache nicht, um seinen Ansatz zu beschreiben. Aber bei jeder Entscheidung, die er im Rahmen des Telefónica-Programms getroffen hat, und bei jeder Änderung, die er seitdem bei TrustPortal vorgenommen hat, ist dasselbe Muster sichtbar: zuerst das strukturelle Problem diagnostizieren, die menschliche Architektur vor der technischen berücksichtigen und dieselbe Logik anwenden, unabhängig davon, ob es sich bei der Herausforderung um eine Fehlausrichtung der Partner, den Verlust von Wissen oder die Einführung agentischer KI handelt.
Das Telefónica-Programm wurde pünktlich abgeschlossen. TrustPortal transformierte die Geschäftstätigkeit des größten Unternehmens in Spanien.
Noch wichtiger ist, dass sich das Muster als übertragbar erwiesen hat. Seitdem wendet Linten bei TrustPortal bei jeder wichtigen Entscheidung den gleichen diagnostischen Rahmen an: dieselbe Sequenzierung, dieselbe strukturelle Linse, denselben Instinkt, die menschliche Architektur zu betrachten, bevor nach einer technischen Lösung gesucht wird.
Der aktuelle Test dieser Übertragbarkeit ist die agentische KI. Die Ingenieure von TrustPortal gehen vom direkten Schreiben von Code dazu über, KI-Agenten auf architektonische Ergebnisse hinzuweisen. Der Widerstand, auf den Linten stößt, ist erkennbar. Kompetente Menschen, die ihre berufliche Identität auf einer Reihe von Tools aufgebaut haben, werden gebeten, ihr Verhältnis zu diesen Tools grundlegend zu ändern. Der Instinkt besteht darin, immer wieder nach dem Vertrauten zu greifen. Gartner sagt das voraus 40% der Unternehmensanwendungen werden mit aufgabenspezifischen KI-Agenten integriert bis Ende 2026, wenn Linten den Übergang vollzieht, steht es nicht um zukünftige Überlegungen, sondern um eine aktuelle Herausforderung bei der Umsetzung.
Seine Antwort folgt dem gleichen Muster. Er schreibt weder eine Einführung vor noch misst er die Produktivität anhand der KI-Output-Ziele. Er definiert die Rolle auf Architekturebene neu: kein Entwickler, der Codezeilen schreibt, kein Techniker, der schnell Anweisungen eingibt, sondern jemand, der die Geschäftsarchitektur gut genug versteht, um ein Programm auf das richtige Ergebnis auszurichten. Und er schützt den Raum, in dem Ingenieure mit dem neuen Ansatz experimentieren können, bevor er zur Lieferanforderung wird.
Die tiefere Herausforderung, für die er bereits entwirft, ist sozialer Natur. „Die Menschen verwenden Agententools und sind tatsächlich weniger mit den Menschen verbunden, die sie kennen, weil sie sich immer weniger auf die Informationen verlassen, die sie in ihren Köpfen haben, und die KI nutzen, um dieselben Informationen zu erhalten.“ Die menschlichen Verbindungen, die dafür sorgen, dass sein Modell funktioniert, könnten unter Druck geraten, da die KI mehr von der Funktion des Informationsabrufs übernimmt, der menschliche Konversation früher diente. Die Aufrechterhaltung der Bedingungen für eine echte Zusammenarbeit in einem Team, dessen Mitglieder zunehmend mit KI statt miteinander interagieren, ist das nächste Strukturproblem, auf dessen Lösung er sich vorbereitet.
Er weiß die Antwort noch nicht. Aber er weiß, welche Frage er zuerst stellen muss.
Sobald die Strukturdiagnose abgeschlossen ist, ergeben sich drei Aktivitätskategorien.
Investitionen in Bereitstellungsstrukturen, die kritisches Fachwissen auf einzelne Personen konzentrieren. Führungsebenen, die die Distanz zwischen Geschäftsproblemen und den Personen, die sie lösen, vergrößern. Zeitpläne und ETAs gelten für Probleme, die noch nicht richtig diagnostiziert und auf der entsprechenden Organisationsebene geklärt wurden.
Strukturelle Redundanz für kritisches Fachwissen in jedem Programm, wobei mindestens zwei Personen über fundierte Fachkenntnisse in jedem Bereich verfügen. Direkter Kontakt zwischen Ingenieurteams und Entscheidungsträgern auf Vorstandsebene ist eine Standardbetriebsbedingung, keine Ausnahme. Geschützte Zeit für autonome Erkundungen, auch unter Lieferdruck, als betriebliche Investition und nicht als kulturelle Geste.
Bestehende Kundenverpflichtungen und Qualitätsstandards für alle aktiven Programme. Die diagnostische Gewohnheit, die menschliche Architektur zu bewerten, bevor versucht wird, die technische zu korrigieren. Onboarding-Prozesse, bei denen das gegenseitige Verständnis Vorrang vor dem Beitrag zur Produktion hat.
Linten sagt direkt, was das in der Praxis schwierig macht. „Sie können niemals ein Geschäftsproblem zu den Ingenieuren bringen und erwarten, dass sie Ihre Arbeit für Sie erledigen. Sie müssen Verantwortung auf der C-Ebene übernehmen.“
Das ist keine kulturelle Beobachtung. Es ist eine strukturelle Anforderung. Solange das Scheitern des Unternehmens nicht richtig diagnostiziert wurde und nicht auf der richtigen Ebene entschieden wird, führt die Weitergabe an das Bereitstellungsteam zu genau dem kostspieligen, fehlgeleiteten Aufwand, auf den das Telefónica-Programm vor den Strukturänderungen gestoßen war.
Die spezifischen Details des Telefónica-Programms sind bereits historisch. Die beteiligten Partner, die Versionskonflikte, die IVR-Integrationen: All das ist nicht der Punkt.
Was nach wie vor relevant ist, ist der Entscheidungsrahmen, den Linten entwickelt hat, indem er jeden Fehler aufgearbeitet hat, den das Programm verursacht hat. Nicht, indem wir sie im Voraus planen, sondern indem wir das Muster in ihnen erkennen, nachdem sie aufgetreten sind, und eine strukturelle Reaktion entwickelt wurde, die verhindern würde, dass sich derselbe Misserfolg in einer anderen Form wiederholt.
Die Lektion besteht nicht darin, Partnerentwickler zu gewinnen, das mittlere Management abzuschaffen oder zehn Prozent der Entwicklungszeit zu schützen. Dies waren die spezifischen Implementierungen eines allgemeineren Prinzips. Die Lektion besteht darin, die menschliche Architektur zu korrigieren, bevor nach der technischen Lösung gesucht wird, die Distanz zwischen Wissen und Ausführung zu verringern und diese Logik konsequent anzuwenden, wenn sich die Umgebung um Sie herum verändert.
„Die Technologie ändert sich, aber die Menschen tun dies auf lange Sicht nicht. Menschen verhalten sich auf eine bestimmte Art und man muss in der Lage sein, damit umzugehen.“
Die einzige Gewissheit ist, dass die strukturelle Herausforderung kommen wird. Eine wichtige Person wird gehen. Ein Partner wird ins Hintertreffen geraten. Ein Versionsupdate wird das, was Sie gebaut haben, kaputt machen. Eine neue Technologie wird auf den Markt kommen und die Ingenieure, die die vorherige beherrschen, werden sich der Umstellung widersetzen. An diesem Punkt stellt sich nicht die Frage, ob Sie über die richtige Technologie verfügen. Es geht darum, ob Sie die menschliche Architektur geschaffen haben, die in der Lage ist, darauf zu reagieren.
Wenn Sie besprechen möchten, wie dieses Framework auf die Technologietransformation, die Plattformmigration oder strategische Technologieentscheidungen Ihres Unternehmens angewendet werden kann, wenden Sie sich bitte an kontaktiere unser Team.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
