Private Equity will Tempo. Was lässt eine CTO dafür liegen? - mit Olga Khorkova

0:01 Wie bereitest du eine Tech-Organisation auf eine Due Diligence vor, wenn du noch nicht weißt, wer später auf der anderen Seite des Tisches sitzt und worauf diese Person besonders achten wird? Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und diejenigen, die es noch werden wollen.

0:18 Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO Community. Heute ist Olga Korkower zu Gast. Sie verantwortet die technologische Transformation bei Barfas und hat dort eine Tech-Organisation unter Private Equity Erwartungen weiterentwickelt. Wir sprechen darüber, was Technik prüfbar und übergabefähig macht und welche Entscheidungen sie selbst als CTO treffen musste.

0:42 Und wir sprechen außerdem darüber, was sich verändert, wenn sie beim eigenen Startup wieder selbst tief in Produkt und Entwicklung einsteigt. Olga, herzlich willkommen.

0:51 Dankeschön für die Einladung, Philipp. Bin froh, an diesem Podcast heute teilzunehmen und meine Geschichte zu erzählen.

0:59 Sehr schön. Dann steigen wir auch genau da ein. Und ich bin übrigens mindestens genauso froh, dass du meiner Einladung gefolgt bist. Welche Station oder Entscheidung hat dich denn am stärksten darauf vorbereitet, so heute technische und unternehmerische Verantwortung zu übernehmen, zu tragen?

1:14 Ja, das ist natürlich die Frage, die ich sehr oft bekomme. Also wie bist du CTO geworden? Und man muss ehrlich sagen, es gab keinen konkreten Zeitpunkt, einen Moment oder Projekt, wo ich oder einen Tag, wo ich aufgewacht bin und habe gesagt, okay, heute fühle ich mich nach CTO. Das war tatsächlich so ein langsamer Übergang, wo ich schon in meiner vorherigen Rolle als Head of IT in andere Firma habe, diese Rolle langsam reinzuwachsen, wo ich gemerkt habe, okay, also ich beziehe mich nicht nur auf perfekten Code, von mir wird ein bisschen mehr verlangt.

1:55 Ich muss eine technische Entscheidung treffen, die die ganze Company beeinflussen wird. Und indem ich angefangen habe, mehr von Code-Perfektion auf eine größere globale Ebene zu denken, was ist eigentlich Business Impact, was sind eigentlich Risiken, was ist eigentlich Return of Investment hier, da habe ich verstanden, okay, ich wäre dann tatsächlich für die Rolle jetzt bereit.

2:20 Du hast dich dann schon als CTO gefühlt, bevor du schon, bevor du CTO warst?

2:26 Ja, so kann man sagen, so habe ich mich gefühlt. Aber ehrlich gesagt, also wenn ich sogar jemanden in meinen Teams promoten möchte, ich gucke nicht, okay, die Person hat idealerweise Potenzial. Ich gucke drauf, okay, die Person führt schon diese Rolle aus. Und was mir eigentlich fehlt, noch dieser nächste Schritt, dieser nächste Schritt, diese Titel dran zu hängen.

2:52 Weil in eine größere Leadership-Rolle hineinzuwachsen, ist nicht so ein Klick oder ein Prozess, der über die Nacht passiert, wie ich schon gesagt habe, sondern das ist ein Prozess der eigenen Entwicklung, die man selbst vorantreibt.

3:07 Ja, du hast ja, der Podcast heißt ja auch Becoming CTO Secrets. So, was ist denn dein Geheimnis dann gewesen, um von der Head of IT-Rolle in eine CTO-Rolle zu wechseln? Irgendjemand muss ja zu irgendeinem Zeitpunkt dann auf dein Profil geschaut haben und gedacht haben, du bist der richtige CTO für meine Organisation oder wie war das genau?

3:26 Das war tatsächlich, wenn man ein Profil auf LinkedIn hat, wird man insbesondere nicht bei solchen höheren Positionen wie CTO oder manchmal auch als CTO, da wird man normalerweise von Headhunters zugeschüttet mit allen möglichen Einladungen, Briefen und so weiter. Und das war der eine, der tatsächlich meine Aufmerksamkeit erregt hat.

3:50 Es ging darum, eine neue Company, die von Private Equity gekauft wurde, sie muss einen neuen Schritt machen. Und der Headhunter meinte zu mir, sie wollen technologisch besser aufsetzen, aber sie wollen nichts programmieren. Wo ich sofort gesagt habe, okay, das ist spannend. Das ist so wie analog, wie ich möchte jetzt ein Restaurant aufmachen, aber ich möchte nichts kochen.

4:14 Das hat mich so getriggert und dann erfolgte darauf so eine endlose Reihe von Interviews über zweieinhalb Stunden mit mehreren Runden und am Ende des Tages konnten wir uns einigen. Das war kein besonderes Geheimnis. Also das nicht so, dass ich bestimmte Connection hatte oder ob sich danach gesucht habe.

4:36 Du bist ja jetzt aber dann nicht gleich in der CTO-Rolle eingestiegen, sondern du warst zuerst Chief Digital Officer.

4:43 Yes. Digitalisierung. Als ich in der Firma angefangen habe, das war die Firma, man muss ehrlich sagen, die Firma war sehr stabil, die hat kontinuierlich und langsam über die Jahre gewachsen mit festen Strukturen, aber Technology und E-Commerce war nicht im Fokus. Und man muss ehrlich sagen, das ist nichts Besonderes auf dem heutigen Markt.

5:17 Also ich habe schon sehr viele mittelständische Unternehmen gesehen, die gleichen White Spots haben. Und zuerst hieß es, okay, wir müssen jetzt mehr Digitalisierungsprozesse reinholen, bevor wir hier anfangen, global Umstrukt zu strukturieren. Und da war ich in der Rolle ein paar Monate, wo es dann klar wurde, okay, dass die Aufgabenbereiche, die ich dann mehr und mehr übernehmen muss, sind nicht nur pure Digitalisierung, das ist schon eine technologische und Produktverantwortung.

5:48 Vielleicht kannst du noch irgendwie ein, zwei Sätze dazu sagen, was Barfast dann genau macht, auch um besser zu verstehen zu können, was du als CTO im Unternehmen leisten musst, das erst so im Bereich digitale Transformation und später dann in der Rolle als CTO.

6:02 Ja. Barfas, das ist ein, wir feiern dieses Jahr 15 Jahre um. Das ist ein Berliner Unternehmen. Wir produzieren tatsächlich, wir produzieren Hunde und Katzenfutter. Das ist ein Barf, das ist biologisch Rohfüterung. Wir kaufen selbst, wir produzieren selbst alles in Berlin. Wir haben Point of Sales, wir haben breite B2B-Strukturen.

