# Preparing Tech Orgs for PE Due Diligence

**Podcast:** Becoming CTO Secrets
**Published:** 2026-10-27

## Transcript

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.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO-Community.
Heute ist Olga Korkova 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.
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.
Dankeschön für die Einladung, Philipp.
Ich bin froh, in diesem Podcast heute teilzunehmen und meine Geschichte zu erzählen.
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?
technische und unternehmerische Verantwortung zu übernehmen, zu tragen?
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, Moment oder Projekt 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 meine vorherige Rolle als Head of IT in einer anderen Firma, habe ich angefangen, diese Rolle langsam reinzuwachsen, wo ich gemerkt habe, okay, also ich beziehe mich nicht nur auf perfekter Code, von mir wird ein bisschen mehr verlangt.
Es 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.
Du hast dich dann schon als CTO gefühlt, bevor du CTO warst?
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 eher drauf, okay, die Person führt schon diese Rolle aus und was eigentlich fehlt, noch diesen nächsten Schritt, diesen Titel dran zu hängen, weil Und 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.
Der Podcast heißt ja auch Becoming CTO Secrets.
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?
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.
Das war der eine, das tatsächlich meine Aufmerksamkeit erregt hat.
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.
Ich möchte jetzt ein Restaurant aufmachen, aber ich möchte nichts kochen.
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 nicht so, dass ich bestimmte Connections hatte oder sich danach gesucht habe.
Du bist ja jetzt aber dann nicht gleich in der CTO-Rolle eingestiegen, sondern du warst zuerst Chief Digital Officer.
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, dass es Nichts Besonderes auf dem heutigen Markt.
Also ich habe schon sehr viele mittelständische Unternehmen gesehen, die gleichen Whitespots haben.
Und zuerst hieß es, okay, wir müssen jetzt mehr Digitalisierungsprozesse reinholen, bevor wir hier anfangen, global umstrukturieren.
Da war ich in der Rolle ein paar Monate, wo es dann klar wurde, okay, die Aufgabenbereiche, die ich dann mehr und mehr übernehmen muss, sind nicht nur pure Digitalisierung, das ist schon technologische und Produktverantwortung.
Vielleicht kannst du noch ein, zwei Sätze dazu sagen, was Barfas genau macht, um besser zu verstehen zu können, was du als CTO im Unternehmen leisten musstest.
Erst im Bereich digitale Transformation und später dann in der Rolle als CTO.
Ja.
Barfas, das ist, wir feiern dieses Jahr 15 Jahre.
Das ist ein Berliner Unternehmen.
Wir produzieren tatsächlich Hunde- und Katzenfutter.
Das ist ein Barf, das biologische allgerechte Rohfütterung.
Wir kaufen selbst, wir produzieren selbst alles in Berlin.
Wir haben Point of Sales, wir haben...
breite B2B-Strukturen.
Wir verkaufen aber und machen größte Prozent von unseren Umsatzes über Online-Kanäle.
Sei es über Web-Version, Mobile-Version, parallel verbessern wir unsere Strukturen für bessere LLM-Crawling.
Und wie bei jedem Unternehmen, der kontinuierlich weiter wächst, also aus einer kleinen Struktur, wird eine größere und größere Struktur, also auch im E-Commerce.
Dementsprechend bilden sich die Teams, die an mich reporten.
Das sind Ingenieure, das sind Netzwerke, Systemadministration, die unbedingt immer vor Ort sein müssen.
Das sind Data Engineering and Analytics, Produkte und UX in Customer Support.
der wir jetzt digitalisiert haben.
Du hast im Vorgespräch auch beschrieben, dass du bei deinem Einstieg erst Grundlage schaffen musstest.
An welcher Stelle oder in welcher konkreten Situation wurde dir denn klar, was zuerst passieren muss?
Sehr gute Frage, weil wenn man auf einmal in so ein Unternehmen kommt, das war bei mir vor zwei Jahren, 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.
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.
Als nächster kam dann Engineering-Bereich, dann Produkte und 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.
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.
Du musstest 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, was hast du liegen gelassen und wie hast du das kommuniziert?
Also in dieser CTO-Rolle, aber ich glaube in jeder CTO-Rolle, geht es sehr oft darum, bewusst viele Dinge liegen zu lassen.
Obwohl man weiß, das gibt es und das ist schwer.
genauso viele Dinge nicht zu sagen oder im Gegenteil sagen.
Wo ist diese Balance?
Ja klar, wir arbeiten unter diesen sehr höheren Erwartungen von unseren Investoren und es ist klar, dass ein bestimmter Punkt der Skalierbarkeit können wir einfach ohne technische Schulden nicht.
weiter uns entwickeln.
Und für mich bedeutet das, okay, was sind dann technische Schulden?
Wo ist diese rote Grenze, wo wir jetzt sagen, okay, das geht nicht mehr.
Meine Entscheidung war, die Schulden, die technischen Schulden, die bei uns stehen, müssen sehr gut dokumentiert werden und sichtbar sein.
was uns zum Beispiel KI heute sehr dabei hilft.
Solange wir wissen, okay, es gibt diese, diese und diese Schwachstelle und das 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.
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 ADRs und diese kleinen Probleme, die man später lösen kann, wieder anzugehen.
Ich stelle immer wieder fest, dass gerade CTOs ganz besonders unter der Investorenerwartungen, ich weiß nicht, leiden ist das richtige Wort, aber zumindest mal Schwierigkeiten haben, Prioritäten zu setzen.
Wie hast du das denn gemanagt?
Ein Investor will vielleicht eher kurzfristige Geschäftsergebnisse sehen.
Du als CTO musst natürlich auch auf langfristige Qualität und Technik 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?
Ja, ich glaube, das ist nicht nur von Investoren so getrieben, weil insbesondere bei Private Equity jeder Department, jede Abteilung, die businessrelevante Entscheidungen trifft, ist unter dem Radar.
Da bin ich immer in gewisser Abhängigkeit zu.
Zu Marketing, zu Finance, zu Operations.
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 geben wir gar kein Geld aus und bleiben so, wie es schon immer war.
Der andere Kollege versteht überhaupt nicht, worum es geht.
Ich bin teilweise glücklich, dass ich es bis jetzt immer geschafft habe, in vernünftiger Weise Investoren zu erklären, warum eine Entscheidung so lange dauern wird oder warum das so viel Geld kosten wird.
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, das 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.
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 kamen wir immer auf gemeinsame Länder.
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 als der ein permanenter Ansprechpartner wäre und dir auch Erwartungen gesetzt hat, Guidance gegeben hat oder hat man das weitestgehend laufen lassen?
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 gewissem Zeitpunkt das Unternehmen zur Transformation zu führen.
Also so im Vorneweg.
Einer der wichtigen Punkte selbstverständlich, also natürlich ein Revenue-Wachstum und EBITDA, was am Ende rauskommt.
Also wie ist das Unternehmen profitabel, wie kann sich das Unternehmen selbst finanzieren.
Und das führt natürlich dazu, dass man sehr tief in allen Geschäftsprozessen involviert ist.
Dass man immer darauf schaut, wer, wann, welche Entscheidung getroffen wurde, ob es strategisch in die richtige Richtung geht.
Und in dieser Zusammenarbeit haben wir regelmäßige Monthly, wo wir uns dann für vier, fünf Stunden treffen.
Quartalweise haben wir längere Meetings, wo dann wirklich um Strategie und Entwicklung geht.
Ich muss ehrlich sagen, da hatte ich tatsächlich kein...
Country-Part auf der anderen Seite, der mich permanent gechallengt 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 natürlich macht es ein bisschen für mich angenehmer.
Du hast im Zuge der Umstellungen, die du gemacht hast, hast du auch ein Engineering-Team-Lied 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?
Also für mich ist es in erster Linie nicht, dass ich jemanden habe, der anstatt mich, instead of me, in dem Meeting sitzt, sondern da ging es eher darum, eine gewisse Zwischenstufe zu sein zwischen dem Ingenieur und mir, damit man gewisse Verantwortungsbereiche übernehmen kann.
Und gemessen an der Firmengröße musste das auch eine Person sein, die nah am Code ist und parallel kann auch gut Business-Anforderungen, technische Anforderungen übersetzen, mit gewissen Massen Verständnis haben.
Was macht jetzt Sinn, zum Beispiel selber zu bauen?
Was macht es Sinn, jetzt zu kaufen?
Oder wenn wir selbst bauen, also was soll das denn für eine Architektur sein?
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önnte...
selbst treffen, also zum Beispiel wie diese Feature architektonisch aussehen muss.
Überlegt euch mal, präsentiert eure Entscheidung, am Ende können wir es besprechen.
Wie zum Beispiel man saubere Systemdesign aufbaut, wie die Ingenieure entwickeln, das gehört auch zu dir.
Wir kommunizieren aber.
auf dem Level, welche strategische Entwicklung und technologische 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.
Wie lange hast du gebraucht, um festzustellen, dass du einen Engineering-Team-Lead 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?
Das war vier bis fünf Monate.
Das war tatsächlich ein harter Weg.
Das kann ich mir vorstellen.
Welche Entscheidungen konnte das Team danach dann selbst treffen?
Entscheidungsmöglichkeiten hast du an den Team Lead und an das Team delegieren können?
Wo lagen da die Grenzen?
Also wir haben, also erstens, warum habe ich so lange gebraucht?
Ich habe so lange gebraucht, weil unsere Systeme sind immer weiter und weiter gewachsen.
Es kam 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 Hänse und da bleiben.
Und da haben wir eine Lösung gefunden, indem wir ein Official Engineering Playbook entwickelt haben, wo genau alles definiert wurde.
Systemdesign, PR-Prozessen, CICD-Pipelines, Testing, Architektur-Decision auf diesem 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 beziehungsweise Teamlead dann selbstständig getroffen werden.
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, wer prüft denn da überhaupt?
Oder welche Interessen hat denn ein Einkäufer?
Hat das Einfluss darauf, wie du so etwas vorbereitest?
Oder machst du das agnostisch davon?
Ja, das ist auch eine sehr gute Frage, weil ich bin der Meinung, also Vorbereitung auf technische Digitalisances ist auch nicht so, okay, ich bin jetzt aufgestanden, jetzt möchte ich mal so perfekte Systeme, perfekte Code haben und jetzt arbeiten wir darauf hin.
Selbstverständlich ist das überhaupt nicht möglich.
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 haben wir darauf hin, dass es jederzeit technische Due Diligence möglich wäre.
Ach, das heißt, du musstest so ab dem Moment, in dem du reingekommen bist, eigentlich direkt schon für eine Due Diligence vorbereiten?
Mir war das klar.
Mir wurde auch gesagt, dass das Ziel kurzfristig, langfristig, mittelfristig, you name it.
wird es sein, dass es kommen wird.
Und das ist auch kein Geheimnis.
Also wenn du oder deine Teammates oder du weißt ja selber besser als ich, also wenn du in so einer Firma im Private Equity arbeitest, dann ist dir klar, dass irgendwann kommen wird, fünf, sechs Jahre und ist das abgeschlossen.
Deswegen, also System so aufzubauen, dass wir nicht da vor zwei oder drei Monaten vor Potential Technique Intelligence hier durch die Gegend rennen mit großen Augen und denken, okay, wo sollen wir jetzt anfangen?
Sollte wir jetzt komplett das System umzuschreiben?
Das ist natürlich No-Go.
Deswegen, von Anfang an war das Thema, deswegen kommt diese große...
Großer Block wie Dokumentation, egal was, technische Schulden oder architektonischer Aufbau, Entscheidungen, ADRs und so weiter.
Das ist ein großes, großes Thema.
Weil ich gebe dir vollkommen recht, man weiß nie, wer dich kauft.
Also wenn ich von meinen Kollegen höre, die schon Startups zu Exit geführt haben, dann plötzlich irgendein Immobilienunternehmen kauft eine Security-Firma.
Also in welchem Zusammenhang.
kam plötzlich auf die Idee, das zu machen.
Aber darf ich dich auch in Gegenfrage stellen?
Ja klar, natürlich.
Weil du so viele Due Diligence hattest.
Hattest du schon in deinen Erfahrungen bei Due Diligence so richtig eine perfekte Technologie, Struktur und Prozesse gesehen?
Nein.
Nein, und das muss auch gar nicht sein.
Also 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 musst natürlich da verantworten, die Technologie, die zur Verfügung steht und du musst dem Investor zeigen, dass sie zukunftsfähig ist.
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.
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.
Von daher glaube ich, dass das, ja, gibt es das einfach nicht.
Genau ist das mein Prinzip, wo ich dann schon seit dem Einstieg daraufhin arbeite.
Also wir müssen einfach Risiken transparent machen, damit der potenzielle Käufer, also falls es welche Risiken gibt, aber sie gibt dann natürlich, genauso wie Unfeilheiten oder technische Schulden, transparent zu machen.
zu zeigen, dass diese Risiken beherrschbar sind.
Also dass man gewisse Investitionen schub oder nächster technologischer Schritt oder diese XY-Entscheidung kann, können wir diese Risiken loswerden.
Also das ist genau so mein Prinzip, was ich da verfolgt habe.
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 der Due Diligence Prozesse durchgemacht wurden.
Da stand damals auch die ehrliche Frage im Raum, ist die Software, auf der Tipico läuft, end of life 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 Inzidenzen 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?
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.
Obwohl sie wirklich, also diese Frage nach End of Life, die war sehr nah dran.
Und ich kann auch mir gut vorstellen, warum das passiert ist.
Also warum Software mit der Frage, also überhaupt in Frage gestellt wurde, weil bevor man sich verkauft, man möchte natürlich ein bisschen EBITDA polieren.
Man möchte keine großen Investitionen machen, damit das gut aussieht, damit man ein gutes Geschäft macht.
Natürlich vermeidet man jetzt, okay, lass mal jetzt komplette Datenbank, Cloud, Upgrades machen, damit es gut ist.
Also das ist ein Spiel.
Am Ende muss das für alle Sinn machen und gewisse Balance haben.
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?
Also die Schwachstellen, ich habe am gewissen Punkt gesagt, dass ich nie wieder ohne Terraform.
in irgendeinem Projekt, in irgendeinem Unternehmen arbeiten werde.
Also Infrastructure as a Code ist für mich wirklich A und O.
Und du kannst dir nicht vorstellen, wie viele Firmen ich gesehen habe, oder dass man immer noch so irgendwas zusammenklickt in irgendeinem Cloud, wo man dann am Ende kein Ende findet 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 as Code entwickelt, dann haben wir schnell das alles aufgeholt mit allen Projekten.
Also wir haben eben noch 10 Prozent, wo wir das abdecken müssen.
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 und eine CTO.
Also 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-Volvenabilities laufen würden, dann würde ich auch keine großen Updates vornehmen.
weil in dem Fall würde ich sagen, okay, ich investiere jetzt in Features und das System werde ich mit Security-Renabilities-Patch am Laufen halten.
Also das wäre für mich eine gesunde Balance zwischen großen Investitionen und nicht.
Und ich bin der Meinung, dass es auch transparent und gut einschätzbar ist, aus der Sicht der potenziellen Käufer.
Sprechen wir mal über eure...
ü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?
Was musst du da raus?
Welche neue Komplexität habt ihr euch damit eingehandelt?
Kannst du uns dazu was sagen?
Ja, also ich bin großer Fan von Not Invented He-Syndrom zu beheben.
Ich muss das nicht erklären.
Ich glaube, unsere Zuhörerinnen und Zuhörer wissen, worum es geht.
Ich denke schon.
Und Shopify, das war tatsächlich so eine gewisse ausgewogene Entscheidung für diese Company, für diese Größe, so einen Tor zu nehmen.
Das Problem war, dass die ganze Company an diesem Tool gearbeitet hat und hat versucht, alles da reinzupatschen.
Also auch Bereiche, die überhaupt nicht zu E-Commerce gehören, wie zum Beispiel Data-Auswertung, Operational-Thema, irgendwelche Business-Logiken, 100 Apps, offener Code, wo jeder irgendwas reinschreiben konnte.
Deswegen, also wenn man so an klassische Clean Architecture denkt, bei Robin Martin, Uncle Bob, Core muss immer simple sein.
betrachte ich hier das E-Commerce-System.
Was macht eigentlich Shopify?
Wozu ist Shopify eigentlich da?
Damit die Leute auf die Seite kommen und eine Transaktion machen.
Also im Prinzip kaufen, zahlen 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.
Step by step haben wir versucht, diese Systeme auseinanderzutrennen.
Entweder haben wir selbst nachgebaut oder haben wir fertige Tools gekauft oder Boilerplates geholt, an denen wir dann weitergearbeitet haben.
So haben wir so ein gesundes System an Core-Features und die begleitende Software drumherum.
Was war technisch da die größte Schwierigkeit bei dieser Art von Transformation?
Oder Migration, keine Ahnung, wie du das nennen möchtest.
Ich würde ehrlich sagen, da 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 selbst verstanden haben, dass die an die Grenze stößen, also Deskalierbarkeit, diese Bereiche, wie zum Beispiel Data.
Und auch nicht mehr nachvollziehen können, was im System passiert.
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?
Und weniger technischer Natur.
Ja, ich würde mal sagen, ja.
Also weil technische, ich meine, das ist, letztes Jahr war das ein bisschen noch, So Selfmade, 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 ja Operational Prozesse, die überhaupt nicht in Shopify sein müssen.
Die Entscheidung war, okay, lassen wir das rausnehmen, weil das, das, das, das, das.
Und wie können wir das rausnehmen?
Wie schaffen wir diesen Übergang?
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.
Ja, und das Thema Daten hast du jetzt auch schon ein, zweimal angesprochen.
Und im Vorgespräch ging es auch darum, eigene, ging es ja auch um 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?
Also ich sage immer, wir sind E-Commerce-Unternehmen.
Also was wollen wir am Ende hier erreichen?
Wir wollen, dass wir Menschen unsere Produkte kaufen und wir mehr Revenue machen.
Und natürlich die gesamte Software, Architektur, Datenauswertung geht es nun darum.
Um New Customer Acquisition, um Retention, um AOV, um...
Chorn Rate von unseren Kunden, um Conversion Rate Optimization, 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, sollen das B2B Kanäle sein, sollen das unsere eigene Stopp.
Stores, Point of Sales sein?
Sollen das E-Commerce sein?
Sollen wir mehr in unsere Mobile App investieren oder sollen wir Webseite so Richtung Weiterentwicklung pushen oder so 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 diese Kanäle?
Okay, was soll ich dabei beachten?
Am Ende entstehen so ein Knoten von Dependenzen, die man so saubere lösen muss und deine Daten können auch anders 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?
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.
Deswegen in erster Linie versuchen wir, die alltäglichen Fragen mit fertigen Tools zu beantworten, also die zum Beispiel unsere Customer Acquisition Costs steuert, wie Kampagnen steuert, offensichtlich Kanälen, Google und so weiter.
Wollen wir mehr die Penditas sehen, schauen zum Beispiel, wie unser Geotargeting aussieht, Inkrementalität und so weiter.
Dafür suchen wir natürlich mehr und mehr in diese Richtung gesammelte Daten und Machine Learning zu schauen.
Projekte 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.
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 Commodity.
Oder siehst du das anders?
Der Punkt ist, ich habe in sehr vielen E-Commerce-Unternehmen gearbeitet.
Ich wollte nie, aber mein ganzes Leben 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...
ist eine ganz andere Welt und ganz andere Unternehmen.
Und jeder E-Commerce lebt von eigenen Besonderheiten.
Und wir sind auf Shopify, aber ich habe zum Beispiel mit Shopware 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.
Wir können wie 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 schnellere Auswertung, schnellere Entscheidungen gehen möchte, desto mehr ist man auf technologische Lösungen angewiesen.
Und das ist, ich spreche nicht da von Flaconi, Zalando oder anderen Firmen, die alles selbst bauen und bei denen da schon so ein Core ist.
Ich spreche auch von kleinen Unternehmen.
Also 18 Millionen aufwärts, so würde ich sagen.
Ich glaube, da gehe ich auch mit.
Die Herausforderung liegt ja eher darin, also 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.
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.
Absolut richtig.
Also ich weiß nicht, wie oft habe ich schon das Wort heute wiederholt, aber so eine Balance zu finden.
Ja, das ist ein schöner Begriff.
Also eine technologische Entscheidung für die Firma zu finden, die genau für diesen Moment, genau diese Teamstructure, genau diese Revenue, genau dieser Entwicklungsschub genau passt.
Und das ist nicht einfach.
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.
Ja, das ist, was mich auf einer Seite freut, auf einer anderen Seite auch nicht.
Warum?
Wie überhaupt das dazu kam?
Eines Tages zwei gute Freundinnen von mir aus dem HR-Bereich, die...
bekannten Bankenunternehmen hier in Berlin arbeiten, haben mich zum Abendessen eingeladen und haben gesagt, wir haben eine Idee, du musst unsere CTO sein.
Und das war für mich so ein bisschen überraschend, weil wie gesagt, also wie jede CTO hatte ich auch so eine Arbeit, 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.
Bei so einem Projekt, da hat man kein Deadline.
Dann muss man wirklich in diese Produkttechnologie, Investorensuche, Teamaufbau und so weiter wieder einzusteigen.
Und das ist natürlich neben einer vollen CTO-Rolle ziemlich herausfordernd.
Warum hast du es trotzdem gemacht?
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 eine ganze Karriere darauf hingearbeitet, CTO zu werden und nach der CTO-Rolle versteht man, okay, jetzt wäre der nächste Schritt, was wäre der nächste logische Schritt für mich.
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 und Graduals zu helfen, ihren Weg zu finden im Beruf, was heute ziemlich schwierig ist, weil heute CVs, K.A.Agenten, die CVs erstellen, kämpfen gegen K.A.Agenten, die CVs auswerten.
Und wir wollen diesen Knoten lösen, indem wir so eine Plattform bauen, wo wir jungen Leuten helfen, ihre Stärken zu finden, ihre Scarce zu finden und dann mit richtigen Firmen in Verbindung zu setzen.
Die Firma heißt Stack, joinstack.com.
Also wenn jemand Interesse kann, dann drauf schauen.
Wir sind jetzt in vielen Projekten und 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 denen, die so begeistert, wir haben jetzt Data Analyst, wir haben Software Engineer.
Wir haben Support im Marketing, wir haben Support bei ich Artem.
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 süß und hetero.
Weil wir waren tatsächlich ein Frauenunternehmen.
Also das war spannend.
Ich glaube, das ist auch nicht so üblich heutzutage.
Ja, in der Tat.
Du bist auch, das muss ich ja auch noch dazu sagen, die allererste Folge hier des Podcasts, die war mit einem weiblichen CTO.
Und du bist seitdem, diese Woche kommt Folge 71 raus.
Wenn deine Folge veröffentlicht, sind wir so bei Folge 73, 74.
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.
Ist es Bias oder wieso ist das so passiert?
Das ist alles andere als Bias.
Es gibt so viele CTOs, weibliche CTOs.
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...
wie das auch entwickelt hat.
Trotz allem, man muss ja auch dazu sagen, diese Domäne ist schon trotz allem sehr, sehr männerlastig.
Und das siehst du auch.
Du bist auch, glaube ich, in CTO-Communities und da siehst du schon, wie groß die Übermacht an Männern im CTO-Bereich ist.
Ja, leider, das ist immer noch der Fall.
Aber ich bin Member of Women 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, es ist schwer, aber immer noch machbar.
Und wenn ich sage Bias, das ist zum Gottes Willen nicht ernst gemeint.
Ich hire Leute und Team schon seit mehreren Jahren.
Und mein Traum war immer, nur Frauen, Ingenieure im Teams, Data-Teams haben und so weiter.
Jetzt kannst du mich fragen, wie viele Frauen ich jetzt in meinen aktuellen Teams habe.
Wie viele Frauen hast du in deinem aktuellen Team?
Eine, okay.
Ich plus eine.
Und ich habe sehr viele Frauen interviewt.
Und ich habe mich wirklich sehr, sehr, sehr bemüht.
Was war denn der Grund, wenn ich das mal fragen darf, warum du dann doch mit so vielen Männern...
eher Männer eingestellt.
War das dann ein besseres Skillset?
War das ein besseres Mindset?
Kannst du das über einen Kamm scheren?
Also wir fangen damit an, der Anzahl BewerberInnen, da war, wenn du ein, zwei Female Profiles siehst, dann bist du schon glücklich.
Also das war schon mathematisch.
sehr schwer, eine passende Person zu finden, weil wenn du 300 Bewerber hast und zwei Frauen drunter, das ist, ja, da muss man hoffen, dass einer davon mindestens die Kriterien erfüllt.
Nein, also das war tatsächlich am Ende des Tages, es ging um Skills, die wir benötigen, weil wir arbeiten ziemlich in Agilen und schnellen Startup-mäßigen Bereich, wo man nicht nur unbedingt eine 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-Ending-Optimization ist oder wie schreibe ich einen sauberen Code, damit Google immer noch das gut interpretiert und versteht.
Und diese Skillset, die waren am Ende entscheidend.
Und kommt man aus einer großen Company, About You, Zalando, You Name It.
Warum?
Fünfmal habe ich schon heute Zalando gesagt.
Das ist das Erste, was mir sofort in meinen kommt.
Kommt man aus solchen großen Companies, das sind eh so die festgelegten Strukturen, wo du dann fünf Jahre sitzt und machst nur Backend.
Und dann bist du Profi in deinem Bereich.
Kommst du in so ein mittelgrößeres Unternehmen.
Da wird von dir schon ein bisschen mehr verlangt.
Also ein Blick nach links, nach rechts ist es schon sinnvoll.
Heierst du heute, wenn du Entwickler einstellst?
Also ich rede jetzt wirklich von heute im Jahr, so August, September, Oktober 2026.
Heierst du dann immer noch in erster Linie noch Skillset oder guckst du noch viel stärker jetzt auf Mindset 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?
Ja, also für mich bedeutet es auf jeden Fall, Personen zu finden, die am nächsten zu dieser End-to-End-Delivery-Standard kommt.
Also es bedeutet nicht, 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 genau so schreiben, was ich haben möchte.
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 ausgeholt 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.
Und egal, in welchem Bereich ich jetzt suchen würde oder suche, Data Engineering, Produkt UX, es betrifft ja alles.
Die Frage ist natürlich, die ich schon seit dem Februar stelle, wie setzt du die KI in deinen Alltag ein?
Das ist, glaube ich, nicht mehr denkbar.
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.
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 Agentic AI und allem, was dazu gehört, auch nochmal viel ausführlicher widmen.
Olga, welche CTO-Aufgabe hast du am längsten unterschätzt?
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 misinterpretiert.
Das ist so kurz und prägnant.
Also baut eure Entscheidungsstrukturen auf, setzt die Engineering Playbooks, das wird euch weiterhelfen.
Und welchen technischen Shortcut würdest du heute nicht mehr nehmen?
Ja, ich glaube, ich habe das schon kurz angesprochen, das ist auf jeden Fall Infrastructure as a Code.
Es gibt immer noch, wie gesagt, es gibt immer noch Unternehmen, die auch super klar ohne kommen.
Also es ist für mich ein Geheimnis.
Ja, aber die Frage war ja, welche Abkürzung würdest du heute nicht mehr nehmen?
Also ich würde nicht irgendwas ohne Terraform oder you name it, irgendein anderer Tool, irgendwas provisionen.
Welche Frage stellst du, bevor du einer Kennzahl vertraust?
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, 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?
Also durch den gesamten Prozess muss ich auf jeden Fall durchschauen.
Und welcher Rat hat deine Art zu führen verändert?
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 es und vertraue es.
Und lass den Menschen selbst diese Probleme lösen.
Das Unternehmen kann das aushalten.
Du musst aber dann irgendwann eine Entscheidung treffen, wenn immer noch irgendwas nicht funktioniert.
Hat das immer so geklappt?
Was denkst du?
Natürlich nicht.
Dann ist ja wieder die zweite Frage, wenn wir es auch noch Zeit hätten, wäre die zweite Frage dann zu sagen, ja, okay, wie hast du es denn dann gelöst?
Also es ist ja einfach, also es ist relativ einfach zu sagen, ja, jetzt ich versuche halt Entscheidungen abzugeben und zu delegieren und zu vertrauen.
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.
Ja, ja, aber für irgendwas kriegt man Gehalt, sage ich immer.
Und wenn das eben nicht immer wieder funktioniert, dann muss man die Frage stellen, ob das richtige Match ist zwischen Company und die Verantwortlichen.
Das ist richtig.
Letzte Frage für heute, Olga.
Was sollten angehende CTOs früher selbst ausprobieren?
Mein Gott.
Da habe ich sofort mehrere Witze in meinem Kopf, würde aber jetzt ernst bleiben, auf Zeitgründen.
Also auf jeden Fall, der eingehende CTO muss versuchen, ein komplettes System nicht nur selbstständig zu bauen, sondern auch sie zu verantworten.
Vielleicht erstmal in einem kleinen Kontext.
Also anfangen, Entscheidungen zu treffen, zu deployen, Risiken zu minimieren.
Business Impact zu estimaten, die Return of Investment zu berechnen, Post-Deployments Risiken zu managen, das zu pitchen, anschließen, das zu validieren.
Also wirklich ein kleines Projekt oder ein größeres Projekt ist auch kein Problem, wenn die Company das erlaubt.
Wirklich ein End-to-End zu begleiten mit allen Pros und Kontras.
Ich glaube, das gibt tatsächlich so einen guten Push für den nächsten Schritt.
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 noch mal 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, aber du wirst mir hoffentlich weiterhelfen können und zu mehr guten Gästinnen, 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.
Sehr gerne und vielen lieben Dank und bis vielleicht Folge 2.
Bis zu Folge 2.
Mach's gut, Olga.
Ciao, ciao.
Danke, ciao.