#54 "Wir wurden kleiner und plötzlich schneller" - Bojan Jukic über den CTO-Runaround

In dieser Folge von Becoming CTO Secrets spreche ich mit Bojan Jukic, Co-CEO bei Wunder Mobility und Gründer von goUrban. Bojan hat eine CTO-Reise erlebt, die fast alle Phasen technischer Führung berührt: vom eigenen Code im Moped-Sharing-Startup über die Skalierung eines Engineering-Teams auf rund 60 Personen bis hin zur CEO-/Turnaround-Rolle und dem Zusammenschluss mit Wunder Mobility.

Wir sprechen darüber, warum mehr Engineers nicht automatisch mehr Geschwindigkeit bedeuten - und warum ein kleineres, fokussierteres Team manchmal schneller wird. Bojan erzählt, wie aus einem Operator-Business im Mobility-Bereich ein SaaS-Produkt für Shared-Mobility-Anbieter wurde, welche technischen Herausforderungen hinter Mobility wirklich stecken und warum Architekturentscheidungen aus der Anfangszeit später entweder helfen oder zur Last werden können.

Ein großer Schwerpunkt liegt auf Engineering-Skalierung: Was passiert, wenn ein Team von 1 auf 10, 30 und schließlich 60 Engineers wächst? Welche Warnsignale zeigen, dass Wachstum nicht mehr proportional zu Output führt? Für Bojan sind vor allem Meeting Time und Cycle Time entscheidende Indikatoren.

Außerdem sprechen wir über den Wechsel vom CTO zum CEO, über Turnaround-Entscheidungen, über Fokus statt Headcount-Reflex und über die neue Engineering-Realität mit AI. Bojan erklärt, warum AI zwar Geschwindigkeit bringt, aber Product-Market-Fit nicht automatisch löst - und warum der Fokus stärker auf Impact statt reiner Velocity liegen muss.

In dieser Folge geht es unter anderem um:

- die CTO-Reise vom Hands-on-Founder zum Systembauer,
- Engineering-Skalierung von 1 auf 60 Personen,
- Growth Pain, Kommunikationskosten und Meeting-Kultur,
- warum kleinere Teams manchmal schneller werden,
- Shared Mobility, IoT, Availability und SaaS-Plattformen,
- Architekturentscheidungen, Microservices und technische Altlasten,
- den Wechsel vom CTO zum CEO,
- ROI statt “wir brauchen einfach mehr Leute”,
- AI in Software Engineering, Cycle Time, Tokenkosten und Kostenoptimierung,
- Scrum vs. Kanban in reifen Engineering-Teams,
- und die Frage, warum Velocity überschätzt und Impact unterschätzt wird.

Diese Episode ist besonders relevant für CTOs, Engineering Manager, Tech Leads, Gründer und alle, die verstehen wollen, wie sich technische Führung über die verschiedenen Wachstumsphasen eines Unternehmens verändert.

Transcript

SPEAKER_00 0:00

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. Und heute spreche ich mit Bojan Jukic. Er ist Co-CEO bei Wunder Mobility und der Gründer von Go Urban. Und wir reden über eine CTO-Reise, die wirklich alle Phasen berührt, die man sich vorstellen kann. Vom eigenen Code im Moped-Sharing Startup, über die Skalierung eines Engineering-Teams auf rund 60 Personen bis hin zum Co-CEO oder zum CEO-Turnaround und dem Zusammenschluss mit Wunder Mobility. Und wir sprechen darüber, warum mehr Menschen nicht automatisch mehr Geschwindigkeit bedeuten. Wie man als CTO loslässt. Und natürlich, was AI, Mobility und Community Building heute für technische Führung bedeutet. Bojan, herzlich willkommen.

SPEAKER_01 0:55

Hallo, Dankeschön. Ich freue mich schon auf das Gespräch.

SPEAKER_00 0:58

Ich ebenso. Und vielleicht kannst du mal kurz in ein, zwei Sätzen anfangen, uns zu erklären, was Wunder Mobility macht. Und genau, dann steigen wir tiefer ein, aber ich glaube, es braucht noch ein, zwei Sätze Erklärung dazu, was ihr macht und wofür er steht.

SPEAKER_01 1:11

Sehr gerne. Also wir sind ein Software-as-a-Service-Plattform, wo wir Lösungen für Shared Mobility-Anbieter bauen. Das heißt, man kann sich vorstellen, ein Carsharing-Unternehmen oder ein Kick-Scooter-Sharing-Unternehmen kommt zu uns und wir bekommen alle Tools, die sie brauchen, um so eine Flotte auch wirklich betreiben zu können, eine User-Applikation im White Label Kunden anbieten zu können. Also wirklich das komplette Toolset kommt alles aus seiner Hand in einem Software-Serie-Service-Format.

SPEAKER_00 1:40

Sehr gut. Und da werden wir gleich noch ein bisschen genauer drauf eingehen, aber vielleicht erstmal zu dir und deiner Rolle. Die hat sich ja auch in den letzten Jahren ein paar Mal geändert. Und wenn du deine Reise mal so in drei Phasen unterteilen würdest, so von Hands-on-Gründer, CTO im Scale-Up und dann CEO im Turnaround, welche der Phasen hat dich denn persönlich am meisten verändert, wenn du das überhaupt so sagen kannst?

SPEAKER_01 2:04

Ich glaube, es ist super schwierig, weil alle drei Phasen sind eigentlich so komplett unterschiedlich sind und ich glaube, ich habe auch sehr viel Spaß gehabt in jeder von diesen Phasen. Ja, ich würde das genauso wie du eigentlich unterteilen. Das eine ist wirklich so dieses Gründerleben, ich fange von null an, ich baue die, das Ziel ist, die ersten Umsätze zu bekommen. Wie bekomme ich den Product Market Fit, wie stelle ich ein Investment auf, dass ich Kapital davor brauche. Also echt super spannende Themen. Dann natürlich auch diese zweite Phase als CTO, wo man dann doch lernen muss, wie man Systeme aufbaut, dass Sachen auch ohne dich effizient funktionieren. Das heißt, du bist nicht so stark mehr involviert in diesen Hands-on-Code schreiben, sondern versuchst eher andere möglichst effektiv zu enebeln und skalierende Systeme zu bauen. Und dann natürlich dieser Switch dann, dass du in diese Geschäftsführerrolle, in diese CEO-Rolle kommst, wo du dann plötzlich darüber nachdenken musst, welche Sachen willst du nicht tun eigentlich? Das heißt, welche Sachen willst du eigentlich nicht bauen, wo soll der Fokus sein, wo willst du vielleicht auch Kompromisse machen, wo willst du Risiko eingehen? Das ist dann doch wieder nochmal eine andere Denkweise, die ich vielleicht auch am Anfang unterschätzt habe, wo ich relativ einfach reingestolper bin, auch in diese CEO.

SPEAKER_00 3:21

Ja, das kann ich mir vorstellen. Aber bist du dann jetzt, wo AI kommt und das Thema Coding und Bauen und Entwickeln nochmal so viel einfacher macht, dann nicht immer wieder in Versuchung, quasi den CEO in dir trotzdem coding, also den Entwickler in dir trotz der CEO-Rolle immer wieder ans Werk gehen zu lassen und Dinge zu bauen, obwohl das eigentlich deine Teams tun sollten?

SPEAKER_01 3:42

Genau, ich glaube, das ist die Herausforderung, die momentan sehr, sehr, sehr viele haben. Ich habe sie genauso. Also ich bin jetzt seit, ich würde sagen, letzten September sehr intensiv fast täglich am Bauen und am Nutzen wieder. Aber ich muss auch ehrlich sagen, am Anfang war es diese Euphorie, endlich wieder etwas tun zu können, wo man doch niemals davon gezäumt hat, wieder Coach halten zu können. Auf der anderen Seite merke ich auch, man muss sehr stark aufpassen, welche Sachen man tatsächlich jetzt baut und macht noch, auch in dieser Rolle. Und wo steigt man vielleicht doch jemanden auf die Füße, wo macht man das alles viel langsamer, als es eigentlich dann am Ende die Idee war, eigentlich das schneller zu machen, aber doch wird es dann langsamer, weil dann Sachen doch die Qualität nicht passt, Sachen gehen raus, Bachse entstehen, wer behebt die dann, wenn du es selber gebaut hast. Das heißt, ich glaube, diese Euphorie vom Anfang, dass ich endlich wieder Sachen bauen kann, ist insofern ein bisschen verflogen, dass ich jetzt die Projekte sehr fokussiert mache. Und für mich war das aber auch noch genauso wichtig, muss ich ehrlich sagen, im Nachhinein, weil es ist eine neue Technologie und ich glaube, es ist wichtig für jeden, der in einem Tech-Unternehmen ist, sie zu verstehen. Und das geht einfach am besten, wenn man sie mal intensiv genutzt hat, weil sonst kann man auch so eine Transformation intern auch eigentlich gar nicht vorantreiben.