6:33 Wir verkaufen aber anders von unserer Umsatzes über Online-Kanäle. And we by jedem Unternehmen that continually weiter wächst, also aus einer kleinen Struktur, we have a größer und größere Struktur, also auch im E-Commerce. Dementsprechend bilden sich die Teams, die ich an mich reporten, das sind Ingenieure, das sind Netzwerke, System Administration, die unbedingt immer vor Ort sein müssen, das sind Data Engineering and Analytics, Produkte und UX im Customer Support, den wir jetzt digitalisiert haben.

7:21 Du hast im Vorgespräch hast du auch beschrieben, dass du bei deinem Einstieg erst Grundlage schaffen musstest. Also an welcher Stelle oder in welcher konkreten Situation wurde dir denn klar, was da was zuerst passieren muss?

7:35 Sehr gute Frage. Weil wenn man auf einmal in so ein Unternehmen kommt, das war bei mir vor zwei Jahren, und der frisch von Private Equity akquiriert wurde, da sind natürlich die Erwartungen ziemlich hoch. Und man möchte alles haben und ziemlich schnell. Und eigentlich schon gestern musste das alles passieren.

7:59 Und warum dauert das alles so lange? Bei Private Equity, da gibt es ganz andere Erwartungen an Geschwindigkeit und Skalierbarkeit. Also das muss man innerhalb von kurzer Zeit ziemlich größere Sprünge machen. Für mich ist es okay, wo haben wir jetzt im Moment die größte Schwachstelle. Und das war tatsächlich Data Engineering and Analytics, wo wir dann ziemlich schnell aufgesetzt haben.

8:25 Als nächste kam dann Engineeringbereich, dann Produkte in UX und anschließend haben wir eine große Frage der Skalierbarkeit gestellt. Und parallel liefen solche Projekte wie ERP-System ins Haus zu bringen, damit wir bessere Einblicke haben, Customer Support digitalisieren, also damit keine Sheets mehr manuell gepflegt werden.

8:51 Solche Themen.

8:53 Ja, du hast jetzt auch selber gesagt, man kann natürlich nicht alles machen, obwohl alle gerne wollen, dass alles gleichzeitig gemacht wird und alles gestern schon fertig ist. So, du musst es also bewusst entscheiden, auch manche Dinge liegen zu lassen. Was war das denn, wenn du in so eine Situation reinkommst und du feststellst, da gibt es so viel zu tun, ich kann ja gar nicht alles machen.

9:12 Was hast du liegen gelassen und wie hast du das kommuniziert?

9:16 Also in diese CTO-Rolle, aber ich glaube, in jeder CTO-Rolle geht es darum, sehr oft darum, bewusst viele Dinge liegen zu lassen. Obwohl man weiß, das gibt es. Und das ist schwer. Das ist genauso viele Dinge nicht zu sagen, oder im Gegenteil sagen. Wo ist diese Balance? Ja klar, und wie wir arbeiten unter diesen sehr höheren Erwartungen von unseren Investoren.

9:56 Und es ist klar, dass ein bestimmter Punkt der Skalierbarkeit können wir uns einfach ohne technische Schulden nicht weiter entwickeln. Und für mich bedeutet das, okay, was sind dann technische Schulden? Und was ist diese rote Grenze, wo wir jetzt sagen, okay, das geht nicht mehr. Meine Entscheidung war, dass die Schulden, die technischen Schulden, die bei uns entstehen, müssen sehr gut dokumentiert werden und sichtbar sein.

10:34 Was uns zum Beispiel KI heute sehr dabei hilft, solange wir wissen, okay, es gibt diese, diese und diese Schwachstelle, and that steht bei uns in RDR, das ist für mich akzeptabel. Sobald wir merken an einem Tag, okay, unser System verhält sich, dass keiner versteht warum. Das heißt, wir haben da wirklich irgendein großes Problem.

11:02 Was wir aber jetzt machen, und das finde ich gut so, dass wir jetzt bewusst unsere Geschwindigkeit reduzieren, weil wir dieses Momentum geschaffen haben, mit businesskritischen Themen voranzukommen und tatsächliche Zeit reservieren, um diese Ader Rs und diese kleinen Probleme, die man später lösen kann, wieder anzugehen.

11:26 Ich stelle immer wieder fest, dass gerade CTOs ganz besonders unter der Investorenerwartung oder Investorenerwartungen, ich weiß nicht, leiden, ist Leiden das richtige Wort, auch nicht leiden, aber zumindest mal Schwierigkeiten haben, Prioritäten zu setzen. Wie hast du das denn gemanagt? Ein Investor will vielleicht eher kurzfristige Geschäftsergebnisse sehen.

11:49 Du als CTO musst natürlich auch auf langfristige Qualität und Technik musst du Acht geben. Du hast das gerade selbst gesagt mit den technischen Schulden. Kannst du von einer Entscheidung erzählen, bei der du das gemanagt hast? Hier kurzfristige Geschäftsergebnisse gegenüber langfristiger Qualität?

12:08 Ja, ich glaube, das ist nicht nur von Investoren so getrieben, weil es auch nur bei Private Equity, jeder Department, jede Abteilung, die businessrelevante Entscheidungen trifft, ist unter dem Radar. Da muss ich in so einem Zusammenarbeit, da bin ich immer so in einer gewissen Abhängigkeit zu Marketing, zu Finance, zu Operations.

12:32 Technische Entscheidung könnte ein bisschen länger dauern. Marketing braucht das morgen, für Finance ist das sowieso alles zu teuer und macht keinen Sinn. Also am besten gehen wir gar kein Geld aus und bleiben so, wie es schon immer war. The other Kollege versteht überhaupt nicht, worum es geht. Ich bin teilweise glücklich, dass ich bis jetzt immer geschafft habe, in vernünftige Weise Investoren zu erklären, warum eine Entscheidung so lange dauern wird oder warum das so viel Geld kosten wird.

13:03 Also so irgendeine magische Formel habe ich auch nicht. Aber ich glaube, vernünftige Darlegung von Zahlen, von Dependenzen, warum das so ist, und versuchen immer noch technische Themen ins nicht-technische zu besetzen. Ich glaube, das kann enorm helfen. Weil das ist, ich glaube, das, woran ich ziemlich gut war und bin, eben diese Translation zu schaffen zwischen technischer und nicht-technischer Seite.

13:36 Und das hat bis jetzt immer funktioniert. Natürlich musste man irgendwo kürzer machen, irgendwo sagen, okay, das können wir uns wirklich nicht erlauben. Wenn wir das machen, dann in zwei Monaten können wir gar nichts mehr machen. Aber im Großen und Ganzen kann wie immer auf gemeinsamen Nenner.

