Inside statt Outside Hire - Was echte Karrierewege im Tech wirklich brauchen - mit Nikolai Gulatz

In dieser Episode des Becoming CTO Secrets Podcasts spricht Philipp Deutscher mit Nikolai Gulatz, CTO und Mitgeschäftsführer von Instaffo - einer Plattform, die den Recruiting-Prozess für Tech-Talente radikal vereinfacht. Nikolai erzählt von seinem Weg vom Entwickler zur technischen Führungskraft und schließlich in die Geschäftsführung eines stark wachsenden Tech-Unternehmens. Dabei wurde er nicht extern eingestellt, sondern hat sich über viele Jahre intern entwickelt - eine Karriere, wie sie in der Startup-Welt selten geworden ist.

Wir sprechen über die Herausforderungen dieses Wachstums, über Mentoren, die entscheidende Weichen gestellt haben, und über die Umstellung vom operativen Entwickler zum strategischen Entscheider. Nikolai teilt offen, wie es ist, plötzlich vom Kollegen zum Vorgesetzten zu werden, wie er sich Produktverantwortung erarbeitet hat und wie sich die Rolle eines CTO im Spannungsfeld zwischen Business, Technologie und Produkt stetig verändert.

Ein besonderes Augenmerk liegt auf der Verbindung von Product und Tech: Warum gehören diese Disziplinen eigentlich untrennbar zusammen - und wo entsteht Reibung? Welche Rolle spielen Architekturentscheidungen, ROI und Refactoring im Alltag eines CTOs? Und wie gelingt es, Teams in einem 100 % Remote-Setup auf Produktziele auszurichten, ohne dass Sichtbarkeit, Vertrauen oder Kultur leiden?

Darüber hinaus gibt Nikolai Einblicke in den deutschen Tech-Arbeitsmarkt: Wie hat sich die Lage für Entwickler seit 2022 verändert? Was bedeutet der AI-Boom für Juniors? Gibt es noch einen Fachkräftemangel - oder nur ein Matching-Problem? Instaffo hat dazu einzigartige Daten und eine klare Meinung.

Ein Gespräch über Vertrauen statt Kontrolle, über Führung im Wandel, über Karrierewege jenseits von Exit und Hype - und darüber, wie man CTO bleibt, ohne die Verbindung zum Code zu verlieren.

🚀 Becoming CTO Secrets ist ein Podcast von Philipp Deutscher Consulting.

🎯 Interesse am CTO Coaching Programm? Mehr Infos findest du hier.

📘 Das Whitepaper "Entwickler Heute, CTO Morgen" zum Download.

💬 Vernetze dich mit mir auf LinkedIn!

Transcript

Philipp Deutscher (00:10)
Hallo und herzlich willkommen zu einer neuen Folge von Becoming CTO Secrets, deinem Podcast, ... wenn du aus der Tech Expertise heraus wachsen ... und strategische Führung übernehmen willst. Ich bin Philipp Deutscher, Fractional CTO Unternehmer ... und Coach für ambitionierte Entwickler, ... die echte Führung übernehmen wollen. Heute zu Gast ist Nikolaj Gulaz. Nikolaj ist der CTO von Instaffo, einer Recruiting Plattform, die man vielleicht sogar auch kennt, wenn man ganz viel OMR Podcast hört.

die aber auch dafür da ist, ... Talente und Unternehmen zu verbinden ... und er war dort einer der ersten Entwickler, ... ... hat es dann vom Software Engineer ... sich zum CTO und schließlich ... zum Mitgeschäftsführer entwickelt. Bei Instaffo verantwortet er heute ... sowohl die technische Entwicklung ... ... als auch das Produkt ... und ich freue mich auf ein spannendes Gespräch über seinen Weg, ... seine Rolle als CPTO, also der Verbindung von Product und Tech ... und was er natürlich auf diesem Weg gelernt hat. Nikolaj, herzlich willkommen hier.

im Podcast.

Nikolai (01:05)
Ja, danke und hi, danke für die Einladung. Ich freue mich auf das Gespräch.

Philipp Deutscher (01:08)
Sehr, sehr

Freut mich auch sehr, dass du meiner Einladung gefolgt

Vielleicht fangen wir so an. Kannst du uns ein bisschen was von deinem Weg erzählen? Also wie hast du bei InstaFo angefangen? Das war ja schon recht früh in deiner Karriere. Und wie bist du dann diesen Weg gegangen vom Entwickler bis zum CTO und bist dann in diese Region aufgestiegen?

Nikolai (01:24)
Hm?

Ja, es war definitiv sehr früh in meiner Karriere. ich habe schon während meines Studiums immer viel gearbeitet. Ehrlicherweise immer mehr gearbeitet als studiert. Also Arbeit war immer so eine Priorität Nummer eins. Studium ist immer ein bisschen nebenbei gelaufen. Immer schon im Bereich Web-Applikationen, ursprünglich viel mit PHP.

dann irgendwann tatsächlich aufgrund des Studiums Ruby für mich entdeckt. Gegen Ende von meinem Studium, das war so 2016, 2017, ich dann bei der Agentur gearbeitet, Launchwerk hießen die, die damals quasi als Auftragsarbeit, die die erste Version von Instafor entwickelt hat. Damals bei der Agentur dann nicht nur an Instafor gearbeitet, es gab

ziemlich viele unterschiedliche Projekte. Aber das war zu dem Zeitpunkt eines der größten Projekte, auf vielen anderen Dingen gearbeitet, vor allem im E-Commerce Bereich. Und Christoph und Daniel, die beiden ursprünglichen Gründer von wollten die Entwicklung von Instaffo aber auf jeden Fall inhausen. Und 2017 kam es dann dazu, dass die beiden Agenturgründer von Launchwerk die Agentur auch aufgeben wollten.

Und so bin ich dann letztendlich mit einem weiteren Kollegen, Patrick, der ist auch immer noch bei uns heute direkt zu uns davor gewechselt. Das war eigentlich mein erster richtiger Vollzeitjob dann. Das schon eine ganze Weile her natürlich. Und wir haben dann im Endeffekt, also Patrick und ich zu zweit, die Plattform

War eine super lehrreiche Zeit.

weil wir im Endeffekt so von jetzt auf gleich einfach auf einen Schlag die komplette Verantwortung hatten für die technische Entwicklung von Instaffo. Und es war zu dem Zeitpunkt dann auch schon live. Also ich glaube es ging live wahrscheinlich Anfang Mitte 2017, wenn ich mich richtig erinnere. die ersten Jahre. Also ich glaube ich war dann Mitarbeiter Nummer 6 oder 7 wahrscheinlich. Also wir waren...

Philipp Deutscher (03:14)
Wie viele Leute wart ihr damals?

Nikolai (03:21)
Auf jeden Fall noch ein super kleines Team. 7-8 Leute, wahrscheinlich zusammen mit Christoph und Daniel. Also war schon noch sehr early und dynamisch.

Philipp Deutscher (03:31)
Aber was

waren denn so die größten Herausforderungen auf diesem Weg? Also, ihr seid ja Spezialisten im Recruiting, das heißt, du weißt ja auch, dass ganz viele C-Level-Rollen nicht innerhalb des Unternehmens besetzt werden, sondern oft dann extern gesucht werden. Deswegen der Werdegang vom Entwickler im Unternehmen bis hin zum CTO und das auch noch heute noch, nicht nur von bis jetzt, das ist ja eine ganz schöne Strecke, das ist ja durchaus ungewöhnlich.

Gab es da Momente, in denen du daran gezweifelt hast, der Verantwortung gerecht zu werden oder in denen du ganz besonders aus deiner Komfortzone heraus musstest?

Nikolai (04:04)
Ja definitiv, also von Anfang an. Es war ja so wie gesagt die Situation, dass wir auf einmal zu zweit dann erstmal verantwortlich waren für die ganze Entwicklung. So klar ich war dann kein CTO aber im Endeffekt...

haben wir ja trotzdem zu zweit alles zusammen geowned. Und das war schon erstmal krass, aber es war auch eine super lehrreiche

Ich habe

paar Jahre super viel selber gecodet. Wir haben das Ding zu zweit sicher viele hunderttausend Zeilen Code

War sehr intensiv, da es davon natürlich auch super early war.

und sich die Prioritäten dann beinahe täglich geändert haben. Aber ich habe wirklich super viel gelernt. dem wurden quasi beide ins kalte

geworfen. Und ja, so hat sich das dann

Wir hatten zuerst einen Werkstudenten eingestellt.

Dann wahrscheinlich so nach einem halben Jahr den ersten Fulltime-Entwickler auch und dann so nach und nach das Team aufgebaut. Von der Businessseite her hat es eigentlich auch ganz gut geklappt von Anfang so hat sich das dann entwickelt. Aber ich habe, wie gesagt, eigentlich die ersten paar Jahre war ich auch noch nicht in der CDO, sondern nur, Anführungszeichen, Entwickler und habe dementsprechend einfach super viel Hands-on gearbeitet.

Philipp Deutscher (05:17)
Und wie seid ihr technisch aufgestellt? Ist das dann hauptsächlich PHP, dem es dafür beruht? was habt ihr für einen Texteq?

Nikolai (05:24)
Nee, PHP

gar nicht. Also ich habe früher viel mehr PHP gemacht. Instaffo war von Anfang an Ruby on Rails Application. Ich bin auch über Ruby quasi zu dem Job gekommen, in der Uni hatten wir dann so einen Kurs, wo es Ruby ging und da habe ich mich so bisschen in die Sprache verliebt, weil man PHP gewohnt ist. Also Ruby ist schon schöner. Es ist angenehmer zu schreiben.

Philipp Deutscher (05:32)
Okay.

Nikolai (05:49)
Und wir laufen auch heute noch hauptsächlich auf Ruby und Rails, wobei ein großer Teil von dem Data Stack mittlerweile auch Python ist, aber so unser großer Monolith ist auch immer noch Ruby.

Philipp Deutscher (06:00)
Okay, das heißt, ihr seid auch faktisch noch auf der gleichen Architektur unterwegs, mit der ihr 2017 gestartet seid und oder du hast eben den Monolithen erwähnt, das klingt ja auch so, als wäre da ein System gewachsen im Laufe dieser Jahre, das ihr jetzt noch in der gleichen Art und Weise maintaint.

Nikolai (06:17)
Ne ganz so nicht, also da gab es mit Sicherheit viele Iterationen dazwischen. hatten zwischendurch tatsächlich einen größeren fast kompletten Rewrite gemacht von der

Gar nicht so sehr wegen des Backends, sondern vor allem wegen des Frontends. Wir haben, das war ursprünglich gar keine Single Page Application, sondern somit

mit JQuery und allem zusammengebastelt. Und irgendwann haben wir dann gesagt, wer schon mal eine größere JQuery-Application maintain hat, der weiß, dass das ein riesen Pain ist. Dann sind wir Richtung SPL gegangen, haben uns für React entschieden. Haben in dem Zug dann auch kompletten Rewrite von der Chord-Base gemacht. Das war wahrscheinlich so...

2018, 2019 rum. Auch mit einem größeren Relaunch. die jetzige Plattform gibt keinen Code mehr von Anfang. glaube, seitdem haben wir es dann so langsam wieder neu aufgebaut.

Philipp Deutscher (07:14)
Würdest du heute auch noch mal mit Ruby on Rain starten?

Nikolai (07:17)
Also es hat Vor- Nachteile. glaube der Vorteil ist schon, dass Ruby und Ruby on Rails ist mit Sicherheit eines der produktivsten Frameworks. mir ist kein anderes Framework bekannt, wo man so produktiv sein kann, auch mit nur einem back-end Entwickler, weil einfach der Abstraktionslevel so hoch ist. Außerdem ist Ruby, schon habe ich ja vorher schon gesagt, ich finde es eine sehr schöne Sprache.

man kann aber sehr, sehr schön einen eleganten Code schreiben. Es ist aber natürlich schon so, dass es auch ein Nachteil sein kann. Ich sehe den größten Nachteil tatsächlich darin, dass es sehr schwer ist, gute Rails-Entwickler zu finden.

Philipp Deutscher (07:52)
Das wäre meine nächste Frage

gewesen tatsächlich.

Nikolai (07:53)
Genau, weil

es einfach nicht so

kenne die Zahl nicht, wie viele Rails-Entwickler es in Deutschland gibt, aber es ist mit Sicherheit ein ganz winziger Bruchteil, verglichen jetzt mit Python oder TypeScript oder auch PHP. Und das merkt man schon im Hiring, dass es deutlich schwieriger ist, Leute zu finden. Andererseits braucht man meiner Meinung nach in so Rails-Setup auch deutlich weniger Backend-Entwickler.

Philipp Deutscher (08:16)
Aber seht ihr euch dann auch im Vorteil dadurch, ihr ja quasi auch mit der Toolchain, die ihr auch als Produkt anbietet, ja quasi im Driver-Seat seid, irgendwie perfektes Recruiting zu machen.

Nikolai (08:27)
Ja, ist natürlich ein Vorteil. Also wir merken es auch ganz stark. die letzten fast alle Product- und Tech-Rollen, die wir eingestellt haben, wir über unsere Plattformen gehired. Also es schon ein Riesenvorteil im Recruiting, vor allem weil wir es halt auch viel besser selbst machen können. Wir haben eine geringere Abhängigkeit von HR. So, das klappt nicht für alle Rollen natürlich, aber wir können da schon einen großen Vorteil rausziehen.

aber bei Ruby und Rails ist es natürlich so, du brauchst halt auch einfach die Leute auf der Plattform. Und dadurch, dass es halt auch ansonsten nicht so super viel Rails-Jobs gibt, ist es, auch wenn es davon natürlich auch nicht ganz so einfach da den richtigen Fit zu finden. Also das ist zum Beispiel im Fullstack-Bereich, wenn es jetzt zum PHP geht, TypeScript oder auch im Frontend-Bereich deutlich einfacher.