SPEAKER_00 4:56

Absolut, das ist ja die Situation, in der wir jetzt sind. Und auf dem Weg dahin gab es ja bei dir auch bestimmt den einen Moment, in dem du vielleicht selber festgestellt hast, dass du nicht mehr derjenige sein darfst, der das Problem selber wegcodet, sondern im Endeffekt, du hast es ja eben schon mal beschrieben, Systeme bauen musst, in denen dann andere dann gute Entscheidungen treffen können. War das dann für dich in dem Moment, in dem du diese CTO-Rolle übernommen hast oder war das schon vorher ein Punkt, an dem du gemerkt hast, das muss ich jetzt machen, ansonsten funktioniere ich in meiner Rolle nicht mehr so, wie ich es tun sollte?

SPEAKER_01 5:28

Genau, ich glaube, es ist tatsächlich leider immer sehr reaktiv. Man kommt dann automatisch als Gründer in diese Rolle, wo man plötzlich ein CTO von einer etwas größeren Organisation ist und dann umdenken muss und lernen muss, wie man in dieser Situation sich selbst dann beweist und dort bestehen bleibt. Und am Anfang war ich sicher viel zu hands-on noch involviert, habe noch viele Sachen selber gemacht. Statt mich darauf zu fokussieren, wie ich eigentlich die Teams und die Systeme baue, skalieren. Und das war sicher so eine Übergangsperiode von ein, zwei Jahren, auch als First-Time-Founder, um ehrlich zu sein, wo man das dann einfach auch wirklich einfach lernen muss. Und das ist dann auch eiskalt, weil die eigene Zeit ist limitiert. Und wenn man dann versucht, die vielleicht auch die Probleme, die man intern nicht durch Systeme lösen schafft, mit eigenem Zeiteinsatz zu beheben, selbst die Bugfixes macht und ausrollt, dann hat man plötzlich sehr, sehr, sehr lange Arbeitstage und dann stellt man sich die Frage, ist meine Zeit überhaupt sinnvoll investiert? Also baue ich ein Unternehmen, das skalieren kann? Eigentlich nicht. Und dann kommt man irgendwie in diese Learnings, weil man mit anderen spricht und auch natürlich viel liest. Und dann ist man plötzlich in dieser Rolle, dass man Systeme dann baut. Aber es war eher tatsächlich reaktiv, würde ich sagen. Und ich glaube, so geht es auch sehr vielen, wenn ich so mit den Leuten spreche. Man weiß eigentlich gar nicht so richtig, auf was man sich einlässt. Man hat diese Rolle irgendwie im Kopf. Aber vor allem, wenn man ein Unternehmen gründet, irgendwie passiert das dann alles sehr automatisch.

SPEAKER_00 7:01

Ist das dann auch das große Missverständnis, was viele Entwickler haben oder vielleicht auch die CTOs haben, die frisch in diese Rolle reingewachsen sind, dass sie immer noch denken, sie müssten der beste Techie im Unternehmen sein? Ist das das große Missverständnis oder woran liegt es?

SPEAKER_01 7:16

Ich glaube, das ist halt so, dieses Missverständnis von, wie bekomme ich diese Gefolgschaft von den Leuten, also diese Autorität eigentlich im Raum. Und dass die Leute gern mit einem gemeinsam arbeiten, dass die Leute gern in meinem Unternehmen sind. Und dann wirkt es vielleicht am Anfang ein bisschen peinlich, dass man bestimmte technische Sachen gar nicht mehr weiß. Man weiß vielleicht auch gar nicht mehr, wo welche Architekturentscheidung herkam, weil man doch relativ high-level unterwegs ist, weil einfach der Scope so breit ist von den Sachen, die man abdecken muss, dass es relativ schwer ist, so spezialisiert zu bleiben in jedem Bereich und auch up-to-date. Und ich glaube, das war auch bei mir so. Es ist noch immer, muss ich ehrlich zugeben, manchmal schwierig, dann manche Sachen nicht zu wissen und sich auf jemand anders zu verlassen. Ich glaube, das ist immer so schwer, dieses Vertrauen auch aufzubauen. Aber das ist gleichzeitig auch ein extrem belohnender Effekt, wenn man dann plötzlich merkt, man hat ein Team, wo du dann Spezialisten hast, die tatsächlich extrem gut in ihren Bereichen sind und du hast geschafft, CR in dein Unternehmen zu bekommen und auf der anderen Seite sie auch zu halten langfristig. Und das ist, glaube ich, die noch viel größere Belohnung, um ehrlich zu sagen.

SPEAKER_00 8:29

Absolut. Und du hast ja, ich habe eingangs erwähnt, du hast ja angefangen, ein Moped-Sharing-Service zu bauen oder eine Plattform dafür zu bauen. Wie sah denn die allererste Version dieses Startups aus? Was hast du damals selbst gebaut?

SPEAKER_01 8:45

Das leider noch vor AI. Aber im Prinzip sah die erstmal. Damals war es noch harte Arbeit. Da haben wir in ein paar Monaten tatsächlich einfach zu einem Prototyp, mit dem wir auch an den Markt gegangen sind, gebaut. Und das war einfach eine User-Applikation, wo man Fahrzeuge mieten konnte. Das heißt, Fahrzeuge auf einer Karte gesehen, man konnte hingehen, das Fahrzeug aufsperren und man hat pro Minute bezahlt und am Ende eine Rechnung bekommen und das wurde von der Kreditkarte abgebucht. Und zusätzlich nur ein kleines Interface, wo so ein Operations-Tooling, wo man die Fahrzeuge sieht, in welchen Status sie sind. Man kann das ganze Flottenmanagement abdecken. Das heißt, das war wirklich so ein MVP, den wir relativ schnell gebaut haben und dann konstant weiterentwickelt haben. Das war auch super spannend, weil ich glaube, was viele unterschätzen auch in diesen ganzen Mobility-Space ist, wie viele verschiedene Aspekte man beachten muss und wie sehr diese Systeme zusammenhängen. Weil auf der einen Seite hat man diese ganze IoT-Kommunikation, das Fahrzeug ist ja konstant verbunden, wie stelle ich sicher, es ist online, wie stelle ich sicher, es sperrt immer auf. Man hängt auch von der Hardware ab, dass die auch gut funktioniert. Dann hast du plötzlich auch eine mobile Applikation im Spiel mit Android- und iOS-Nutzern. Und dann hast du auch noch eine Plattform, die eigentlich 24.7 zur Verfügung stehen muss, weil wenn jemand aktuell auf einem Fahrzeug unterwegs ist und plötzlich die Systeme ausfallen, dann strandet diese Person und kann die Miete nicht beenden. Das ist dann genauso unangenehm. Also es ist wirklich eigentlich ein ziemlich komplexes System mit sehr vielen Abhängigkeiten und war aber auch super spannende Experience, so das Baum zu dir.

SPEAKER_00 10:29

Ich glaube, als User kennen wahrscheinlich alle, auch alle Hörer hier des Podcasts, wahrscheinlich den ein oder anderen Mobility-Services und hat den mal ausprobiert. Was ist denn aus deiner Sicht technisch am schwierigsten gewesen zu implementieren oder umzusetzen? Du hast jetzt ein paar Themen schon angesprochen, von IoT, Flotte und so weiter. Aber aus technischer Perspektive, was war denn der größte Knackpunkt? War es die Availability oder was anderes?

SPEAKER_01 10:56