13:58 Jetzt ist natürlich nicht jeder CTO hat einen Private Equity Investor. Kannst du irgendwie zwei, drei Sätze dazu sagen, wie die Zusammenarbeit mit dem Investor abläuft? Heißt, hast du regelmäßigen Austausch mit den Investoren gehabt? Hast du einen Peer auf Seite der Investoren, der auch für dich als CTO dedicated war und der ein permanenter Ansprechpartner wäre und dir auch Erwartungen gesetzt hat, Guidance gegeben hat?

14:24 Oder hat man das weitestgehend laufen lassen?

14:27 Ja, also Private Equity vorneweg, ich würde mal sagen, das ist eine der schwierigsten Finanzierungsformen, die man sich vorstellen kann. Warum? Weil das ist eine Firma, die Kapital von irgendeiner Person XY verwaltet und ist natürlich daran interessiert, das investierte Geld nicht nur zu verdoppeln, für Zehnfachen und nach einem gewissen Zeitpunkt das Unternehmen zu Transformationen zu führen.

14:57 Also so vorneweg. Und jetzt einer der wichtigen Punkte, selbstverständlich, also natürlich ein Revenue-Wachstum und ein ABTA, was am Ende rauskommt. Also wie ist das Unternehmen profitabel, wie kann sich Unternehmen das selbst finanzieren? Und das führt natürlich dazu, dass man sehr tief in allen Geschäftsprozessen involviert ist.

15:24 Dass man immer darauf schaut, okay, wer wann, welche Entscheidung getroffen wurde, ob es strategisch in die richtige Richtung geht. Und in dieser Zusammenarbeit haben wir regelmäßige Monthleys, wo wir uns dann für vier, fünf Stunden treffen. Quartalweise haben wir längere Meetings, wo es dann wirklich um Strategie und Entwicklung geht.

15:46 Ich muss ehrlich sagen, da hatte ich tatsächlich kein Country Part auf der anderen Seite, der mich permanent gechallengedt hat, sondern ich habe diesen Luxus in dem Fall, wo ich dann Entscheidungen treffen kann, begründen kann und man mir vertraut einfach. Und das ist natürlich ein bisschen für mich angenehmer.

16:09 Du hast einen im Zuge der Umstellungen, die du gemacht hast, hast du auch einen Engineering-Team-Lead geholt, gerade um mir das Thema Qualität und Zusammenarbeit im Team im Alltag zu stärken. Nach was hast du genau gesucht? Warum hast du den mit an Bord geholt? Was hat sich dadurch konkret verändert?

16:28 Also für mich ist es in erster Linie nicht, dass ich jemanden habe, der anstatt mich, instead of me in the Meeting sitzt, sondern da ging es eh darum, eine gewisse Zwischenstufe zu sein zwischen Ingenieur und mir, damit man gewisse Verantwortungsbereich übernehmen kann. Also und gemessen an der Firmengröße musste das auch eine Person sein, die nah am Code ist und parallel kann auch gut Businessanforderungen, technische Anforderungen übersetzen, mit gewisse Massen, gewissermaßen Verständnis haben, was macht jetzt Sinn, zum Beispiel selber zu bauen, was macht jetzt Sinn, jetzt zu kaufen oder wenn wir selbst bauen, also was soll das denn für eine Architektur sein?

17:23 Also für mich war es wichtig, also mich aus dieser CTO-Bottleneck-Rolle rauszuarbeiten und gewisse Entscheidungsstrukturen aufzusetzen, wo man sagt, okay, diese Entscheidung könnt ihr selbst treffen, also zum Beispiel, wie diese Feature architektonisch aussehen muss. Überlegt euch mal, präsentiert euch Entscheidung, am Ende können wir es besprechen.

17:53 Wie zum Beispiel man sauberem Systemdesign aufbaut, wie die Ingenieure entwickeln, das gehört auch zu dir. Wir kommunizieren aber auf dem Level, okay, welche strategischen Entwicklung und technologischen Entwicklung wäre sinnvoll für das Unternehmen und das gebe ich als CTO vor. Also zusammengefasst war das auf einer Seite mehr Support für Ingenieure und auf der anderen Seite CTO als Bottleneck zu eliminieren.

18:30 Wie lange hast du gebraucht, um festzustellen, dass du ein Engineering-Teamlead brauchst, um genau das zu tun? Um genau diese Flughöhe auch zu kriegen, dass du das nicht alles selber machen musst und nicht das Bottleneck bist?

18:42 Das war vier bis fünf Monaten. Das war tatsächlich ein harter Weg.

18:47 Das kann ich mir vorstellen. Und welche Entscheidungen konnte das Team danach dann selbst treffen? Oder wie viele von Entscheidungsmöglichkeiten hast du an den Teamlead und an das Team delegieren können? Wo lagen da die Grenzen?

19:03 Also wir haben, also erstens, warum habe ich so lange gebraucht? Ich habe so lange gebraucht, weil unser System haben wir immer weiter, wir sind weiter und weiter gewachsen. Es kamen mehr und mehr dazu, mehr Features, mehr Überblick und so weiter, und das war auf einmal klar, okay, ich kann nicht mehr mit Kopf und Handzone da bleiben.

19:23 Und da haben wir eine Lösung gefunden, in dem wir ein Official Engineering Playbook entwickelt haben, wo genau alles definiert wurde. Systemdesign, PR-Prozessen, CICD-Pipelines, Testing, Architektur Decision auf diesem, diesen Level, auf Produkte bezogen und so weiter. Also das ist so, ich würde mal sagen, low- bis middle level technische Entscheidungen, die dann tatsächlich vom Team bzw.

19:52 Teamlied dann selbstständig getroffen werden.

19:54 Und du musstest ja dann irgendwann anfangen, das Team auf eine Due Diligence vorzubereiten. Wie bereitest du denn das Team, also Thema Technik, Organisation, auf so etwas vor, vor allen Dingen dann, wenn noch gar nicht feststeht, so wer prüft denn da überhaupt oder welche Interessen hat denn ein Einkäufer?

20:17 Ist das dann, hat das Einfluss darauf, wie du so etwas vorbereitest oder machst du das agnostisch davon?

20:23 Ja, das ist auch eine sehr gute Frage, weil ich bin der Meinung, also Vorbereitung auf technische Dutiligence ist auch nicht so was, okay, ich bin jetzt aufgestanden, jetzt möchte ich mal so ein perfektes System, perfekte Code haben und jetzt arbeiten wir darauf hin. Selbstverständlich ist das überhaupt nicht möglich.