Philipp Deutscher (09:17)
Ja, das stimmt. Aber auch weniger elegant oder auch gut skalierend dann teilweise. Wie hat sich denn deine Rolle dann im Laufe der Zeit verändert? Was ist dir da auch am schwersten gefallen? Ich meine, Instaffo ist stark gewachsen. Du musstest dich mit Sicherheit mehrmals neu orientieren oder transformieren oder weiterentwickeln, neue Fähigkeiten erlernen, dann auch mitzuhalten mit dem Wachstum. Und ich hatte ja am Anfang angesprochen, ich finde das ja beachtlich, dass du immer noch da bist. Das bedeutet ja auch dein Wachstum.

Nikolai (09:22)
Ja.

Mh.

Philipp Deutscher (09:45)
hat mit dem des Unternehmens mitgehalten. Das Unternehmen ist auch so schnell gewachsen, du gewachsen bist, dass beides so im Gleichschritt verläuft und man beide über so lange Zeit voneinander profitiert. Das sieht man ja in nicht so vielen

Der Mitarbeiter entwächst der Geschwindigkeit des Unternehmens, verlässt es dann und macht woanders seine Karriere weiter. Oder das Unternehmen wächst schneller, als der Mitarbeiter in der Lage ist, sich zu entwickeln und dann wird er irgendwann

nicht ersetzt, aber dann kommt jemand anderes, der die Rolle vor ihm kriegt. Wie hat sich deine Rolle mit dem Wachstum des Unternehmens dann verändert?

Nikolai (10:18)
Also ständig natürlich. Also ich habe am Anfang wie gesagt vielen noch selber entwickelt. Ich habe dann 2019 glaube ich die CTO Rolle übernommen, weil wir einfach gemeinsam überlegt haben, wie wir auch das Unternehmen und Product & Tech in Zukunft weiter strukturieren wollen. Und 2021 dann auch, seit 2021 bin ich einer der beiden Geschäftsführer zusammen mit Christoph, auch einer der Gründer.

Und auf dem Weg ist natürlich super viel Es kamen immer neue Aufgaben dazu, immer neue Sachen, die man lernen muss. Ich habe dann auch 2021 die Verantwortung für Produkt als Ganzes übernommen. Also nicht nur Technologie, sondern auch das war natürlich dann schon so ein Punkt, wo

wo ich noch mal extrem viel dazulernen musste. Also ich habe das ja vorher noch nie wirklich gemacht. Ich kam eher aus dem technischen Bereich. Ich glaube, ich hatte schon immer eine gewisse Affinität zu den Themen im Produkt und zu Business und auch zu Your I.O.X. Aber habe das vorher natürlich nicht so in der Art und Weise verantwortet.

und habe mich dann erstmal super intensiv mit dem Thema Produktentwicklung beschäftigt. So alles dazu gelesen, was ich finden konnte. Die ganzen PM-Klassiker-inspired, Escaping the Build Trap und so weiter und so fort. Also hatte einfach viel auch nachzuholen, weil wir waren ja damals schon an der Stage.

wo wir auch schon ein paar Millionen Euro Umsatz gemacht haben letztendlich. Ich war aber in dieser Produktrolle quasi nicht komplett neu. Ich habe ja vorher auch schon daran entwickelt, aber die Verantwortung war definitiv neu. Und ehrlicherweise auch viele falsche Entscheidungen getroffen am Anfang, aus denen ich zum Glück auch, denke ich, viel gelernt habe, was ich heute anwenden aber ich glaube,

einem klar sein muss in einem wachsenden Unternehmen, muss man sich ja immer ständig weiterentwickeln mit dem Unternehmen. Selbst wenn man sich in der bestehenden Rolle nur weiterentwickeln muss. Und das ist natürlich nochmal eine besondere Herausforderung, wenn sich eben auch die Rolle verändert.

Philipp Deutscher (12:20)
Und wie hat es angefühlt, CTO zu werden? Das war ja dann doch im Vergleich zu vielen anderen einer relativ frühen Phase deiner Karriere. 2019 hast du eben gesagt, das? es dann für dich nur die logische Konsequenz dessen, was du sowieso zu dem damaligen Zeitpunkt schon gemacht hast? Oder was hat sich konkret dann in dem Moment verändert, wo du diesen CTO-Titel dann in deinem E-Mail-Food da drin hattest?

Nikolai (12:24)
Ahem.

Hm?

Ja, teilweise war es so natürliche Entwicklung, weil ich ja vorher auch schon viel einfach Verantwortung übernommen habe über technische Themen. Was sich aber natürlich schon geändert hat, dann auch die, sag ich mal, die formelle Verantwortung, dass man dann plötzlich der Vorgesetzte ist von der ganzen Abteilung letztendlich. Und das war schon eine Herausforderung.

Was ich damals auch schwierig fand, war aus dieser IC-Rolle rauszukommen. Also ich hatte ja bis 2019, 2020 quasi noch als normaler Entwickler wirklich mit im Team gearbeitet, bei den Sprint Planings dabei, hab mehr Issues assigned, hat Merchants erstellt, hab Code Reviews gemacht und das ganze schon gewöhnungsbedürftig war,

war dann diese neue Situation, wo man quasi seine eigene Contribution gar nicht mehr so klar messen und sehen kann. Also wenn man codet, dann arbeitet man letztendlich Issues ab. Man macht Merchal Cast, man released Features, so am Ende vom Tag kann man dann sehen, okay, genau das habe ich jetzt gemacht, das Feature ist live.

Das Review ist abgeschlossen. Das ist in so einer Leadership-Rolle nicht unbedingt immer so. Das war auf jeden Fall erst mal gewöhnungsbedürftig, auch weil es ja schon so war, dass mir das Coden Spaß gemacht

musste ich mich auf jeden Fall dran gewöhnen. Aber es ging eigentlich, es hat nur zwei, drei Monate gedauert, dann bin ich da, glaube ich, schon sehr gut angekommen mit der neuen Rolle.

Philipp Deutscher (14:07)
Ja, das ist ja eine Veränderung, die sehr viele haben, die sich in so eine Richtung weiterentwickeln. Der Unterschied zwischen vorher bist du produktiv ... und du kannst die Produktivität ja in irgendeiner Art Weise messen, ... sei es in Tickets oder sei es, jetzt euer Sprint-Call erreicht, ... aber wie misst du dann am Ende des Tages dann ... ... den Impact oder die Wirksamkeit als CTO? also du hast es ja gerade selber beschrieben, aber hast du dann für dich einen Weg gefunden, wie du dann selber

sicherstellen kannst, dass du wirksam bist in dem, was du tust als CTO?

Nikolai (14:35)
Ja, meine, im Endeffekt muss man halt verstehen, als Lead, egal was jetzt der Titel ist, aber als Lead ist der der Outcome von deiner Rolle, ist letztendlich einfach der Team-Outcome. Und man muss sich dran gewöhnen, dass man nicht mehr selber nur mit Individual Contributions sozusagen den Outcome erzeugen kann.

sondern dass es eben andere Mechanismen gibt, wie zum Beispiel gute Ziele zu setzen, Leute zu coachen, locker aus dem Weg zu räumen, als Sparingpartner da zu sein. Und das ist eben ein bisschen mehr eine indirekte Beziehung zum Outcome. Aber im Endeffekt hat man dadurch ja absolut gesehen deutlich mehr Outcome, weil dann der Outcome von einem selbst ist letztendlich der Outcome von dem ganzen Team.

Philipp Deutscher (15:22)
Die Frage ist natürlich auch, warum bist du dann als den, du warst ja nicht der einzige Entwickler zu dem damaligen Zeitpunkt, warum bist du dann CTO geworden? es, weil du sagst, du warst auch derjenige, der am meisten Verantwortung übernommen hat, am meisten mitgeschultert hat, warst du der am meisten irgendwie die Kohlen aus dem Feuer geholt hat, als es dann irgendwo kritisch wurde, aber was hat dich jetzt im Vergleich zu anderen prädestiniert, in diese Rolle reinzuwachsen? Vielleicht eine schwierige Frage so natürlich, aber vielleicht, wie hast du das wahrgenommen?

Nikolai (15:49)
Ja.

Also ich glaube, ich hatte schon einen gewissen Hunger auf Impact und auch einen gewissen Grid, das dann zu erreichen. Das ist glaube ich schon sehr wichtig, ohne dass es jetzt irgendwie so Ellenbogen-Mentalität geht. Aber dass man eben

als sehr klares Ziel für sich selber definiert hat, man was gemeinsam mit der Company erreichen will. Und ich war schon immer so,

dass ich auch sehr gerne an solchen Entscheidungen dann mitgewirkt habe, es dann auch strategische Themen geht. Was machen wir als nächstes? Das jetzt nicht technologischen Topics. Und das brauchen wir, glaube ich, auch unbedingt in so einer Rolle.

Philipp Deutscher (16:30)
War es dann schwierig, auf einmal vom Kollegen zum Chef zu werden oder war die Entwicklung vielleicht fließender oder gradueller als das vielleicht der Anschein hat?

Nikolai (16:41)
Ja, war definitiv auch eine Herausforderung. Ich sehe das im Nachhinein aber eher als Stärke, dass ich vorher mit dem Team gearbeitet habe und dann auf einmal der Chef war. Weil ich denke, dadurch hatte ich sehr viel Vertrauen auch einfach im Team. Also dadurch, dass ich vorher wirklich hands-on mit fast jedem gearbeitet habe.

und alle wussten, ich weiß auch, wie Softwareentwicklung geht. Ich war ja auch, denke ich, ganz guter Entwickler und dadurch war schon ein sehr hohes Maß an Vertrauen von Anfang an da, was ich mir nicht erst erarbeiten

Ich glaube, trotzdem war es mich wahrscheinlich schwieriger als für das Team. Was mir ...

schwergefallen ist und das ist ja bei den meisten so, ist auch negatives Feedback richtig zu geben, auch mal schwierigere Situationen confident zu handeln. Hat mich auch viel mit guter Kommunikation beschäftigt, natürlich auch viel Bücher gelesen, auch mit unterschiedlichen Coaches zusammengearbeitet. Es war glaube ich schon ein extrem großer Vorteil, dass ich quasi diesen Vertrauensvorschuss

vom ganzen Team hatte und ich mir das nicht erst erarbeiten musste. Was man ja hat, wenn jemand jetzt zum Beispiel von extern dazukommen würde.

Philipp Deutscher (17:52)
Spannend. Also du hast jetzt weniger den Widerstand aus dem Team gemerkt, die dich dann in der Rolle nicht annehmen wollten, sondern es war dann eher, du hast dich selber noch in der Rolle orientieren müssen und feststellen müssen, wie du die am besten einnimmst. Und daher ist dann die Unsicherheit oder Konflikte daraus entstanden?

Nikolai (18:10)
Ja, genau. Also was mir damals extrem geholfen hat, ich habe mit einem anderen erfahrenen CTO zusammengearbeitet, Andreas, wenn er das hört, schaut er dann ihn. Der hat mich wirklich super stark, ich kann ihm auch mal schreiben.

Philipp Deutscher (18:22)
Darf auch gerne zu uns in den Podcast kommen.

Nikolai (18:26)
Der hat mich wirklich super stark gechallenged und dadurch weitergebracht. Derzeit, dem er quasi immer wieder gesagt hat, du bist jetzt im Driver's Seat, du musst deine Meinung vertreten, du musst Entscheidungen treffen, es hängt letztendlich an dir. Und das war erstmal auch ein bisschen beängstigend, aber bei mir hat es dann irgendwann so Klick hat den Schalter umgelegt und dann lief auch alles auf einmal viel besser.

Philipp Deutscher (18:50)
Das ist ja was, was ganz viele gar nicht haben, den Mentor oder den Sparing-Partner, der sich auch immer wieder die Zeit für einen nimmt, genau diese Entwicklung mitzubegleiten. Hast du das Gefühl, du wärst weniger gut vorangekommen, wenn du das nicht gehabt hättest? Kannst das im Nachhinein so sagen? Oder hat dir das wirklich noch mal den Boost gegeben, den du gebraucht hast, sei es jetzt im Selbstverständnis oder tatsächlich im Mindset?

Nikolai (18:55)
Nein.

Ja, definitiv. Also ich glaube, das war wirklich so eine Art Pivot-Moment letztendlich, das Coaching mit ihm. Auch jemanden an der Seite zu haben, wirklich die Herausforderungen in der Rolle gut versteht, wo es jetzt nicht nur irgendwie Persönlichkeitscoaching geht, sondern auch wirklich ganz konkret hands-on die Themen, die man als CTO eben auf dem Tisch hat.

Philipp Deutscher (19:37)
War der schon da oder hat er schon mit dir gearbeitet, als du noch kein CTO warst und hat dich dann mitbegleitet auf diesem Weg? Oder ist er dann in den Fokus gerückt, als du dann diese Rolle hattest und er hat Angst, komm ich nehm dich bei der Hand und wir machen das zusammen. Also ein bisschen im übertragenen Sinne.

Nikolai (19:50)
Ja,

hat uns damals begleitet in diesem Prozess zur CTO Rolle. Als wir damals diese Doppelspitze hatten mit Patrick und mir, wo wir viel zusammen gemacht haben und es dann die Entscheidung geht, wer übernimmt den Lead bei uns davor, hat er uns in dem Prozess begleitet und ich habe dann noch ein paar Monate später mit ihm zusammengearbeitet.

Philipp Deutscher (20:13)
Und wie siehst du dich

du dich eher als Unternehmer? Siehst du dich eher als CTO, also als reiner CTO oder bist du dann doch noch Entwickler im Herzen? du bist ja mittlerweile auch ein Teil der Geschäftsführung. Nicht jeder CTO ist automatisch Teil der Geschäftsführung, sondern das kommt ja nochmal on top. Wie hat sich dann deine Selbstwahrnehmung dann verändert, seitdem du nicht mehr nur Coder oder Entwickler bist, sondern auch dann strategischer Entscheider? Hast du dann immer noch so zwei Herzen, die bei dir in ...

Nikolai (20:28)
Hm.

Philipp Deutscher (20:41)
der Brust schlagen oder hast du dich dann für eine Seite entschieden?