Es ist tatsächlich auch so ein bisschen die Availability im Sinne von der Skalierung. Das war zum Beispiel eine Herausforderung, weil der Demand teilweise sehr unvorhersehbar zumindest anfangs reinkam. Das heißt, man hat natürlich die üblichen Peaks, in der Früh fahren viele Leute irgendwo hin, am Nachmittag nach der Arbeit wieder zurück. Aber gleichzeitig gibt es dann zum Beispiel einen Streik in London und die U-Bahnen fahren nicht mehr. Plötzlich switchen alle Leute zu den Bikes und auf einmal hast du deutlich mehr Last auf deinen Servern, die diesen auch standhalten müssen. Weil auch wenn die Leute zum Beispiel nicht mal mehr ein Bike finden, weil alle besetzt sind, alle machen die Applikation auf und suchen danach. Also das war zum Beispiel so eine typische Herausforderung. Aber da gibt es noch viel mehr Komplexität, auch im Sinne von zum Beispiel den IoTs und den Latenzen. Wie stelle ich sicher, dass dem Kunden das Fahrzeug schnellstmöglich aufsperrt und dass die GPS-Position akkurat ist, damit er das Fahrzeug A findet und B, wenn er dort ist, auch sehr schnell aufsperrt. Und das waren so zwei, würde ich immer sagen, von den sowieso Hürden, die wir einfach hatten. Dass aber diese Verfügbarkeit da ist und auf der anderen Seite auch die Zuverlässigkeit.

SPEAKER_00 12:07

Ja, kann ich gut nachvollziehen. Startups treffen gerade am Anfang eine ganze Menge Entscheidungen. Einige davon, wenn sie erfolgreiche Startups dann später sind, haben sich dann als Glücksentscheidungen oder sehr gute Entscheidungen herausgestellt. Andere sorgen dann eher für Altlasten oder für Schulden, für die sie dann später nochmal doppelt und dreifach zurückzahlen müssen. Wie war das dann bei euch? Welche technischen Entscheidungen aus der Anfangszeit hat euch später wirklich geholfen, vielleicht auch der Konkurrenz voraus zu sein? Und was hat euch vielleicht, was ist euch vor die Füße gefallen?

SPEAKER_01 12:39

Genau. Ja, auf jeden Fall, so wie du sagst, ich glaube, was uns geholfen hat, definitiv war von Anfang an, bestimmte Architekturentscheidungen zu treffen, wie wir das System, also das Datenmodell von Grund auf aufbauen. Und das ist sehr gut skalierbar aktuell. Und wir können weiterhin auf Basis von dem ursprünglichen Datenmodell, wo wir damals die ersten Linien Code geschrieben haben, es baut weiterhin sehr schön auf diesen Datenmodell auf. Wir konnten uns sehr gut skalieren. Wir mussten die Datenmodelle nie grundlegend umbauen. Das hat uns auch ziemlich viel Power gegeben. Wenn man diese Grundstrukturen, die man am Anfang legt, wieder ändert, ist das sehr, sehr mühsam. Und das haben wir uns weiterhin, ich sehe keinen Grund, wieso wir das ändern sollten. Das heißt, da haben wir uns, glaube ich, sehr viel erspart, was anderen nicht erspart bleibt. Und auf der anderen Seite Fehler, ich glaube, vielleicht sogar gar nicht Fehler, aber es war halt damals in der Zeit auch dieser ganze Hype rund um Microservices. Alles muss ein Microservice sein. Und dann nimmt man ein Investment auf und das Team wird größer. Und dann ist der erste Reflex, wir müssen den Monolithen aufbrechen, damit die Teams quasi ihre Microservices die Ownerships überhaupt haben. Und dann fängst du an so zu bauen und brichst das auf des Aufbrechens Willens.

SPEAKER_00 14:00

Auf der Zweitachse, in welchem Jahr war das dann ungefähr, dass weil genau dieser Shift stattgefunden hat?

SPEAKER_01 14:06

Also ich glaube, es war so um 2,92, so in die Richtung 2,19, sowas um die Zeit. Und dann machst du das und baust das. Und dann verkleinerst du auch dein Team wieder oder du baust auch wieder die Strukturen um und plötzlich sind die Microservices irgendwie eine Last, weil da es eine Geschwindigkeitseinbuße gibt, weil das nämlich auch jemand warten muss, weil auch jemand die Komplexität zwischen den Services beachten muss, wenn neue Sachen gebaut werden und ähnliches, Resilience-Themen. Und da kommen einfach sehr viele Sachen dazu und das sind so Punkte, wo ich sagen würde, das hätten wir uns sicher sparen können, dass wir nicht so auf diesen Hype aufspringen des Hypes-Wilds.

SPEAKER_00 14:49

Ihr wart ja am Anfang ein reines, in Anführungszeichen, Operator-Business, wenn ich das so richtig verstanden habe. Und dann später hat sich herausgestellt, ihr macht ja Software as a Service-Business für andere Sharing-Anbieter. Wann wurde das denn klar, dass das eine aus dem anderen entsteht oder vielleicht die logische Konsequenz oder das bessere Business Model ist?

SPEAKER_01 15:10

Ja, ich glaube, da waren zwei große Punkte, die ja mitgespielt haben. Wir haben tatsächlich immer mehr Anfragen einfach bekommen von anderen Betreibern. Es war auch eine Zeit, wo sehr viel in dem Markt los war. Das war so um 2017, 2018. Und es gab einfach nicht viele Softwarelösungen, die man lizenzieren kann. Deswegen haben sich auch viele tatsächlich entschlossen, Inhouse zu bauen, weil es einfach keine andere Wahl gab zu dem Zeitpunkt. Wir haben in dem Moment aber auch Anfragen bekommen, wo wir Info ausgebaut haben. Wir haben gemerkt, dass die Möglichkeiten, die Hardware zu skalieren, begrenzt sind zu dem Moment und haben dann einfach unsere Stärke erkannt im Softwarebereich. Und das war dann auch die Entscheidung, wo wir gesagt haben, okay, wir wollen jetzt nicht so viele Sachen gleichzeitig machen. Wir wollen den Fokus wirklich auf die Software selbst geben und ein SaaS-Unternehmen daraus bauen. Und somit haben wir auch begonnen, die Software an die ersten Kunden zu lizenzieren. Damals war unser erster Kunde ein Moped Sharing in Malta tatsächlich. War auch ein schöner Ort, um hinzufahren mal. Das ist auch der Vorteil an den Business, dass sie ganz gut verteilt sind in Europa. Und ja, es war auch jetzt im Nachhinein auch die richtige Entscheidung. Und ich glaube, diese Entscheidung zu treffen, wie viel man, also bezüglich Fokus und wo man genauer darauf achtet, das ist, das war nicht leicht, aber am Ende vom Tag hat uns das dann auch geholfen, große Schritte vorwärts zu machen in dem Bereich.

SPEAKER_00 16:36

War das dann im ersten Moment ein, der, also war es eine Opportunitätsentscheidung zu sagen, wir wollen das vielleicht auch nochmal an andere lizenzieren und dann erst in Hindsight stellt sich raus, naja, es ist vielleicht strategisch besser, wir shiften komplett darüber oder habt ihr wirklich in dem Moment auch schon die strategische Entscheidung getroffen, das ist wahrscheinlich der bessere Software oder der bessere Business-Aspekt.

SPEAKER_01 16:57

Ich glaube, bei den ersten ein, zwei Kunden war die Entscheidung gar nicht so klar noch, dass es jetzt der Hauptmarkt wird. Wir haben einfach die Opportunity gesehen und haben es ausprobiert sozusagen. Und dann hat sich einfach herausgestellt, dass da immer größere Kunden reinkamen, die Flottenanzahl gewachsen ist und einfach der Umsatz für sich gesprochen.

SPEAKER_00 17:13

Ja, du hast jetzt auch in genau diesem Zusammenhang, es geht ja auch, Skalierung hat ja nicht nur was mit dem Business zu tun, sondern wahrscheinlich damals noch viel mehr, auch du musstest mit Engineers skalieren, um überhaupt alles abdecken zu können. Am Anfang warst du wahrscheinlich alleine und später kamen immer mehr Engineers dazu, irgendwann waren es dann 60. Wie hat sich denn der Sprung angefühlt? Also jetzt gerade von einem auf 10 später, von 10 auf 30, von 30 auf 60, so gab es da bestimmte Aspekte, wo du sagst, das hat es jetzt nochmal um einen Faktor X schwieriger gemacht oder waren es irgendwann nur, naja, dann habe ich jetzt halt 15 Teams anstatt drei?

SPEAKER_01 17:51