20:48 Und außerdem, bei uns ist es klar, dass zu einem gewissen Punkt eine Transaktion kommen wird, aber wann sie kommen wird, ist es unklar. Deswegen, jeder Prozess, jede Struktur abend darauf hin, dass es jederzeit technische Due Diligence möglich wäre.

21:04 Ach, das heißt, du musstest so ab dem Moment, in dem du reingekommen bist, eigentlich direkt schon für eine Due Diligence vorbereiten?

21:11 Mir war das klar, mir wurde auch gesagt, dass das Ziel kurzfristig, langfristig, mittelfristig, you name it, also wird es sein, dass es kommen wird. Also, und das ist auch kein Geheimnis. Also, wenn du oder deine Teammates oder du weißt das selber besser als ich, also wenn du in so einer Firma in Private Equity arbeitet, dann ist es klar, dass es irgendwann kommen wird, fünf, sechs Jahre und ist das abgeschlossen.

21:36 Und deswegen, also das System so aufzubauen, dass wir nicht da vor zwei oder drei Monaten for Potential Technical Diligence hier durch die Gegend trennen mit großen Augen und denken, okay, wo sollen wir jetzt anfangen? Sollten wir jetzt das complete System umzuschreiben, that's natürlich no go. Deswegen, von Anfang an war das Thema Deswegen kommt dieser große Block wie Dokumentation, egal was, technische Schulden oder architektonischer Aufbau, Entscheidungen ADS und so weiter, ist ein großes, großes Thema.

22:14 Weil ich gebe dir vollkommen recht, man weiß nie, wer dich kauft. Also wenn ich von meinen Kollegen höre, die schon Startups zum Exit geführt haben, dann plötzlich irgendein Immobilienunternehmen kauft eine Security-Firma. Also in welchen Zusammenhang? Okay, sie kam plötzlich auf die Idee, das zu machen.

22:32 Aber darf ich dich auch in Gegenfrage stellen? Also wenn du so viele Due Diligence hatte, hattest du schon in deinen Erfahrungen bei Due Diligence so richtig eine perfekte Technologie, Struktur und Prozesse gesehen?

22:46 Nein. Nein. Und das muss auch gar nicht sein. Also ich glaube, das ist ja, deswegen, ich glaube, die Frage, ob das jetzt so wichtig ist, wer der Käufer ist, die ist aus der technischen Sicht vielleicht gar nicht so wichtig, weil du, du musst natürlich dafür verantworten, die Technologie, die zur Verfügung steht.

23:06 Und du musst dem Investor zeigen, dass sie zukunftsfähig ist, dass sie, also er muss einen realistischen und ehrlichen Einblick in die Technologie bekommen und das Gefühl haben, dass nichts verheimlicht wird. Und du darfst ruhig auch Leichen im Keller haben, um das mal so zu formulieren, wenn du es transparent machst und wenn du auch erklärst, wo kommt das her und warum ist das da und was ist der Plan, um das loszuwerden.

23:33 Also ich glaube, ein Investor, der auf eine nach außen hin perfekte Technologie-Landscape schaut, also ich als Investor wäre vorsichtig, weil irgendwas ist da nicht in Ordnung. Das wäre sehr ungewöhnlich, eine Software as a Service oder Product Company, in der es keine technischen Schulden gibt, in der es keine falschen Entscheidungen aus der Vergangenheit gibt, die man lieber gerne rückgängig gemacht hätte.

23:58 Von daher glaube ich, dass das gibt es das einfach nicht.

24:02 Genau ist das mein Prinzip, wo ich dann schon seit dem Einstieg darauf hinarbeite. Also wir müssen einfach Risiken transparent machen, damit der potenzielle Käufer, also falls es welche Risiken gibt, oder aber sie gibt dann natürlich, genauso wie Unfreiheiten oder technische Schulden, transparent zu machen und die zu zeigen, dass diese Risiken beherrschbar sind.

24:28 Also dass man gewisse Investitionen, Schub oder nächsten technologischer Schritt oder die XY-Entscheidung, können wir diese Risiken loswerden. Also, das ist genauso mein Prinzip, was ich da verfolgt habe.

24:48 Vielleicht noch ein kurzer Einschub von mir, auch weil das jetzt schon über zehn Jahre her ist, zu dem Zeitpunkt, als damals Tipico von den privaten Eigentümern an Private Equity auch verkauft wurde und da Due Diligence-Prozesse durchgemacht wurden, da stand damals auch die ehrliche Frage im Raum, ist die Software, auf der Typico läuft, End of life?

25:08 Oder very close to end of life? Und diese Frage musste man sich stellen und das konnte man auch nicht verheimlichen, man konnte nicht verheimlichen, wie viele Incidences es in Produktion damals gab und man musste aber zeigen, wie geht man damit um, wie hat man einen Umbau geplant, wie soll der ablaufen?

25:23 Und das muss dann im Nachhinein oder muss das im gleichen Prozess, muss das dann gegenübergestellt werden, gegenüber dem Risiko und den Opportunitäten einer Neuentwicklung. Und letzten Endes hat trotz all der Probleme und Herausforderungen, die Tipico zu dem Zeitpunkt hatte und auch die Software hatte, war man trotzdem in der Lage, einen sinnvollen Weg nach vorne zu zeigen, der dem Investor auch die notwendige Confidence gegeben hat, es weiterzumachen mit der bestehenden Software.

25:52 Obwohl sie wirklich, also diese Frage nach End of Life, war sehr nah dran.

25:59 Und ich kann auch mir gut vorstellen, warum das passiert ist. Also warum Software mit der Frage überhaupt in Frage gestellt wurde. Weil bevor man sich verkauft, man möchte natürlich ein bisschen an EBTA polieren. Man möchte keine großen Investitionen machen, damit das gut aussieht, damit man gutes Geschäft macht.

26:22 Natürlich vermeidet man jetzt, okay, lass man jetzt komplette Datenbank, Cloud, Upgrades machen, damit es gut ist. Das ist ein Spiel, wo man am Ende muss das für alle Sinn machen und gewisse Balance haben.

26:45 Welche Schwachstellen würdest du denn auf jeden Fall vor so einer Due Diligence noch beheben? Und gibt es auch welche, die du ganz bewusst offen lassen würdest?

26:56 Also die Schwachstellen, ich habe am gewissen Punkt gesagt, dass ich nie wieder ohne Terraform in irgendeinem Projekt, irgendein Unternehmen arbeiten werde. Also Infrastructure as a Code ist für mich wirklich auch und o. Und du kannst dir nicht vorstellen, wie viele Firmen ich gesehen habe, wo dass man immer noch so irgendwas zusammenklickt in irgendeinem Cloud, wo man dann am Ende kein Ende findet.