Nikolai (20:44)
Ja, es ist definitiv beides. Also ich würde mich nicht

% Unternehmer bezeichnen, aber natürlich auch nicht als 100 % Entwickler. Also das ist ein bisschen was von beiden Seiten. Ich glaube, das eine schließt das andere auch nicht unbedingt aus. Also im Endeffekt ist Software entwickeln ja auch eine unternehmerische Tätigkeit. Also egal, ob man jetzt selbst codet oder eher die Richtung vorgibt. Deswegen sehe ich da keinen so großen Widerspruch.

Und ich glaube auch tatsächlich unternehmerisches Denken ist ein unglaublich wichtiger Skill für jeden Entwickler. Ich sehe mich aber schon tendenziell vielleicht ein bisschen in Richtung eher als Entwickler als als Unternehmer, weil ich schon noch ganz gerne bei manchen Themen in the details bin, Hashtag Foundermode. Also ich code jetzt natürlich nicht mehr selbst im Day to Day, aber ich beschäftige mich immer noch gerne

Mit Code, mit manchen Details probiere ich jetzt vor allem mit AI natürlich auch viele Sachen selbst aus, weil ich schon denke, dass es wichtig ist in der Rolle noch relativ nah an der Technologie zu sein. man braucht immer

so eine gewisse Connection mit dem, was quasi die Entwickler machen und wie die Infrastruktur aussieht, wie die Architektur funktioniert, was für Frameworks wir verwenden und diese ganzen Themen.

Philipp Deutscher (22:10)
Ja, du hast gerade was gesagt. Da habe ich jetzt gerade überlegt. Du hast gesagt, Softwareentwickler zu sein ist ja auch eine unternehmerische Tätigkeit. Das finde ich spannend. Also da würde ich mal gerne wissen, wie du das siehst. Weil auf der anderen Seite sagst du dann, ja es wäre ja gut, wenn mehr Softwareentwickler halt wie ein Unternehmer halt denken würden. Das unterschreibe ich. Aber wie ist dann der Twist zu Softwareentwicklung oder Softwareentwicklung zu betreiben, ist ja auch eine unternehmerische Tätigkeit.

Nikolai (22:33)
Letztendlich stellt man ja ein Produkt her, was verkauft wird. Klar, der Software-Entwickler ist meistens nicht derjenige, der es verkauft. Es kommt aber natürlich auch bisschen immer auf das Produkt an. Also bei uns ist es ja zum Beispiel so, Instaffo als Jobplattform, wir haben im Tech-Bereich angefangen.

ist auch immer noch unsere größte Jobkategorie gerade. Das heißt, die allermeisten von unseren Nutzern sind auch Softwareentwickler, DevOps Engineers, Data Scientists, Machine Learning Engineers und so weiter und so ich erwarte schon von jedem Entwickler bei Instaffo ein gewisses Maß an, dass man sich auch mit den Usern ein bisschen identifizieren kann, weil das ist ja letztendlich die gleiche Zielgruppe.

und da auch nicht nur, sage ich mal, Dienst nach Vorschrift zu machen, sondern auch mal Input zu so von unseren besten Ideen sind auch Ideen, quasi von den Entwicklern kamen, aus dem Tech-Bereich, weil es ja auch oft darum

einmal eine gewisse

Empathie zu haben mit dem Jobsuchenden und ein Entwickler kann sich, denke ich, deutlich besser mit einem Entwickler-Jobsuchenden identifizieren als ein Produktmanager, weil die Themen dann noch mal bisschen besser versteht. Und andererseits gibt es auch viele

wo Technologie einfach ein Enabler sein kann für gewisse Features oder um gewisse Probleme zu lösen.

Philipp Deutscher (23:50)
Also erwartest du dann auch von den Entwicklern, dass sie unternehmerisch denken und handeln im Sinne von, okay, was ist denn jetzt Return on Investment, was ist denn jetzt Total Cost of Ownership, was ist denn Time to Market? Sind das dann auch KPIs oder Gedankenanstöße, die du in die Teams reinträgst und wo du auch Output ganz spezifisch darauf von den Entwicklungsteams erwartest?

Nikolai (24:13)
Ja, definitiv. Also ist jetzt nicht so, dass jeder Entwickler als KPI hat den individuellen ROI, weil letztendlich die Wertschöpfungskette ist ja relativ lang und der Entwickler ist dann ein Teil davon. Aber ich erwarte schon ein gewisses Maß an unternehmerischem Denken. Das können ja auch so Dinge sein wie zum Beispiel Kostenoptimierung. So wenn ich was sehe, was einfach total ineffizient läuft und was uns zehnmal so viel kostet, als es kosten sollte, da erwarte ich natürlich schon ganz klar, dass man auch als Entwickler sagt so Hey,

Wir zahlen da gerade viel zu viel für, wir können das doch deutlich besser machen. Das sind, glaube ich, schon so Gedanken, die super wichtig sind.

Philipp Deutscher (24:48)
Ja, und jetzt trägst du natürlich nicht nur den Titel des CTO, sondern ich habe es ja in der Intro schon angemerkt, du bist ja CPTO, also Chief Product and Technology Officer. Frage Nummer eins, warum kommt das P vor dem T? Und nein, wie kam es denn dazu, dass du neben Tech auch das Produkt verantwortest und wie interpretierst du dann diese Rolle?

Nikolai (25:11)
Ich glaube, auf LinkedIn ist mein Titel noch CTO, wo das P ist, würde ich mich jetzt nicht festlegen. Ich glaube, tendenziell schon aktuell eher das P vorne, weil ich mich schon mittlerweile bisschen mehr mit Produktthemen beschäftige. Aber wie es dazu gekommen ist, ist letztendlich einer der Mitgründer Daniel, der hat vorher Produkt verantwortet. hat Instaffo verlassen, glaube Ende 2020, Anfang 2021.

Philipp Deutscher (25:17)
Okay.

Nikolai (25:37)
Und da gab es noch einfach eine Lücke, ich dann übernommen

genau, war auch im Kontext von einer größeren Änderung bei Instaffo, wir haben. Covid war für uns tatsächlich ein relativ großer Pivot, weil wir hatten dann halbwegs funktioniert als Business, würde ich sagen.

Mit Covid wurde dann aber alles anders, weil auf einmal keiner mehr eingestellt hat. gab Heimkriegs, es gab super viel Unsicherheit im Markt. Keiner wusste, ob überhaupt in drei Monaten noch Jobs vermittelt werden. Und das hat dann bei uns dazu geführt, dass wir nochmal einen Schritt zurück gemacht haben und nochmal unser ganzes Business Modell, unser Produkt überdacht haben.

Es war eine interne Änderung, wir angestoßen haben, die dann auch dazu geführt hat, dass wir im Endeffekt einen relativ großen Pivot auch nochmal im Produkt gemacht haben. Und mit dem Pivot habe ich dann auch die Verantwortung übernommen für das Produkt.

Philipp Deutscher (26:26)
Kann man denn heutzutage überhaupt noch CTO sein ohne Produktverständnis?

Nikolai (26:30)
Ich glaube, es kommt auf das Produkt an und auf das Unternehmen. Ich glaube, gewisses Produktverständnis muss immer da sein, weil letztendlich diese beiden Rollen, das Ziel ist das Gleiche. Wir wollen das beste Produkt bauen. Wir wollen Revenue für das Business generieren. Wir wollen Mehrwert für unseren Nutzer generieren. Das will ja der CTO und das will ja auch der CPO.

Philipp Deutscher (26:35)
Okay, fairer Punkt,

Nikolai (26:56)
Von daher sind die Ziele eigentlich allein. Ich glaube, das ist vielleicht ein bisschen anders bei sehr technischen Produkten, wo die Anwendung der Technologie so bisschen weiter weg

von dem Schreiben der Technologie sozusagen.

Aber zum Beispiel bei einem, also wir sind ja ein Marketplace-Business, bei uns wäre, selbst wenn wir diese Rollen getrennt hätten, es wäre absolut notwendig, dass der CTO auch ein sehr gutes Verständnis davon hat, wie das Produkt funktioniert, was die Challenges sind, wie das Business funktioniert, weil man eben nicht seiner Nische in der Technologie denken kann.

Philipp Deutscher (27:31)
Du hast jetzt gerade eben vom Alignment zwischen Produkt und Tech gesprochen und in der Theorie ist das natürlich, also nicht nur ist es der Theorie, es ist immer super wichtig und in der Theorie ist es auch einfach da, das Alignment herzustellen. Aber in der Praxis sieht man ja ganz häufig Konflikte zwischen genau diesen beiden wichtigen Säulen. Wie erlebst du das bei euch in der Organisation oder gerade wie schwierig oder einfach ist denn es tatsächlich, und unter einen Hut zu bringen, miteinander zu alignen und dafür zu sorgen?

dass die miteinander können. Weil die einen ziehen immer in die eine Richtung, die anderen sagen, wir müssen jetzt aber refactoren, wir müssen aber dies machen, wir müssen jenes machen. Und das ist nicht technisch sauber, wenn wir das jetzt so machen. Also da gibt es ja durchaus unterschiedliche Interessen.

Nikolai (28:08)
Hm?

Ja, aber es gibt keine unterschiedlichen fundamentalen oder es sollte keine unterschiedlichen fundamentalen Interessen geben. Also eigentlich sollten alle Funktionen im Unternehmen, wie gesagt, das Gleiche wollen. Mehrwert für Nutzer generieren, Revenue fürs Business generieren. Das heißt, die fundamentalen Interessen sind eigentlich die gleichen. Wo sich das natürlich unterscheidet, dann ist in dem, wie kommen wir dahin? Da können dann die Meinungen natürlich auseinandergehen. Und

Ich glaube aber, das Wichtigste ist, dass beide Funktionen

letztendlich ein sehr klares Verständnis davon haben, was jetzt gerade einfach wichtig ist und was vielleicht auch nicht so wichtig ist und was in zwei bis drei Monaten wichtig werden könnte. ich glaube, ein großer Teil von so einem Missalignment kommt daher, dass es kein ganz so klares Bild gibt davon, was eigentlich die Prioritäten und die größeren Probleme sind. Was dann eventuell eben dazu führt, dass jemand in seiner Technologie

denkt, okay, wir müssen da irgendwie erst mal ein riesen Refactoring machen. Aber von der Business- und Produktseite wird das gar nicht so als Thema

da zum Beispiel das Wissen da ist, dass der Teil vom Produkt, wo wir das Refactoring machen wollen, sowieso nicht weiterentwickelt wird. Also jetzt ein ganz banales Beispiel. Aber ich glaube, diese Situationen passieren tatsächlich relativ

vereine jetzt die beiden Funktionen in einer Rolle, aber ich habe natürlich unter mir immer noch auch Produktleute und Techleute. Und ich glaube auch da ist es einfach super wichtig, dass alle wissen, ist gerade wichtig? Was ist das Ziel? Was ist jetzt im Moment wichtig? Was ist nicht wichtig? Was ist in den nächsten zwei bis drei Monaten wichtig? Und ich versuche dann eher die Teams dazu zu enablen, diese Trade-offs und Entscheidungen selber zu treffen. Also zum Beispiel wenn...

Philipp Deutscher (30:02)
Wie oft

werden dann technisch, also ich kann mir nicht vorstellen, dass es gar keine Konflikte gibt zwischen Tech und Product. Und der eine oder andere wird ja bestimmt mal irgendwie auch an dich eskaliert oder gar nicht. hast du wirklich so eine Organisation geschaffen, die in der Lage ist, das dann selbst zu lösen und alles nur eine Frage ist von wie kommuniziere ich dann die Produktvision in die Teams und dann läuft das?

Nikolai (30:18)
Ahem.

Ja klar, also Konflikte gibt es da natürlich immer. wir sind auch nicht die, es gibt keine ideale Organisation, wo alles total smooth läuft und es da nicht auch mal ein Misalignment gibt. Aber im Endeffekt, also ich versuche das so zu unterscheiden, die kleineren Themen letztendlich, also wenn es Feature-Entwicklung geht.

Das sollte 99 % innerhalb von den Teams geklärt werden. Also wenn es jetzt darum geht, wir bauen ein neues Feature, wir bauen das ⁓ whatever, wir erweitern das, das soll der Produktmanager mit dem Team klären, ob da jetzt was refactored werden oder nicht. Weil letztendlich das Team muss wissen, die haben ihre Ziele als Team und die müssen das Ziel erreichen. Und wenn sie confident sind, die richtige Lösung, das Ziel zu erreichen, oder der richtige Weg, das Ziel zu erreichen, ist, erstmal einen Rewrite zu machen von einer Component.

Dann sollten sie das machen, aber dann müssen sie auch die Verantwortlichen dafür tragen, wenn das dazu führt, dass es eben erst zwei Wochen später live geht oder gar nicht live geht. Also das sind eher so die kleineren Themen, was schon an mich eskaliert wird und wo ich auch noch stark involviert bin, sind so ganz grundsätzliche Themen.

wenn es ⁓ die grundsätzliche Architektur von Dingen geht, wenn es ganz grundsätzlich darum geht, wie wir gewisse Dinge machen da kommt es natürlich schon mal vor, dass es unterschiedliche Vorstellungen davon gibt, was jetzt gerade wichtig ist. Also Beispiel, wir hatten ein Wunsch, der kam von Produkt war, okay, wir müssen eigentlich langsam ein richtiges Translation Management einführen für die App. Wir haben einen

gewisses Translation Management, aber das ist kein Self Service. Das lebt in JSON Files letztendlich, was natürlich nicht alles andere als State of the Art ist und das macht vieles dann komplizierter, wenn man die Texte ändern will. Man muss immer sehr vorsichtig sein beim definieren von Texten im Produkt. Wenn ich dann irgendwie in Buchstaben ändern will als Produktmanager, muss ich zu den Entwicklern gehen. Also kann ich total nachvollziehen. Deswegen kam da der Wunsch her.