Ja, ich glaube, es gibt irgendwie so diese, wenn ich so mit Leuten spreche, oder die Erfahrung teile ich auch, so zwei große Steps. Der eine große Step ist irgendwie so von so um 20, 25 Mitarbeiter, wo die Komplexität wächst. Und der zweite Step ist dann so, wenn man so ab 50, 100 aufwärts, wo es dann nochmal deutlich anders wird. So ungefähr. Und das war dann auch tatsächlich bei uns der Fall. Und was heißt das, wenn ich von anders spreche, es werden einfach die Kommunikationswege anders. Es entsteht sehr viel Growth Pain, wo es viele Prozesse einfach noch nicht ausdefiniert sind, wo es nicht klar ist, wer wie kommuniziert, wie sind die Teams strukturiert. Man hat alles irgendwie auf einem Whiteboard, in irgendwelchen Eroboards durchgeplant und das sich alles natürlich durchüberlegt. Aber es ist dann anders, wenn plötzlich 50 neu eingestellte Personen, doppelt so groß die Firma plötzlich, dort zusammenarbeiten beginnen und dann auch die Probleme losgehen. Und das ist dann doch sehr zeitintensiv, das Ganze zu betreuen. Und ich glaube, was anders ist, ist einfach genau das Mindset komplett switcht, zu eben das System zum Laufen zu kriegen, Prozesse zu verstehen, Ineffizienten zu verstehen, welche Daten messe ich, wie komme ich an diese Datenpunkte überhaupt, welche Toolings werde ich dafür verwenden. Dann verwendet man plötzlich viel zu viele Tools, weil man sehr viel Autonomie lässt, dann verliert man den Überblick, weil man nicht mehr an die Daten rankommt, weil die in allen in irgendwelchen Tools feststecken. Dann versucht man das wieder umzubauen, weniger Tools einzusetzen. Das sind so ganz viele Beispiele für diesen Growth Band, der da irgendwie entsteht, wo man dann konstant dagegen kämpft und auch in diese Richtung danach arbeitet einfach. Das heißt, ich würde einmal zusammenfassen, dass einfach die Kommunikationswege immer intensiver werden, mehr Ebenen in der Kommunikation eingeführt werden und Prozesse einfach von Gesunder auf neu definiert werden müssen und dann aber auch validiert werden, dass man sicherstellt, dass sie auch gut funktionieren. Und am Ende vom Tag, was ist das Hauptziel? Du hast ja weiterhin die Kunden, du hast weiterhin die CS-Ziele und du musst gegen diese Kunden, also du musst für diese Kundenzufriedenheit arbeiten, du musst diese SES-Ziele erreichen und gleichzeitig musst du mit diesem Growth Pain kämpfen. Und ich glaube, so ein großes Learning von mir ist ja auch, das ist, es klingt dann immer am Anfang cool, diesen Headcount zu erhöhen. Und das ist irgendwie so dieses Ziel und alle freuen sich dann immer, wenn sie auch das Investment aufstellen und in die Richtung gehen. Die Zeit ändert sich jetzt aber auch wieder etwas mit AI und ähnlichem. Ich glaube, das war tatsächlich auch, ich mache das mal in dieser ganzen Microservice-Ecke 2019, 2020, in die Ecke. Das war damals ja auch ein Thema, was einfach vorangetrieben wurde. Ich glaube, das macht Sinn tatsächlich, dass man den Headcont auch erhöht in ganz bestimmten Situationen. Und da muss man wirklich davon überzeugt sein, dass es wert ist, diese Ineffizienzen hinzunehmen und gegen den Growth Band zu kämpfen, um in ein, zwei Jahren ein stark skalierbares System aufgesetzt zu haben, das noch weiter wachsen kann.

SPEAKER_00 21:02

Habt ihr euch dann auch an bestehende Frameworks orientiert, also Frameworks für Organisationsentwicklung im Engineering-Bereich? Also ich denke da, wenn das jetzt 2017, 2018, 2019 irgendwie ist, dann war das Spotify Engineering-Modell immer noch ein großer Hype. An was habt ihr euch orientiert zu dem Zeitpunkt? Oder habt ihr einfach nur versucht, die bestmögliche Lösung zu finden anhand irgendwelcher Best Practices oder was für euch funktioniert hat?

SPEAKER_01 21:28

Ich glaube, wir haben tatsächlich sehr viel Zeit einfach investiert, um uns einzulesen in diese ganzen verschiedenen Themen. Also wir haben sehr viel Augenmerk auf Productmanagement gelegt und wie wir das so aufsetzen können, dass wir product-driven Teams aufbauen können, die tatsächlich den Impact beim Kunden und ähnliches verstehen. Das heißt, wir haben uns in dir dort sehr viel Zeit fokussiert und im Engineering und in den Frameworks natürlich gab es immer wieder verschiedenste Konzepte, auch Sachen, die wir eingeführt haben, die dann doch zu komplex sind. Waren. Beispiel Klassiker in Unternehmen ist, glaube ich, OKRs, die man dann einführt und dann werden sie hype gelebt und dann baut man das fünfmal um und ähnlich. Das heißt, wir haben in die Richtung schon viel geschaut und viel ausprobiert. Am Ende vom Tag muss ich sagen, ich glaube, so ein Buch, was mir tatsächlich am meisten geholfen hat damals, war dieses An elegant Puzzle von Stripe über das Engineering Management und ähnliches. Das fand ich damals ziemlich inspirierend. Aber sonst würde ich sagen, es war, ja, ich muss ehrlich zugeben, das war dann einfach so, dass wir die Teams so aufgesetzt haben, dass wir die Frameworks genommen haben und zum Teil uns einfach zurechtgebogen haben, dass es einfach in unserem Environment gut funktioniert.

SPEAKER_00 22:44

Ist ja auch völlig okay. Also welche Rolle hat denn eure Architektur beim Skalieren gespielt? Es ist ja oft so, du baust eine Architektur und dann versuchst du die Teams danach auszurichten, gleichzeitig so, wie du die Teams halt schneidest oder aufsetzt, das hat natürlich auch Auswirkungen für die Architektur. Musstet ihr eure Systeme konkret umbauen, weil die Organisation größer wurde, oder habt ihr so gebaut und habt dann, dass ihr gleich schon die Organisation mitgedacht habt?

SPEAKER_01 23:11

Genau. Also wir haben begonnen, sie umzubauen. Im Nachhinein glaube ich nicht, dass es notwendig war, in der Form zumindest, teilweise. Aber das war genau dieser Shift zu den Microservices, wo wir dann plötzlich nicht mehr nur zwei Teams hatten, aber dann sechs Teams. Und dann diese Teams auch so aufgebaut haben, dass die sozusagen direkte Ownership über bestimmte Bereiche bekommen haben und auch über Microservices, die dann komplett in der Verantwortung des Teams lagen. Also das heißt, das würde ich einmal definitiv in die Ecke schieben, was wir gemacht haben. Und das zweite aber ist, glaube ich, auch wichtig zu sagen, wir haben dennoch auch versucht, dass wir den Monolyten dann beginnen zu modularisieren und dass dann auch der sozusagen, dass da die Ownership über die Bereiche Monolyten auch klar bei den Teams aufgeteilt sind.

SPEAKER_00 24:04

Gab es denn da spezielle Wahlsignale, die du wahrgenommen hast? Also wenn ein Engineering-Team zwar wächst, aber am Ende des Tages nicht mehr proportional gleich viel Output dabei rauskommt. Ich meine, das wird jetzt auch eine spannende Situation sein, inwiefern das Thema AI, Agentic AI, autonome Agenten und so weiter, die Software brauchen. Was für Auswirkungen die dann nochmal drauf haben auf die Organisationen der Zukunft. Da sind wir aber noch nicht, aber jetzt rückblickend betrachtet bei euch. Gab es da Warnsignale dafür, dass es irgendwann nicht mehr proportional wächst zur Menge der Leute, die ihr einstellt? Auf jeden Fall.

SPEAKER_01 24:39

Also ich glaube, so Klassiker sind, dass du deine erfahrensten Leute, die most senior people, plötzlich nur mit Meetings sitzen und wenig Zeit haben, selbst noch Code zu schreiben, weil sie entweder mit Onboarding beschäftigt sind, weil sie mit irgendwelchen Alignment-Meetings beschäftigt sind, wo der Outcome der Meetings nicht so klar ist. Es gibt keine klare Agenda, sondern dann wird einfach einmal 45 Minuten über ein Thema diskutiert. Das heißt, es hat definitiv, das würde ich alles Richtung Growth Pain sagen. Das ist genau, dass sehr viele Personen dann zum ersten Mal in bestimmten Situationen waren und wir einfach Zeit gebraucht haben, um in diese Situationen, diese Ineffizienzen dann einfach zu beheben. Und ich würde sagen, diese Warnsignale einfach immer auf die Meetingkultur schauen, wie viel können die Senior Engineers tatsächlich auch selbst noch Code schreiben, wie viel sind sie in Meetings beschäftigt, die Cycle Times in den Teams, droppt die durch das Wachstum, was kann man dagegen tun, um die Teams zu unterstützen. Oder wie kann man die Teams am besten unterstützen, dass die Cycle Time wieder besser wird und ähnliche Sachen. Also das würde ich immer so sagen, sind die zwei Warnsignale eigentlich für mich immer Meeting Time und Cycletime.