27:23 Und wenn ich diese Button klicke, was passiert? Ja, keine Ahnung. Und wir haben tatsächlich am Anfang unter großem Zeitdruck gearbeitet und da haben wir ein paar Stellen, wo ich sage, die waren ohne Infrastructure Scott entwickelt, dann haben wir schnell das alles aufgeholt mit allen Projekten. Also wir haben neben noch 10%, wo wir das abdecken müssen.

27:48 Das muss unbedingt da sein. Die komplette Architektur muss dann finalisiert werden. Was ich aber, ja, also jetzt muss ich überlegen, wie würde ich jetzt sprechen, wie eine Geschäftsfrau oder CTO. Also, das ist in mir sind zwei Seiten, also Business oder Technology. Ich würde selbstverständlich sagen, also wenn meine Pakete oder meine Erweiterungen noch vier, fünf Jahre auf dem Markt ohne große Security Vulnerabilities laufen würden, dann würde ich auch keine großen Updates vornehmen.

28:29 Weil würde ich, in dem Fall würde ich sagen, okay, ich investiere jetzt in Features und das System werde ich mit Security Vulnerabilities Patch am Laufen halten. Also das wäre für mich eine gesunde Balance zwischen Großinvestitionen und nicht. Und ich bin der Meinung, dass es auch transparent und gut einschätzbar ist aus der Sicht der potenziellen Käufer.

28:55 Ja, sprechen wir mal über eure Systemlandschaft. Die wurde bei euch rund um Shopify aufgebaut, wenn ich da richtig informiert bin. Und ihr habt eine Landschaft aus eigenen und aus externen Systemen entstanden. Vielleicht kannst du uns mal konkret mitnehmen. Was habt ihr denn mit dieser Plattform gemacht?

29:14 Was musst du da raus? Welche neue Komplexität habt ihr euch damit eingehandelt? Kannst du uns dazu was sagen?

29:21 Ja, also ich bin ein großer Fan von Not-Invented Heath Syndrome zu beheben. Ich muss das nicht erklären. Ich glaube, unsere Zuhörerinnen und Zuhörer wissen, worum es geht.

29:36 Ich denke schon.

29:37 Und Shopify, das war tatsächlich so eine gewisse ausgewogene Entscheidung für diese Company, für diese Größe, so ein Tool zu nehmen. Das Problem war, dass the ganze Company an diesem Tool gearbeitet hat anders da reinzupatchen. Also auch Bereiche, die überhaupt nicht zu E-Commerce gehören, wie zum Beispiel Data-Auswertung, Operations-Thema, irgendwelche Business Logiken, 100 Apps, offener Code, where jeder irgendwas reinschreiben konnte.

30:14 Und deswegen, also when man so an classic clean architecture denkt, by Robin Martin, Uncle Bob, Core muss immer simple sein. And so betrachte ich hier the E-Commerce System. What macht eigentlich Shopify? Wozu ist Shopify eigentlich da? Damit die Leute auf die Seite kommen und eine Transaktion machen.

30:40 Also im Prinzip kaufen sein Geld und bekommen das. Und alles andere muss natürlich von anderen Systemen und Satelliten gemacht werden. Sonst haben wir einen Mix von Coupling, man versteht nicht, was wohin passiert. Deswegen, step by step haben wir versucht, diese Systeme auseinanderzutrennen. Entweder haben wir es selbst nachgebaut oder haben wir fertige Tools gekauft oder Boilerplates geholt, an denen wir dann weitergearbeitet haben.

31:11 So haben wir so ein gesundes System an Core Features und die begleitenden Software drumher.

31:21 Was war technisch da die größte Schwierigkeit bei dieser Art von Transformation oder Migration, keine Ahnung, wie du das nennen möchtest?

31:29 Ich würde ehrlich mal sagen, das stand mir nichts im Weg am Ende des Tages. Also als wir gesagt haben, okay, ich glaube, das Gute dabei bei diesem Projekt war, dass die Leute auch an einem gewissen Punkt selbstverstanden haben, dass die an die Grenze stößen, also Diskalierbarkeit dieser Bereiche, wie zum Beispiel Data.

31:52 Und auch nicht mehr nachvollziehen können, was im System passiert.

31:59 Also waren die Fragen am Ende des Tages, oder war die Herausforderung am Ende des Tages mehr organisatorischer Natur? So, was holen wir raus und wieso, weshalb, warum und was lassen wir da drin oder an weniger technischer Natur?

32:12 Ja, ich würde mal sagen, ja. Also weil technische, ich meine, das ist letztes Jahr war das ein bisschen noch so self-made, heute kann man mit KI ziemlich schnell zu irgendeinem Ergebnis kommen. Aber das war tatsächlich eine technisch saubere Darstellung, was wir da gemacht haben. Also ich meine, es gibt eine Operational-Prozesse, die überhaupt nicht in Shopify sein müssen.

32:46 Die Entscheidung war, okay, lass mal das rausnehmen, weil das, das, das, das, das. Und wie können wir das rausnehmen? Wie schaffen wir diesen Begang? Was passiert, wenn wir Daten nicht mehr vertrauen? Können wir diesen Daten dann vertrauen? Können wir diesen Prozessen dann vertrauen? Ich glaube, das war tatsächlich eher so organisatorisch.

33:05 Ja, und das Thema Daten hast du jetzt auch schon ein, zweimal angesprochen. Und im Vorgespräch ging es auch darum, eigene eigene Vorhersagemodelle. Was macht ihr denn jetzt aktuell mit euren Daten? Welche geschäftlichen Entscheidungen sollen damit besser werden und wie weit seid ihr ganz aktuell damit?

33:24 Also, ich sage immer, wir sind E-Commerce-Unternehmen. Also, was wollen wir am Ende hier reichen? Wir wollen, dass wir Menschen unsere Produkte kaufen und wie mehr Revenue machen. Und natürlich die gesamte Software, Architektur, Datenauswertung geht es nur darum. Um New Customer Acquisition, um Retention, um AOV, um Churnrate von unseren Kunden, um Conversion Rate Optimization?

33:58 Wie weit kommen sie? Wo springen sie ab auf der Webseite? Wie können wir unser Angebot attraktiver machen? Wie positionieren wir uns im Vergleich zu unseren Competitors? Wo sollen wir dann vielleicht mehr Fokus setzen? Soll das B2B-Kanäle sein? Sollen das unsere eigenen Stores Point of Sales sein? Sollen das E-Commerce sein?