Und die Idee dahinter ist ja, okay, das ist jetzt nichts, was irgendwie sofort Value delivert für irgendjemand. Wenn wir jetzt einen Translation Management haben, wenn wir da mehr Revenue haben nächste Woche, noch werden unsere Nutzer sagen, boah, geil, jetzt habt ihr Translation Management, weil die merken das ja gar nicht.

Aber die Idee dahinter ist ja, dass wir in Zukunft einen ROI davon haben, dass es uns in Zukunft dann schneller macht und irgendwann sich der Aufwand dann amortisiert. Und da kam dann zum Beispiel schon von der Tech-Organisation vor einem Frontend-Bereich, der einmal, okay, aber eigentlich haben wir doch gerade wichtigere Themen, die uns noch langsamer machen als das und sollten wir nicht zuerst das angehen. Das ist tatsächlich vielleicht kein ganz so gutes Beispiel, was wir da gemacht haben, ist,

Wir fangen mal an in die Richtung zu bauen, dass wir Translation Management einbauen können. Wir comitten uns aber nicht 100 Prozent darauf. Das hat dann natürlich dazu geführt, dass beide Seiten nicht wirklich das bekommen haben, was sie wollen. Da wäre es dann wahrscheinlich auch besser gewesen von meiner Seite, da eine klare Entscheidung zu treffen, das eine oder das andere zu priorisieren.

Philipp Deutscher (33:21)
Wie gehst du dann in Diskussion auch von dieser Tragweite oder Entscheidungen von dieser Tragweite, da bist du dann durchaus auch mal mit involviert. Wie tief steigst du denn dann da ein? Schaust, also bist du dann mit auf Architekturebene dabei und schaust dir das an und segnest das auch ab oder schaust du das dann eher aus dem Business Case an und stellst dir ja genau diese Fragen, die du gerade beschrieben hast im Sinne von

Was bringt uns denn jetzt mehr

internem Enablement und internem Return on Investment oder bist du tatsächlich dann in Architekturentscheidungen dann mit involviert?

Nikolai (33:53)
Beides. Ich bin auch in Architekturentschaltungen involviert, wenn es ⁓ grundsätzliche Dinge geht. bin jetzt nicht involviert, wenn es darum geht, welche Frontend-Library wir nutzen für What-you-see-is-what-you-get-editoren oder sowas, weil ich da auch einfach zu weit weg bin. Das lasse ich dann.

die Entwickler selber entscheiden. Aber wenn es ganz grundsätzlich darum geht, wie unsere Architektur aussieht, wie wir ganz grundsätzlich Dinge machen, da bin ich da auch involviert. Und mir ist auch schon wichtig, dass ich das verstehe und da Input geben kann, auch von der technischen Seite. Das schon ein Thema, wo ich jetzt erwarte in nächsten zwei, drei Monaten, dass ich da wahrscheinlich ein bisschen weniger involviert bin. Patrick, der andere Mitarbeiter, der mir zusammen Instaffo gejoint hat.

ist jetzt seit kurzem Head of Engineering, das heißt, das liegt dann schon eher bei ihm, diese Themen. sind da gerade aber auch in einer Transitionsphase dahin. Das heißt, da werde ich mich wahrscheinlich ein bisschen mehr rausziehen in Zukunft. Ich gucke mir das aber natürlich auch von der Businessseite an. Also im Endeffekt, das Bewertungskriterium ist immer der ROI.

Wir brauchen nichts machen, was kein ROI erzeugt. Wir brauchen kein Refactoring machen von irgendeiner Komponente im System, die wir sowieso nicht ändern wollen und die gerade funktioniert. Also es ergibt keinen Sinn das irgendwie zu rewriten, nur weil es nicht schön aussieht oder sowas, wenn es halt sowieso nicht angefasst wird. Also der ROI muss immer stimmen.

Philipp Deutscher (35:16)
Das heißt, es gibt ja auch durchaus andere Unternehmen, die dividieren genau diese beiden Bereiche, also Product und Tech, auseinander und sagen, ich brauche einen CPO und einen CTO und die müssen das auf C-Level-Ebene unter Umständen auch miteinander verhandeln. Was denn jetzt wie funktioniert? Sagst du, das sollte eigentlich nie die beste Lösung sein, weil

Die Zusammenführung von diesen beiden Teildisziplinen ist so essentiell, dass sie eigentlich alternativlos ist.

Nikolai (35:49)
Alternativlos sicher nicht. Es kann auch schon sinnvoll sein, wenn das in zwei unterschiedlichen Rollen ist, weil letztendlich aus der Meinungsverschiedenheit und aus dem

ja auch was Positives rauskommen. Im Idealfall findet man dann eine dritte, beste Lösung zum Beispiel. Es ist aber natürlich so, dass es in der Realität dann nicht immer der Fall ist. Ich würde nicht sagen, dass es falsch

grundsätzlich in zwei Rollen zu haben. Das hat Vor- und Nachteile.

Jetzt in meiner Rolle ist es halt so, dass ich viele Sachen dann mit mir selber sparen muss oder dass ich mir auch extern nochmal Input holen muss, um die richtige Entscheidung zu treffen. Und ich denke, das funktioniert. Das andere System funktioniert aber kommt natürlich auch total auf die Größe des Unternehmens an. Also ich glaube, Team von jetzt 10, 20 Entwicklern und Produktmenschen

brauchst jetzt nicht unbedingt einen CTO und einen CPO und dann noch einen Head-off dazwischen oder irgendwas, da würde ich das schon eher flach halten. Aber natürlich in größeren Organisationen ist es nochmal ganz anders, weil man auch dementsprechend eine viel größere, viel größere Risikobeänderung hat, eine viel größere Legacy. Also da geht es ja dann nicht darum zu besprechen, ob man jetzt dann...

irgendwas technologisch umbaut, was dann zwei Wochen dauert, dann spricht man über zwei Monate oder sogar zwei Jahre. Und da gibt es natürlich schon Sinn, dass das dann auch in unterschiedlichen Rollen ist. Aber ich glaube, da sind wir eben noch lange nicht.

Philipp Deutscher (37:11)
Hast du unter dir eine VP-Struktur oder erstens Directors oder wie hast du deine erste Führungsebene dann strukturiert?

Nikolai (37:18)
Wir sind tatsächlich sehr flach organisiert insgesamt bei Instaffo. Wir sind wirklich sehr lean gewachsen. Ich glaube, sind als der leansten Start-up, Scale-ups überhaupt. Das heißt, habe unter mir einen Patrik als Head of Engineering. Jetzt sind sich alle Engineers, die an Patrik

und habe dann aber zum Beispiel die Produktmanager, Produktdesigner oder ein paar andere Rollen auch letztendlich direkt unter mir, weil ich da jetzt noch keinen großen Need sehe, da eine weitere Ebene einzuziehen. Also Head-of-Product ist schon so eine Rolle, wo ich sagen wollte, das steht wahrscheinlich an

Philipp Deutscher (37:47)
Und da gibt's doch kein Head of Product dafür. Okay.

Nikolai (37:57)
ein, zwei Jahren, aber aktuell funktioniert das auch so sehr gut und

Ich bin da auch noch sehr gerne sehr nah dran und solange ich das so machen kann, würde ich das auch so weiter fortführen. ⁓

Philipp Deutscher (38:08)
Sehr

schön. Lass uns doch mal zu einem anderen Thema übergehen. zwar, seid ja als Instaffo sehr nah am Puls des Arbeitsmarktes. ist denn der Tech-Job-Markt? Ist der aktuell im Wandel? Der ist ganz sicher im Wandel. Aber wie verschieben sich jetzt dann Realitäten, Erwartungen? Wie nimmst du die aktuelle Lage gerade für Tech-Fachkräfte wahr? Ist das jetzt eher Kandidatenmarkt? Ist das ein Arbeitgebermarkt? Irgendwo dazwischen?

Nikolai (38:24)
Ahem.

Philipp Deutscher (38:37)
Wie ist da euer Einblick in die Landschaft?

Nikolai (38:41)
Seit Mitte 2022 ist es definitiv wieder eher ein Arbeitgebermarkt. Vor allem in Tech, ganz spezifisch im Bereich Softwareentwicklung. Wir sehen schon, dass die Anzahl der offenen Stellen geht wirklich stetig zurück seit, ich glaube, Mai 2022. Ich glaube, ich habe jetzt für Mai noch nicht reingeschaut.

Philipp Deutscher (38:58)
Immer noch?

Nikolai (39:03)
Aber es gibt den BAX Index von der Bundesagentur für Arbeit, der hat sich jetzt noch nicht erholt. gibt, also wenn man auf externe Daten setzen will, das Indeed Hiring Lab, wo man sich über Indeed Teacher Postings anschauen kann, auch nach Geografie. Und man sieht da schon, dass es kontinuierlich runtergeht. Und die Anzahl der Arbeitssuchenden nimmt definitiv zu.

Bewerber müssen sich auf deutlich mehr Stellen bewerben. Also es gibt eine deutlich größere Competition zwischen den Arbeitnehmern letztendlich. Und Unternehmen sind teilweise auch bisschen zögerlicher bei den Einstellungen. Was jetzt natürlich durch das ganze AI-Thema nochmal eine besondere Brisanz gewinnt. Für mich ist es aber eher ein vielleicht ein bisschen übertriebenes Back to Normal nach Covid.

weil letztendlich nach Coat, was wir ja gesehen haben, ist, dass es ein absolut maßloses Overhiring gab, vor allem in der Softwareentwicklung. Und das führt jetzt einfach dazu, dass viele Unternehmen entweder entlassen, so wir hatten ja super viele Layoffs. Ich glaube, die Layoffs haben jetzt so langsam abgeerbt, in USA ja schon ein bisschen früher als in Europa.

Oder eben, dass es ein Unternehmen einfach langsamer einstellen oder dass es so eine Art kalten Stellenabbau gibt. das liegt für mich, also der Nummer eins Faktor ist mit Sicherheit einfach das Overhiring nach Covid, weil das auch einfach kein gesunder Markt war in der Situation.

Philipp Deutscher (40:33)
Würdest du sagen, dass die goldenen Zeiten der

ein gutes Stück vorbei ist? Also für jetzt wahrscheinlich schon, aber dass die vielleicht auch so schnell gar nicht mehr wiederkommen.

Nikolai (40:46)
Also, es ist temporär vielleicht vorbei. Die Zeiten sind mit Sicherheit nicht mehr so golden wie zwischen Covid und Mai 2022. Aber ich bin mir auch sicher, dass das wieder zurückkommen wird. Wie gesagt, das ist jetzt eine Normalisierung. Die Sachen mit dem Arbeitsmarkt ist ja, dass es da gewisse Effekte gibt, die einfach dazu führen, dass sich alles sehr lange

Wir ja auch das Problem der gesamtwirtschaftlichen Entwicklung jetzt vor allem in Deutschland. Und selbst wenn es wirtschaftlich wieder nach oben geht, der Arbeitsmarkt wird halt auch noch mal eine Weile brauchen, bis er wirklich anzieht. Von daher gehe ich jetzt nicht davon aus, dass sich da diesen Sommer noch was ändert. Ich bin aber langfristig schon auf jeden Fall bullish für den Bereich. Ich glaube, wir brauchen auch langfristig viele Softwareentwickler.

würde jetzt nicht empfehlen, Softwareentwickler zu werden, nur weil der Arbeitsmarkt aktuell nicht mehr ganz so gut aussieht.

Philipp Deutscher (41:41)
Ja, ist interessant. kann da schlecht dagegen argumentieren, wenn du das so sagst, weil du bist natürlich der Experte auch mit Markteinblick. Meine Perspektive darauf ist aber auch, dass gerade so in den Covid-Jahren, also davor, aber auch gerade 2020, 2021, sind auch sehr viele Juniors in den Markt geströmt, die auch über Coding-Bootcamps dann kamen. Also weil auch viele dann gesehen haben, mit Software-Engineering, da wurde ja alles gehired, was nicht bei drei auf dem Baum war.

Nikolai (42:06)
Hm.

Philipp Deutscher (42:07)
Und da konnte man auch mit relativ geringer Expertise in den Markt. Das ist natürlich klar, dass diejenigen wahrscheinlich als allererstes aus dem Markt wieder rausgespült werden. So, jetzt gibt es natürlich AI-Tools, aber als Unternehmen kann ich ja sagen, ich habe jetzt ja ganz große Effizienzgewinne, wenn ich

Engineers und gute Seniors einstelle, die man auch noch mit Enablement durch zusätzliche empowern kann.

irgendwann noch mal auf genau so eine Welle von Juniors setzen?

Also diese Welle sehe ich einfach nicht mehr kommen in absehbarer Zeit. Einfach weil der Junior, dem kannst du zwar ein AI Tool in die Hand es dann ja trotzdem nicht richtig verstanden. Und ich weiß nicht, ob ein Unternehmen im Jahr 2025 oder 2026 dann sagen wird, ach so, super tolle Idee. Ich stelle jemanden ein, der eigentlich kaum entwickeln kann und mit den richtigen AI Tools wird das bestimmt mega gut sein. Also den Teil, den,

Nikolai (42:43)
Hm?

Hm?

Philipp Deutscher (42:57)
Den sehe ich einfach nicht, aber jetzt darfst du mich gerne widerlegen, dass ich da völlig daneben liege.

Nikolai (43:03)
Ja klar, also das mit den Juniors und den Bootcamps, ist definitiv so, dass halt einfach der Markt zu der Zeit, weil es gab einfach einen extremen Lead für Softwareentwickler und das hat dann letztendlich dazu geführt,

super viele umgeschult haben und gesagt haben, okay, jetzt ich Softwareentwickler. Auch teilweise, es war ja auch eine, ja fast schon, gesellschaftliche Krise mit Covid. Also super viele Leute haben ja

sich als ich daheim saß und überlegt, was mache ich jetzt eigentlich mit meinem Leben, soll ich nochmal den Job wechseln. Also es hat ja super viel bewegt letztendlich. Und das stimmt definitiv, wenn der Bedarf sinkt.