SPEAKER_00 25:56

Ja, ihr habt ja auch in einer Zeit, seit ihr gewachsen, in der jeder Softwareentwickler eingestellt hat. Das war ja dann auch eine Zeit, in der es immer schwieriger wurde, in den großen europäischen Standorten, also zum Beispiel UK oder auch Deutschland oder Österreich oder was auch immer, die richtigen Entwickler zu finden. Und man musste immer überproportional viel mehr bezahlen, was man eigentlich dafür bekommen hat. So, haben jetzt Leute angefangen, an Nearshowing zu gehen oder selber andere Offices in anderen Ländern aufzumachen. Wie war das bei euch? Wie habt ihr diese Skalierung, wie seid ihr das angegangen? Habt ihr an den gleichen Standorten geheirat wie vorher oder habt ihr euch dann auch entschieden, an andere Standorte zu gehen und dort nochmal bessere, gute Qualität zu einem sinnvolleren Preis einzukaufen?

SPEAKER_01 26:42

Genau. Also wir haben tatsächlich in Serbien und in Bosnien einen Standort aufgemacht damals. Und wir haben weiterhin einen auch hier jetzt in Bosnien. Und das war, der Hintergrund war einfach genauso, wie du es ansprichst. Es war sehr umkämpft. Vor allem haben einfach Scale-Ups, die deutlich mehr Investment in sich hat natürlich auch die Preise bei der Zielgruppe einen Entwicklern, die du gerne einstellen würdest, nach oben getrieben. Und beispielsweise für uns, im Markt in Serie nicht schlecht die Sprache. Und auf der anderen Seite war dort auch sehr viel Talent, die in Outsourcing-Firmen arbeiten, die auch für große Unternehmen in den USA beispielsweise Aufträge abarbeiten, beispiel Apple und ähnliches. Und dort haben wir einfach einen ganz guten Talente-Pool auch gefunden, den wir nutzen konnten, um damals das Unternehmen auch zu skalieren und auch die richtigen Leute einzustellen. Plus das Unternehmen war ja auch damals in Wien, das war auch nicht weit weg, weil mit dem Auto war man in fünf Stunden dort. Das heißt, das war alles zeitlich okay.

SPEAKER_00 27:42

Ja, im Vorgespräch hast du gesagt, und du hast es jetzt ja eben auch nochmal indirekt von der anderen Seite beleuchtet, dass ihr eigentlich als ihr größer wurdet, natürlich auch langsamer wurdet aus diversen Gründen. Die Seniors waren auf einmal nicht mehr in der Lage, Code zu schreiben, sondern irgendwie mit anderen Themen beschäftigt, Meetings und so weiter. Und ich erinnere mich, du hast im Vorgespräch auch erwähnt, dass ihr nach einer Verkleinerung der Teams tatsächlich auch nochmal schneller geworden seid. Ich habe jetzt nur noch mal ganz im Kopf, was habt ihr denn genau verkleinert? Die Teams, die Menge an Teams und Leute in der Organisation, die im Engineering sind, oder habt ihr die Teams einfach nur kleiner gestaft und hat dann ein Team, hatte nur noch vier Leute anstatt acht? Was war da? Und was genau wurde dann schneller? Wurden dann Entscheidungen schneller, Delivery, Fokus, was auch immer?

SPEAKER_01 28:27

Genau, also wir haben tatsächlich die Organisation insgesamt verkleinert. Das heißt, das war jetzt nicht nur das Engineering, sondern tatsächlich aber die gesamte Organisation. Wir sind auf insgesamt um die 40 Leute wieder in der Organisation gestumpft. Und dementsprechend mussten natürlich auch die Teams und ähnliches umgebaut werden. Das heißt, es wurden auch weniger Teams. Damit einher gingen auch viele Entscheidungen, auf was will man tatsächlich den Fokus legen. Also welche Bereiche vom Business will man weiterhin ausbauen, wo will man den Fokus legen, wie können wir weiterhin gewinnen in dem ganzen Markt. Und diese Entscheidungen zu treffen war auch essentiell, weil einer der Probleme vom Wachstum war auch, dass man konstant den Markt erweitert hat und ganz viele verschiedene Sachen in verschiedenen Bereichen gebaut hat und es sehr schwer war, in einem Bereich wirklich die beste Lösung zu bauen, weil der Fokus einfach ein bisschen Verwaschen war von der Mutter.

SPEAKER_00 29:26

Ja, was war denn der Auslöser überhaupt, sich doch mal zu schrumpfen? War das die Wahrnehmung, wir müssen nochmal, wir werden ineffizient, lass uns kleiner werden oder gab es andere Aspekte, die doch dazu geführt haben?

SPEAKER_01 29:37

Es ist definitiv ein externer Aspekt gewesen, wo einfach der Runway, also wie viel das Unternehmen noch Liquidität hatte, kleiner wurde, auch bedrohlich und wir einfach die Entscheidung treffen mussten. Das heißt, wir wurden extern gezwungen. Aber ich glaube, das ist auch eine der großen Herausforderungen für First-Time-Founder, die auch zum ersten Mal in so eine Situation kommen, dass es nicht nur konstant nach oben geht mit dem Wachstum, sondern auch schwierigere Entscheidungen zu treffen sind, auch diese Entscheidung zu treffen, dass man halt auch umbauen muss und das auch das auch richtig zu machen, das Ganze. Und genau, das heißt, das war einfach ein externer Treiber.

SPEAKER_00 30:13

Was hast du dann festgestellt, als ihr dann euch verkleinert habt, so auf einem, oh krass, wir werden ja schneller, obwohl wir weniger sind, ist ja super. Welche Komplexität ist denn dann als erstes verschwunden, als ihr euch dann gesund geschrumpft habt und die Teams kleiner wurden? Waren das die Abstimmungen, war das die Meetings selber oder was genau war das?

SPEAKER_01 30:30

Genau. Ich glaube, vielleicht auch zuallererst, es war ja natürlich auch keine einfache Situation, überhaupt kleiner zu werden. Man musste das Ganze auch kommunizieren, man musste mit den Teams reden, man musste ja auch dieses Vertrauen von den Leuten behalten, die noch geblieben sind und gleichzeitig sind auch sehr, sehr viele Leute gegangen, wo auch viel Wissen da war. Und wir haben auch sicher einiges an Wissen noch verloren mit diesen Schritten. Das heißt, es war jetzt auch nicht eine super einfache Entscheidung. Und als die Entscheidung dann aber auch passiert und umgesetzt wurde, natürlich, also es war sehr viel Last von diesen Growth-Bein, den ich erwähnt habe, einfach weg. Kommunikationswege waren kleiner. Man war näher am Kunden dran, weil plötzlich die Product Manager, die Tech Leads auch manchmal in Kundengespräche mit reingegangen sind, wo es davor noch einfach sehr viel mit uns selber beschäftigt waren. Jetzt waren wir plötzlich nur mal mit dem Markt beschäftigt, weil es einfach auch viel einfach fokussierter geworden ist. Und ich würde sagen, das waren alles so Faktoren, wo ich jetzt im Nachhinein sagen würde, wir sind schneller gewesen als kleiner, wie jetzt dann in diesem großen Format. Ich denke dennoch, das große Format kann natürlich auch schnell werden und kann auch gut funktionieren, wenn man dann länger durchhält und diese Strukturen und diese Systeme auch so aufsetzt, dass die natürlich dann auch noch mehr Impact bei den Kunden hervorrufen. Aber das dauert einfach an Zeit. Das muss man halt für sich selbst als Unternehmen genau wissen, wann ist was angebracht, in welcher Situation und was kann man sich tatsächlich leisten.

SPEAKER_00 32:03

