.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.
Tiago Franco, Gründer und Geschäftsführer von Imaginary Cloud, stand vor einer Herausforderung, vor der letztlich jedes Technologieunternehmen steht. Das Fachwissen, das sein Unternehmen erfolgreich gemacht hatte, verlor den Überblick. Nicht weil die Technologie selbst an technischer Reife oder Robustheit verloren hatte, sondern weil ihre Marktrelevanz abgenommen hatte, als sich die Branche einem anderen Tech-Stack zuwandte.
In den ersten Jahren lieferte Imaginary Cloud Projekte hauptsächlich in Ruby on Rails. Dann begannen Interessenten, Vorschläge mit zunehmender Häufigkeit abzulehnen, was hauptsächlich auf den Technologie-Stack zurückzuführen war. Der Grund war einfach: React und Node.js waren das neue Trendthema.
Was Francos Erfahrung einer Untersuchung wert ist, ist nicht, dass er diesen Übergang erfolgreich gemeistert hat. Was ihn wertvoll macht, ist nicht das Scheitern, sondern die Tatsache, dass der Übergang unstrukturiert, schwierig und kostspielig war, bevor ein systematischer Ansatz entstand, der auf zukünftige Technologieveränderungen angewendet werden könnte. Dies ist ein Bericht über diese Reise und die daraus gewonnenen Erkenntnisse.
Franco gründete Imaginary Cloud, ein Beratungsunternehmen für digitale Transformation mit Sitz in Portugal, das Kunden dabei unterstützt, im digitalen Raum erfolgreich zu sein und dort präsent zu sein. Seit seiner Gründung im Mai 2010 hat das Unternehmen zur Skalierung von über 300 digitalen Produkten in Europa, den Vereinigten Staaten und dem Nahen Osten beigetragen und Kunden wie Nokia, BNP Paribas und Thermo Fisher betreut. Das Unternehmen beschäftigt heute über 100 Mitarbeiter in vier Niederlassungen weltweit und verzeichnet eine Kundenempfehlungsrate von 99%
Er entwickelte Imaginary Cloud, nachdem er als Softwareingenieur und Projektmanager für Organisationen wie das CERN, die Europäische Weltraumorganisation und das britische Verteidigungsministerium gearbeitet hatte. Was diese Organisationen auszeichnete, war ihr tiefes Vertrauen in Innovation sowie Forschung und Entwicklung, eine Denkweise, die Franco in Imaginary Cloud übertrug.
Dieser Fokus wurde jedoch hauptsächlich aus technischer Sicht und nicht von den Zielen des Benutzers bestimmt, eine Spannung, die seine Überzeugung prägte, dass sich der Entwicklungsprozess ändern muss.
Die Gründungsarbeit befasste sich mit dem, was Franco als wiederkehrendes Problem ansah: Qualitätsorientierte Software ist oft schwierig zu bedienen und anfällig für menschliche Fehler, da sie den Benutzer nicht in den Mittelpunkt stellt. Ohne ein nutzerorientiertes Design führt technische Qualität nicht zu einer effektiven, zuverlässigen Nutzung.“ Imaginary Cloud würde beide Ansätze zusammenführen.
Ruby on Rails wurde zur Haupttechnologie, weil es dieser Vision entsprach. In den ersten Jahren funktionierte die Strategie und das Unternehmen realisierte Dutzende von Projekten auf der ganzen Welt. Dann veränderte sich der Markt, teilweise beeinflusst von Facebooks Entscheidung, React als Open Source zu veröffentlichen und fördern neue Architekturansätze, die JavaScript-basierte Stacks wie React und Node.js gegenüber traditionelleren Frameworks bevorzugten. Heute stehen Unternehmen vor einer ähnlichen Herausforderung in Bezug auf KI-Technologien, bei denen der schnelle Einführungsdruck dazu führen kann, dass etablierte Tools oder Prozesse veraltet erscheinen.
Die Umstellung erfolgte schneller als Franco erwartet hatte. React und Node.js, die ein grundlegendes architektonischer Wandel von monolithischen zu Microservice-Mustern, wurde zu dem, was Franco als „das, mit dem jeder Kunde beginnen wollte“ beschreibt. Ruby on Rails „ist keine wünschenswerte Technologie mehr, um ein neues Projekt zu starten“.
Das Paradoxon war entscheidend. Imaginary Cloud schlug Ruby on Rails-Lösungen vor, die für die Produkte in der Anfangsphase, die die meisten Kunden entwickelten, technisch überlegen waren und 30 bis 40% günstiger waren als Microservice-Alternativen. Die Kunden lehnten diese Vorschläge jedoch ausschließlich aufgrund des Technologie-Stacks ab.
„Der Kunde hat keinen Mehrwert bekommen. Der Kunde erhielt weniger Wert, weil er mehr für eine Technologie bezahlte, die für die jeweilige Phase, in der er sich gerade befindet, weniger geeignet ist, aber er kaufte diesen Tech-Stack einfach nicht.“
Franco beschloss, das gesamte Unternehmen auf React und Node.js umzustellen. Er hatte jedoch keinen systematischen Ansatz für die Durchführung dieser Transformation. Das Ergebnis war, was er heute als tiefgreifende Ineffizienz bezeichnet.
Auf die Frage, wie er das Problem formuliert und dem Unternehmen die Übergangsstrategie mitgeteilt hat, antwortet Franco direkt: „Ich habe es nicht getan. Das ist der Punkt. Das ist es, was sich an mir als Führungskraft im Laufe der Jahre geändert hat. In der Anfangsphase wusste ich nicht, wie ich mit dieser Veränderung umgehen sollte.“
Statt eines strukturierten Plans ergriff Franco sofort Maßnahmen. „Wir haben angefangen, Projekte in Node und React abzuwickeln, und alles war sehr handlungsorientiert.“ Einige Kunden akzeptierten diese Vorschläge jedoch zu höheren Preisen, obwohl React und Node.js für ihre Produktanforderungen in der Anfangsphase weniger geeignet waren und deutlich mehr technischen Aufwand erforderten als vergleichbare Ruby on Rails-Lösungen. Die Projekte begannen, aber schnell traten Probleme auf: Der Stack war neu, und dies waren die ersten Projekte des Unternehmens, die ihn verwendeten.
Widerstand war vorhersehbar, aber nicht darauf vorbereitet. Ingenieure, die Ruby on Rails beherrschten, sahen Kollegen, die andere Richtungen erkundeten. „Es ist ganz natürlich, dass Menschen mit neuen Technologien experimentieren, und das ist gesund“, erklärt Franco. „Einige Ingenieure haben React oder andere Tools wie Elixir ausprobiert. Aber es ist die Organisation, die entscheiden muss, was eingeführt werden soll.“
„Wir haben gerade angefangen, Dinge zu tun, und einige Leute haben Widerstand gezeigt. Am Ende haben wir sie in Node.js Projekten verwendet, von denen einige angepasst wurden. Ich würde sagen, die Mehrheit hat es nach einiger Zeit getan. Aber ich habe keine strategische Richtung kommuniziert und gesagt, dass wir in diese Richtung gehen müssen. Es war eher so, als hätten wir angefangen, Dinge zu tun. Das war ineffizient.“
Der Durchbruch kam, als er ein Muster erkannte, auf das Franco wiederholt gestoßen war.
Wie er erklärt:
„Was dich normalerweise dorthin führt, bringt dich nicht zum nächsten Schritt. Also hat sich die Umgebung verändert, und du musst dich damit ändern.“
Das passiert, so Franco, „sehr oft. Das passiert normalerweise alle paar Jahre, wenn Sie die Art und Weise, wie Sie Software bereitstellen, anpassen müssen, nur weil sich die Umgebung ändert.“
Franco erinnert sich auch an Ratschläge eines Universitätsprofessors, der einem Kollegen des Vorstandsvorsitzenden sagte:
„Der strategische Plan muss sich so wenig wie möglich und so oft wie nötig ändern.“
Das Paradoxon fasste zusammen, was Franco gerade gelernt hatte: Strategie erfordert Engagement über einen Zeitraum von drei bis fünf Jahren, aber das starre Festhalten an gescheiterten Strategien garantiert Obsoleszenz.
„Die Techniken, die ich jetzt anwende, um mit dieser Veränderung umzugehen, sind völlig anders. Sie sind reifer als in der Anfangsphase.“ Der Unterschied bestand darin, dass er durch Erfahrung lernte und auch eine formelle Ausbildung in Unternehmensstrategie erhielt, die es ihm ermöglichte, Übergänge mit einem systematischen und nicht mit einem improvisierten Rahmen anzugehen.
Was aus mehreren Übergängen hervorging, Francos erster war chaotisch, sein zweiter geringfügig besser, sein dritter systematischer, identifiziert er nun als wiederholbares Muster.
Das Strategie-Muster, das seinen Ursprung in der Softwaretechnik hat, definiert eine Familie von Algorithmen, kapselt jeden einzelnen ein und macht sie austauschbar, sodass Algorithmen unabhängig vom Code, der sie verwendet, variieren können.
Es handelt sich um ein Verhaltensmuster, das Flexibilität bietet und hartes Programmieren verhindert. Sie könnten zum Beispiel eine Funktion haben wie calculate_time_home (Strategie), wobei die Strategie die schnellste Route, ein malerischer Spaziergang oder ein anderer Ansatz sein könnte.
So wie Software Algorithmen zur Laufzeit austauschen kann, wenn sie mithilfe des Strategy Patterns implementiert wird, sollte ein Unternehmen nicht an starre, veraltete Praktiken gebunden sein. Unternehmen können Prozesse oder Technologie-Stacks ändern, ohne das gesamte System neu schreiben zu müssen. Dadurch sind sie flexibler und wartungsfreundlicher als spröde und veraltet.
Auf die Frage, was andere Führungskräfte tun sollten, wenn sie vor ähnlichen Veränderungen stehen, zeigt Francos Antwort den Kern des Musters: „Das Erste, was sie tun müssen, ist zu entscheiden, was diese Veränderung ist, in welche Richtung sie gehen. Und wenn das entschieden ist, müssen Sie aufhören, alles zu tun, was gestoppt werden muss, und Sie müssen anfangen, alles zu tun, was getan werden muss, um dieses Ziel zu erreichen.“
Doch zuvor betont Franco:
„Bevor du verstehst, womit du aufhören musst, musst du verstehen, wohin du gehst. Machen Sie eine Diagnose, wo sie sich jetzt befinden und wohin sich die Branche entwickelt, und definieren Sie dann eine Strategie.“
Dieser Rahmen umfasst drei integrierte Dimensionen, von denen Franco gelernt hat, dass sie gleichzeitig angegangen werden müssen.
Francos erste Lektion bestand darin, strukturelle Marktverschiebungen von vorübergehenden Schwankungen zu unterscheiden. Ruby on Rails ist nicht verschwunden. Es war einfach nicht mehr die Standardwahl für neue Projekte. Diese Unterscheidung war wichtig.
Während des Übergangs von Ruby zu React enthüllte die Diagnose eine unbequeme Wahrheit. Die Kunden verlangten nach einer Technologie, die einen geringeren Nutzen bei höheren Kosten bot. Doch die Nachfrage war marktübergreifend konstant und hielt im Laufe der Zeit an. Dies deutete auf einen Strukturwandel hin, nicht auf einen vorübergehenden Trend.
Francos ausgereifter Ansatz, der nach dem anfänglichen Scheitern entwickelt wurde, beinhaltet eine explizite strategische Planung: „Wir entwickeln eine Strategie und entwerfen eine Strategie für drei Jahre. Das wollen wir erreichen.“
Der Plan muss jedoch mit absoluter Klarheit kommuniziert werden:
„Sie stellen die Diagnose, Sie bereiten die Strategie vor und stellen dann sicher, dass die Strategie allen auf einer Seite präsentiert werden kann. Und dann teilen Sie diese Strategie mit allen.“
Die technische Dimension befasst sich mit einer Realität, die Franco durch Erfahrung gelernt hat: Übergänge können nicht sofort geschehen. Imaginary Cloud hat Ruby on Rails nicht ganz aufgegeben. Bestehende Kundenprojekte wurden in ihrer ursprünglichen Technologie weitergeführt. Neue Projekte wurden in React und Node.js gestartet.
Die Lösung, die Franco entwickelte, war die Schaffung von Praxisgemeinschaften.
„Am Ende haben wir sogenannte Praxisgemeinschaften gegründet, in denen Menschen ihr Wissen über die von ihnen verwendeten Technologien austauschen können.“
Diese Gemeinschaften erfüllten mehrere Funktionen: Sie beschleunigten den Wissenstransfer, schafften soziale Beweise durch sichtbare Erfolgsfälle und etablierten Standards ohne zentrale Engpässe.
Franco musste auch die Teams umstrukturieren. „Aufgrund der Marktkräfte mussten wir die Frontend-Spezialisierung von der Backend-Spezialisierung trennen. Vorher hatten wir das nicht. Es war einfach Full-Stack.“ Diese Trennung führte zu neuen Koordinationsherausforderungen, bei deren Bewältigung die Praxisgemeinschaften mitwirkten.
Das kulturelle Dimension erwies sich als am komplexesten. Franco erklärt, dass Menschen unterschiedlich auf Veränderungen reagieren.
Einige nehmen die neue Technologie sofort an und werden zu Early Adopters. Andere widersetzen sich zunächst, aber sobald sie sehen, dass Kollegen Ergebnisse erzielen und die Vorteile der Einführung nutzen, folgen sie allmählich diesem Beispiel. Schließlich entscheiden sich einige dafür, sich nicht anzupassen, und verlassen möglicherweise die Organisation, wenn die Änderung ihren Präferenzen oder Prinzipien widerspricht. „Wenn sich eine Organisation verändert, passen sich manche Menschen daran an, andere nicht. Es ist wichtig, diese Dynamik zu verstehen, und diese Lektion gilt für jeden Wandel.“ Franco bemerkt.
Francos Framework erkennt drei Populationen an. Early Adopters begrüßen Veränderungen mit Begeisterung. Pragmatiker passen sich an, wenn sich Erfolgsnachweise abzeichnen. Widerstandskämpfer bevorzugen den alten Ansatz und betrachten den Übergang als unnötig oder fehlgeleitet.
„Führung befasst sich mit Veränderung. Führung gibt die Richtung vor und sorgt dafür, dass Veränderungen stattfinden. Veränderung ist chaotisch. Wenn Veränderungen stattfinden, wissen wir manchmal nicht, ob Sie Recht haben oder ob Sie sich irren, aber wir müssen in diese bestimmte Richtung gehen.“
Die Bestätigung von Francos Muster basiert auf messbaren Ergebnissen. Imaginary Cloud behielt seine Weiterempfehlungsrate von 99% während der gesamten Umstellung bei — trotz der Lernkurve und der höheren Projektkosten während der 18-monatigen Transformationsphase. In dieser Zeit gewann das Unternehmen auch Toller Ort zum Arbeiten bei ihrer ersten Registrierung, und die Kundenbindung lag weiterhin über dem Marktdurchschnitt.
Noch wichtiger ist, dass sich das Muster als übertragbar erwies. Franco hat dasselbe Framework auf nachfolgende Übergänge angewendet, darunter Cloud-native Architekturen, serverloses Computing und die Integration künstlicher Intelligenz. Jeder Übergang verlief reibungsloser, da der systematische Ansatz die Improvisation ersetzte.
Sobald die Richtung festgelegt ist, ergeben sich drei Kategorien von Aktivitäten.
Investitionen in Fähigkeiten, die der strategischen Ausrichtung widersprechen. Marketingdienstleistungen, die der Markt nicht mehr schätzt. Aktiver Widerstand, der strategische Initiativen untergräbt. Franco erklärt: „Wenn Sie die Strategie ändern, wenn Sie die Richtung ändern, wird Ihnen die Strategie sagen, womit Sie aufhören müssen.“
Aufbau strategischer Fähigkeiten trotz unmittelbarer Kosten. Messung des Fortschritts bei der Umstellung anhand spezifischer Kennzahlen. Wiederholtes Kommunizieren strategischer Beweggründe, bis die Botschaft im Unternehmensbewusstsein verankert ist.
Bestehende Kundenverpflichtungen. Qualitätsstandards trotz Effizienzdruck. Marktpositionierung bei gleichzeitiger Änderung nur der technologischen Umsetzung.
Franco betont, dass erfolgreiche Übergänge mehr bewahren, als sie verwerfen. Während der Umstellung von Ruby auf React blieben das Betriebsmodell, die Kundenbeziehungen und die Marktpositionierung von Imaginary Cloud konstant. Nur die technologische Implementierung änderte sich. Dadurch wurde der Versuch einer gleichzeitigen Transformation über mehrere Dimensionen hinweg verhindert.
- Austauschbare Lösungen: Das gleiche Framework gilt unabhängig davon, ob Sie Tech-Stacks wechseln, KI einführen oder Teams umstrukturieren. Die Entscheidungslogik bleibt konstant, auch wenn sich bestimmte Herausforderungen ändern.
- Kontextunabhängige Logik: Die Entscheidungsreihenfolge gilt für Startups und Unternehmen, obwohl die Ausführung unterschiedlich ist. Ein Unternehmen mit 20 Mitarbeitern und ein Unternehmen mit 2.000 Mitarbeitern stehen vor unterschiedlichen Herausforderungen bei der Umsetzung, folgen aber demselben strategischen Muster.
- In großem Maßstab wartbar: Wie Franco erfuhr, verhindert ein klares Muster das Chaos eines Ad-hoc-Change-Managements. „Das passiert sehr oft“, stellt er fest. „Das passiert normalerweise alle paar Jahre, wenn Sie die Art und Weise, wie Sie Software bereitstellen, anpassen müssen, nur weil sich die Umgebung ändert.“
Andere Führungskräfte können Francos Ansatz nicht übernehmen, weil sie vor derselben technologischen Herausforderung stehen, sondern weil sie auf dasselbe Muster von Umweltveränderungen stoßen, das eine strategische Anpassung erfordert. Die Instrumente ändern sich, aber der Entscheidungsrahmen bleibt robust.
Francos Reise von Ruby on Rails zu React ist bereits veraltet, aber es war eine der ersten Herausforderungen, denen er sich stellen musste. Sein Framework zur Bewältigung von Veränderungen bleibt jedoch relevant, da es sich um ein Strategiemuster handelt: eine kontextunabhängige Entscheidungslogik, die sich an jede Herausforderung anpasst.
Die Lektion lautet nicht „Microservices einführen“ oder eine bestimmte Technologie. Die Lektion besteht darin, systematisch auf Veränderungen zu achten, sei es in Bezug auf KI, Software-Frameworks oder Geschäftsmodelle, zu diagnostizieren, bevor Maßnahmen ergriffen werden, zu testen, bevor eine Verpflichtung eingegangen wird, und ehrlich zu kommunizieren.
Dieses Muster funktioniert unabhängig davon, ob Sie ein Softwareunternehmen mit 50 Mitarbeitern oder ein Unternehmen mit 5.000 Mitarbeitern sind, ob Sie Technologie-Stacks oder Geschäftsmodelle ändern und ob Ihr „Ruby on Rails-Moment“ im nächsten Quartal oder in fünf Jahren stattfindet.
Sicher ist nur, dass Ihr Moment kommen wird: Vorschläge werden abgelehnt, Kernkompetenzen werden veraltet sein und das Umfeld wird sich verändern. An diesem Punkt müssen Sie sich dafür entscheiden, sich bewusst anzupassen, sonst riskieren Sie, den Anschluss zu verlieren.
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.
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
