# Agency CTO Strategy: People-First Digital Transformation

**Podcast:** Becoming CTO Secrets
**Published:** 2026-03-03

## Transcript

Hallo und herzlich willkommen zu Becoming CTO Secrets.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO-Community.
Als CTO-Coach begleite ich Tag-Leader und aktive CTOs natürlich auf dem Weg zu mehr Verantwortung, Klarheit und Wirkung.
Und in der Becoming CTO-Community treffen sich jede Woche über 50 CTOs mittlerweile und angehende Führungskräfte zum Austausch auf Augenhöhe.
Wer tiefer einsteigen will, der Link dazu ist in den Shownotes.
Jetzt aber direkt zu unserem heutigen Gast.
Das ist nämlich Alexander Hipper.
Er ist der CTO bei Move Elevator.
Und Alexander ist ein echtes Agentur-Urgestein.
Er ist vor über 20 Jahren als Junior-Entwickler bei Move Elevator eingestiegen, hat sich dann Schritt für Schritt bis zum CTO entwickelt.
Und heute verantwortet der intern ein rund 40-köpfiges Team aus, können wir gleich noch dazu, auch Software-Entwickler und aber noch diverse andere Rollen und arbeitet gleichzeitig extern als Digitalstratege.
für große Kunden von mittelständischen Unternehmen bis hin zu Konzernen.
Sein Fokus liegt dabei weniger auf Technologien als Selbstzweck, sondern auf einer klaren People-First-Haltung.
Und in dieser Episode heute sprechen wir über den Weg vom Entwickler zur Führungskraft, natürlich über CTO-Arbeit im Agenturkontext und darüber, warum die Nutzerforschung, das Prototyping und gute Entscheidungen oft mehr Wirkung haben als noch ein weiteres Feature.
Liebe ich zum Beispiel.
Genau, Alexander, herzlich willkommen und freut mich sehr, dass du heute hier bist.
Ja, hallo, hallo Nierunde und Philipp, danke für die Einladung.
Ich freue mich sehr auf die Session, bin gespannt auf deine Fragen.
Ja, wir haben ja auch ein volles Programm, da müssen wir auch richtig durch.
Müssen wir Gas geben.
Nein, alles gut.
Wo erwischen wir dich denn eigentlich gerade in deinem Alltag?
Bist du jetzt eher intern mit deinen Teams beschäftigt oder gerade draußen beim Kunden?
Ich würde mal sagen, guter Mix.
Also meine Rolle, wie du es ja gerade schon angeteasert hast, ist genau der Mix zwischen Teamführung, um zu schauen, wie tun wir die richtigen Dinge für unsere Kunden, in der Beratung nach draußen.
Wir haben auch gerade einen Auftrag bekommen, einen Kunden in der Digitalstrategie zu beurteilen und den bereiten wir gerade vor, die Workshops, die wir dazu machen.
Und dazu gibt es ein Thema, was natürlich ja gerade über allem steht und ist einfach diese ganze KI-Transformation nach innen und nach außen und das ist auch ein Thema, da komme ich heute Mittag noch aus einer Session zu sagen können, welches Tool führen wir jetzt gerade ein, geben wir die Lizenz ab, nehmen wir die dazu.
Also auch das nimmt mittlerweile einen sehr, sehr großen Anteil in meinem Alltag ein.
Wenn du heute auf deine Rolle schaust und du bist nicht der erste Agentur-CTO, den wir hier im Podcast hatten, aber was macht denn dein CTO-Job im Agentur-Kontext grundsätzlich aus und was macht es anders als eine klassische CTO-Rolle in einem, ja, was haben wir denn normalerweise, SaaS-Organisationen?
Was ist da der große Unterschied?
Ja, da möchte ich eigentlich mal gar nicht diskutierlich sein, weil ich kenne jetzt nicht so viele klassische CTOs in den Rollen, deswegen kann ich das nur so begrenzt einschätzen, was jetzt bei uns anders ist.
Was ich aber glaube ich merke, was mich sehr herausfordert ist, dass wir eben nicht nur den Blick nach innen und unsere eigene Infrastruktur, eigene Systeme, eigene Prozesse haben, sondern dass ich permanent auch den Blick nach draußen habe und mit ganz vielen unterschiedlichen CRM-Systemen, ERP-Systemen, mit Marketing-Automation-Systemen, mit Vertriebssystemen zu tun habe und da eigentlich die Aufgabe habe.
permanent eigentlich am Zahn der Zeit zu sein und mich damit zu beschäftigen, welches Tool kommt gerade raus, was hat welche Vor- und welche Nachteile, um dann im nächsten Beratungsgespräch wieder up-to-date zu sein.
Ich habe das Gefühl, wenn man sich mehr nach innen konzentrieren kann, kann ich irgendwann sagen, ich habe mich jetzt für das System entschieden, das führe ich jetzt ein und optimiere es vielleicht ein paar Jahre.
Und ich glaube, als Agentur hat man wirklich mehr die Herausforderung einfach auch.
eingeführte Systeme trotzdem die ganze Zeit im Blick zu behalten, damit, wenn man im nächsten Beratungsgespräch ist, auch zumindest weiß, worum geht es gerade und sich da auch nochmal schnell Informationen zu ziehen.
Hast du da viel TechSec, den du nach innen managen musst oder ist es dann tatsächlich wirklich wahrscheinlich 80, 90 Prozent, was der Kunde dir oder erstens mal, was die neuen Trends dir vorgeben und der Kunde dann die auch haben möchte oder was der Kunde gerade hat und was du weiterbauen sollst und wie viel davon kannst du wirklich intern vorantreiben und hast eine eigene Agenda außer der klassischen IT, die ihr intern habt?
Ich glaube schon, dass mein Fokus tatsächlich mehr bei Kunden und mehr draußen ist.
Ich habe sicherlich den Vorteil, dass wir eine Agentur sind.
Wir haben jetzt knapp 100 Mitarbeiter, die vor allen Dingen aber alle einen sehr starken Beratungsanspruch unseren Kunden gegenüber haben, weil wir nicht halt nur klassische umsetzende Agentur sind, sondern auch sehr, sehr stark beratend und sehr strategisch auch für unsere Kunden tätig sein.
Das heißt, ich habe eine Organisation, die selber sehr stark mitdenkt und Verantwortung übernimmt.
Das heißt, ich muss mich sehr wenig damit beschäftigen.
Da gibt es eine Idee und das an die richtige Person zu vermitteln und zu bewerten, ob das Sinn macht.
Da haben wir eine Organisation aufgebaut, die das sehr gut aus sich selbst heraus kann.
Deswegen ist mein Fokus schon tatsächlich mehr draußen.
Wir haben aber auch für uns selber einen Transformationsprozess gerade durch, wo wir früher, weil wir sind auch für sehr viele gesetzliche Krankenversicherung tätig, auch für Kliniken, wo wir über Sozialversicherungsdaten sprechen, wo wir auch...
tatsächlich sehr lange Inhouse-Systeme hatten, die wir gehostet haben, die wir gewartet haben, geupdatet haben.
Und jetzt sind wir auch mehr und mehr zu Cloud-Dienstleistungen gegangen, die einfach eine höhere Update-Geschwindigkeit haben, als wir es selber haben, um da eigentlich auch mehr Geschwindigkeit in unseren eigenen Transformationsprozess zu bekommen.
Also da haben wir auch eine Transformation für uns selber durch, aber tatsächlich nimmt der bei mir eher einen kleineren Anteil ein, als mehr wirklich Kundensysteme und diese Dinge.
Vielleicht kann man sagen, KI relativiert es gerade ein bisschen, weil wir schon sehr auch viel damit experimentieren, das System zu verwenden, das System, wie funktioniert das, im Entwicklungsprozess, automatisierte Code-Reviews zu machen und solche Dinge irgendwie auch zu auszuprobieren und dann wieder zu sagen, können wir das aus Datenschutzsicht da machen, müssen wir das Inhouse hosten, also wir experimentieren auch mit eigenen Systemen, die wir...
beispielsweise bei Hetzner hosten, eine Libre Chat Oberfläche draufsetzen, wo wir dann die Confluence bei uns andocken können, um da Daten rauszuziehen und die einfach für die Nutzung auch aufzubereiten, damit wir die datenschutzkonform auch nutzen können.
Also da ist tatsächlich wieder gerade nach innen ein größerer Transformationsprozess, aber auch da legen wir als Move Elevator unglaublich viel Wert als agile Organisation.
Das heißt, wir haben trotz 100 Mitarbeitern keine Hierarchien in der gesamten Organisation.
Sehr viel Wert darauf, dass Kollegen Verantwortung für Systeme übernehmen und schauen eigentlich eher, wie wir das koordinativ in die Umsetzung bekommen.
Und deswegen bin ich mehr Sparringspartner, Feedbackgeber, manchmal auch der, der irgendwie Entscheidungen der Teams auch bekräftigt und sagt, ja, das ist im Sinne der Gesamtagentur, aber ich muss zum Glück viele Dinge nicht mehr selbst treiben, weil ich glaube, das ist heutzutage auch unglaublich schwer.
Wie oft musst du denn, wenn du mit Kunden arbeitest, wie oft musst du dann mit dem Tech-Stack der Kunden leben oder wie oft kannst du wirklich innovieren und wirklich neue Dinge ausprobieren oder Dinge anstoßen?
Ist das 50-50 oder hast du dann doch 80% der Zeit, dass du an dem klebst, was der Kunde auch schon mit vorgibt und da musst du dann weiter dran arbeiten?
Also ich würde sagen, dass ich sogar eher 95 oder 98% mit dem Tech-Stack leben muss, den unsere Kunden haben.
Weil wir ja schon auf uns auf größere mittelständische Unternehmen konzentrieren, die meist ganz viele Bestandssysteme über die letzten 10, 20, 30 Jahre eingeführt haben.
Ein FIBU-System, was keine Schnittstellen hat, ein ERP-System, was keine Schnittstellen hat, was irgendwie in-house gehostet ist und man will trotzdem eine digitale Kundenreise irgendwie abbilden oder man will einen Blick auf den Kunden haben und die Daten aggregieren und solche Dinge und da muss man schon sagen.
Also wir können meistens Anstöße geben, aber es ist eigentlich selten so, dass man jetzt mal, weil wir jetzt als Agentur kommen, das ERP-System tauscht.
Da geht es dann schon meistens darum, wie kriegen wir das dann abstrahiert.
Ganz oft führen wir dann so Middle-Wares ein, die Daten aus verschiedenen Systemen aggregieren, zur Verfügung stehen, dann für den E-Commerce-Prozess oder für die Website zur Verfügung stellen oder für Apps zur Verfügung stellen, wo wir die Dinge abstrahieren.
Und dann passiert schon mal über eine Zeit, dass man dann sagt, okay, das Unternehmen hat jetzt auch begonnen.
Prozesse nach intern neu zu denken.
Das heißt, wir können an der Middleware ein anderes System andocken und haben da noch mal ein paar Folgeschritte.
Aber das ist meistens eher der fünfte oder der zehnte oder der zwanzigste Schritt.
Meistens leben wir eigentlich damit, wo wir gerade stehen und versuchen es eher eine Abstrahierung draufzusetzen, um dann das zu tun, was wir halt tun.
Und das ist Unternehmen dabei zu helfen, für die Kundenzentrierung, die Menschen in den Mittelpunkt zu nehmen, ihre Wünsche und Bedürfnisse in den Mittelpunkt zu nehmen.
Prozesse zu vereinfachen.
Die können ja hochkomplex nach innen sein, aber der Kunde will einfach ein leichtes, gutes Kundenerlebnis haben, was einfach seine Probleme und seine Bedürfnisse im Mittelpunkt rügt und nicht, weil intern es einen Prozess gibt, dass die Freigabe von XY benötigt wird, bringen wir das so nach außen und der Kunde muss dann auf irgendwelche Dinge warten, um die Dinge zu abstrahieren.
Aber da müssen wir uns meistens nach der Infrastruktur richten, die da aus.
Was sind denn die Beweggründe, dass sich ein Kunde...
bei euch meldet, hat er dann in der Regel keine eigenen Entwicklerkapazitäten oder die sind voll und er braucht Bedarf?
Es geht ja auch darum, warum meldet er sich bei einer deutschen Agentur, warum geht er nicht Richtung Nearshoring oder warum macht er nicht gleich komplett Offshoring irgendwo anders hin?
Wie erlebst du das?
Was sind denn die Beweggründe?
Ich meine, ist es dann oftmals so, ihr müsst Unterkapazitäten beim Kunden überbrücken oder sagen sie, naja, das ist ein komplett autarkes Projekt oder Teilprodukt?
Und da wollen wir jetzt nicht unsere Ressourcen drauflegen und deswegen geben wir es nach extern.
Also ich würde sagen, viele haben wirklich wenig bis keine Entwicklerkapazitäten, aber selbst wenn sie die haben, haben die eine Roadmap auf die nächsten ein, zwei, drei Jahre mit Features, die in das ERP-System noch integriert werden müssen, wo irgendwie das ist und jenes ist, wo es aber gar nicht mehr möglich ist, wirklich...
Agile nach außen hin zu sein oder eine höhere Abstraktion zu machen.
Also ich merke schon, dass unglaublich viele Unternehmen sich mit dem Thema Digitalstrategie total schwer tun.
Ganz schwer tun.
Ganz viele wissen, Mit dem Legacy-Code oder mit dem Legacy-System kann ich eigentlich nicht Richtung Marketing-Automation gehen oder habe Einblick auf den Kunden und kann irgendwie sagen, weil der das eine gemacht hat, wäre das für den wirklich aus Kundenreisesicht an B auch spannend als Feature, als Upselling-Potenzial, als digitaler Service und dann merkt man eigentlich, die Idee ist da, aber mit dem System, die wir haben, ist dann eigentlich in den nächsten Jahren nicht möglich.
Und dann kommen wir eigentlich meistens rein und schauen uns an, wo können wir das machen?
Wie kriegen wir eine Abstraktion hin?
Wie können wir vielleicht einen Prozess aus einem Bestandssystem rausnehmen und das einfach über eine andere Systeme abstrahieren?
Und dann kommen wir eigentlich so in einen kontinuierlichen Transformationsprozess mit unseren Kunden.
Aber die meisten tun sich vor allen Dingen mit dem Thema Digitalstrategie schwer.
Das heißt, die haben vielleicht sogar die Entwicklerkapazitäten, aber die sind auf irgendwelchen Projekten einfach auf gefühlt Jahre meistens gebunden oder haben das gar nicht und wissen einfach gar nicht, wo fange ich an?
Wo ist mein erster Step und was ist eigentlich mein langfristiger Nordstern?
Und das ist wirklich mittlerweile das, was wir am meisten tun, ist genau diese Klarheit eigentlich reinzubringen, indem wir alle Beteiligten an einen Tisch bringen, indem wir über verschiedene Workshop-Formate reden, um da Sichten zusammenzubringen, dann auch immer den Kunden mit an den Tisch bringen.
Was ist dem sein Wunsch?
Was ist dem sein Bedürfnis?
Was will der eigentlich?
Da hat ja auch Jeff Bezos bei Amazon diesen spannenden Aspekt eingebracht, dass ein Stuhl im Meetingraum immer leer sein soll, der den Kunden repräsentiert.
So als Reminder dafür, was ich eigentlich einen ganz schönen oder spannenden Move finde, um auch immer die Kundenperspektive mit einzubringen.
Aber wenn das Unternehmen schwerfällt, dann gehen wir eigentlich genau in diese Rolle rein und bringen den Blick von außen bis hin auch den Kunden virtuell an den Tisch.
indem wir verschiedenste Methoden verwenden, auch so User Research, Customer Research, Tiefeninterviews, Analyse von Bestandstoulen, wie wird eine Software genutzt, wie wird eine Website genutzt, wie wird eine Buchungsstrecke genutzt, um halt diesen Aspekt mit reinzubringen.
Weil am Ende tun das die Organisationen, Probleme für Kunden da draußen lösen, das vergessen bloß ganz viele oder wissen nicht, wie sie es tun.
Ja, das kenne ich auch sehr gut.
Wir kommen noch später wahrscheinlich nochmal zu genau dem Punkt, was ihr inhaltlich alles macht.
Ich würde aber gerne nochmal auf deine Entwicklung zu sprechen kommen.
Du hast eine Karriere hingelegt, von der viele wahrscheinlich träumen, wenn sie als Juniorentwickler irgendwo anfangen.
Das hast du nämlich auch getan vor über 20 Jahren bei Move Elevator und bist dann heute, also bist nicht nur wahrscheinlich die ganze Zeit bei Move Elevator geblieben, sondern hast dich auch peu a peu Richtung CTO-Rolle bewegt.
Gab es da bestimmte Stationen und Übergänge, die rückblickend total entscheidend waren auf diesem Weg zum CTO?
Entscheidungen oder bestimmte Ereignisse, die eingetreten sind, bestimmte Meilensteine, die du geschafft hast oder bestimmte Projekte, die du finalisieren konntest.
Ich würde sagen, bei mir war das eher so ein sehr kontinuierlicher Prozess, der da entstanden ist.
Es gab jetzt weniger ganz klassische Stufen.
Es gab, glaube ich, in der Entwicklung von Move Elevator ein paar Stufen, wo ich dann, glaube ich, ganz gut in die Verantwortung reingegangen bin und Themen strukturiert habe.
Um euch da mal so ein bisschen mitzunehmen, ich habe als wirklich klassischer Softwareentwickler für Backend-Bereiche und damals sogar noch im Corporate-Website-Bereich begonnen mit Typo3.
Bin dann auch mehr in die Verantwortung gegangen, denn unser Entwicklersteam ist größer geworden, dann bin ich Teamleiter Entwicklung geworden, habe dann schon angefangen Aufgaben zu koordinieren und das, was man früher in hierarchischer Führung auch gemacht hat, hat dann irgendwie Aufgaben verteilt, für Qualitätssicherung gesorgt, bin da schon ein bisschen mehr in eine koordinative Rolle gegangen.
Und dann hatten wir eine Fusion mit einer anderen Agentur, da ist auch der Name Move Elevator entstanden, will ich aber gar nicht so tief drauf eingehen, die dann im Prinzip das Thema Personalmarketing mit angebracht haben.
Und da haben wir angefangen, eigene Software zu bauen für Vertriebsteams.
Auch im sehr großen Stil für Coca-Cola, für Red Bull, für Sky, für Vodafone, für Apple sogar, wo wir dann im Prinzip Vertriebssoftware gebaut haben, erst um unseren eigenen Außendienst und unsere Vertriebler zu steuern und unsere Merchandiser und Promoter, die wir draußen haben und haben das dann sogar als Software für Kunden gemacht.
Und da bin ich dann eigentlich in der Rolle der technischen Konzeption gegangen, habe die ganzen typischen Fehler gemacht, die man einfach in so einem Step auch tut.
endlose Pflichtenhefte geschrieben, die niemand verstanden und gelesen hat und andere Dinge.
Aber bin dann mehr in so eine koordinative Rolle gegangen.
Dann sind wir gewachsen, dann bin ich mal Unit Lead geworden und dann kam bei uns tatsächlich die Entscheidung zu sagen, bei der Komplexität, die wir da draußen lösen und die Komplexität, die unsere Kunden haben und Anforderungen, wir brauchen eine andere Organisation als eine klassische hierarchische Struktur.
Und da bin ich dann Teil der Geschäftsführung sozusagen geworden.
Dann haben wir auch festgestellt, dass wir eigentlich in unserer GF-Runde auch uns extrem gut ergänzen in unseren Kompetenzen.
Bin dann auch irgendwann mal sogar auch Gesellschafter, Mitgesellschafter von Move Elevator geworden.
Und so war das so ein bisschen ein kontinuierlicher Prozess, wo immer ein Step dazugekommen ist und ich, glaube ich, einen ganz guten Job gemacht habe und einfach Verantwortung übernommen habe und auch die Verantwortung, die ich bekommen habe, auch irgendwie ganz gut gewuppt habe.
Sehr gut.
Ein Thema, ein Step.
Ja, schön, dass du auch Typo 3 erwähnst.
Tatsächlich war auch meine erste Festangestelltenrolle früher, war auch bei einer Agentur und war dann auch in, ja, hab dann auch viel mit Typo 3 gearbeitet damals.
Kann man damit heute noch Geld verdienen mit Typo 3?
Auf jeden Fall.
Ja?
Also Typo 3 ist nach wie vor auch im Content Management Bereich, im Enterprise Bereich.
Wir sind auch Partner der Typo3 GmbH, Mitglied der Typo3 Association, die das als Open Source System treibt.
Tatsächlich ist es krass, was die meisten nicht wissen, wenn man das von ganz früher kennt, weiß man noch, Seitenbaum ist cool und redaktionelle Pflege ist cool, aber gerade dieses Typo-Skript-Einstieg ist unglaublich schwer.
Die letzten vier, fünf Jahre gab es für das System noch mal einen unglaublich krassen Boost, weil die Bundesregierung entschieden hat, alle Websites auf TYPO3 umzustellen.
Und deswegen fließt da gerade sehr viel Investition rein, aber auch sehr viel Fokus.
Und jetzt gehen natürlich auch Länder mit hinterher, die sagen, wenn der Bund entscheidet und der ganze Quelltext gereviewt wird, ist es sogar eher so, dass aus meiner Sicht TYPO3 gerade unglaubliche Wachstum.
hat und nun durch einen Boom hat, weil es einfach von der Bundesregierung supported wird.
Und ich halte grundsätzlich die Entscheidung Richtung digitale Souveränität auch für total richtig, sich da auch nicht von proprietären Systemen, erst recht nicht von amerikanischen Systemen abhängig zu machen, sondern so ein Open-Source-System auch zu pushen.
Deswegen an alle Hörer, es ist wirklich für Enterprise-Seiten mit einem gewissen Anforderungs-Stack wirklich ein richtig gutes System, um vor allen Dingen Investitionssicherheit zu haben.
Das ist jetzt einfach kein System.
wie andere, wo man irgendwie eine Website baut oder eine Buchungsstrecke baut und dann hat man irgendwie zwei, drei Jahre später das System, das eigentlich alles sich grundlegend geändert hat und man eigentlich einen Relaunch machen muss.
Da Typo 3 eigentlich hat es früher schon und heute immer noch eine sehr hohe Investitionssicherheit, dass man sagen kann, man kann auch problemlos mal zehn, zwölf, vielleicht sogar 15 Jahre ein System laufen lassen und das mit Updates weiter und dann erst einen Relaunch nachdecken.
Deswegen, wer vor dieser Frage steht, sollte sich auf jeden Fall mit Typo 3 beschäftigen, wenn es um Enterprise-Seiten geht.
Ja, das ist spannend.
Der Typo 3 hat ja auch mit Sicherheit schon mehr als 20 Jahre mittlerweile auf dem Buckel.
Scheint auf jeden Fall noch weiter gefragt zu sein.
Interessanterweise fällt mir da ein, es gab damals noch eine Zeitschrift, die war damals als reine Typo 3 Fachzeitschrift erschienen.
T3N sagt dir bestimmt noch was.
Ist ja mittlerweile keine Typo 3 Fachzeitschrift mehr, sondern definiert sich ja eher als global digital Transformation.
Ich weiß nicht, was so genau der Anspruch ist, aber auf jeden Fall haben sie sich sehr stark von dem ursprünglichen Typo 3 Aspekt emanzipiert.
Aber die sind mir damals noch, sind es mir als reines Typo 3 Magazin aufgefallen.
Hast du auch noch auf dem Schirm, oder?
Ja, auf jeden Fall.
Ich lese sie auch.
Ich oute mich als T3N Leser, weil es so ein bisschen...
etwas marketinglastiger ist mit digitalen News, als es vielleicht ein heise oder so ist, die schon etwas technologischer ist.
Deswegen ist es ganz gut, so einen Überblick zu bekommen, welche Systeme passieren gerade, was ist irgendwie wo unterwegs.
Deswegen ist es auch für, glaube ich, auch wenn man jetzt nicht ganz tief techy ist, wirklich eine gute Seite, wo man Newsletter abonnieren kann und einfach immer wieder ein paar spannende Themen auch einfach in sein Postfach kommt.
Gab es denn bei dir einen Moment auf deiner Reise vom Entwickler zum CTO, so einen Moment, in dem du wirklich gemerkt hast, okay, jetzt bist du nicht mehr Primärentwickler, sondern Führungskraft oder war es wirklich ein harter Cut und von heute auf morgen hattest du Personalverantwortung oder Tech-Verantwortung und hast den Stift fallen lassen oder beziehungsweise hast du die Tastatur hingestellt und warst nicht mehr in der IDE tätig?
Ich würde auch sagen, das war auch ein fließender Prozess bei mir.
weil ich am Anfang irgendwie noch dieses Thema Projektmanagement, technische Konzeption ein Stück weit zusätzlich gemacht habe, auch die Führungsarbeit einfach zusätzlich gemacht und habe trotzdem noch weiter gecodet.
Und irgendwann ist der Zeitfaktor einfach immer geringer geworden.
Das war auch eine Phase, wo ich tatsächlich auch sehr, sehr viele Überstunden gemacht habe, wo ich dann einfach gemerkt habe, ich komme hier auch nicht mehr mit.
Und ich habe auch gemerkt, dass es andere gab, die einfach...
in Coden an sich sogar noch besser sind.
Also ich kann ganz gut so abstrahieren und schnell in Themen einsteigen und habe eine gute Auffassungsgabe und kann die Dinge auch auf so eine strategische Ebene beleuchten und habe einfach gemerkt, da komme ich immer mit, ich hatte den zeitlichen Faktor nicht und das hat mir auch ein bisschen mehr Spaß gemacht und dann hat sich das sozusagen dahin verlagert, dass ich dann auch gesehen habe und dann ist einfach der Fortschritt viel schneller gewesen mit den ganzen Frameworks und Updates und automatisierten Tests und all diesen Dingen und da habe ich auch gemerkt, Ich verstehe noch, was da alles passiert, aber das selber zu tun, dafür fehlt mir eigentlich komplett der Raum, aber irgendwie auch die Lust, sondern eher, ich will verstehen, was der Benefit daraus ist und wo ich wen dann in Gespräche zusammenbringen kann und wo ich irgendwie Vorteile gegenüberlegen kann.
Aber das tatsächlich zu machen, da hatte ich bei den anderen Dingen einfach mehr Spaß und so kam dann sukzessive der Shift.
Was war denn auf diesem Weg am Ende schmerzhafter oder schwieriger, als du es erwartet hast?
War es das Loslassen von der Entwicklungstätigkeit oder war es dann doch das eine oder andere im Bereich Leadership, Management zu lernen oder war es tatsächlich alles recht intuitiv bei dir?
Also ich würde sagen, ich habe wirklich viele schmerzhafte Learnings auf diesem Weg gehabt, was glaube ich ja jeder, der irgendwie die Themen hat, von kein gutes Anforderungsmanagement, die Zielgruppe nicht in den Blick genommen, Dinge nicht bedachtet.
Technologien eingesetzt, die sich nicht als stabil erwiesen haben oder die für die Anforderungen am Ende gar nicht gepasst haben, weil in der zweiten, dritten Ausbaustufe Dinge gab, die so das Framework oder so nicht bedacht haben.
Also da gab es einige, die wir auf dem Weg hatten.
Ich glaube, was für mich die größte Herausforderung war, war so ein Mindset-Shift, zu sagen, andere können das besser als ich.
Weil ich kam ja aus der Softwareentwicklung.
Ich war auch ein guter Entwickler, würde ich glaube ich sagen.
Und ich habe auch gute Architekturen gebaut und gute Frameworks eingesetzt.
Und jetzt habe ich auch noch die andere Seite.
Ich habe die Anforderungen verstanden.
Also habe ich auch immer gedacht, das geht ja auch alles super schnell.
Weil die Anforderungen sind klar.
Dann ist es ja auch schnell runtergecodet.
Dann hat das länger gedauert, tatsächlich die Übersetzungsarbeit zu machen.
Und dann fiel mir es aber irgendwann unglaublich schwer zu akzeptieren, dass andere dann einfach besser können.
weil sie einfach technologisch weiter sind, weil sie sich vielleicht auch mit anderen Architekturen und Pattern beschäftigt haben, die ich so noch nicht auf dem Schirm hatte.
Und das fiel mir wirklich schwer, irgendwann mich aus dieser Diskussion rauszunehmen und in so eine Coaching-Rolle reinzugehen und nicht mehr zu sagen, ich habe vielleicht ein Störgefühl, das würde ich heute sagen und würde das adressieren und sagen, lass uns ausdiskutieren.
Aber früher fiel es mir unglaublich schwer zu sagen, gerade mit einem gewissen Zeitdruck, Budgetdruck zu sagen, habe ich in meinem Kopf den Weg gehabt und andere haben gesagt, dass der Weg ist besser und mich dann nicht durchzusetzen, beziehungsweise ich habe mich auch ein paar Mal durchgesetzt, um schmerzhafte Learnings irgendwie zu teilen.
Und irgendwann muss man einfach akzeptieren, dass andere dann auch besser können oder dass sie im Zweifel auch ihre Learnings selber machen müssen, um einfach die Dinge auch weiterzuentwickeln, Verantwortung für die Systeme zu übernehmen, sich einfach noch tiefer in Anforderungen einzugraben, in die Situation des Kunden reinzugraben, auch die Testautomatisierung zu erhöhen.
Das funktioniert nicht, wenn du denen immer die Entscheidung abnimmst und sagst, mein Weg ist der richtige.
Also ich muss sagen, das war für mich das härteste Learning und das hat bestimmt auch ein paar Jahre gebraucht.
Was würdest du denn denjenigen, die jetzt gerade an so einer Stelle sind und sich jetzt weiterentwickeln wollen, was würdest du denen denn raten?
Was hat dir denn geholfen?
Ist das eine reine Haltungsfrage für dich gewesen oder gab es auch Dinge, die du immer wieder ins Bewusstsein rufen musstest, die dir dann geholfen haben, hier nicht wieder immer wieder in die Falle zu tappen?
Ich würde auf jeden Fall mit dem Nehmt euch nicht zu wichtig.
sondern, wie gesagt, andere haben Learnings, die Dinge damit einbringen.
Woran man das ganz gut merkt, ist, wenn jetzt jemand eine Idee vorstellt, ist, dass man nicht anfängt, dagegen zu argumentieren oder seine eigene Argumentation auszupacken, sondern seine Themen als Fragen zu formulieren.
Zu sagen, hast du das bedacht?
Wie gehen wir damit um?
Wie gehen wir vielleicht mit diesem Fall um?
Oder jenes, was so im Kopf rumschwirrt.
Das findet man viel, viel schneller an Konsens, als dass man so Fronten aufbaut und harte Diskussionen und Argumentationen gegenüberlegt.
Aber grundsätzlich muss man sich halt selber fragen, was möchte ich eigentlich?
Möchte ich alle Entscheidungen in allen Projekten, in allen Konstellationen selber treffen oder möchte ich eine Organisation, ein Team, eine Struktur aufbauen, die für sich selber Entscheidungen trifft, dahinter steht, ein Commitment dazu hat?
Da muss man, glaube ich, für sich entscheiden und dann die entsprechenden Wege zu gehen.
Und ich habe auf jeden Fall irgendwann gemerkt, ich kann das nicht mit so vielen Personen.
Ich bin heute für 40 Leute disziplinarisch verantwortlich.
Ich kann mich nicht darum kümmern, was die oder die Entscheidungen treffen, die dort tagtäglich getroffen werden müssen.
Meine Aufgabe ist, ein System zu bauen, was ohne mich funktioniert.
Und ich sage mal, vielleicht die extrem wichtigen Entscheidungen mitzutreffen, mitzutragen, das Commitment dazu zu geben, dass sie in der Einführung auch funktionieren, in der Organisation funktionieren, dass sie vielleicht auch eine Langfristigkeit haben.
Expertise mit einzubringen und gewisse Entscheidungen auch mitzutragen und auch mitzufördern.
Aber grundsätzlich brauche ich eine Organisation, die für sich selber funktioniert.
Und ich glaube, wenn man die Entscheidung muss, muss man als erstes treffen.
Dann kommt halt das Mindset dahinter, dass man dann auch seine eigene Persönlichkeit nicht zu wichtig nehmen sollte.
Und wie gesagt, ein guter Tipp ist tatsächlich, Fragen zu stellen, statt zu argumentieren und Aussagen zu treffen.
Hast du denn als Agentur-CTO überhaupt Zeit dafür?
Durch Fragestellungen die Leute dahin zu führen oder tickt dann nicht doch wieder die nächste Abgabe oder Deadline des Kunden oder das Budget, was du bekommen hast oder das Team bekommen hat, um bestimmte Deliverables an den Kunden zu liefern?
Hast du dann aktiv die Zeit dafür, um das so konsequent durchzuführen, was du gerade beschrieben hast?
Oder sitzt du dann doch manchmal da und sagst, nee Leute, wir müssen jetzt einfach Gas geben.
Normalerweise würde ich das so machen, aber ich sage euch jetzt, wie es läuft.
Ich würde sagen, ich habe heute die Zeit dafür, aber das habe ich mir auch die letzten, fünf, sieben, vielleicht sogar zehn Jahre erarbeitet in einer Struktur, wo ich Menschen um mich herum habe, die auch mich kritisch beleuchten, die auch Dinge, die ich irgendwie kommuniziere, auch mal sagen, das könnte man, hast du mal daran gedacht oder jenes gedacht.
Ich glaube, das ist ein Ergebnis harter Arbeit über die letzten vielen Jahre.
Aber heute würde ich sagen, habe ich die Zeit, genau da reinzugehen, von den ganz wichtigen Entscheidungen, die Dinge zu unterfragen, mir auch zu sagen, schick mir doch mal das Konzept, ich lese es mir mal durch, sag, passt für mich oder hier, mach Kommentare dran und sag.
schaut da nochmal rein.
Also da lässt sich ja heutzutage auch viel asynchron über Confluence und diese Dinge auch machen.
Aber grundsätzlich ist das aus meiner Sicht meine Aufgabe, die Teams dahin zu bringen, gute Entscheidungen zu treffen.
Und ich merke auch, und das ist ja auch so, wir betreuen ja sehr viele Kunden, dadurch, dass wir eine gewisse Größenordnung haben.
Und wir haben das so über cross-funktionale, eigenverantwortliche Teams geschütten, dass die nicht zu viele Kunden betreuen.
Und da ein unglaublich hohes Commitment, Branchenwissen.
tiefen Know-how für dieses Thema aufzubauen.
Das kann ich ja selber so gar nicht mehr haben und trotzdem kann ich da reingehen und sagen, Mensch, das ist mir aufgefallen, wie habt ihr euch das gedacht, wie löst ihr vielleicht dieses Thema?
Und das macht auch Spaß, weil die dann auch sagen, ja cool, daran haben wir noch gar nicht gedacht, das als Bereicherung zu finden.
Und wenn man das eine Beile macht, lernt man sich auch gut kennen und dann wissen die schon, wenn es um strategische Entscheidungen in dem Projekt trifft, dann schreiben die mich an und fragen mich, ob ich Zeit dafür habe, darüber zu schauen, dann kann ich es immer noch entscheiden.
Aber meistens nehme ich mir die, weil es mir a Spaß macht und b das Ergebnis besser macht.
Und dann entstehen einfach ganz viele Synergien und ganz viel Wirkung und vor allem dauerhaftes Commitment und eine Struktur, die einfach in sich sich auch kontinuierlich weiterentwickelt.
Jetzt hast du eben selber schon gesagt, du führst ja ein 40-köpfiges Team, großfunktional, und bist natürlich gleichzeitig als strategischer Sparingspartner für Kunden unterwegs.
Gibt es da auch einen Zielkonflikt hin und wieder zwischen den Rollen?
Also dass der strategische Sparingspartner in dir dem Ja, dem internen Entwicklungsleiter, der du ja auch bist, im Wege steht?
Ja, würde ich sagen, dass es Tazi-Konflikte gibt.
Und auch das sehe ich als meine Lösung, das aufzulösen.
Also wenn ich jetzt irgendwie mit einem Kunden oder manchmal habe ich auch mit anderen Ebenen da irgendwie zu tun, irgendwie Dinge aufnehme und mit dem Team darüber diskutiere und die das einfach ganz anders sehen, dann heißt es ja, dass wir nicht den gleichen Informationsstand haben oder dass wir irgendwie Themen brauchen, die aufzulösen sind.
Und dann haben wir zum Glück auch Coaches bei uns im Haus, die solche Sessions auch moderieren und zusammenbringen.
Und dann kann ich sagen, Ich habe das Gefühl, die Anforderungen sind nicht klar genug.
Oder es gibt hier vielleicht von dem Projektteam ein anderes Briefing als das, was ich von der Geschäftsführung mitnehme.
Stopp, das müssen wir auflösen.
Wir kommen zusammen und klären das, dass wir einfach wieder ein Commitment haben.
Und das sehe ich auch als meine Aufgabe, diese Dinge übereinanderzulegen.
Und am Ende sehe ich ja verschiedenste Interessen, die da zusammenkommen.
Erstens mal bei der Person anfangen, das heißt die Person, der Entwickler, der Consultant, der Konzepter, der hat ja auch ein persönliches Interesse, sich mit gewissen Technologien auseinanderzusetzen, sich selbst zu verwirklichen.
Du hast das Interesse des Teams, was auch eine wirtschaftliche Stabilität haben will, was erfolgreiche Kunden haben will.
Du hast die Interessen des Ansprechpartners, der ja auch persönliche Interessen hat, die Dinge sich weiterzuwickeln.
Du hast das Interesse des Kunden, dann hast du auch nochmal die Interessen der Kunden, unserer Kunden.
Also es sind aus meiner Sicht immer viele Dinge aufeinander zu bringen und ich merke, Wenn man die in der richtigen Struktur diskutiert, findet man meistens auch einen Konsens, weil die größten Interessenkonflikte kommen eigentlich aus mangelnden Informationen und mangelnden Diskussionen auf den wichtigen Themen.
Das heißt, das lässt sich meistens auflösen.
Jetzt hast du vorhin gesagt, du kennst nicht so viele SaaS-CTOs oder klassische Produkt-CTOs, aber trotzdem mal die Frage, was müssen denn CTOs im Agenturkontext früher lernen oder anders machen?
was viele Produkt-CTOs dann erst deutlich später realisieren müssen.
Schwere Frage, finde ich.
Ich glaube, der Blick nach außen und diese permanente Veränderung und dieses permanente, auch der menschlichen Nutzer, als Agentur sind wir ja selten ja für interne IT verantwortlich.
Es gibt auch mal irgendwie Themen, wo man am Rande mal ein Produkt baut oder irgendwie auch ein Tool baut, was nur für...
Du meinst für die interne IT des Kunden?
Genau.
Oder was von den Mitarbeitern unserer Kunden verwendet wird.
Hauptsächlich sind wir ja dafür verantwortlich, wirklich...
für die Kunden unserer Kunden, die einen Blick mit reinzubringen, für die Funktionalitäten zu schaffen, Buchungsstrecken zu schaffen, Kundenportale zu schaffen, Apps für eine Offline-Erfassung oder andere Dinge zu bauen.
Und da ist es natürlich permanent wichtig, diesen Blick, die technologischen Bedürfnisse, da eine App, eine Offline-App, Stores, Offline-Synchronisiert, Progressive-Web-Apps und andere Technologien im Blick zu behalten.
Und ich glaube, das ist schon etwas, was uns wahrscheinlich von internen CTOs unterscheidet, die einfach mehr die Aufgabe haben, nach innen stabile Strukturen zu schaffen, einen Progress der Organisation zu schaffen und solche Dinge.
Und da heißt es wirklich unglaublich viel, den Markt zu beobachten.
Und ich glaube, da ist Neugier auch ein ganz, ganz wichtiger Faktor, genau in der T3N und andere Dinge einfach permanent zu lesen, zu screenen, Interesse daran zu haben.
Ah, und da kommt irgendwie dort ein Soho CRM oder da eine Salesforce oder ein HubSpot oder Kone und zu sagen, boah, ich nehme mir jetzt mal eine Viertelstunde und schaue mir mein YouTube-Video an und lasse mir mal, was ist das Beste an dem System oder schaue mir mal einen Test davon an oder lesen einen Test durch.
Da ticken wir auch alle ein bisschen unterschiedlich.
Ich glaube, das ist einfach wichtig, Neugier am Markt für Interessen der Menschen, für Veränderungen zu haben, was hier auch mit mobilen Endgeräten und da kommt früher noch irgendwie so ein Windows-Phone rausgekommen, dann ist irgendwie mal, jetzt hat sich das ja mehr auf Google und auf Apple konzentriert, aber da herauszufinden, wie nutzen eigentlich Menschen draußen?
und was muss ich für eine Infrastruktur, für Möglichkeiten, für Daten schaffen, um einfach das bestmögliche Kundenerleben zu bauen.
Auf der einen Seite völlig nachvollziehbar, dass du dich als Agentur-CTO sehr viel intensiver mit den Neuerungen und den neuesten technologischen Trends auseinandersetzen musst, weil Kunden gegebenenfalls danach fragen und du up-to-date sein musst und das vielleicht sogar mehr als ein CTO eines SaaS-Unternehmens.
Auf der anderen Seite sagst du ja auch, naja, 90%, 95% der Projekte, die ich habe oder der Kunden, die kommen mit ihrem alten Tech-Stack, der vielleicht sogar schon 10, 15, 20 Jahre auf dem Buckel hat.
Wo kannst du denn dann überhaupt neue Trends aktiv einsetzen und wie sehr fragt denn der Kunde überhaupt nach neuesten Trends und sagt dann nicht, ah ja, schön, dass ich das jetzt weiß, aber jetzt bauen wir trotzdem an dem weiter, was wir eigentlich schon haben.
Ich glaube, das kommt vor allen Dingen daher, dass es ist mal so.
Ich glaube, die großen Systeme sind alle gesetzt.
So ERP-Systeme, meistens CM-Systeme, wahrscheinlich Warenwirtschaft für je nachdem.
Die sind meistens irgendwie festgesetzt und da ist es schwer, eine Veränderung zu haben.
Aber alles, was dann nach außen geht, da ist dann doch meistens ein bisschen Spielraum da.
Oder was auch dann ganz oft passiert, ist, wir kriegen eine Ausschreibung, den Wunsch, eine neue Website zu machen, ein Kundenportal zu bauen und da steht dann sowas drin, wir überlegen, das und das CM-System mit zu verbinden.
Das heißt ja, die haben es noch nicht eingeführt.
Das heißt, dort kann ich tatsächlich in die Beratung gehen und sagen, ist das überhaupt das Thema, macht das Sinn, habt ihr einen Nordstern dafür?
So solche Dinge, da kann ich dann auch eine Beratung reingehen.
Aber natürlich muss ich auch, wenn jetzt irgendjemand sagt, ich habe SAP R3 noch im Einsatz oder eine HANA oder ich habe ein Salesforce und die klaut davon oder das im Einsatz, da muss ich natürlich irgendwie schon einordnen können, okay, welche Prozesse haben die denn jetzt darauf schon abgebildet?
Können wir darauf aufsetzen?
Gibt es eine API, die wir irgendwie nutzen können, um da Daten rauszubekommen?
Also da heißt es, vor allen Dingen auch, um die Dinge einordnen zu können und vor allen Dingen auch, um die Beruflichkeiten einzuordnen, weil es wäre jetzt auch als beratende Organisation peinlich, wenn jetzt irgendwie da so bekannte Namen stehen und man selber einfach gar keine Ahnung davon hat.
Das heißt, um da einfach vernünftige Diskussionen führen zu können, ist es schon sehr hilfreich, zumindest mal einen groben Überblick über die Systeme zu haben, um da einfach reinzugehen.
Und je mehr, also je näher das am Kunden am Ende dran ist, desto mehr Flexibilität ist dann doch dabei, Dinge auch zu verändern.
Ich merke auch, dass gerade in interner IT ist, auch eigentlich sehr schätzt zu sagen, wir kümmern uns um die Prozesse unserer Organisation.
Das heißt, wir geben eine saubere AP nach außen, wie ein Buchungsprozess aussieht und haben mit dem Rest des Kunden auch gar nichts mehr zu tun.
Und wie wir in der Agentur kümmert sich dann darum, den möglichst einfach nach außen zu bringen, aber die Komplexität, die nach innen notwendig ist, auch abzubilden und dann einfach eine Schicht dazwischen zu bringen.
Und dann entsteht meistens doch Flexibilität und was ganz viele Organisationen da draußen ja noch gar nicht haben.
ist sowas wie eine Marketing Automation, eine Vertriebsvernetzung.
Zu sagen, ich habe Marketing und Vertrieb in einem strukturierten Prozess, gerade wenn das Thema Lead-Generierung ein Thema ist, da sind ganz viele Organisationen nicht gut aufgestellt.
Und auch CRM erlebe ich eigentlich noch sehr, sehr viel da draußen, gerade im deutschen Mittelstand, die CRM als Orderbook verstehen in ihrem ERP-System, aber dass da Kundeninteressen, Informationsbedürfnisse, Upselling-Themen.
verbessertes Kundenerlebnis und das CRM ja noch viel, viel mehr ist, da sind tatsächlich auch noch nicht so viele draußen unterwegs und da können wir dann doch sehr viel beraten.
Aber wie gesagt, meistens ist das nicht der erste Step, dass wir da ein System einführen, sondern dass das dann eher so ein iterativer Prozess ist.
Wir arbeiten mit dem, was da ist.
Wir denken mal groß, sagen dann, ah, hier wäre es gut, wenn wir perspektivisch vielleicht Marketing Automation, Reporting oder was auch immer draufsetzen und konzentrieren uns aber auf die erste Ausbaustufe, die schon für die Organisation einen riesen Mehrwert bietet und auch für den Kunden.
also den Kunden unserer Kunden einen riesen Mehrwert bieten und fangen dann an, iterativ zu verbessern.
Du hast jetzt an anderer Stelle auch schon, du hast nochmal gesagt, dass Digitalisierungsprojekte sehr oft scheitern, trotz der guten Technologien.
Hast du eine Erklärung, warum das so ist?
Ich würde sagen, Kommunikation ist das größte Thema.
Dieses Thema Silo-Denken in verschiedenen Organisationen und dieses Nichts an einem Tisch zusammenbringen und mal wirklich strukturiert darüber zu diskutieren.
Ich muss da immer wieder an den Satz denken hier von, ich glaube Albert Einstein hat das gesagt, wenn ich 60 Minuten Zeit habe, ein Problem zu lösen, nehme ich mir 55 Minuten, um nur das Problem zu durchdringen und dann fange ich erst mit der Lösungsfindung an.
Und ich glaube, die meisten Digitalisierungsprojekte und die meisten Organisationen erhoffen sich ganz schnelle Lösungen, indem die irgendwie mal ein Video zu einem CRM-System führen, dann kippen die das in ihre Organisation ein und sagen, das hätte ich gern, weil das löst das Problem.
dass die Leute gar nicht mitgenommen werden, dass Anforderungen nicht sauber ausgearbeitet werden, dass Rahmenbedingungen nicht sauber ausgearbeitet werden.
Das passiert an meiner Stelle zu wenig, weil die meisten kriegen bei dem Thema Strategie schon irgendwie Panik.
Und wenn sie da noch keine Panik haben, dann bei dem Thema Workshop, Anforderungsworkshop.
Da gehen bei allen immer gefühlt so die Alarmglocken an.
strukturierte Anforderungsworkshop, wo wirklich verschiedenste Abteilungen an deinen Tisch kommen, vernünftig diskutieren und gemeinsam Nordständer arbeiten, die Insights mit reinbringen, Datenschutz von Anfang an an deinen Tisch mitzubringen und solche Aspekte mit zur Berücksichtung, um einfach eine gute Digitalstrategie aufzubauen, das ist aus meiner Sicht elementar und das tun aber die wenigsten, weil man sich immer so Quick-Wins erhofft.
Wie gesagt, ich lese irgendwo über ein gutes System.
und kippt dann in meiner IT-Abteilung ein und sagt, installiert mir das mal.
Und die sagen ja, aber Vernetzung und das und wie ist denn das und wie ist denn jenes.
Und eigentlich haben die ja sowieso mit ihrem Bestandssystem schon super viel zu tun.
Da fehlt aus meiner Sicht auch ein bisschen die Ruhe, einen klaren Plan zu erarbeiten.
Oder sich auch die Zeit zu nehmen, nicht nur einen Prozess, einen analogen Prozess eins zu eins zu versuchen, digital umzusetzen, sondern eine neue Lösung zu entwickeln, die vielleicht unabhängig ist von der analogen Version.
Wir hatten jetzt, das ist zum Zeitpunkt der Aufnahme heute, ist die Folge noch nicht erschienen, aber sie wird zwei Folgen bevor seine Folge erscheinen, mit dem Tobias Eis gesprochen, der dann das auch immer wieder in seinem Team reingebt.
Stellt euch mal vor, es gibt das Thema Geld und Geld ist erfunden worden, hat einen bestimmten Zweck und jetzt versuchen wir das Thema Geld gerade im digitalen Kontext umzusetzen, was das dazu führt, dass die Leute teilweise vier Tage auf ihr Geld warten müssen, obwohl es theoretisch jederzeit da sein sollte.
Und ein Grund ist, weil man das von den Prozessen her...
den analogen Prozess im Endeffekt versucht hat, digital umzusetzen.
Und er gibt seinem Team gerne mal die Maßgabe mit, denkt einfach, was wäre denn, wenn das Geld schon vor dem Computer da gewesen wäre?
Nicht das Geld, wenn der Computer vor dem Geld da gewesen wäre.
Wie würde das Geld dann aussehen, wenn du das von vornherein so denkst?
Also sich komplett losmachen von dem ursprünglichen analogen Gedanken und dann die Lösung suchen.
Ist es was, was du auch aktiv dann förderst in deinen Teams oder wie gehst du damit um?
Ja, auf jeden Fall.
Das halte ich auch für total wichtig.
Auch nicht zu sagen, ah, jetzt ist das eine Thema, was ich verändern will und das erschlage ich mit einem System, sondern eher wirklich auch mal grundlegend denken.
Deswegen sagen wir auch immer People First.
Wir nutzen Technologien, wir nutzen Systeme, um das Leben der Menschen leichter zu machen.
Also lass uns doch mal verstehen, was...
für die das Leben schwer macht, wo die was ausgeben, was die erwarten, den Gesamtprozess zu beleuchten, auch zu beleuchten, was bedeutet denn eine Systemeinführung für die Organisation?
Wie sieht die Welt denn nach fünf Jahren wirklich anders aus, wenn ich das System eingeführt habe, um auch ein klares Zielbild im Kopf zu kriegen, auch um Energien freizusetzen?
Auch das ist ja ein Thema.
Wenn man so immer sagt, ich will ein neues System haben, denken immer alle, oh Gott.
Jetzt hier noch ein Thema drauf.
Wir kommen ja mit dem Bestandssystem schon nicht klar und wir kriegen die Schulung nicht und die Kommunikation dazu passt.
Da ist erstmal sehr, sehr viel Widerstand da.
Aber ich glaube, wenn man wirklich diese soften Themen auch mit reinbringt, neben den harten Anforderungen, die auch beleuchtet werden müssen, setzt das Energie frei.
Es gibt dem Denken eine Richtung.
Es gibt den Diskussionen eine Struktur.
Und deswegen halten wir das für total wichtig, auch in der Zusammenarbeit wirklich das alles immer auf ein vernünftiges Fundament zu setzen.
durch eine gute Strategie, die einfach von innen herauskommt, aber auch von den Nutzern oder von den Kunden geprägt wird, um dann ein gemeinsames Verständnis aufzubauen, warum das eigentlich getan wird, was ein sinnvoller Benefit ist, was eine erste Ausbaustufe ist, die schon einen signifikanten Mehrwert bietet, aber kein Dreijahresprojekt daraus macht.
Also diese ganzen Aspekten der Agilität eigentlich mit einbringen.
Weil wenn man sich tiefer mit dem Agile Manifest beschäftigt, ist das ja eigentlich genau deswegen mal auch entstanden, weil die Welt so komplex geworden ist.
dass es mit da Mechanismen gibt, die helfen, diese Komplexität zu handeln.
Aber dafür muss man auch die richtigen Dinge tun und Iterationen, auch messbare Ergebnisse zu haben und all die Aspekte, die dort drinstehen, auch wirklich zu berücksichtigen.
Ja, ihr arbeitet auch, wenn ich das richtig verstanden habe, stark mit Themen wie Nutzerforschung, wie Prototyping und so weiter.
Aha-Momente erleben dann Kunden typischerweise, wenn sie genau damit konfrontiert werden und ihr das aktiv auch entfreust, dass mit sowas gearbeitet wird.
Der Aha-Moment ist vor allem, dass die meisten Kunden oder die meisten Menschen wahrscheinlich sogar glauben zu wissen, was ihre Nutzer und Kunden wollen.
Das erleben wir eigentlich immer.
Wir haben auch manchmal so Projekten, wo wir sagen, lass uns doch mal die Insights mit rausgehen.
Die sagen, die Kunden wissen ja gar nicht, was sie wollen.
Ich weiß aber, was die Kunden wollen.
Das ist ja aber so eine totale Überlegenheitsillusion und wenn wir die mal brechen können, indem wir wirklich einfach mal mit drei Kunden sprechen, ein Tiefeninterview durchführen und sagen, was bewegt dich eigentlich gerade, was ist das Thema, was bewegt dich im Alltag und die ganz andere Dinge erzählen, dann kommt eigentlich ein krasser Aha-Moment.
Den hatte ich selber, als wir für einen Anbieter von Elektro-Ladesäulen mal User-Research durchgeführt haben und E-Fahrer befragt haben, wie die mit diesem Thema Ladethemen umgehen.
Und meine Annahme als Hybridfahrer war, die auch von unserem Team und auch sogar von unserem Kunden war, die Menschen nervt es permanent an der Ladesäule zu fahren und irgendwie alle 400 Kilometer oder wie auch immer mein Auto es halt schafft, laden zu gehen.
Die Gespräche haben aber herausgefunden, dass das E-Fahrer lieben.
Die mögen die Pause, sie mögen es sich dann vielleicht auch mit anderen Leuten zu unterhalten.
Das war wirklich eine signifikante Menge.
Das heißt, es ist gar kein Pain, das Auto zu laden.
Es ist ein positives Teil des Erlebnisses von E-Autos.
Und das ist ja krass, wenn ich eigentlich in meiner Kommunikation die ganze Zeit versuche zu sagen, schneller laden, weniger Stress zu haben, aber das ein positives Erlebnis ist.
Das war ein Moment, wo wir zum Beispiel mal wirklich diese Situation hatten zu sagen, krass, die Menschen sagen was ganz anderes als alle.
unsere Kunden und auch wir gedacht haben und sowas erleben wir tatsächlich sehr häufig.
Hast du interessanterweise auch mal den umgekehrten Fall erlebt, dass du hast vielleicht mit einem Kunden gesprochen, der sagt dir, ah, wir wissen ja alles über den Kunden und wir haben ja genau Vorstellungen davon.
Dann erzählst du ihm, nee, wir müssen erstmal User Research machen und es ist, glaub mir, Return on Invest, es wird super sein und dann kommst du auf, stellst du auf einmal fest, ja, der Kunde hatte leider doch recht gehabt.
Er wusste eigentlich alles schon über den Kunden oder sagen wir mal 90 Prozent.
Gab es den Fall?
Hand aufs Herz?
Das ist ehrlich gesagt kein so richtiger Fall bekannt.
Also ich würde schon mal sagen, es gab den Fall, wo die anderen bestätigt wurden.
Aber ich würde immer sagen, haben wir mehr Insights generiert und mehr Erlebnisse und mehr Tiefe in die Themen bekommen, als das, was unser Kunde formulieren konnte.
Weil es gibt ja in diesem Research-Bereich auch sehr viele unterschiedliche Methodiken, die eher auf das Verhalten orientiert sind, die eher auf den Antrieb und die Motivation konzentriert sind, die eher quantitativ sind, eher qualitativ sind.
Und ich sage mal, das, was diese Methoden und ja Experten im User-Research rausfinden, Das kannst du nicht einfach mal, selbst als Product Owner, der 15 Jahre sein Produkt macht und irgendwie mit einem Haufen Kunden gesprochen hat, der kann das ja gar nicht in so einer Struktur abrufen.
Und deswegen haben wir wirklich in allen Bereichen eigentlich immer viel mehr Insights generiert.
Und am Ende muss man eigentlich sagen, finde ich auch Kosten nutzen sich.
Es gibt ja so eine Studie, eine Forbes-Studie, wo man sagt, jeder investierte Euro spart 100 Euro in der Entwicklung.
mit Features, die keiner braucht und anderen Dingen.
Und wenn man diese Studie nimmt, kann man dann auch, selbst wenn man sagt, man zieht davon 10% ab oder die Hälfte oder was auch immer, glaube ich, ist das echt sinnvoll investiertes Geld.
Und ich finde, dass die meisten Projekte, wenn ja mal schnell sechsstellig, in krassen Bereichen, wenn es eine neue Systemanführung gibt, auch siebenstellig.
Und da mal irgendwie niedrigen fünfstelligen Betrag oder vielleicht sogar vierstelligen Betrag anzunehmen, um mehr Nutzerverständnis hinzubringen, da würde ich dann auch sagen, dann stimmen auch die Werte.
Und es ist tatsächlich auch so, dass wir haben ganz oft, ehrlich gesagt, die Situation, dass Kunden sagen, User Research ist uns zu teuer in unserer Kalkulation.
Und je nachdem, wie groß das Budget ist oder ob wir gerade einen Pitch befinden und so, ist es dann schon, dass wir manchmal auch mit so Anbietern wie User Brain und anderen Plattformen kann man auch mit sehr überschaubaren Kostenfaktor-Insights generieren.
Die schneiden wir dann als Video zusammen und die pitchen wir dann beim Kunden und sagen, deine Kunden haben das und das gesagt und die und die Thesen daraus.
Und die Aha-Effekte führen eigentlich meistens dazu, dass wir dann auch ...
A, den Gesamtauftrag kriegen, aber B, auch die Budgets für User Research freikriegen, was doch verrückt ist.
Und ich muss ehrlich gesagt, selber in meiner Rolle, ich verantworte auch ein Stück weit als Techniker ja auch unsere eigene Website mit und bin auch sehr tagend an unserer eigenen Strategie mit beschäftigt.
Und auch da haben unsere Kollegen im Rahmen des Website Relaunches Kundeninterviews geführt und die habe ich mir angesehen und gesagt, krass, das ist denen wichtig?
Das ist das, was die suchen.
Das ist das, was die an Informationsbedarf an so einer Seite haben oder an einem Interaktionsthema.
Da muss ich sagen, war ich selber in der Rolle und da habe ich gedacht, ich bin so nah an meinen Kunden dran, hatte ich selber den Effekt, wo ich gesagt habe, gut, dass wir es gemacht haben.
Ja, jetzt sind ja natürlich nicht nur die Kunden, die vielleicht die Nutzerperspektive auch mal außen vor lassen, sondern auch selbst die stärksten Entwickler vergessen das hin und wieder mal.
Wie gehst du denn überhaupt mit denen um?
Also starker Senior Engineer, technisch brillant, aber...
Nutzerperspektive wird dann gerne mal außen vor gelassen.
Musst du dann auch mal mit dem Hammer kommen und draufhauen?
Oder wie machst du das?
Also ich würde mal sagen, ich habe schon manchmal Überzeugungsarbeit zu leisten.
Um es ein bisschen passiver zu formulieren.
Nee, aber Spaß beiseite.
Durch unsere kostfunktionalen Teams ist es ja so, dass wir bei uns immer Frontentwickler, Backendentwickler, Konzepterdesigner, Berater, Projektmanager in einem Team haben.
Und die lösen das eigentlich meistens untereinander.
Weil es ist ja schon so, dass wir auch versuchen, oder nicht versuchen, dass unser Konzept der Designer dieses User-Research mit durchführen, meistens mit Unterstützung aus anderen Teams und diese Sichtweise mit reinbringen.
Und wenn man die Konzepte, die wir zum Beispiel erarbeiten, Oberflächenkonzepte oder Anforderungen, aus Nutzersicht argumentieren, kann dann auch schweren Entwickler sagen, das ist mir egal, ich baue das ganz anders.
Also dadurch, dass unsere gesamte Struktur darauf ausgelegt ist.
den Blick mit in die Kommunikation reinzunehmen, ist es so, dass das auch hinten raus sich gar nicht mehr die Frage stellt.
Aber das ist natürlich schon so, dass das etwas mehr bei den Beratern liegt und etwas mehr in der Natur auch der Konzepter und Designer liegt, den Nutzer zu verstehen.
Aber wenn die das ausarbeiten, das intern präsentieren, dann ist das meistens auch dann eigentlich...
dann hat man mal hier noch Anmerkungen und sieht Dinge vielleicht anders oder sagt, ich würde gerne Features anders sortieren, weil die technologisch nicht zusammenpassen oder wir müssen ein Tool splitten, um einen Microservice-Ansatz einzuhalten und all diese Dinge, die uns ja so tagtäglich bewegen.
Also der Blick ist ja auch wichtig für das Gesamtergebnis und wenn das aber moderativ zusammenpasst, ist es am Ende für alle eigentlich immer gut und so kriegen wir die Dinge eigentlich ganz gut übereinander.
Das weißt du jetzt natürlich, weil du auch schon sehr viel Erfahrung hast und weil du dir auch die Erfahrung im Laufe der Jahre und in den 20 Jahren, die du jetzt da Erfahrung hast, auch geholt hast.
Was würdest du denn deinem jüngeren Ich im ersten Jahr als CTO raten, wenn er jetzt vor diesen Herausforderungen steht, der all diese Erfahrung vielleicht noch nicht gewonnen hat?
Würdest du sagen, mach alles genauso, wie du es jetzt gemacht hast?
Oder würdest du ihm signifikant etwas anderes mitgeben wollen?
Also ich würde Ihnen wahrscheinlich schon sagen, dass Learnings, die ich sehr hart über die Zeit haben muss, dass man die schneller mal ausprobieren sollte, fängt bei einem selber an, sich selber nicht zu wichtig zu nehmen.
Also ich glaube wirklich, dieses Gefühl, das hatte ich lange, ich bin der Cleverste im Raum, mal ganz überspitzt zu sagen.
Und ich habe das beste Verständnis, weil ich habe mit Kunden gesprochen, ich habe die technologische Expertise, ich kann eine Entscheidung am besten treffen.
Ich glaube, dieses Mindset zu sagen, lass den anderen Raum, lass die das ausarbeiten, im Zweifel dir präsentieren und dann stell kritische Fragen, aber nicht immer in dem Lied zu sein, das würde ich mir auf jeden Fall gern mitgeben und ich glaube auch, dieses Thema Anforderungs- Workshops, Anforderungsanalysen mit allen zusammen machen, über strukturierte Formate, ich glaube auch da haben wir viel, viel Energie auf der Straße liegen lassen, dass wir das zu spät begonnen haben.
Die Projekte, die wir vor 15 Jahren gemacht haben, da kannte ich ehrlich gesagt auch niemanden, der Anforderungsworkshop gemacht hat.
Heute würde ich wirklich sagen, kein einziges Thema mehr.
Also selbst wenn wir Inhouse über Aufgabenmanagementsysteme oder jetzt KI-Systeme oder Co.
sprechen, gibt es immer einen strukturierten Anforderungsworkshop.
Wer sind die Nutzer?
Was haben die davon?
Was ändert sich in ihrem Alltag, wenn das eingeführt ist?
Weil da einfach eine andere Sichtweise dazu...
Ja, das ganze Business hat eine riesen Professionalisierung durchgemacht.
Und das ist ja wahrscheinlich jetzt auch dann die...
Die logische Konsequenz daraus.
Das hat vielleicht ja weniger was mit deiner Entwicklung zu tun, sondern mit der allgemeinen Professionalisierung des gesamten Bereichs.
Alex, wir sind auch fast schon am Ende der heutigen Folge angekommen.
Ich habe aber noch, wie es so schön Tradition ist mittlerweile bei uns hier im Podcast, ein paar Rapid-Fire-Fragen mitgebracht.
Hast du Lust drauf?
Ja klar, bin gespannt.
Sehr schön.
Also, ich glaube, ich weiß schon, was du mir sagen wirst.
Aber wenn ich frage, People First oder Tech First, was scheitert denn schneller?
Tech First.
Jeder hasst Systeme, die einfach drüber gebügelt werden.
Natürlich.
Mit den Menschen und mit den Nutzerlern.
Hast du so ein typisches Feature?
Du arbeitest mit vielen Unternehmen.
Feature, das fast jedes Unternehmen baut, aber kaum jemand wirklich braucht oder nutzt?
Also ich sehe schon viele Anforderungen, die immer mal irgendwie gebaut werden und dann hinten raus nicht genutzt werden.
Wenn ich das als Schnittmenge über die Tools sehe, sehe ich das mit dem ganzen Thema Data Lakes und Reportings.
Ich weiß nicht schon, wie viele Systeme und Reportings ich in Unternehmen gesehen habe, die auch nicht schlecht sind, die aber niemand nutzt, weil auch da wieder die Nutzerperspektive fehlt.
In welchen Routinen nutze ich Daten, um daraus Entscheidungen abzuleiten?
Dieser Blick fehlt total.
Deswegen sehe ich sehr viele Reportings, die irgendwo eingebaut wurden, die aber am Ende nie genutzt würden, weil man einfach nicht darüber sich Gedanken macht, in welchen Momenten nutze ich die Reportings, welche Zahlen brauche ich, was sind die Ziele dahinter?
Also ich würde mal sagen, da habe ich schon sehr viele Systeme gesehen.
sehr schick aussahen und nie genutzt wurden.
Ja, sehr gut.
Beste Investition unter 10.000 Euro, die eure Produktqualität messbar verbessert hat.
Das ist auf jeden Fall das Thema User Research.
Ja, das hatten wir ja gerade.
Nutzamt zu nehmen, Analysen zu haben.
Das kriegt man auch unter 10.000 Euro hin und kriegt Insights, die Gold wert sind.
Wie oft musst du dann trotzdem mit dem Kunden darüber diskutieren, dass er das unbedingt für notwendig erachtet und dass er am Ende des Tages dafür sogar einen Benefit hat und eigentlich einen Return on Invest?
Oder ist das für ihn dann relativ schnell gegessen, das Thema?
Das ist schon wirklich was, wo wir auch gefühlt Aufklärungsarbeit betreiben müssen, weil mit dem Namen User Research oder Customer Research viele nichts anfangen können.
Da haben wir schon viele Präsentationen, auch in Folien fertig, die das erklären, was das ist, was der Vorteil daraus ist.
Aber wie gesagt.
Manchmal gehen wir auch einfach in Vorkasse, zeigen das, beweisen das eigentlich an dem jeweiligen Case, welchen Impact das haben kann.
Also das ganze Thema wird auf jeden Fall noch deutlich unterschätzt.
Was nervt dich denn mehr?
Schlechte UX oder schlechte Daten?
Gute Frage.
Ich würde sagen, das schlechte UX führt zu schlechten Daten.
Also von da würde ich eher UX sagen, weil ich glaube, wenn die Eingabemasken nicht gut sind, die Prozesse nicht gut gedacht sind, nicht vom Nutzer und vom Kunden her gedacht sind.
kannst du hinten auch mit den Daten nichts anfangen und du willst ja eigentlich über eine gute UX auch eine Prozesssicherheit und eine Datensicherheit herstellen.
Aber klar, gerade wenn man mit vielen Bestandssystemen arbeitet und irgendwie versucht, da was rauszulesen und nichts vorne und hinten passt, ist natürlich auch frustrierend, aber da kann man ja auch drauf aufbauen.
Sehr gut.
Und welche Entscheidung triffst du heute als CTO schneller als früher?
Ich würde sagen, dieses Testen von Tools und von Technologien.
Da habe ich mir früher total schwer mitgetan.
Und heute kommt aber irgendjemand und sagt, ich habe das und das gesehen, kann ich es ausprobieren.
Ich sage, jo, mach einfach.
Mach es im geschützten Rahmen, nicht auf unser Hauptsystem.
Probier aus.
Da haben wir vor, viel statischer in unserem ganzen Denken.
Da würden wir immer sagen, test es aus, aber schreib am Ende eine Internetnachricht, was du gelernt hast, dass wir darauf aufbauen können.
Welcher typische Satz von Stakeholdern löst bei dir innerlich die Alarmglocken aus?
Ich schwanke zwischen, das haben wir schon immer so gemacht und das wissen wir besser als unsere Kunden.
Ja, genau.
Ich dachte auch, dass man den Kunden kommt, ist bestimmt als Antwort, weil das passt ja auch super ins Thema des Podcasts heute.
Ja, das auf jeden Fall.
Aber auch, das haben wir schon immer so gemacht und das System hat sich schon seit 30 Jahren etabliert und ist aber trotzdem irgendwie eine in-house gehostete Variante, ohne APIs, ohne Struktur, ohne die Menschen noch da, um das weiterzuentwickeln.
Also auch das ist natürlich, steht fast für Stillstand.
Und ein Skill, den CTOs massiv unterschätzen?
Ich würde sagen Empathie.
Oh, okay, sehr gut.
Ich glaube, dass das heute...
Gerade als CTO wichtig ist, diese fachliche Expertise zu haben, aber vor allen Dingen die Menschen zusammenzubringen, die Diskussionen zu bereichern, auch für individuelle Wünsche und Bedürfnisse auch offen zu sein.
Ich glaube, dass Empathie in einer Führungsrolle, und das ist ja CTO am Ende, auch wirklich wichtig ist, weil die wenigsten tun sich schwer mit technologischem Verständnis, aber mit menschlicher Führung ist, glaube ich, eher die Baustelle, die viele da draußen haben.
Fantastisch, gute Antwort.
Und letzte Frage für heute.
Was dürfen CTOs sich erlauben, trauen sich aber viel zu selten?
Ich würde sagen, harte und klare Entscheidungen treffen.
Ich habe das Gefühl, dass wir gerade in so eine Situation reinrutschen, wo man sagt, man will es allen recht machen und will all die Aspekte zu haben.
Und ich glaube, dass dadurch ganz viel Stillstand entsteht, indem man sagt, das muss aber dort nochmal diskutiert werden, da diskutiert werden.
Ich glaube, es ist unsere Aufgabe, die Leute zusammenzubringen.
Verständnis für das Thema aufzubauen, auf einer breite Schulter das zu stellen, aber am Ende auch eine klare Entscheidung zu treffen und eine Roadmap abzuarbeiten.
Weil ich glaube, das ist ja auch unsere Verantwortung als C-Level.
Und ich glaube, da tun wir uns gerade zu schwer und haben mehr so eine Mentalität, versuchen uns allen recht zu machen.
Aber wir sehen ja, es braucht bei der Komplexität am Ende auch klare Entscheidungen.
Und entweder ich treffe die selber oder eine Empfehlung des Teams einfach wirklich zu supporten und sagen können, okay, das ist jetzt der Weg, den wir gehen.
Weil nichts ist schlimmer als...
lasst uns mal probieren und wir starten mal rein, weil dann entsteht keine Energie, dann entsteht kein Drive.
Deswegen glaube ich, habt den Mut, klare und harte Entscheidungen zu treffen.
Sehr schöne Antwort, mag ich auch sehr.
Alex, vielen lieben Dank.
Es war mir eine Freude und wir hätten auch noch einige Fragen in der Hinterhand gehabt, aber die Zeit ist uns davon gerannt.
Wie ist das doch immer so im Leben?
Ich bedanke mich aber sehr, dass du heute hier warst.
Das wird eine fantastische Folge und hoffe, wir sehen uns bald mal wieder.
Vielen, vielen Dank.
Hat Spaß gemacht.
Macht's gut.
Ciao, ciao.
Tschüss.