Ja, das ist richtig. Und du sprichst zu einem sehr wichtigen Aspekt und ich möchte das auch nochmal hervorheben. Es gibt natürlich Learnings aus solchen Maßnahmen, die man treffen muss, die trifft man nicht, weil man einen schlechten Tag hat oder weil man Lust hat. Und trotzdem ist es wichtig, solche Entscheidungen zu treffen, damit das Unternehmen als solches existieren kann und die anderen auch weiter ihre Jobs behalten können. Und natürlich, auch wenn es dann positive Effekte von solchen Entscheidungen geht, ist es wichtig, das Ganze so zu machen, ohne zynisch zu werden gegenüber den Menschen, die halt vorher Teil der Organisation waren. Das ist auch nochmal ein sehr, sehr wichtiger Aspekt. Trotzdem ist es natürlich, bist du auch CTO und jetzt CEO, weil du in der Lage sein musst, solche und solche Entscheidungen zu treffen, wenn sie denn notwendig sind und auch mit und zu kommunizieren und durchzuziehen und so weiter.

SPEAKER_01 32:50

Das ist richtig. Und das ist, glaube ich, auch diese Schwierigkeit, ich würde auch nicht nur sagen beim Schrumpfen selbst, sondern auch generell in der Arbeit mit Menschen, in Teams, ist für sich selber zu verstehen, was ist für mich ein Fit, wie passt das eigentlich in meinen Teams, wie sollen die Mitarbeiter, also welche kulturellen Werte sollen sie erfüllen. Und das war auch für mich so ein Weg über die letzten zehn Jahre, nur weil diese Person für mich nicht passt, heißt es nicht, dass diese Person nicht woanders passt. Und ich glaube, das ist genau diese Schwierigkeit, dass es, wie du sagst, so ein bisschen, wo das leider in letzter Zeit auch so ein bisschen, würde ich fast sagen, entmenschlicht wurde. Dass es, würde ich eher sagen, einfach so wie es ein Product Market Fit gibt, gibt es auch einen fit zu unternehmen. Und den noch früh zu erkennen und mit den Personen auch offen zu reden, offenes Feedback zu geben und Entscheidungen einfach zu treffen in dieser Führungsrolle, das macht dich auch stärker als Unternehmen dann Christian. Und auch erhöht die Fairness auch gegenüber den Mitarbeitern, um ehrlich zu sein.

SPEAKER_00 33:53

Ja. Und wir sind, wir kommen ja auch aus einer Zeit, vor fünf bis zehn Jahren, in der natürlich der Ruf nach, wir brauchen einfach mehr Leute, der war schnell da. Das war natürlich auch in einer Situation, in der sehr viel Geld reingeflossen ist in dieses ganze, in dieses ganze Ökosystem, in der gleichzeitig Engineering immer noch sehr teuer war. Und eigentlich wird das jetzt so ein bisschen aus den Angeln gehoben, nicht nur durch die Veränderungen, die Art und Weise, wie investiert wird, sondern auch durch AI und welche Notwendigkeit dadurch entsteht. Siehst du heute noch viele Tech Leader, die sagen, oh, wir brauchen einfach mehr Leute? Oder ist das auch ein bisschen ein Relikt seiner Zeit gewesen und wir entwickeln uns jetzt gerade in eine andere Richtung, wo dieser Ruf einfach sehr viel seltener zu hören ist?

SPEAKER_01 34:40

Ja, ich glaube, es ist tatsächlich etwas sehr Gesundes passiert und das ist, dass seit alles jetzt eine Return-on-Invest-Rechnung braucht. Egal was man tut. Und das finde ich tatsächlich auch für mich selber angenehm. Weil wenn ich mir jetzt im Nachhinein überlege, wie Entscheidungen eigentlich in der Vergangenheit getroffen wurden, ja, das ist definitiv gut, dass man sich jetzt sich diesen Return on Invest überlegen muss. Ich glaube, wenn man sich die Gedanken macht, ob man tatsächlich mehr Personen braucht, ist einfach für mich selbst auch immer diese Übung, sich Gedanken zu machen, was wird passieren, wenn diese Person nicht eingestellt wird. Was kann ich nicht bauen, wenn diese Person nicht da ist? Was wird vielleicht langsamer gebaut werden? Und dann kann man sich immer überlegen, wie lange die Person zum Onboarding braucht, dann werden die ersten Ergebnisse sichtbar sein und dann sieht man auch sehr oft, wahrscheinlich hilft es gar nicht, jetzt eine Person mehr zu bekommen in dem Bereich. Oder man sieht auch, man ist tatsächlich schneller fertig mit einem bestimmten Produkt und dann hat man auch eine Rechnung dahinter, wo man auch sagt, ich beschleunige die Entwicklung um drei Monate, kann es früher verkaufen und das ist dann der Umsatz, den ich daraus sehen kann. Und ich glaube, das ist etwas, das sehe ich jetzt einfach immer mehr. Dass einfach dieser Gedanke vorweg. Und natürlich jetzt auch dieser ganze Push mit AI, der einfach da ist, wo man merkt, dass eine Person einfach produktiver sein kann. Also sie kann einfach mehr bauen als davor. Das heißt, man hat einfach einen Multiplikator auf jeden Entwickler, der jetzt im Team ist. Natürlich unterschiedlich ausgeprägt, je nachdem, wie weit die Person in der AI-Adoption ist. Aber auf jeden Fall ist immer ein Multiplikator drauf. Dann überlegt man sich ja auch, ob man tatsächlich jetzt nochmal heilen muss oder eher an der AI-Adoption arbeitet, an der Effizienz intern. Wie bin ich als Unternehmen überhaupt aufgestellt in dem Bereich? Das ist dann etwas, wo ich momentan, wenn ich so mit den Leuten spreche, eher den Fokus sehe, um ehrlich zu sein. Also es ist aktuell, sind alle eher damit beschäftigt, wir haben ein ganz neues Tooling in die Hand bekommen. Wie können wir das eigentlich effizienter nutzen, bevor ich jetzt unbedingt erhöhe. Und ich glaube, da entstehen dann wieder neue Herausforderungen, dass das natürlich nicht mit Null Euro an Kosten kommt, sondern tatsächlich Kosten dahinter stehen für die Modelle und ähnliches. Die verwende ich für die Tokens, die verbrannt werden. Und das sind dann wieder neue Herausforderungen. Was mache ich jetzt mit den Kosten?

SPEAKER_00 36:57

Wo werden die verbucht?

SPEAKER_01 36:58

Wie viele Kosten sind rechtfertigbar?

SPEAKER_00 37:00

Aber schön, dass du nochmal den Bogen schlägst zu der Zeit vorher. Und du jetzt auch mal, der sagst, ja, jetzt ist die Return-on-Invest-Rechnung, die ist sehr viel wichtiger. Vorher war die Rechnung ja einfach. Da hat man gesagt, es ist egal, was ihr einnimmt, wachst einfach nur. Und das Wachstum war der Indikator, der gezählt hat. Und die Profitabilität stand überhaupt nicht im Vordergrund und das hat sich jetzt geändert. Und jetzt ist die Frage, lass uns doch genauso schnell oder sogar schneller wachsen, aber gleichzeitig von vornherein profitabel sein. Und darauf, das ist der große Turnaround, den ich auch sehe. Auch nochmal schön, dass du das auch nochmal hier nochmal so hervorhebst. Du hast selber noch, also du bist ja selber von der CTO-Rolle dann zum CEO geworden oder Co-CEO. Wie kam es denn genau dazu, zu diesem Wechsel?

SPEAKER_01 37:46