34:24 Sollen wir mehr in unsere Mobile App investieren oder sollen wir Webseite so Richtung Weiterentwicklung pushen? Und so weiter und so fort. Und am Ende des Tages alle diese Fragen sind miteinander verbunden. Also wenn ich zum Beispiel sage, okay, wie entwickelt sich dieser Kanal, okay, was soll ich dabei beachten?

34:45 Und am Ende entsteht so ein Knoten von Dependenzen, die man so sauber lösen muss. Und deine Daten können auch anderes dargestellt werden, wenn du zum Beispiel eine Dependenz löst und der andere vergisst. Und dann hast du ganz andere Ergebnisse. Und wie vertraue ich dem das? Und wir sind kein großes Unternehmen, also wir sind kein Zalando oder sowas, aber immer noch, wir machen sehr gute Revenue und gehören zu Führer in dem Markt.

35:16 Deswegen in der ersten Linie versuchen wir, die alltäglichen Fragen mit fertigen Tools zu beantworten. Also die zum Beispiel unsere Customer Acquisition Costs steuert, wie Kampagnen steuert, auf natürlichen Kanälen, Google und so weiter. Wollen wir mehr Deep Dieters schauen, zum Beispiel wie unser Geotargeting aussieht, Inkrimentalität und so weiter, dafür suchen wir natürlich mehr und mehr in diese Richtung, gesammelter Daten und Machine Learning zu schauen.

35:46 Projekt haben wir angestoßen, werden wir aber schauen, wie weit wir da kommen, insbesondere mit heutigen Systemen wie Google Cloud, mit BigQuery, also die fertigen Modelle sind schon da.

35:59 Ja, ich stelle mir auch die Frage, wie viel oder wie wichtig ist eigentlich noch Technik im Rahmen von E-Commerce. Jetzt wirst du natürlich sagen, ja, super wichtig, weil wir müssen das alles mit Technik machen, ja, aber ganz viel von dem, was im E-Commerce-Bereich passiert, ist doch mittlerweile eine Commodity oder siehst du das anders?

36:17 Der Punkt ist, ich habe in sehr vielen E-Commerce-Unternehmen gearbeitet. Ich wollte nie, aber my arbeite ich in e-commerce. Und jeder E-Commerce, ja, von big picture, du hast natürlich, du willst was verkaufen und geld verdienen. Aber jeder e-commerce is a ganz andere Welt anderer Unternehmen. And jeder e-commerce lebt von eigenen Besonderheiten.

36:45 And we are auf Shopify, but I have some people with Shopify auch gearbeitet. Und als sie von, oh mein Gott, ich glaube von Shopify 5 auf Shopify 6 umsteigen wollen, korrigiert mich, wenn ich falsch bin, das ist schon Jahre her. Ich war auf einer Konferenz, wo gesagt wurde, für uns war die große Frage, wie können wir E-Commerce-Prozesse universell machen?

37:08 Wie können wir so ein System bauen, wo Company XY zu uns kommt und muss nirgendwas drumherum mehr bauen? Sie haben versucht, sehr viele Parameter hinzuführen, dies und jenes zu optimieren, aber so wie ich das gehört habe, war das auch nicht die Lösung aller Probleme. Und je mehr man in diese Richtung, okay, individuelle Angebote, mehr schnelle Skalierbarkeit, schnellere Auswertung, schnellere Entscheidungen gehen möchte, desto mehr ist man auf technologische Lösungen angewiesen.

37:44 Und das ist, ich spreche nicht da von Flaconi, Zalando oder andere Firmen, die alles selbst bauen und bei denen da schon so ein Core ist. Ich spreche auch von kleinen Unternehmen. Also 10 Millionen aufwärts.

38:01 Ich glaube, da gehe ich auch mit. Also die Herausforderung liegt ja eher da. Also jetzt jetzt weniger, dass die Technologie, die du brauchst, cutting edge ist und Rocket Science, sondern es geht eher darauf, für das jeweilige Business die richtige Auswahl an Technologien zu finden, um die Prozesse effizient zu unterstützen.

38:19 Und das ist natürlich auch eine große Herausforderung. Erstens mal das Business soweit zu verstehen und dann aber auch die richtigen Technologien zu finden und wie sie miteinander zusammenarbeiten, um zur richtigen Lösung zu kommen.

38:32 Absolut richtig. Also ich weiß nicht, wie oft habe ich schon das Wort heute wiederholt habe, so eine Balance zu finden. Also eine Firma, technologische Entscheidung für die Firma zu finden, die genau für diesen Moment, genau diese Team Structure, genau diese Revenue, genau diese Entwicklungsschub genau passt.

38:52 Und das ist nicht einfach.

38:55 Dafür bist du ja auch da und dafür bist du CTO im Unternehmen. Aber du bist nicht nur CTO, sondern du bist jetzt auch wieder Gründerin und hast angefangen, selbst wiederzubauen.

39:06 Ja, das ist, was mich auf einer Seite freut, auf einer Seite auch nicht. Warum? Weil überhaupt dazu kam. Eines Tages zwei gute Freundinnen von mir aus dem HR-Bereich, die in bekannten Bankenunternehmen hier in Berlin arbeiten, haben mich zum Abendessen eingeladen und haben gesagt, wir haben eine Idee, and du musst unsere CTO sein.

39:37 Und das war für mich so ein bisschen überraschend, weil, wie gesagt, also wie jede CTO hatte ich auch so Projekte, dann Beratung oder kleine kurze Projekte, wo man meine Einschätzung benötigt. Diese Projekte sind terminiert. Ich helfe da ein paar Abende, gucke mit drauf und dann ist wieder alles gut.

40:03 Bei so einem Projekt hat man kein Deadline. Dann muss man wirklich in diese Produktechnologie, Investorensuche, Teamaufbau und so weiter wieder einzusteigen und das natürlich in eine volle CTO, neben eine volle CTO-Rolle ziemlich herausfordernd.

40:22 Warum hast du es trotzdem gemacht?

40:24 Weil ich habe verstanden, am gewissen Punkt, dass ich vielleicht nach dem Exit ein bisschen mehr machen möchte als nur CTO. Also, weil ich habe schon diese CTO-Rolle erreicht. Und ich kann mir gut vorstellen, so ein Gefühl hattest du auch irgendwann. Also dass man irgendwie auch, man hat die ganze Karriere darauf hingearbeitet, CTO zu werden und nach der CTO-Rolle versteht man, okay, es wäre der nächste Schritt, was wäre der nächste logische Schritt für mich.

40:56 Und das habe ich trotzdem gemacht und das reizt mich, vor allem, dass es ein Feld ist, wo wir ein Problem lösen, was wirklich nicht so trivial ist. Und es ist kein E-Commerce. Es geht um early talent hiring. Da versuchen wir Studenten anders to helfen, ihren Weg zu finden in Beruf. Was heute ziemlich schwierig ist.