dann sinkt er auch erstmal primär wahrscheinlich bei den Juniors und Unterfahrenden. Und ich glaube auch schon, dass die Latte ist definitiv höher geworden, auch für Juniors. Also ein Junior heute muss mit Sicherheit deutlich mehr können und leisten als vor drei, vier, fünf Jahren. Und AI trägt natürlich auch nochmal dazu bei, weil letztendlich, also was AI jetzt schon

super gut kann, er also simple Sachen machen. Du brauchst kein im Vorstellungsgespräch mehr Fragen, was dir in Linked-Liste irgendwas implementieren kann, weil du kannst halt auch einfach Cursor

das führt halt dazu, dass schon die Messlatte noch mal steigt.

Philipp Deutscher (44:28)
Zwischenfrage, dann setzt ihr aktiv Cursor oder ähnliches ein, also bietet ihr euren Entwicklern diese Tools an, kauft ihr dafür extra Lizenzen oder lasst ihr die Entwickler entscheiden und die enablen sich dann selber damit.

Nikolai (44:36)
Na ja, klar.

Ja klar, also bei uns, ich hab's jetzt nicht ganz im Kopf, aber die allermeisten arbeiten, soweit ich weiß, mit Cursor oder mit einem anderen AI-Tool gibt ganz wenige. Oder wahrscheinlich keinen mehr, der das nicht nutzt. Also es ergibt ja auch total Sinn. Das heißt ja nicht, dass jetzt jeder nur noch mit AI-Code schreiben soll, weil es auch einfach noch nicht möglich ist. Ich glaube, es gibt noch ganz fundamentale...

Limitierung vor allem bei größeren Codebases, was super funktioniert ist irgendwie Prototyping. Da ist es ein totaler Gamechanger, wie schnell man da was auf die Beine stellen kann, was wirklich 100 Prozent funktioniert. Aber dann bei komplexeren Themen ist es schon eher schwieriger und ich da AI eher als Unterstützung. Also für mich ist aktuell schon auch größtenteils ein Autocomplete on steroids letztendlich, was natürlich alle Entwickler effizient

-er machen ich bin auch eigentlich recht bullish, dass da die Entwicklung auch noch weiter stärker in die Richtung geht, also dass sich auch diese Software-Engineer-Rolle so entwickeln wird, dass man eben wahrscheinlich immer weniger und weniger Code schreiben wird, weil die Modelle immer besser und besser werden. Ich glaube aber nicht, dass es dazu führt, dass es weniger Software-Engineers gibt, weil letztendlich ist es ja

Wenn jedes Unternehmen Zugang hat zu der Technologie, dann wäre es unternehmerisch eine schlechte Entscheidung zu sagen, meine Entwickler sind 50 % produktiver, deswegen katte ich jetzt 50%, weil ich kann ja auch die 50 % mehr Produktivität mitnehmen. Und wenn das jeder macht, dann ist das letztendlich so eine Art Zero-Sum-Game, wenn man das Bigger Picture betrachtet. Und ich glaube schon, dass es stark in die Richtung gehen wird.

Philipp Deutscher (46:13)
Das ist richtig.

Nikolai (46:24)
Vielleicht mit der Ausnahme, so keiner weiß, wird AGI kommen und wird dann alle irgendwie abgelöst. Kann sein. Das ist aber für mich eher so eine philosophische Frage.

Philipp Deutscher (46:37)
Oder,

also ich weiß meine Theorie ist dann auch, es kann ja auch sein, dass sich der Einsatzzweck eines Software-Engineers verschiebt. Heutzutage, heutzutage auch noch, aber früher war es doch so, früher haben sie dann irgendwie jede Kleinigkeit auf einer Website, musste im Endeffekt von einem Engineer irgendwie angepasst werden. Das wird dann irgendwann nicht mehr der Fall sein, da setzt du im Endeffekt automatisch deine AI-Tools drauf an. Aber sobald es Richtung Komplex Deep Tech geht,

Nikolai (46:52)
Ja.

Philipp Deutscher (47:02)
sich dann die Engineeringleistung hinverschieben und alles drum herum ist dann nur noch irgendwie Commodity. Das wäre eine Möglichkeit, wie sich das auch verändert. Und der Entwickler dann selber, je senioriger es das ist, umso mehr wird er zum Orchestrator und Überprüfer dessen, was denn seine AI-Bots im Endeffekt da permanent produzieren. Und dass sein Skillset sich noch mal sehr stark verschiebt und auch vielleicht teilweise weggeht vom Hands-on-Coding.

Nikolai (47:24)
Definitiv.

Hm?

Philipp Deutscher (47:31)
Natürlich braucht er immer noch das tiefe Wissen darin, wie alles funktioniert und zusammenhängt, dann auch eingreifen zu können, aber dass da viel mehr Richtung Orchestration, Administration und Delegation irgendwie geht.

Nikolai (47:43)
Ja, definitiv. Das sehe ich ganz genau so.

Philipp Deutscher (47:46)
Ich habe noch eine Frage, weil ich dann noch die Zusammenhänge bei einer Sache noch nicht ganz verstanden habe, nämlich das Thema Layoffs und der Anzahl der offenen Stellen. Auf der einen Seite gab es eine Phase, die ist jetzt schon eine ganze Weile rum, hast du glaube ich auch gesagt, dass die Layoffs, haben jetzt abgenommen. Die Phase der großen Layoffs dürfte eigentlich vorbei sein. Ich hätte jetzt zum Beispiel angenommen, dass zeitgleich mit den großen Layoff-Phases eigentlich auch die Anzahl offener Stellen irgendwie nach unten kracht. Jetzt sagst aber, dass es ja eigentlich nicht der Fall gewesen ist, sondern die offenen Stellen...

Die sinken halt graduell nach und nach und sind Stand heute immer noch am sinken, jetzt wo die Layoffs eigentlich schon längst durch sind. Wie sind da so diese Wechselwirkungen zwischen diesen beiden Kennzahlen? Also hast du da eine Erklärung dafür?

Nikolai (48:28)
Ja klar, also eine Stelle kann ja entweder wegfallen, indem man sagt, die Stelle gibt es bei uns, die ist besetzt und sie fällt weg. Das ist dann ein Layoff. Aber eine Stelle kann ja auch wegfallen, indem man sagt, die Stelle gibt es noch nicht und sie wird es nicht geben. Indem man einfach vorsichtiger ist beim Stellenaufbau letztendlich. Und was wir gesehen haben, ist, dass letztendlich beides passiert. Also es gibt Unternehmen, die haben Layoffs gemacht. Es gibt aber auch Unternehmen, gesagt haben, okay wir

Wir stellen auch erstmal einfach nicht mehr ein oder wir stellen nur vorsichtig ein oder wir besetzen zum Beispiel nur bestehende Rollen nach. Und das zusammenführt dann eben dazu, dass wir diesen Trend sehen, dass die Stellen runtergehen. Der Arbeitsmarkt ist aber wirklich ein super komplexes Thema und da gibt es

sehr viele Dinge, die sich dann gegenseitig beeinflussen. Auf LinkedIn gibt es ja auch schon seit Wochen diese Diskussion, woran das jetzt liegt, dass die Software-Engineerstellen runtergehen. glaube, irgendein Influencer hat wahrscheinlich diesen Detiring-Chart gefunden und gepostet und dann haben sich da auf einmal alle drauf gestürzt und gesagt, es liegt jetzt an AI und alles, was ja aber komplett der Unsinn ist, weil der Stellenabbau hat ja mehr als ein Jahr begonnen, überhaupt GPT-3.5 rauskam. Deswegen gibt es da, glaube ich, Zusammenhang, weil es natürlich schon

so ist, dass es sein kann, dass Unternehmen jetzt vorsichtiger sind im

meine aktuellen Entwickler effizienter sein können und ich gerade finanziell vielleicht in einer bisschen unsicheren Situation bin, wieso sollte ich dann Stellen aufbauen? Das sehe ich schon.

Philipp Deutscher (49:58)
Ja, das stimmt.

Aber es gibt ja auch einen Zusammenhang offensichtlich zwischen, oder zumindest mal irgendeine Korrelation zwischen Fachkräftemangel, der immer noch ausgerufen wird, und Entlassungswellen gesunkener Anzahl offener Stellen. Wie passt das denn zusammen? Also in der IT hört man einerseits vom Fachkräftemangel, andererseits gab es halt diese Layoff-Runden bei Tech-Unternehmen, ist die gesunkener Anzahl offener Stellen. Was beobachtet ihr dazu bei Instaffo?

Nikolai (50:24)
Ja, Fachkräftemangel ist ein kompliziertes Thema. Also ich denke, es gibt definitiv einen Fachkräftemangel in einigen Bereichen, generellen Fachkräftemangel in einigen Bereichen. Genau, ruby on rails Entwickler.

Philipp Deutscher (50:34)
Ruby on Rails Entwickler zum Beispiel.

Nikolai (50:38)
Wobei, ich weiß gar nicht, so viele stellen die auch nicht ein für ruby on rails. Also einfach Bereiche, es quasi faktisch gesehen nicht genug Personal gibt für die offenen Stellen. Da muss man sich natürlich überlegen, was macht man. Also Pflege ist ein großes Thema. Gastronomie, Handwerk, sicher noch ein paar andere. Also wo es einfach nicht die Personen gibt dafür.

Letztendlich. Ich glaube in vielen anderen Bereichen ist primäre Problem eher so eine mangelnde Effizienz des Marktes. Also ich glaube zu viele Personen sind letztendlich in den falschen Jobs und wechseln nicht in die richtigen Jobs und zu viele Unternehmen finden dann wieder nicht die wirklich richtigen Personen für die Jobs. Das ist ja auch genau das Problem, was wir mit Instaffo lösen wollen. Also einfach wie möglich beide Seiten letztendlich zusammen zu bringen.

was auch wieder super viele Ursachen hat. Es gibt viele Hürden im Bewerbungsprozess, die den Wechsel auch schwerer machen. Es gibt in Deutschland gerade auch rechtliche Gegebenheiten, wo ich sagen würde, dass das eher dazu führt, dass der Markt inflexibel wird mit sehr starken Arbeitnehmerrechten.

glaube auch insbesondere an so eine politische Entwicklung in Deutschland, dass auch tatsächlich viele von den gemeldeten IT-Stellen sind Stellen im öffentlichen Dienst Also das ist der Sektor, der trotz des Stellenabbaus seit Mai 2022 der einzige Sektor, der kontinuierlich gewachsen ist, Stellen im öffentlichen Dienst. Gleichzeitig wollen aber natürlich die wenigsten im öffentlichen Dienst arbeiten, einfach weil das nicht die attraktivsten Jobs sind. Und das alles zusammen führt dann, glaube ich, zu dieser Verzerrung.

Ich würde insgesamt eher nicht sagen, dass wir einen generalisierten Fachkräftemangel haben in Deutschland für alle Fachkräfte, sondern ich glaube, das ist schon sehr

ich glaube, gesagt, das größere Problem ist die Effizienz des Jobwechselmarktes letztendlich.

Philipp Deutscher (52:26)
die Gehälter, wie haben sich Gehaltsvorstellungen entwickelt? Wie realistisch sind die aktuell? Ihr habt da glaube ich, auch gute Einblicke. Auch was da für utopische Fantasien es gab, beziehungsweise auch Gehälter, die gezahlt wurden ganz aktiv noch 2021. Es hat sich mit Sicherheit geändert. Schließt sich so langsam die Lücke zwischen den Erwartungen der Kandidaten und dem, was die Unternehmen bereit sind zu zahlen?

Nikolai (52:28)
...

Vielen

Ich glaube langsam schließt sich die Lücke. Die Lücke ist aber definitiv immer noch da. Wir haben ja hunderttausende Gehaltsdaten sowohl von Jobs als auch von Kandidaten. Wir sehen, eigentlich sowohl die Gehaltsvorstellungen als auch die Angebotengelder sich seit

nicht großartig verändert haben. Deswegen ist auch immer noch die Lücke da.

ist aber natürlich eigentlich eine trendwendende, historische, weil historisch sind die Gehälter ja immer gewachsen, insbesondere super stark dann in 2021, es einen sehr hohen, glaube ich, die Zahlen jetzt nicht im Kopf. Ich hatte mal nachgeschaut, es, glaube ich, irgendwie 5, 6, 7 Prozent nach oben ging innerhalb eines Jahres. Und auf dem Level bewegen wir uns jetzt ungefähr. Also ich glaube, wir hatten da auch durch Covid

oder nicht durch Covid, sondern durch die Situation nach Covid, absolut übertriebenen Anstieg der Gehälter. Das wird sich jetzt so langsam abbauen und normalisieren. Problem ist dadurch, dass bei einem Jobwechsel oft, aber nicht immer, gerade kein großer Kaltsprung nach oben mehr möglich ist. Das war 2021 definitiv anders, wo super viele aufgrund der Marktsituation für ein attraktiveres Gehalt gewechselt haben.

Ich glaube, das wird sich langfristig alles wieder normalisieren. Die Gehälter werden wieder steigen. hängt natürlich auch stark an der gesamtwirtschaftlichen Entwicklung. Der Arbeitsmarkt hängt an der wirtschaftlichen Entwicklung letztendlich. Und das geht es nicht.

Also bei uns ist so, ich glaube die Median-Gehaltvorstörungen für Softwareentwicklung jetzt über alle Erfahrungslevel hinweg sind so 77.000 wahrscheinlich. Natürlich für Seniors noch mal ein bisschen höher, für Juniors ein bisschen niedriger. Während das Median-Gehalt ein bisschen drunter liegt bei den Jobs. Das Median-Gehalt ist glaube ich eher so, wir erfassen immer nur Spanne und wir gucken uns dann den Mittelpunkt der Spanne an und der liegt eher so bei 70.000 Grad. Es gibt definitiv noch eine Lücke.