Genau, der Wechsel wurde mir so ein bisschen auch irgendwie so, das war jetzt nicht so, dass irgendein Plan dahinter war oder so, es wurde eigentlich irgendwie so aufgedrückt und der Hintergrund war einfach, dass der Mitgründer aus dem Unternehmen ausgeschieden ist, der diese Rolle davor belegt hat. Und dementsprechend musste ich irgendwie diese Rolle übernehmen. Und dann gab es die Wahl, kommt jetzt irgendein externer oder mache ich das? Und da einfach am meisten Kontext vom Unternehmen bei mir lag, bin ich da irgendwie reingerutscht in diese Rolle. Bist du dann immer noch CTO gleichzeitig? Genau, das war jetzt so, dass ich den Head of Engineering zum CTO gemacht habe, damit ich wirklich den vollen Fokus auf die CEO-Rolle geben kann. Jetzt in dieser Co-CO-Rolle mit Wunder Mobility habe ich wieder die CTO-Slash-CPO-Verantwortung bei mir gebündelt. Dort am bekannten dezidierten CTO. Und ich glaube, dieser Switch, der für mich damals tatsächlich so, auf der einen Seite, ich glaube, das CTO hat man, lieber man manchmal mit dieser CEO-Position und man findet das gut, dass man bestimmte Sachen dann einfach selber entscheiden kann, wo man sonst sie nicht versteht. Und dann merkt man plötzlich, dass man in dieser Rolle ist und dass man extrem aufpassen muss auf einem ganz anderen Niveau, was man kommuniziert, wie man kommuniziert. Die Mitarbeiter schauen ganz anders auf dich, im Sinne von irgendwelchen Meldungen, die du irgendwo von dir äußerst. Du musst lernen, wie du richtig kommunizierst, richtig schreibst. Das ist alles viel weniger sensibel, finde ich, in der CTO-Rolle, weil der Impact einfach nochmal deutlich größer ist im Unternehmen und im Vertrauen der Mitarbeiter. Und das heißt nicht natürlich, dass ein CTO da sorglos sein kann, aber es wird einfach nochmal mehr hingesumt auf zum Beispiel Rechtfertigung von strategischen Entscheidungen. Und das fand ich für mich war echt tatsächlich die größte Umstellung und dieses Gefühl von, ja, jetzt kann ich zwar selber entscheiden, aber es ist eigentlich noch viel komplexer geworden und ich musste eher entscheiden, was wir nicht tun, als das, was ich gerne tun wollen würde.

SPEAKER_00 39:47

Naja, und wenn du jetzt natürlich noch den Hut auf hast und quasi Co-CEO bist, aber gleichzeitig noch CTO-CPO, dann hast du auch mehrere Verantwortlichkeiten in einer Rolle vereint. Das ist natürlich A, mehr Macht- und Gestaltungsmöglichkeit. Das ist aber auch in der Komponente, also du musst ja intern mit dir auch in den Diskurs gehen und der CEO müsste mit dem CTO eigentlich auch diskutieren. Und bestimmte Entscheidungen, die du aus CEO-Sicht treffen würdest, würdest du vielleicht aus CEO-Sicht nicht treffen. Wie gehst du denn damit um?

SPEAKER_01 40:18

Ich glaube, wir haben sicher Kompromisse intern wegen dieser Aufstellung, aber ich glaube, vor allem jetzt im Zeitalter von AI ist es gar nicht so schlecht, um ehrlich zu sein. Ich bin extrem auch produktgetrieben aktuell und ich glaube, dass jeder in seiner Engineering-Kultur jetzt diesen Impact, den jeder einzelne Engineer im Produkt erzeugt, also beim Kunden, dass das jetzt ins Zentrum drücken muss. Und ich finde es momentan extrem hilfreich tatsächlich, dass ich aus der Rolle heraus das auch bedienen kann, diese zwei Rolle. Wegen Geschwindigkeit, wegen der Geschwindigkeit bei Entscheidungen, plus weil ich sehr nah im Kunden bin und diesen Impact einfach direkt sehe, den meine Teams erzeugen und direkt Feedback geben kann in die Teams und auch die Systeme nachschärfen kann, wie wir Impact messen, wie unsere Product Manager priorisieren, wie die Tech Leads Kontext vom Problem verstehen. Ist da genug Kontext da? Welches Tooling haben wir, um überhaupt die Nutzung zu erfassen und ähnliches? Und ich glaube, das ist jetzt ein elementarer Shift, der jetzt bei vielen passiert, weil die Codegenerierung selbst ist jetzt unfassbar günstig und in Anführungszeichen. Mal schauen, wie es mit den Tokenkosten weitergeht. Aber es ist auf jeden Fall im Vergleich zu davor trotzdem sehr günstig geworden. Und jetzt kommt es vielmehr darauf an, auf der einen Seite natürlich das Problem zu verstehen, aber auch die Lösung für dieses Problem zu bauen und dann auch zu validieren. Und den Shift merke ich, dass jetzt die Zeit vom Ingenieur strumpft in der Delivery und immer stärker in dieses, was bauen wir und wieso bauen wir das überhaupt. Und auch zu verstehen, war ich jetzt erfolgreich mit dem, was ich gebaut habe. Das ist sehr spannend, wenn ich aktuell diese ganze Stift.

SPEAKER_00 42:04

Ja, du hast gerade die Token-Kosten erwähnt. Was ist denn, also da gibt es ja durchaus mehrere unterschiedliche Positionen dazu. Die einen sagen, oh, die Tokenkosten werden steigen, weil diese Unternehmen machen halt die ganze Zeit Verlust. Das heißt, die müssen ja eigentlich steigen. Ganz ehrlich, halte ich für eine Milchmädchenrechnung und das wird so nicht passieren. Aber wie siehst du das? Du darfst mir gerne da hart widersprechen.

SPEAKER_01 42:29

Ich tue mir so schwer, jetzt hier eine Antwort zu liefern, weil am Ende vom Tag, ich habe jetzt so viele verschiedene Antworten gehört. Ich habe von Unternehmen gehört, sie spenden pro Engineer, haben sie Kosten von 3000 Euro pro Ingenieur für die Token Usage. Dann andere 1500, dann andere, die sind nur bei 50. Das heißt, es gibt sehr viele verschiedene Sachen. Ich glaube, um ehrlich zu sein.

SPEAKER_00 42:51

Das sind die Kosten, das sind ja nicht die Token-Preise.

SPEAKER_01 42:53

Das sind nicht die Token-Preise, richtig. Aber ich würde sagen, das wird sich auf jeden Fall einpendeln. Ich glaube auch nicht daran, dass es irgendwie großartig explodieren wird, um ehrlich zu sein. Da ist auch so viel Konkurrenz am Markt, da tut sich die ganze Zeit so viel. Da kommen jetzt plötzlich sehr spezialisierte LLMs heraus, die vielleicht an der Qualität gar nicht dem Aktuent so hinter nachstehen. Und solange Entropic sich nicht sicher wiegt, dass sie in der Position bleiben, wie sie sind, werden sie weiterhin das alles subventioniert.

SPEAKER_00 43:21

Ja, vor allen Dingen, es muss ja auch nicht heißen, dass das gerade subventioniert wird, sondern vielleicht, wenn du Forschung und Entwicklung, wo ja gerade auch ein sehr großer, also substanzieller Teil des ganzen Unternehmens da reinfließt, wenn der mal nicht mehr einen so großen Fokus hat, dann kannst du ja genau, dann hast du einen, dann kannst du viel weniger kosten und bist dann vielleicht sogar auch mit den gleichen Token-Preisen, bist du eventuell schon profitabel. Ganz davon abgesehen sind natürlich neue Modelle, die im Premium-Bereich dann rauskommen mit noch viel krasserer Leistung, die sind vielleicht auch erstmal teurer. Aber wenn du mal siehst, wie sich, also das kannst du ja mittlerweile auch statistisch, kannst du ja belegen, wie sich die Tokenpreise für die Über die Modelle hinweg entwickeln. Die kommen teuer raus, wenn sie ganz neu sind, und dann gehen die Kosten halt über die Laufzeit halt immer runter, weil es immer mehr Commodity wird. Und dann kommt irgendwann ein neueres Modell raus, da sind die Tokenpreise wieder hoch und dann geht es über die Dauer immer noch runter. Was natürlich gerade halt substanziell steigt in den Unternehmen, ist der Verbrauch. Aber, und das ist mein Hottake hier, weil da einfach noch, ich sag's mal so lapidar, einfach schlechte Designentscheidungen getroffen werden, oder gar keine Token-Ökonomie intern betrieben wird, sondern die Leute einfach diverse Prompts schreiben, ihr gesamtes Wiki mit reinklatschen als Kontext, ja, da muss man sich nicht wundern, wenn die Tokenpreise nach, oder nicht die Tokenpreise, wenn die Kosten für AI in die Höhe gehen. Aber das hat ja erstmal mit den Tokenpreisen nichts zu tun.

SPEAKER_01 44:46

Genau, und ich glaube, du sprichst was etwas Wichtiges an, das ist dann alles das Thema der Optimierung. Und da gibt es ganz, ganz, ganz viel Potenzial, die Kosten zu optimieren, wenn man sie mal in die Höhe geschossen sind. Ich glaube dennoch, dass es aktuell wirklich wichtiger ist, die AI-Adoption-Unternehmen voranzutreiben, die Budgetposten einfach mal vorzunehmen. Man freut sich tatsächlich ja lieber, dass die Leute das nutzen. Und wenn man merkt, dass man wirklich optimieren muss und die Adoption ist da, wo man sie gerne hätte, dann, so wie du sagst, gibt es ganz, ganz viele Möglichkeiten, dass man die Kosten dann auch senkt.