41:26 Weil heute CVs, KI-Agenten, die CVs erstellen, gegen KI agents, die CVs auswert. And we won't these knot losing, in which we soon platform bowl, in which we young leuten helfen, cares to find, and then miten rich firms in verbindung zu setzen. So the firm heißt Stach, joinstack.com. Also wenn jemand Interesse kann, dann drauf schauen.

41:52 We are just in vielen Projekten and bearbeiten das. Und zweiter Punkt, also neben diesem Interesse, was Neues und Schönes zu bauen, was nach CTO kommen wird, das waren die Leute, mit denen ich gerne zusammenarbeiten wollte und zusammen was gründen wollte. Was wichtig zu merken ist, wir haben ziemlich schnell Teams aufgebaut von Menschen, die genauso nebenbei arbeiten fulltime, aber waren von der Idee so begeistert.

42:22 Wir haben jetzt Dataanalyst, wir haben Software Engineer, wir haben Support in Marketing, wir haben Support bei HR-Tem, ich habe viele Leute gefragt, die uns auch unterstützen wollen, auch aus Universitäten. Das war spannend. Und wir haben sogar einen Quotenmann, der ist CIS und Hetero. Also das, weil wir sind tatsächlich, wir waren tatsächlich ein Frauenunternehmen.

42:47 Also das war spannend. Ich glaube, das ist auch so nicht so üblich heutzutage.

42:53 Ja, in der Tat. Und du bist auch, das muss ich dir auch noch dazu sagen, die allererste Folge hier des Podcasts, die war mit einer weiblichen CTO. Und du bist seitdem, das ist jetzt, diese Woche ist Folge, kommt Folge 71 raus. Wenn deine Folge veröffentlicht, sind wir so bei Folge, ich keine Ahnung, 73, 74.

43:12 Du bist die zweite Frau erst, die ich dann hier im Podcast drin habe. Das heißt, wir haben hier auf jeden Fall noch einen Überschuss an Männern.

43:20 Es ist bias oder wieso ist das so passiert? Also es gibt auch genug CTOs. Es gibt so viele CTOs, weibliche CTOs.

43:31 Ich muss dazu sagen, ich habe nicht speziell danach gesucht, ich habe es aber auch nicht vermieden. Es war etwas immer davon abhängig, mit wem ich zu welchem Zeitpunkt auch ins Gespräch gekommen bin und wie sich das, wie das auch entwickelt hat. Trotz allem, man muss ja auch dazu sagen, diese Domäne ist schon trotz allem sehr, sehr männerlastig.

43:51 Und das siehst du auch, du bist auch, glaube ich, in CTO-Communities und da siehst du schon, welche, wie groß die Übermacht an Männern im im CTO-Bereich ist.

44:01 Ja, leider, leider ist es immer noch der Fall. Aber ich bin Member of Women's CTO Community. Und ja, so ein bisschen Werbung für die Frauen, die das hören. Wenn ihr weiblich und CTO seid, könnt ihr gerne Mitglied von dieser Community werden. Es ist sehr nett dort, sehr vertraulich. Ja, also das ist schwer, aber immer noch machbar.

44:29 Und wenn ich sagen bias, that is um Gottes Willen nicht ernst gemeint. Ich hirte Leute und Teams schon seit mehreren Jahren. Und mein Traum war immer, dass Frauen in Ingenieurenteams, Data Teams haben und so weiter. Jetzt kannst du mich fragen, wie viele Frauen ich jetzt in meinen aktuellen Teams habe.

44:48 Wie viele Frauen hast du in deinem aktuellen Team? Eine, okay.

44:52 Ich plus eine. Und ich habe sehr viele Frauen interviewt, ja. Und ich habe sehr viel, ich habe mich wirklich sehr, sehr, sehr bemüht.

45:02 Was war denn der Grund, wenn ich das mal fragen darf, was war denn der Grund, warum du dann doch mit so vielen Männern quasi eher Männer eingestellt hast? War das dann ein besseres Skillset? War das ein besseres Mindset? Kannst du das über einen Kamm scheren?

45:17 Also wir fangen damit an, der Anzahl BewerberInnen, wenn du ein, zwei Female Profiles siehst, dann bist du schon glücklich. Also das war schon mathematisch sehr schwer, da passende Person zu finden. Weil wenn du 300 Bewerber hast und zwei Frauen drunter hast, da muss man hoffen, dass einer davon mindestens die Kriterien erfüllt.

45:45 Nein, also das war tatsächlich am Ende des Tages ging um Skills, die wir benötigen, weil wir arbeiten ziemlich in agilen und schnell, startup-mäßigen Bereich, wo man nicht nur unbedingt einige Skills mitnehmen soll. Also es ging nicht darum, okay, wenn ich jetzt zum Beispiel Backend Entwickler bin, dann habe ich Backend Entwickler und ich habe keine Ahnung, was Search Engine Optimization ist oder wie schreibe ich einen sauberen Code, damit Google immer noch das gut interpretiert und versteht.

46:30 Und diese Skillset, die waren am Ende entscheidend. Und aus einer grossen Company, about Youth Salando, you name it, why? Five months have heard Salando gesagt. Das ist das erste, was mir so in minder in solche gross company, das sind eher so die festgelegten Strukturen, in which five years sitzt and machst du ein Backend, and then bist du Profi in that bereich.

46:54 Du kommst in so ein mittelgrößeres Unternehmen, that wird von dir schon ein bisschen mehr verlangt.

47:00 Also ein Blick nach links, nach rechts, ist das schon sinnvoll, heirst du heute, wenn du Entwickler einstellst, also ich rede jetzt wirklich von heute im Jahr, so August, September, Oktober 2026. Heirst du dann immer noch in erster Linie nach Skillset oder guckst du noch viel stärker jetzt auf Mindset?

47:17 In so einer Zeit, in der über Agentic AI viel mehr möglich ist? Oder schaust du deswegen gerade noch viel stärker auf Technik?

47:26 Ja, also für mich bedeutet es auf jeden Fall, Person zu finden, die am nächsten zu dieser End-to-End-Delivery-Standard kommt. Also es bedeutet nicht jetzt, okay, ich schreibe perfekten Code und schicke das in die Welt raus. Nein, es geht darum, ich muss diese Feature verstehen, ich muss das Code Agenten so erklären, dass sie das genauso schreiben, was ich haben möchte.

47:54 Das muss auch testable sein. Ich muss das selbst durchtesten, ich muss dafür auch Verantwortung tragen, wenn am Ende das nicht sauber in Production ausgerollt wird. Und nach dem Release muss ich auch Verantwortung tragen, um zu gucken, okay, ist es jetzt genau das, was wir erreichen wollten, inklusive Daten und so weiter.