Philipp Deutscher (54:47)
Und wie hat sich die Wechselbereitschaft verändert? Ich kann mir vorstellen, dass die natürlich auch aufgrund der wirtschaftlichen Situation, der Layoffs der weniger Stellenausschreibung, dass die Leute natürlich auch weniger wechselbereit sind und mehr sicherheitsorientiert sind. Also das ist jetzt meine These. Wenn das ja der Fall ist, dann könnte es ja bedeuten, dass Unternehmen, wenn sie jemanden einstellen wollen den irgendwo abwerben wollen, ja trotzdem noch mal tiefer in die Tasche greifen müssen, den davon zu überzeugen, dann rüberzuwechseln.

Werden Entwickler momentan zögerlicher ... beim Jobwechsel oder wie seht ihr das?

Nikolai (55:20)
Ich glaube insgesamt nicht. Also was wir sehen ist, dass sich der Anteil der aktiv Jobsuchenden massiv erhöht hat. Wir sind da jetzt glaube ich, also beidens davor, dass es...

Philipp Deutscher (55:29)
Aufgrund der Layoffs dann

oder sind das dann Leute, die aus ihren Jobs raus sich aktiv neu orientieren oder könnt ihr das gar nicht sehen?

Nikolai (55:35)
Es ist sowohl als auch vermutlich, ich habe da jetzt genauen Daten, aber was wir sehen, Instaffo ist natürlich auch bisschen biased, weil bei Instaffo geht es darum, einen Job zu suchen. Also natürlich suchen die meisten Leute bei uns dann auch

der Anteil hat sich schon nochmal relativ stark verschoben. ich glaube wir waren 2021, 2022 bei 60, 70 Prozent wirklich aktiv suchen. Jetzt sind wir so zwischen 80 und 85 Prozent. Ich glaube das liegt einerseits an Layoffs. Also es gibt tatsächlich mehr Softwareentwickler, die auch tatsächlich einen Job suchen, die gerade keinen Job haben und einen neuen brauchen. Aber auch

mehr Wechselwürdige. Deswegen glaube ich jetzt nicht, also ich würde nicht sagen, dass sich die Wechselbereitschaft unbedingt verschlechtert hat. Eher wahrscheinlich sogar bisschen verbessert hat. Das ist jetzt aber eher ein Wild guess. Wir sehen ja schon, dass mehr und mehr Leute letztendlich unzufrieden im Job sind.

Hab da eine Studie im Kopf von Xing, wo 77 % der Arbeitnehmer angegeben haben, dass sie über einen Wechsel nachdenken. Was ja total krass ist, wenn man sich das mal so vorstellt. 77 % der Leute sind in Jobs, die ihnen eigentlich gar nicht gefallen.

Philipp Deutscher (56:56)
Branchen übergreifen oder in

Bezug auf Tech.

Nikolai (56:58)
Das weiß ich jetzt gerade nicht. war wahrscheinlich branchenübergreifend. Ich würde erwarten, dass es wahrscheinlich in Tech ein bisschen geringer ist, weil es ja schon Branchen gibt, man ganz klar sagen kann, dass die Arbeitsbedingungen insgesamt wahrscheinlich schlechter sind als als Softwareentwickler.

Philipp Deutscher (57:13)
Würdest du

Entwickler nach wie vor eine sehr privilegierte Berufsgruppe sind, auch aufgrund der Tatsache, dass sie quasi alles remote machen können, wenn das Unternehmen es erlaubt, die quasi eigentlich immer noch in Bereichen unterwegs sind, die ja sehr stark Funding bekommen oder bekommen haben, vielleicht aktuell nicht mehr ganz so.

Spiegelt sich das dann auch wieder, wie sich dann solche Gehälter entwickeln oder wo sie aktuell stehen im Vergleich zum Rest der Gesellschaft oder anderen Bereichen der Gesellschaft? Ist das dann immer noch so

privilegiert oder gleicht sich das so langsam an, weil andere Bereiche jetzt vielleicht noch mal gefragt sind als Engineers?

Nikolai (57:52)
Ich würde sagen, Entwickler sind definitiv nicht mehr so privilegiert wie noch vor ein paar Jahren, was die Jobsuche angeht. Es ist jetzt definitiv nicht mehr so durch den Markt, dass man die Jobs gefühlt hinterher geworfen bekommt von Arbeitgebern. Und ob dann eine Rolle an sich privilegierter ist als eine andere, das ist ja dann letztendlich eine persönliche Sache. Ich glaube schon, insgesamt glaube ich, guter Job.

sehr viele Benefits. Man arbeitet tendenziell wahrscheinlich auch eher in moderneren Unternehmen mit einer cooleren Kultur, mit besseren Benefits. Man kann komplett remote arbeiten, was glaube ich so einer der größten Benefits ist. Auch ein super gefragtes

bei vielen Talenten. Also insgesamt gesehen glaube ich schon noch eine privilegierte Gruppe, aber es ist natürlich dann auch eine individuelle Sache.

Philipp Deutscher (58:43)
Wie steht ihr zu Remotarbeit? Bietet ihr das

Nikolai (58:46)
Ja, wir sind hybrid. Also in Product & Tech sind wir tatsächlich 100 % remote. Also wir haben auch noch ein Büro in Heidelberg. Ich bin auch mehrmals die Woche da, aber unsere Product & Tech Org ist eigentlich auf ganz Europa verteilt mittlerweile. Das hat auch den Hintergrund,

In Product & Tech ist es meiner Meinung nach am einfachsten, auch asynchron zusammenzuarbeiten. Wir haben das ganz stark gemerkt, als wir mit Covid dann tatsächlich alle ins Homeoffice mussten. Das hat eigentlich im Day-to-Day fast gar nichts geändert. Also alles ist ganz normal weitergelaufen, weil sowieso schon alles asynchron gelaufen ist über GitLab und über Slack und so weiter und so fort. Also die Zusammenarbeit funktioniert absolut problemlos. Und für den größten Rest der Company

sind wir hybrid, also wir haben sehr flexible Homeoffice-Optionen. haben einen Tag die Woche, wo wir alle ins Büro einladen, es auch kostenlose Lunch gibt, ein bisschen Incentive zu schaffen. Das ist natürlich auch schön, dass man die Leute dann ab und zu mal in echt sieht. Product and Tech ist es quasi historisch so passiert, dass wir auch über komplett Europa verteilt sind. Da ist es dann natürlich schwierig, einmal die Woche auch ins Büro zu kommen.

Philipp Deutscher (59:57)
Habt ihr eine Möglichkeit, die Produktivität zu messen oder habt ihr das auch früher getan? Also gerade so von dem Übergang zu vor Covid bis hin zu ersten Wellen Lockdowns, alle remote und wie sich das jetzt irgendwie verteilt? Kann man das überhaupt sinnvoll meine, natürlich gibt es Meinungen rechts wie links, die halt in die eine oder andere Richtung pushen von ja, es braucht halt irgendwie Vertrauen und wir sind ja alle remote viel produktiver als Entwickler.

Nikolai (1:00:20)
Hm?

Philipp Deutscher (1:00:22)
Auf der anderen Seite gibt es natürlich auch Leute, die dieses System auch ausnutzen für sich und sich ihre Freiheiten nehmen. Also das darf man ja auch nicht unter Tisch fallen lassen. Nivelliert sich das am Ende des Tages und die Produktion oder die Produktivität ist am Ende des Tages eher gleich? Oder gab es in irgendeiner Form Schwankungen, die ihr gespürt habt, sei es in die eine oder die andere Richtung?

Nikolai (1:00:41)
Ich habe jetzt keine historischen Daten dazu, wie das bei uns war. Ich glaube, es ist auch superschwer zu vergleichen, weil wir während Corona auch in einer ganz anderen Phase waren und jetzt kein...

kann universelle KPI haben für Produktivität. glaube letztendlich ist auch eine sehr individuelle Sache. Also ich glaube schon, dass viele Entwickler, der Großteil der Entwickler wahrscheinlich produktiver ist im Homeoffice. Ich glaube, ein Großteil der Entwickler hat auch gar kein Problem damit im Homeoffice zu arbeiten. Ganz umgekehrt, die meisten wollen das ja auch.

weiß jetzt auch die genaue Zahl nicht im Kopf, aber ich glaube so 60-70 % der Entwickler wollen auch eigentlich ausschließlich remote arbeiten. Dass das dann in der Realität klappt, nochmal eine andere Sache. Ich glaube, es ist eine individuelle Sache. Ich glaube aber auch, dass dieses wirklich 100 % remote immer Homeoffice nicht für jeden was ist. Also es gibt durchaus Personen, die wahrscheinlich in einem On-Site-Umfeld dann besser performen oder die das auch einfach brauchen.

die nicht eben nicht alleine in dem Home Office produktiv sein können. Und das ist natürlich auch ein Thema, was von der Kommunikationsstruktur im Unternehmen irgendwie gestützt werden muss. Also manche Sachen sind remote schon nochmal deutlich schwerer.

Also dadurch, dass man nicht mehr diesen Casual-Austausch hat auch mit Leuten, man trifft die Leute nicht mehr beim Kaffee oder Wasser holen, man geht nicht mehr zusammen Mittagessen und genau, Beiläufigkeit fehlt. Das kann natürlich schon was auch mit der Kultur dann machen und da muss man aufpassen, dass man eben trotzdem

Philipp Deutscher (1:02:09)
Ja, die Beiläufigkeit fehlt. Man läuft aneinander vorbei.

Nikolai (1:02:20)
dieses Miteinander auch im Remote-Kontext fördert. Also was wir machen, ist wir versuchen schon ab und zu uns in real life zu sehen. Wir treffen uns ab und an zu OKA-Workshops. Jetzt diese Woche hat es leider nicht geklappt, aber im nächsten OKA-Zyklus werden sehr wahrscheinlich wieder alle im Büro sein. Wir haben auch zwei größere

pro Jahr, wo wir uns auch nochmal alle sehen. Weil ich glaube, schon wichtig für diese Connection, dass man zumindest ein paar Mal im Jahr die Gelegenheit hat, die Leute

auch in echt zu sehen.

Philipp Deutscher (1:02:48)
Wie bewertest du denn als CTO das Thema Sichtbarkeit gerade in diesem Remote-Kontext? Ist dir das egal und sagst dann, ich gucke nur auf Gesamtautput der Organisation und ob das in die richtige Richtung geht? Oder stellst du dann irgendwann fest, der Mitarbeiter, gibt es ja auch noch, den habe ich eigentlich schon seit zwei Jahren nicht mehr gesehen. Wie gehst du damit ⁓ oder tangiert dich das überhaupt nicht oder betrifft dich das nicht, weil du tatsächlich so Outcome-Focus bist?

Dass du sagst, andere ist für mich nur Störgeräusche und das blend ich aus.

Nikolai (1:03:17)
Du meinst jetzt Sichtbarkeit in Bezug auf Performance von den Mitarbeitern oder?

Philipp Deutscher (1:03:21)
Ja, das ist ja wieder schwer zu messen. geht dann ja auch darum, dass ja einige sich in ihrer Remote-Bubble quasi kaum noch existent sind, also auch in ihrer Kommunikation nach außen. Die schreiben vielleicht dreimal was im Slack, dann sind sie natürlich irgendwo vielleicht im Tunnel und entwickeln halt sehr, sehr produktiv vor sich hin und haben vielleicht ja auch einen sehr, guten Output dann geliefert.

Nikolai (1:03:33)
Hm?

Philipp Deutscher (1:03:42)
Aber wenn du die halt gar nicht wahrnimmst, sondern du siehst am Ende nur halt das Ergebnis des Teams, ... dann kannst du immer sagen, ... ja mir geht es ja auch nur um das Ergebnis des Teams ... und das Team hat irgendwie seinen Job gemacht, ... aber wenn die einzelne Person ... dann hinter ihr Bildschirm und so komplett verschwindet und gar nicht mehr sichtbar ist für einen, ... also ich halte das durchaus für problematisch ... so über einen längeren Zeitraum, ... wie die paar Jahre, die wir jetzt da gemacht haben, ... was das ja mit den Menschen macht, ... was das mit dem Arbeitsumfeld macht.

Da ist meine Frage, inwiefern du darüber nachdenkst oder das für dich vielleicht sogar problematisch ist oder überhaupt nicht.

Nikolai (1:04:18)
Ja, ist eine gute Frage. Also ich glaube, der Vorteil in der Softwareentwicklung ist dadurch, dass das ja letztendlich extrem kollaborativ ist. Also ich kann ja als einzelner Entwickler, ich kann ja fast nichts, also je nach Setup natürlich, aber bei uns kann einzelner Entwickler fast nichts wirklich 100 % selbst machen, weil ...

Jedlicher Code, der geschrieben wird, geht durch einen Code Review. Jedlicher Code, der geschrieben wird, da gibt es auch dann ein Issue zu und das wurde vorher im Team besprochen. Das geht durch QA und alles. Wir demoen die Features. Wir holen uns viel Feedback von anderen Teams ein. Das heißt, es gibt schon eine gewisse Sichtbarkeit einfach by default. Also es gibt ja jetzt nicht die Situation, dass es irgendwie einen Mitarbeiter gibt, ein Jahr lang

in seinem stillen Kämmerlein entwickelt und niemand sieht, was er macht. Das glaube ich schon ganz gut. Was aber schon fehlt, dann so der persönliche Kontakt. Weil ich

super problematisch in so einem Remote-Kontext, wenn es quasi gar keinen Raum gibt.

⁓ auch mal über andere Dinge zu sprechen. wenn jedes Meeting einfach nur die Agenda ist letztendlich. Wir haben jetzt Backlog Refinement und jetzt gucken wir nur durch die Issues durch. Dann haben wir Demo und dann gucken wir jetzt nur die Features an. Und dann machen wir Pair Programming, aber gucken uns nur den Code an. Das ist schon, glaube ich, schwierig. Aber ich glaube, es gibt viele Dinge, die man da machen

dem eben positiv zu wir haben zum Beispiel auch Online-Team-Events einmal im Monat zusammen mit allen. Das ist super, weil man da halt...