SPEAKER_00 45:15

Sehr schön, Bojan, wir sind auch fast schon am Ende der heutigen Aufnahme. Die Zeit rennt uns davon, aber ich glaube, wir haben jetzt genug Material auch noch in der Hinterhand. Wir verraten nicht, was das alles sein wird. Aber dafür werden wir uns nochmal zusammensetzen und werden dann einen zweiten Teil rausbringen. Aber für die Rapid-Fire-Fragen hast du noch kurz Zeit, oder? Auf jeden Fall. Sehr gut. Eine CTO-Entscheidung, die du heute anders treffen würdest.

SPEAKER_01 45:42

Das ist genau dieses Thema rund um Schützen von Senior Engineers, die tatsächlich die Atmosphäre eher negativ beeinflusst im Unternehmen als positiv und dass man die Entscheidung einfach verzögert.

SPEAKER_00 45:55

Sehr gut, wichtiges Learning. Eine Metrik, die jeder CTO jede Woche anschauen sollte.

SPEAKER_01 46:01

Vor allem jetzt mit AI auf jeden Fall Cycle-Time. Und Kosten.

SPEAKER_00 46:05

Nein, das ist aber Cycletime definitiv. Seht ihr bei euch einen positiven Effekt?

SPEAKER_01 46:10

Auf jeden Fall, aber ich merke auch, da ist sicher noch ein Weg vor uns, dass man, also sie ist noch sehr unregelmäßig. Und das ist etwas, wo man auch direkt sieht, dass man Ineffizienzen hat.

SPEAKER_00 46:21

Was ist denn ein Prozess oder ein Meeting, das du gerne sofort abschaffen würdest?

SPEAKER_01 46:27

Ich bin überhaupt kein Fan von Scrum und den ganzen Ritualen rund um Scrum. Und ich würde am liebsten sehr viele Meetings rund um Scrum abwerfen.

SPEAKER_00 46:36

Warum? Also ich erstmal dahingestellt, ohne Wertung, aber warum? Was sind deine, warum, was stört dich?

SPEAKER_01 46:45

Ich finde tatsächlich, dass irgendwie so dieser Peak von der Zusammenarbeit in einem klassischen Kanban-Board ist, mit einigen Meetings um dieses Kanban-Board herum und die Sprintplanung eher so ein Tool ist, um quasi dieses Korsett dem Team aufzuzwängen und sie zu kontrollieren, was haben sie geschafft zu delivern in diesen zwei Wochen, was konnten sie in Probleme lösen. Und wenn du aber ein seifes Team hast, die mit Kanban arbeiten, und die werden nicht durch die Sprintplanung schneller werden. Die werden eher eingestrengt werden, weil sie bestimmte Learnings, vor allem jetzt mit AI, nicht einfach bearbeiten können, sondern in diesem Zwei-Wochen-Block sich nicht bewegen können eigentlich. Du leider, eigentlich dezimierst du die Agilität dann.

SPEAKER_00 47:26

Ja, es war ein Hilfsmittel und das ist eine gute Frage. Auch vielleicht eine Frage, die man ja auch mal in einer anderen Weise noch erörtern kann. Vielleicht gibt es noch zu wenig Datenpunkte dafür, aber es war ein Hilfsmittel für eine Zeit, die vielleicht zu Ende ist. Und was macht das mit der Bedeutung von uns? Kann brauchen wir das noch? Brauchen wir noch diese zwei, drei Wochen-Zyklen, in denen wir uns bewegen? Oder ist alles sehr viel schneller und dann braucht es auch andere Formate dafür, um das zu moderieren? Vielleicht ist es schon.

SPEAKER_01 47:54

Es ist ein gutes Tool, um junge Teams, also die noch nicht lange zusammenarbeiten, in diesen Zusammenarbeit-Modus zu bewegen, dass man sich Gedanken macht, was will man am Lösen, was will man bauen. Aber sobald man seniorigere Teams hat, ist es eher destruktiv, würde ich fast sagen. Einfach viel zu viele Meetings und es macht halt eine langsamer.

SPEAKER_00 48:13

Ja. Weil was ist eine Fähigkeit, die dich als CTO oder CEO am meisten weitergebracht hat?

SPEAKER_01 48:21

Ich habe lernen müssen, sehr direkt zu sein in meinem Feedback und nicht versuchen, alles immer sehr schön zu verpacken. Und da geht es aber auch vor allem darum, dass du es nicht dich einfach auskottzt, sondern einfach deine Pennung, ehrlich sagst, aber auch gleichzeitig sehr offen und empfänglich und empathisch bist für die Gegenweinung. Damit du wirklich auch verstehst, eh, das denke ich, das denkst du. Und lass uns wirklich die beste Entscheidung im Sinne vom Unternehmen treffen.

SPEAKER_00 48:46

Wichtiger Punkt. Zum Thema AI, letzte Rapid-Fire-Frage für heute. Was ist denn aktuell überbewertet und was wird noch unterschätzt?

SPEAKER_01 48:57

Ich glaube, dass das Thema Velocity einfach viel zu stark im Mittelpunkt ist beim Thema AI. Ja, man kann halt Sachen wie schneller bauen, das hat aber sehr, sehr viele Fallen. Weil man dann auch quasi diesen klassischen Enterprise, zum Beispiel im Enterprise-Bereich Lösungen bauen, die einfach viel zu komplex sind, viel zu viele Sachen haben. Es ist eigentlich gar nicht klar, wieso ein Feature so aussieht, wie es aussieht. Also ich glaube, es ist komplett überbewertet, dieser Velocity-Gain. Und was komplett unterschätzt wird, ist der Fokus, den die Leute jetzt wirklich auf den Impact der Lösungen setzen müssen, die sie bauen. Und zu verstehen, jetzt baue ich zwar Sachen schneller, aber wie stelle ich sicher, dass es tatsächlich die Probleme gelöst hat? Und wie kann ich das dann konstant verbessern und welche Metriken messe ich?

SPEAKER_00 49:41

Wichtiger Punkt. Auch dafür kann es ja Lösungen geben, bei denen Agenten helfen können, das zu bewerten. Und natürlich ist der Enterprise-Kontext natürlich immer so das Hauptargument gegen viel Velocity-Gain bei AI. Dem würde ich trotzdem entgegenhalten, dass der größte Teil der Software außerhalb von Enterprises immer noch gebaut wird. Und das kann man sich auch auf LinkedIn mal anschauen mit einem Sales-Navigator, wie viele Engineers eigentlich im Dachraum in Enterprises arbeiten und wie viele denn nicht. Und das sind vielleicht nur 20 Prozent der Engineers, die in Enterprises sind. Man hätte vielleicht gedacht, dass das mehr sind, aber es sind nur so um die 20 Prozent. Das heißt, da muss substanziell viel mehr Substanz entstehen außerhalb davon.

SPEAKER_01 50:25

Gleichzeitig gewinnen aber oft die Produkte, die mit Simplicity bestechen und nicht durch Funktionsvielfalt in sehr vielen Use Cases. Und ich glaube, das ist halt eben dieses schwierige Thema, wie baue ich Sachen, die tatsächlich Probleme lösen, die einen Product Market Fit einfach hervorrufen. Und das AI hilft dir schneller, zum Product Market fit zu kommen, aber den überhaupt zu erreichen, das ist halt das Schwierige. Und ich würde jetzt so als Faustregel sagen, Syp, hast du vielleicht 30 Leute gebraucht, um ein bestimmtes Produkt zu bauen, jetzt brauchst du Nummer fünf. Aber der Weg zum Product Market fit ist immer gleich schön.

SPEAKER_00 50:56

Das ist gut möglich, ja. Da stimme ich 100% mit dir überein. Bojan, vielen lieben Dank. Wir haben eine Punktlandung hingelegt und wie gesagt, wir hören uns in ein paar Wochen auf jeden Fall wieder. Bis dahin erstmal nochmal vielen lieben Dank und bis zum nächsten Mal.

SPEAKER_01 51:11

Danke, bis zum nächsten Mal. Tschüss.

SPEAKER_00 51:12

Ciao, ciao.