48:13 Und egal in welchem Bereich ich jetzt suchen würde oder suche, Data Engineering, Produkt UX, ist es, das betrifft ja alles. Und die Frage ist natürlich, die ich schon seit seit Februar stelle, wie setzt du die KI in deinen Alltag ein? Also das ist, weil ohne, ist es, glaube ich, nicht mehr denkbar.

48:38 Richtig, und das wäre jetzt auch die passende Überleitung gewesen, jetzt auch noch zum Thema AI, noch ein bisschen mehr darüber zu sprechen. Aber die Zeit ist uns auch etwas davon gerannt und wir sind jetzt auch schon fast am Ende der heutigen Aufnahme. Deswegen kommen wir jetzt eigentlich nur noch zu den Rapid-Fire-Fragen.

48:55 Aber weißt du was, du bist ja gerade neu am Gründen, es laufen M ⁇ A-Prozesse, das sind ganz viele Themen, die dann hoffentlich dazu führen, dass du genug zu erzählen hast, um zu einer zweiten Folge nochmal bald wiederzukommen. Und dann können wir auch uns das Thema, das Thema Agentic AI und allem, was dazu gehört, auch nochmal viel ausführlicher widmen.

49:13 Olga, welche CTO-Aufgabe hast du am längsten unterschätzt?

49:18 Ja, das war auf jeden Fall die richtigen Entscheidungsstrukturen aufzubauen. Also zurück kurz zu deiner Frage, Engineering Team Lead, was wäre für Antworten, welche Teams und so weiter. Weil ich bin der Meinung, ich habe lange Zeit dieses Konzept von self-organized team komplett missinterpretiert. Das ist so kurz und prägnant.

49:43 Also baut eure Entscheidungsstrukturen auf, setzt die Engineering Playbooks, das wird euch weiterhelfen.

49:53 Welchen technischen Shortcut würdest du heute nicht mehr nehmen?

49:57 Ja, ich glaube, ich habe das schon kurz angesprochen, das ist auf jeden Fall Infrastructure as a code. Es gibt immer noch, wie gesagt, also es gibt immer noch Unternehmen, die auch super klar ohne kommen. Also ist es für mich ein Geheimnis.

50:11 Ja, aber die Frage war ja, welche Abkürzung würdest du heute nicht mehr nehmen?

50:16 Also ich würde nicht irgendwas ohne Terraform or you name it, irgendein anderes Tool irgendwas provisionen.

50:29 Welche Frage stellst du, bevor du einer Kennzahl vertraust?

50:33 Naja, für mich sind das, ich frage mich, woher kommt diese Zahl? Also ich muss mir ganz genau die ETL-Prozesse anschauen und zu verstehen, also welche Zahl, welche Frage dahinter steht und diese Zahl genau diese Frage beantwortet. Und das kommt natürlich aus der Quelle. Was wurde definiert, wie wurde das transformiert, wie wurde das dargestellt.

50:58 Also durch den gesamten Prozess muss ich auf jeden Fall durchschauen.

51:02 Und welcher Rat hat deine Art zu führen verändert?

51:05 Ja, dass ich delegieren muss, das war immer klar. Aber ich hatte immer Angst zu delegieren manchen Menschen, weil ich manchmal nicht Vertrauen hatte. Und mir wurde gesagt, Delegiere ist und vertraue. Und lass den Menschen selbst diese Probleme lösen. Das Unternehmen kann das aushalten. Du musst aber dann irgendwann Entscheidung treffen, wenn immer noch irgendwas nicht funktioniert.

51:34 Hat das immer so geklappt?

51:35 Was denkst du?

51:36 Natürlich nicht. Dann ist ja die zweite Frage, wenn wir es auch noch Zeit hätten, wenn die zweite Frage dann zu sagen, ja, okay, wie hast du es denn dann gelöst? Es ist ja einfach zu, also es ist relativ einfach zu sagen, ja, jetzt ich versuche halt Entscheidungen abzugeben und zu delegieren und zu vertrauen.

51:56 Ja, aber die andere Seite muss ja auch in der Lage sein, die Verantwortung zu übernehmen und zu wissen, was sie denn damit tut. Und das klappt auch nicht immer out of the box. Das ist leider so.

52:06 Ja, ja, aber für irgendwas kriegt man Gehalt, sage ich immer, ja. Also und wenn das eben nicht immer wieder funktioniert, dann muss man die Frage stellen, ob das das richtige Match ist zwischen Company und die Verantwortlichen.

52:24 Das ist richtig. Das ist richtig. Letzte Frage für heute, Olga. Was sollten angehende CTOs früher selbst ausprobieren?

52:33 Mein Gott. Da habe ich sofort mehrere Witze in meinem Kopf, müssen aber jetzt ernst bleiben aus Zeitgründen. Also auf jeden Fall, der eingehende CTO muss versuchen, ein komplettes System nicht nur selbstständig bauen, sondern auch sie verantworten. In irgendeinem, vielleicht erstmal in einem kleinen Kontext.

52:55 Also anfangen, Entscheidungen zu treffen, zu deployen, Risiken minimieren, Business Impact zu estimaten, die Return of Investment zu berechnen, Post-Deployman-Risiken zu managen, das zu pitchen anschließen, das zu validieren. Also wirklich ein kleines Projekt oder ein größtes Projekt ist auch kein Problem, wenn die Company das erlaubt.

53:26 Wirklich ein End-to-End zu begleiten mit allen Pros und Contras. Ich glaube, das gibt tatsächlich so einen guten Push für den nächsten Schritt.

53:37 Sehr schön. Und sehr schönes Schlusswort. Olga, vielen lieben Dank. Ich habe heute wieder eine Menge gelernt. Erstens mal über deinen Werdegang. Natürlich auch nochmal ein bisschen was über E-Commerce und eine Due Diligence in E-Commerce. Und tatsächlich auch gelernt, dass ich wahrscheinlich in der falschen Stelle nachgeschaut habe, wenn ich potenziell nach weiblichen CTOs gesucht habe.

53:56 Aber du wirst mir hoffentlich weiterhelfen können und zu mehr guten Gästen helfen können an der Stelle. Deswegen schon mal vielen lieben Dank und dir auch weiterhin viel Erfolg mit deinem neuen Startup und mit Barfas.

54:08 Sehr gerne und vielen lieben Dank und bis vielleicht zu Folge zwei.

54:13 Bis zur Folge zwei. Mach's gut, Olga. Ciao, ciao.

54:15 Danke, ciao.