die sich die Gelegenheit gibt auch über anderes als über die Arbeit zu sprechen. So 50 Prozent ist dann trotzdem über die Arbeit, aber 50 Prozent auch anderes. Ich glaube, man kann auch viele kleine Dinge machen in dem Remote Setup, wie einfach in Meetings auch mal bewusst mit Smalltalk anzufangen. Das ist so was, passiert in On-Site Meetings ja ganz automatisch. Es kommt keiner einfach so in den Raum und dann startet das Meeting. Bei Online Meetings kann das aber durchaus passieren. Und da muss man so bisschen vorsichtig sein, weil das macht dann auch was mit

der Kultur letztendlich und wie sich die Leute fühlen und wie die Leute sich auch mit der Organisation und mit den anderen verbunden fühlen.

Philipp Deutscher (1:06:34)
Wenn ich dich richtig verstanden habe, sagst du dann auch, naja, das System trägt sich ja auch irgendwo selber. Also dadurch, dass ein Software-Engineer ja irgendwann seinen Code auch einchecken muss und den muss ja jemand auch mal reviewn, fällt dann ja, würden ja Minderleistungen irgendwann auffallen innerhalb der Gruppe, innerhalb des Teams. Und damit ist es gar nicht so wichtig, jemanden die ganze Zeit zu sehen. Ja, weiß, es gibt immer noch so ein Thema, über das ich immer wieder stolpere, weil ich trotzdem irgendwie

Nikolai (1:06:56)
Ja, definitiv.

Philipp Deutscher (1:07:01)
der Meinung bin, also ich verstehe die These zu sagen, als Software Engineer bist du vielleicht sogar remote produktiver, weil du weniger Ablenkung hast, da bin ich 100 Prozent akkord damit. Auf der anderen Seite würde ich sagen, ein Team, was nur remote arbeitet und du vergleichst das Team mit dem gleichen Team, was dich hin und wieder dann on-site trifft oder auch regelmäßig on-site arbeitet, da würde ich jede Wette dafür eingehen, dass das on-site Team das andere outperformt.

Einfach weil mehr Interaktion da ist wie beim reinen Remote Setup. Würdest du da mitgehen oder sagst du, nee, das nicht

Nikolai (1:07:38)
Ich glaube, ist tatsächlich individuell das Thema. Es kommt auf das Team an. Ich glaube, gibt auf jeden Fall Teams, die on-site besser performen werden, wenn die sich zusammen in ein Büro setzen. Ich glaube, gibt aber auch Teams,

on-site mindestens genauso gut performen werden. Also ich glaube, das ist tatsächlich sehr individuell. Und da muss man natürlich aufpassen als Unternehmen, wenn man sagt, wir sind 100 % remote. Und natürlich gucken, man die richtigen Leute hired, die dann auch zu diesem Setup passen.

Philipp Deutscher (1:08:07)
Habt ihr Probleme das zu verargumentieren intern? Wer sagt ihr seid ja hybrid, aber im Sinne von Teile der Organisation sind teilweise 100 % remote, während andere wiederum dann auch on-site da sein müssen? So habe ich es zumindest verstanden. Also wahrscheinlich auch so Sales und sowas oder Support, die werden wahrscheinlich nicht alle nur remote arbeiten.

Nikolai (1:08:27)
das ist so, das ist historisch so gewachsen. meine, die Sache ist ja so, wir können nicht die Entwickler jetzt auch jetzt ins Boot holen weil die sind über ganz Europa verteilt. Ich glaube, das wird schon auch so akzeptiert.

Tatsächlich viele, die regelmäßig ins Büro kommen, die wollen das ja auch. Wir zwingen die Leute ja nicht, jetzt musst du einmal die Woche kommen, sondern viele wollen ja auch ins Büro kommen und dann den persönlichen Austausch da haben. wie gesagt, Dienstags ist bei uns immer sehr voll und das wollen die meisten dann auch.

Philipp Deutscher (1:08:57)
Ja, jetzt sind wir ein bisschen zum Thema Remote-Arbeit abgedriftet. Dabei haben wir uns noch über den Jobmarkt unterhalten und ich habe noch eine Frage, das Thema irgendwie zuzumachen. Wir haben jetzt viel über die Situation gesprochen, die Bewerber und die offenen Stellen. Wie reagieren denn die Unternehmen? Also was sind eure Eindrücke, die ihr

aus der Sicht der Unternehmen, die eure Kunden sind?

Nikolai (1:09:18)
Aktuell ist es schon so, würde ich sagen, dass die Arbeitgeber ein bisschen wählerischer sein können, einfach weil das Angebot insgesamt gesehen besser ist. Aber so Themen wie Gehalt, Remote und die Unternehmenskultur sind natürlich immer noch super wichtige Themen bei den Talenten. Also es ist schon so. Ich würde jetzt nicht sagen, dass es so ist, dass schlechte Unternehmen auf einmal deutlich weniger Probleme im Hiring haben.

durch das Angebot, weil ja trotzdem letztendlich niemand bei unattraktiven Unternehmen arbeiten will. Das heißt schon, wenn man gute Talente finden will, unabhängig vom Arbeitsmarkt gerade.

muss man sich, glaube ich, immer noch als Arbeitgeber auch anstrengen. Man muss weiterhin ein gutes Gehalt bieten. Thema Remote Optionen ist super wichtig, gerade für Softwareentwickler. Also wir sehen zum Beispiel, dass es ja auch ganz offensichtlich Unternehmen, die Remote Stellen haben im Bereich Software Engineering, die hiren mit uns dreimal so erfolgreich letztendlich, einfach weil es ein super populäres Thema ist.

Und die Kultur muss passen. Das heißt, ich würde jetzt keinem Unternehmen empfehlen, sich hier auszuruhen auf dem Markt und sagen, kriege ja trotzdem noch die Bewerbung rein, weil am Ende will man die besten Leute finden, das Unternehmen voranzubringen und da muss man auch attraktive Konditionen bieten.

Philipp Deutscher (1:10:38)
Stell dir fest, dass es aber im

der Benefits, die geboten werden, irgendeiner Weise sich noch mal verändert hat, vielleicht sogar rückläufig

ich erinnere mich an Auswüchse da, da ein Entwickler, hat gesagt, da will er nicht kommen, weil wir nicht die richtigen Getränke angeboten haben, die er sich dann vielleicht, die er gerne gehabt hätte. Also das war jetzt ein Einzelfall tatsächlich, aber solche Auswüchse gab es dann schon mal vor noch ein paar Jahren. Habt ihr da einen Einblick, was solche

Nikolai (1:11:00)
Hm.

Philipp Deutscher (1:11:03)
Benefits angehen, die sich jetzt nicht unbedingt im Gehalt widerspiegeln, sondern eher die Kultur vor Ort oder die Möglichkeiten wie Fitnessbeiträge bezahlen und so weiter, dass die rückläufig sind genauso oder sind die auf dem gleichen Niveau oder steigen die sogar?

Nikolai (1:11:18)
Ich müsste mal die Daten schauen, kann ich jetzt nicht beantworten. Ich habe nicht den Eindruck oder das Gefühl, dass das unbedingt rückläufig ist. Weil ich glaube, ganz unabhängig vom Markt werden mittlerweile solche Dinge einfach erwartet von den Talenten. Was schon ein Thema ist, also wenn man das Benefit in einen Markt der rückläufig ist, ist schon auch das Thema Remote.

Wir haben einen sinkenden Remote-Share seit dem Post-Covid-Peak letztendlich, weil dann doch ein paar Unternehmen sich wieder umorientiert haben. Ja, auch ein paar Großwirts, zum Beispiel SAP. Und das sehen wir schon. Aber ich glaube, insgesamt ist meiner Meinung nach eine gute

Arbeitgeberbenefits ist Teil der Normalität geworden und ich glaube, das wird nicht unbedingt jetzt wegfallen, nur weil der Markt sich ein bisschen gedreht hat.

Philipp Deutscher (1:12:16)
Ja, okay, verstehe. Sehr schön. Spannende Einblicke in den Markt. finde es, ja, das war für mich auch schon sehr wichtig, da mal drüber zu sprechen. Und du warst auch perfekte Gesprächspartner genau dafür. Ich habe noch ein Thema, was ich gerne mit dir irgendwo ansprechen würde. Und das ist auch ein Thema, was du, glaube ich, sehr gerne im Bereich der Entwicklung machst, nämlich das Bereich DevOps. Und der mich natürlich auch sehr stark geprägt hat in meiner Zeit bei Tipico, bei TeamViewer. ging es auch sehr viel das Thema.

verfügbarkeit. ging auch damit darum, wer ist jetzt ... verantwortlich für was. Es ging um you build it, you run it. Was hast du als Dev-Ops-Engineer gemacht oder im Dev-Ops Bereich gemacht? Welche Erfahrungen hast du dort gesammelt?

Nikolai (1:12:53)
Also ich habe bei Instaffo quasi von Anfang an die komplette Infrastruktur gebaut und verwaltet. Wir haben damals, als wir diesen Switch hatten von der Agentur von direkt zu Instaffo,

bestehende Infrastruktur geerbt. Das waren zwei riesig dimensionierte dedicated Server bei Hetzner.

256 GB Memory, und dann wurden drei davon benutzt, die irgendwann mal mit Ansible aufgesetzt worden waren, aber dann schon länger nicht mehr über Ansible konfiguriert worden sind. Das war schon so bisschen Legacy alles. Und ich musste mich dann erstmal einarbeiten. Das war auch tatsächlich ein großer Teil von diesem Switch von der Agentur damals zu Instaffo.

Philipp Deutscher (1:13:13)
Der Klassiker.

Nikolai (1:13:38)
So dieses Gefühl, okay, jetzt sind wir auch irgendwie verantwortlich dafür, dass das auch weiter läuft, dass die Plattform online ist und alles. Wir haben dann irgendwann umgestellt oder ich habe das umgestellt auf ein bisschen modernere Infrastruktur mit mehreren VMs, mit self-hosted databases, dann irgendwie alles schön konfiguriert mit Ansible und Terraform. Das war auch, wir hatten zwischendurch mal so ein Site-Product gebaut, das waren People.

People Search Engine, wo wir sehr große Datenmengen hatten. war auch tatsächlich eine ziemlich große Herausforderung, da die Infrastruktur für zu bauen. Da musste ich ja super viel lernen. Also einmal, ich hab vorher noch nie mit Ansible Terraform das muss man das alles aneignen Hat aber auch super viel Spaß. Zwei, nee, das war schon ein bisschen später. Das war...

Philipp Deutscher (1:14:24)
In welchem Jahr war das, als du das gebaut hast? 2016, 2017?

Nikolai (1:14:33)
glaube, ursprüngliche Umstellung auf VMs, wir haben vorher noch weiter diese beiden riesen dedicated Servers benutzt. Bis dann mal, da gab es mal ein Incident bei Hetzner mit einem Stromausfall im Rechenzentrum und der hat das RAID kaputt gemacht von dem Server. Die standen auch interessanterweise beide im selben Rechenzentrum. Und das hat mehrere Stunden gedauert, bis die Festplatte getauscht wurde, das RAID neu konfiguriert wurde. Und danach haben wir dann gesagt, okay, wir machen jetzt keine dedicated Server mehr, wir machen nur noch VM.

Cloud. Klar, war wahrscheinlich so 2018, 2019 rum, würde ich sagen.

Und wir haben dann, ich hatte ja vorher gesagt, hatten da mal so ein größeres Rewrite gemacht und mit diesem Rewrite haben wir dann auch einen Relaunch gemacht von der ganzen Infrastruktur. Da erinnere ich mich noch sehr gut dran, das habe ich glaube ich so an einem Wochenende alles durchgecodet und das war dann super Gefühl zu sehen, dass alles irgendwie zusammenspielt. Das war dann irgendwie so Zusammen-Orchestrierung von 15 unterschiedlichen VMs mit allem drum und dran und Backups und...

MySQL, Master Slave Replication und das ganze Zeug. Das war schon cool.

Und seit ein paar Jahren laufen wir aber komplett auf Kubernetes mittlerweile, also auf ein Managed Kubernetes. Das heißt jetzt nicht mehr so viel mit Infrastrukturmanagement zu tun. Bin auch eigentlich recht happy damit. Den Umstieg auf Kubernetes habe ich dann aber schon größtenteils, glaube ich, nicht mehr selbst gemacht. Also ich habe das so ein bisschen begleitet, aber es haben dann damals zwei Entwickler von uns das endlich umgesetzt.

Philipp Deutscher (1:16:04)
Wie prägt denn DevOps oder eine DevOps-Mentalität ... deinen Führungsstil? Würdest du sagen, du brauchst dafür ... eine andere Mentalität, ... wie einfach nur engineer zu sein?

Nikolai (1:16:12)
Hmm.

Nicht unbedingt, würde ich sagen. hast ja vorher gesagt, you build it, you run it. bin da mittlerweile so, dass ich eigentlich sage, es gibt da kein Schwarz und

Ich denke, you build it, you run it ist super für kleinere Teams. Irgendwann kommt man aber auch an den Punkt, wo es einfach eine Person braucht, die sich spezifisch mit DevOps-Themen auseinandersetzt. Sonst kommt dann irgendwann keiner mehr zum entwickeln.

Was ich glaube, es schon für jeden Entwickler wichtig ist, gewisses Grundverständnis zu haben von DevOps.

Es sollte nicht diese Mentalität herrschen, ich mach halt nur den Code und dann werfe ich den über den Zaun und irgendeiner baut einen Container draus und der wird dann irgendwann deployed und wenn es ein Problem gibt, dann rufe ich den DevOps Engineer an. Sondern eine gewisse end-to-end-responsibility ist doch schon wichtig. Ich erwarte schon von Backend-Entwicklern in dem Fall, dass man versteht, wie funktioniert Container-Orchestration.

Wie kann ich so basic Dinge machen, basic Dinge debuggen auch in Kubernetes, wenn irgendwie ein Pod nicht startet oder sowas, ohne da immer direkt zum DevOps zu rennen. Das ist, ich, schon wichtig. Auch so Dinge wie CICD Pipelines aufsetzen. Ich glaube, ist kein Good Practice jetzt zu sagen, der Entwickler macht den Code und dann der DevOps baut die CICD Pipeline dafür und entscheidet irgendwie, wie das alles funktioniert. Sondern ich glaube, das schon wichtig, dass da ein gewisses End-to-End gibt.

Aber dass es auch jetzt in größerem Kontext wie bei uns mindestens eine Person gibt, die sich auch...

Philipp Deutscher (1:17:41)
Ist das ein Widerspruch?

Ich habe jetzt auch einige Unternehmen erlebt, die machen das ähnlich. sagen, wir wollen, dass die Teams Ende zu Ende verantwortlich sind. Aber dazwischen gibt es den einen Teil, den macht dann das DevOps-Team. Also im Sinne von, die bereiten die Pipelines vor, also das Deployment und das ...

die Maintenance in Produktion ... und wenn es da Probleme gibt, ... dann steht das Teamgewehr bei Fuß, weil sie haben auch die Monitoring-Checks, sie haben Pager-Duty und so weiter. die Engineering-Teams ... sind nicht mehr diejenigen, jetzt den Fokus darauf legen, ... jedes Mal selbst die Pipelines zu bauen, sondern dafür haben sie dann im Endeffekt ... ... ein dediziertes Team, ... was das für sie bereitstellt.

Nikolai (1:18:20)
Ja, ich meine, es kommt auf den Texteck an, die Architektur, die Infrastruktur, was da Sinn ergibt. Ich würde jetzt nicht unbedingt sagen, dass es ein Widerspruch ist, weil es ja eben kein Schwarz und Weiß ist. Also ich halte es nicht für sinnvoll zu sagen, es gibt so entweder den extremen Case da und das Team alles, es gibt den anderen extremen Case da und das Team, was jetzt die ICD und Deployments angeht, gar nicht, sondern das ist ja immer irgendwo dazwischen und ich glaube, das ist auch eigentlich eine ganz gute Lösung. Aber wie gesagt, es dann auch wieder hängt vom Kontext ab.

vom Texteck.

Philipp Deutscher (1:18:48)
Wie förderst du denn das Thema Automatisierung und Verantwortung und Zusammenarbeit zwischen all diesen verschiedenen Menschen? Wie förderst du das, dass am Endeffekt wirklich dieses Verantwortungsbewusstsein auch da ist? Ist es damit dann auch getan zu sagen, ne ihr müsst jetzt das alles selber machen und los? Oder musst du da noch mehr einmassieren und damit das dann auch tatsächlich so passiert?

Nikolai (1:19:13)
Jetzt in Bezug auf DevOps-Themen oder allgemein.

Philipp Deutscher (1:19:15)
Jetzt den

Bezug auf DevOps-Themen oder gerade so dieses You build it, you run it. So diese Mentalität auch dafür zu haben. Wie förderst du das aktiv? Oder ist es einfach nur das Setup herzustellen im Sinne von, ich setze die Teams so zusammen, dass sie ja keine andere Wahl haben, genauso zu arbeiten?

Nikolai (1:19:30)
Ja,

meine, das ist ja auch zum größten Teil ein Mindset-Thema letztendlich bei den Entwicklern. Und ich glaube, das Beste, was man machen kann, ist Leute einzustellen, die das richtige Mindset schon mitbringen, weil dann muss man das Mindset nicht ändern.

Philipp Deutscher (1:19:43)
Ja.

Nikolai (1:19:45)
Und

für mich ist da schon der wichtig, dass es einfach so ein Mindset gibt von gewissen Gesamtverantwortungen, dass der Job ist halt nicht damit getan, einen Commit zu machen, wenn es nicht deployt wird, sondern muss dann halt auch live gehen. Und das muss ich halt auch als Entwickler begreifen letztendlich. Ich sehe jetzt da konkret bei uns nicht irgendwie den Need, dass ich da in diese Richtung unbedingt pushen muss, weil glaube, wir haben super viele Entwickler, die da sehr...

proaktiv sind, weil wir alle ein gemeinsames Ziel und jeder will dazu beitragen und da kann es diese Art von Blockern eigentlich gar nicht geben.

Philipp Deutscher (1:20:25)
Und wie habt ihr das Thema bei euch dann organisiert? Habt ihr dafür dediziert Leute eingestellt, die dann eine bestimmte Anzahl Teams damit supporten? Also 1, 2, 3 oder ist es dann eher wieder ein DevOps Team, was dann wieder partiell dazugerufen wird, wenn ein Team diese Expertise braucht für einen gewissen Sprint? Weil es ist ja auch nicht in jedem Sprint, dass das im Endeffekt ein Team seine Pipelines anpassen muss. Oder wie habt ihr das bei euch aufgestellt?

Nikolai (1:20:48)
Hm?

Ja, also wir haben ein DevOps-Team, das ist aber eine Person. Das heißt, haben einen DevOps-Ingenieur gerade, der letztendlich alle Teams supportet bei allem rund Deployments, Observability, CI-CD und so weiter und so fort. Aber wie gesagt, kleinere Sachen sollten die Leute selber machen können. Ich will nicht, jeder da immer zum DevOps-Ingenieur.

läuft, wenn es ⁓ kleinere Anpassung geht. sehe die Rolle der Dev-Ops Engineer bei uns eher so, der ist dafür verantwortlich, die grundlegende Infrastruktur zur Verfügung zu stellen, dass die Teams selber möglichst viel machen können. Also zum Beispiel

Philipp Deutscher (1:21:33)
Also Enablement

quasi.

Nikolai (1:21:34)
Genau, Enablement. Also zum Beispiel wird jetzt nicht den Teams sagen, so ihr müsst jetzt eurer eigenen CI-CD-Runner da irgendwie maintainen, weil das ist ja auch ein einfach zentrales Thema. Ihr das Team braucht, CI-CD-Runner. Also ganz klar, liegt beim DevOps-Engineer, dass das läuft und die Teams können dann darauf ihre Pipelines schreiben.

Das ist auch ein ganz gutes Modell für unsere Mit nur einem DevOps-Engineer ist es schon noch eher Wir haben natürlich mehr Arbeit als eine Person machen kann, immer so. Man muss sich eben priorisieren und sich auf die wichtigsten Themen beschränken.

Philipp Deutscher (1:22:10)
Ist ja dann auch etwas Self-fulfilling Prophecies. Also wenn du jetzt auch einmal fünf DevOps-Engineers hättest, da würde ganz viel Arbeit zu diesen DevOps-Engineers ausgelagert werden. Arbeit, die jetzt aktuell von den Teams gemacht wird. der eine DevOps-Engineer kann sich auf das Enablement konzentrieren. Kann ja auch Teil der Strategie sein.

Nikolai (1:22:17)
Naja, 100 Prozent.

Ja, glaube

ich generell ein Risiko bei so Enablement-Funktionen, dass wenn man die scaled, dass man dann sehr schnell gar nicht wirklich mehr Value rausholt, weil eben super viel so Vanity-Work dann gemacht wird, was eigentlich gar nicht so super wichtig ist gerade.

Philipp Deutscher (1:22:43)
Ja, guter Punkt, das stimmt. Das stimmt, guter Impuls. Zum Schluss noch, also hast du einen wichtigen Rat, ... den du jungen Entwicklern oder aufstrebenden Entwicklern geben würdest, ... ... gerne selbst mal CTO werden

was du früher selbst schon mal gerne gewusst hättest, ... bevor du die Rolle übernommen hast, ... oder welche Geheimnisse gibt es für dich, ... die jemand kennen muss, damit er ... es vielleicht auch mal eines Tages an einer Stelle schafft, ... wie du und CTO wird?

Nikolai (1:23:08)
Also für mich so in der Entwicklung meiner Rolle, eins der größten Learnings war eigentlich, dass

unglaublich schwer ist und ich glaube das unterschätzen viele, wie schwer es ist, wirklich gutes Team aufzubauen und wie wichtig das ist. glaube, das habe eben schon mal gesagt, glaube das Allerwichtigste ist es, die richtigen Leute zu hiren für das Team, also wenn du Leute im Team hast.

die nicht zur Kultur passen oder nicht performen, macht es deinen Job als CTO einfach zehnmal schwerer ... und der ist schon schwer genug. Also es fängt alles bei den richtigen Leuten im Team an. War auch so generell, glaube ich, eins meiner größten ... ich mal sagen, Leadership Learnings. Ich glaube, das ist auch ein geteiltes Learning ... von Christoph und mir. So wie wichtig eigentlich das Hiring ist und wie wichtig das ist, ... ... dass man sehr klar darüber ist, mit welchen Personen man überhaupt arbeiten möchte und mit welchen nicht ... ... und dass eben auch einfach nicht jeder in jedes Team ...

passt, selbst wenn es fachlich passt, es muss eben dann auch kulturell das ist, einerseits eine sehr große Challenge, gut hinzubekommen, andererseits aber auch sehr großer Enabler. Ich bin super dankbar für das Team, mit dem ich bei Instaffo arbeite, der, glaube ich, wir alle auch einen sehr guten Job gemacht haben, die richtigen Leute für Instaffo zu begeistern.

Philipp Deutscher (1:24:20)
Sehr gut, schöne

Ganz zum Schluss, bevor wir uns dann zur Ruhe setzen können für den heutigen Tag und den Freitag, am sehr, sehr späten Nachmittag dann beenden können, würde ich gerne eine Runde Rapid-Fire-Fragen mit dir am Schluss machen. Sechs Fragen und du haust mal richtig Welches Tool öffnest du als erstes, wenn du Arbeitstag startest?

Nikolai (1:24:35)
Let's go!

Definitiv Outlook. Also ich organisiere mich komplett über meinen Kalender. Ich habe alle meine Tasks im Kalender letztendlich. Ich nutze kein Taskmanagement, ich habe nur Outlook quasi. Das heißt, ich starte immer mit einem Check-In, was heute ansteht.

Philipp Deutscher (1:24:58)
Okay, was ist deine liebste Automatisierung

bester DevOps Hack?

Nikolai (1:25:01)
Also was ich jetzt angefangen habe zu nutzen ist Zoom AI Companion für Meeting Summaries. Ich hatte das schon mal probiert, als es noch ziemlich early war, da war es super schlecht. Jetzt mittlerweile ist ziemlich gut geworden. Also die Qualität von den Summaries ist echt gut und ich nutze super viel, nochmal nach dem Meeting kurz zu reflektieren, die next steps durchzugehen. Also ein riesen Time-Saver.

Philipp Deutscher (1:25:22)
auch sehr stark Fathom empfehlen, das ist auch kostenlos und ist auch ziemlich gut in dem Transkribieren der Meetings. nutze ich auch sehr stark. Dritte Frage, Kaffee, Tee oder doch lieber Wasser zum Wachwerden?

Nikolai (1:25:26)
Hm, kenne ich auch.

Espresso. Ich bin große Espresso-Fan. Ich habe im Büro, als auch daheim eine Siebträgermaschine. Deswegen immer nur Espresso.

Philipp Deutscher (1:25:43)
Guckst du dann auch YouTube Videos dazu, wie man so den perfekten ... Gotshot dann irgendwie macht oder? Okay, stark. Ein Techbuch oder Podcast, das du jedem CTO-Anwärter ... empfehlen würdest.

Nikolai (1:25:48)
Ja.

Einst der besten Bücher, das ich je gelesen habe, war The Hard Thing About Hard Things von Ben Horowitz. Das beschreibt extrem gut so die Struggles in einem Start-up Scale-up. Und wie der Titel schon sagte, warum es so wichtig ist, auch die harten Entscheidungen treffen zu können. Es ist wirklich ein mega gutes Buch und auch super spannend zu lesen.

Philipp Deutscher (1:26:00)
ja.

Weißt du, was ich lustig finde? Ich war letzte Woche auf einer Konferenz und war dort auch als Speaker auf einem Panel und wurde auch so eine Frage am Schluss gefragt. Und was meinst was meine Antwort war? Genau das gleiche Kein Witz. Was ist dein größtes Pet-Peeve in Meetings? Also was bringt dich auf die Palme?

Nikolai (1:26:23)
Sehr gut.

Ich glaube, was in Meetings schwierig ist, wenn man größere Meetings hat mit mehreren Personen und dann gibt es Diskussionen zwischen zwei Personen, die sich dann auch manchmal länger ziehen. ist für mich so ein Indikator dafür, dass entweder die Audience von dem Meeting nicht richtig ist, also dass es die falschen Personen drin sind oder dass es ein Alignment-Problem gibt, das man vielleicht hätte vorher lösen sollen, als es super ineffizient ist, wenn dann acht Leute in einem Meeting sitzen und nur zwei Leute reden.

Philipp Deutscher (1:26:59)
Wie gehst du damit

Nikolai (1:26:59)
Also ich versuche, wenn ich selber Meetings lege, versuche eben die Audiences so zu wählen, dass es Sinn ergibt. Also ich versuche vorher schon ein kurzes Intro zu geben und auch die Leute zu fragen, so hey willst du dabei sein, glaubst du du kannst Contribute oder nicht. Damit dann Endeffekt keiner sitzt, der nur zuhört oder für den das Thema auch komplett uninteressant ist oder irrelevant.

Philipp Deutscher (1:27:20)
Okay,

Letzte Frage. Eine Fähigkeit, die du dir für die nächsten zwölf Monate unbedingt aneignen willst?

Nikolai (1:27:27)
Definitiv mehr über Agentic AI lernen

Philipp Deutscher (1:27:29)
Okay, das ist gut. Gefällt mir auch sehr. Sehr schön. Nikolai, es hat mir riesengroßen Spaß gemacht mit dir heute. Ich das eine fantastische Unterhaltung, gerade Tech-Arbeitsmarkt und auch darüber hinaus, was deinen Werdegang angeht, deine Interpretation der CTO-Rolle. Hat mir sehr viel Freude gemacht und vielen Dank, dass du heute da warst.

Nikolai (1:27:36)
Ebenso.

Wir auch, danke für die Anleitung.

Philipp Deutscher (1:27:50)
Sehr gerne, dann, ciao ciao.

Nikolai (1:27:52)
Ciao,