Der Balanceakt des CTO: Konstantin Norin über Leidenschaft, technische Exzellenz und die Härte des Loslassens

Keywords

CTO, Softwareentwicklung, IT-Dienstleister, Karriere, Führung, Staffwerke, Entwickler, Management, Technologie, Teamführung

Summary

In dieser Episode des Becoming CTO Secrets Podcasts spricht Philipp Deutscher mit Konstantin Norin, dem CTO von Staffwerke, über die Herausforderungen und Chancen in der IT-Branche. Konstantin teilt seine Erfahrungen als Entwickler und Führungskraft und diskutiert die Notwendigkeit von technischem Verständnis in Managementpositionen. Er spricht über die Gründung von Staffwerke, die Vision des Unternehmens und die Balance zwischen Entwicklung und Management. Zudem gibt er Einblicke in Karrierepfade für Entwickler und die Herausforderungen, die mit der CTO-Rolle verbunden sind.

Takeaways

• Die besten Entwickler sind entscheidend für den Erfolg eines Unternehmens.
• Technische Entscheidungen sollten von Fachleuten getroffen werden.
• Die Balance zwischen Management und Entwicklung ist herausfordernd.
• Karrierepfade für Entwickler sollten flexibler gestaltet werden.
• Führungskräfte in der IT sollten technisches Verständnis haben.
• Die Vision von Staffwerke ist es, qualitativ hochwertige Dienstleistungen anzubieten.
• CTOs müssen die Verbindung zwischen Entwicklern und Stakeholdern schaffen.
• Die IT-Branche benötigt mehr kompetente Führungskräfte.
  Entwickler sollten die Möglichkeit haben, in ihrer Rolle zu wachsen, ohne ins
• Management zu wechseln
• Die Herausforderungen der CTO-Rolle erfordern ständige Weiterbildung und Anpassung.

Chapters

• 00:00 Einführung in Staffwerke und Konstantin
• 02:57 Die Philosophie von Staffwerke
• 05:36 Der Antrieb zur Gründung von Staffwerke
• 08:48 Wettbewerbsdenken und Teamdynamik
• 13:56 Zukunftsvision und Unternehmenswerte
• 16:54 Die Balance zwischen CTO und Entwickler
• 19:55 Der Übergang vom Entwickler zum CTO
• 21:06 Die Herausforderungen der Führungsrolle
• 23:04 Der schmerzhafte Abschied vom Coden
• 24:41 Die Balance zwischen Management und Technik
• 26:35 Führungsstile in der IT
• 30:11 Karrierewege in der Softwareentwicklung
• 32:28 Hausgemachte Probleme in der IT
• 34:42 Die Herausforderungen in der IT-Entscheidungsfindung
• 37:15 Der Weg vom Entwickler zur Führungskraft
• 39:59 Risiken und Chancen des Karrierewechsels
• 43:16 Die Bedeutung von technischem Verständnis in Führungspositionen
• 46:14 Motivation und persönliche Entwicklung
• 48:42 Führungsstil und Entscheidungsfindung
• 51:41 Authentizität und individuelle Ansätze in der Führung

Transcript

Philipp Deutscher (00:21)
So, hallo und herzlich willkommen zu einer weiteren Ausgabe des Becoming CTO Secrets Podcasts. Heute habe ich die große Ehre, Konstantin Norin begrüßen zu dürfen. Konstantin ist der CTO von Staffwerke hat mittlerweile ein Team von 20 Mitarbeitern ungefähr, wenn ich das richtig aus dem Vorgespräch in Erinnerung habe. Sehr engagierten Mitarbeitern und du hast ja auch gesagt, du möchtest gerne so die Top 1 % der Entwickler in deinem Unternehmen haben. Das ist dein Anspruch. Ihr habt Expertise.

Konstantin (00:40)
Ja genau.

Philipp Deutscher (00:51)
aus Healthcare, aus Banking, Manufacturing und Software as a Service. Besonders an Konstantin ist auch noch, dass er von sich selber sagt, er ist im Herzen immer noch ein leidenschaftlicher Entwickler. Und wir haben auch im Vorgespräch schon herausgefunden, dass er durchaus mit dieser Balance zwischen Hands-on-Coding und strategischer Führung durchaus auch ringt. Und darüber werden wir unter anderem heute reden. Deswegen erst mal Konstantin, schön, dass du da bist und freue mich sehr auf die Konversation.

Konstantin (01:15)
Ich freu mich auch.

Philipp Deutscher (01:17)
Sehr gut. Vielleicht kannst du mal ganz kurz zum Beginn dein Unternehmen und dessen Positionierung am Markt kurz vorstellen Was macht ihr und wofür kennt man euch?

Konstantin (01:27)
Ich probiere es kurz zu halten, weil ganz so kurz funktioniert es nicht. Wir sind im Endeffekt eine Art IT-Dienstleister. Jetzt werden aber die meisten irgendwie bei IT-Dienstleister irgendwas wissen, sie schon mal gehört haben. Eigentlich ist der Markt zumindest in Deutschland unterteilt in so verschiedene Anbieter. Es gibt die klassischen Recruiter, die sage mal Freelancer einfach durchrouten.

Und dann gibt es diejenigen, sich eben als der IT Dienstleister im weitesten Sinne bezeichnen. Da funktioniert das Spiel in der Regel so, du hast ein, zwei Leute, die wirklich was drauf haben. Die werden dann zum Kunden vorgeschickt, machen da irgendwie eine große Party. Und dann wird irgendwie ein Team engagiert oder vielleicht zwei oder vielleicht outsourcing, outstaffing Im Endeffekt das gleiche Schema. Das heißt, der Kunde kriegt ein bis zwei gute Leute, fünf, sechs, sieben, acht, neun, ich sag mal Füller.

Und das ist dann im Grunde die Manpower, der er arbeitet und die ihm abgerechnet wird. Wir funktionieren halt eben anders, weil jeder bei uns ist selber im Herzen Entwickler und immer noch Hands-on Entwickler. Es gibt ja eine Ausnahme in der Buchhaltung, aber sonst sind wir alle im Herzen Nerds Und unser Anspruch ist es halt, dass wir Spaß an dem haben, was wir tun.

Und diesen Spaß haben wir nur, weil wir mit Leuten arbeiten, die im Endeffekt gleichgesinnt sind. Das heißt, wir behaupten von uns, haben die besten Entwickler, die es auf dem Markt gibt. Das kann man auch nachweisen. Gerne ist jeder eingeladen bei uns, mal durch einen Bewerbungsprozess zu laufen. Da wird man es verstehen. Das ist im Grunde das, was uns halt von allen anderen unterscheidet. Wir sind nicht auf Marge ausgelegt. Wir versuchen nicht, die günstigste Ressource zum teuersten Preis zu verkaufen, sondern wir wollen mit

Teams in die Projekte gehen, die einfach Bock haben, geile Software zu entwickeln. Die technologiebegeistert sind, die das lieben, was sie tun und einfach Spaß haben wollen. Und natürlich müssen wir auch bisschen Geld damit verdienen, aber in der Regel ist es so, dass wir für die Kunden deutlich günstiger sind, weil wir einfach viel weniger Leute brauchen, weil jeder von uns einfach so schlagwertig ist wie komplette Teams. Das ist so das, was uns unterscheidet.

Das ist bei uns mit 5, 6 Leuten Dinge umgesetzt, die andere mit 100 Mann nicht umgesetzt bekommen. Weil wir auch weniger Reibungsverluste haben, weil wir mit kleineren Teams unterwegs sind.

Philipp Deutscher (03:40)
Okay.

Und der ganze Projektmarkt oder das ganze Thema Nearshoring, Offshoring, Outsourcing von IT-Projekten ist ja durchaus ein Red Ocean. Also kann ich mir gut vorstellen, dass es auch schwierig ist, sich darin zu behaupten. Und ihr macht das dann, indem ihr sagt, ihr wollt eher Qualität als Quantität bieten. Wenige Entwickler, aber dafür umso besser. Dann müsst ihr wahrscheinlich höhere Preise für die verlangen, aber in der Summe.

werdet ihr doch trotzdem billiger einfach, ... weil ihr halt nicht irgendwo ... drei komplexe, ... komplette Fully-Fledged Engineering Teams ... den Kunden loslasst. Habe ich das richtig verstanden?

Konstantin (04:15)
Tatsächlich sind wir gar nicht teurer. Unsere Stundensätze sind, ich sag mal, on par. Wir sind nicht die teuersten, wir sind nicht die günstigsten. Was auch damit zusammenhängt, dass wir keinen Wasserkopf durchfüttern müssen. Wir haben keine 3-Level-Management-Struktur, 12 Personaler, 3 Marketingnasen und was weiß ich was alles, die alle irgendwie Gehalt beziehen müssen, weil wir alle eben ITler sind, weil wir alle Nerds sind.

haben wir auch den Großteil unserer Prozesse automatisiert. Der Personalaufwand, den andere brauchen, den brauchen wir gar nicht. Dadurch ist quasi alles, was wir in Marge machen, uns mehr oder weniger Rein-Marge Da gibt es keine Overheadkosten und deswegen können wir die Stundensätze anbieten, wie wir es können. Wir verhandeln zum Beispiel auch nicht über Stundensätze, sondern wir haben einen Satz, der gilt für alle und

Philipp Deutscher (05:06)
Okay, alles klar. aber du bist ja auch Mitgründer von Staffwerke, was hat dich denn zur Gründung inspiriert? Also gab es eine bestimmte Marktlücke, in die du reinwolltest oder was war dein Drang, dein Antrieb, Staffwerke zu gründen?

Konstantin (05:20)
Eigentlich war mein Antrieb genau das, was ich beschrieben habe. Ich habe lange Zeit als Freelancer auf dem deutschen Markt gearbeitet, habe unzählige Schulungen auch gegeben, also Entwicklerschulungen, Architekturschulungen, Abteilungen umgeschult. Das waren so die Projekte, die haben Spaß gemacht, aber die langläufigen Sachen, du gehst zum Kunden XY, eigentlich egal welche Branche, egal welches Projekt, du findest dort irgendwelche Leute vor, teilweise intern, teilweise extern.

Große Unterschiede gibt es da nicht. so am Anfang meiner Zeit, als ich mich selbstständig gemacht habe, da war ich 24. Da war das halt so, ja ich will die neueste Technologie, ja ich will einen geilen Rechner, ich will einen netten Bürostuhl, irgendwie sowas. Oder ja ich möchte was, was spannend klingt, keine Ahnung, Robotik, Healthcare. Und nachdem du da so eine Weile in diesen Projekten drin bist,

Stellst du fest, das was am Ende des Tages zählt, halt nicht nur das was man selber leistet, bist du mit Herzen dabei, macht dir der ganze Job überhaupt Spaß. Also gehst du morgens gerne ins Büro oder bist du gerne mit den Leuten in Touch, mit denen du arbeitest. Und die Projekte sind meistens so geendet, dass es halt nicht der Fall war. Also dass du irgendeinem gesagt hast, ich hab keinen Bock mehr, ich kann nicht mehr. Und das hängt immer an den Leuten. Das ist wahr.

Es ist egal, bei wem du bist, es ist egal, was du machst. Am Ende, größte Unterschied, wo wirklich die Menschen, denen du zusammen arbeitest. Und bei mir war immer das Konflikt-Potenzial. Ich bin sehr, sehr kompetitiv Typ, schon immer gewesen. Und ich wollte immer irgendwie einer der besten Entwickler werden. Keine Ahnung, ob ich es geschafft habe. Und wollte auch immer mit Leuten zusammenarbeiten, die genauso drauf sind. Und davon findest du gar nicht so viel. Das ist ein Projekt, sind 20, 30 Entwickler plus.

der Wasserkopf, der halt drum herum schwebt und hast du vielleicht einen, der ungefähr genauso tickt wie du. irgendwann stauten sich mehr oder weniger die Kunden an Fragen. Ich gesagt, na ja, ich kenne ja ein paar Leute, können wir ja mal was starten. ja, so hat es im Endeffekt angefangen. Einfach nur mit dem Wunsch, ich will das mein Job wieder Spaß macht und zwar durchgehend Spaß macht nicht nur die ersten drei, vier Monate, wo man sich noch nicht kennt, wo man sich, sag mal...

nicht so sehr auf den Senkel geht, sondern dass du einfach jeden Morgen aufstehst und sagst, geil, heute machen wir das und das. Oder dass du auch abends bis tief in die Nacht mit irgendjemanden da sitzt und... Es sind eigentlich berufliche Dinge, die du da machst, aber du hast halt Spaß dran. Und am Ende macht man sich noch ein Bier zusammen auf und ja, genießt du den Tag, genießt so bisschen das Leben. Das war das Ziel und dann haben wir halt die Staffwerke gegründet. Und ja, da sind wir heute.

Philipp Deutscher (07:52)
Also so ein bisschen Software Engineering as a Lifestyle, so verstehe ich das auch. Du sagst jetzt selber, du bist competitive und Competitiveness warst du schon immer. Wie äußert sich das im beruflichen Leben? Und dann sagst du ja auch, das ist ja auch etwas, was du in anderen Entwicklern suchst. Das heißt, du erwartest von denen die gleiche Art von Competitiveness, die du hast?

Konstantin (08:14)
Vielleicht nicht ganz so extrem, für mich, alles was ich in meinem Leben je gemacht habe, habe ich immer extrem gemacht. Ich habe nie irgendwas angefangen, gesagt, ja das ist jetzt ein Hobby. Ich habe zum Beispiel irgendwann mal das Tauchen für mich entdeckt. Ich war innerhalb kürzester Zeit maximal zertifiziert und habe dann irgendwann Tauchgänge gemacht, die du eigentlich gar nicht erwähnen darf, aber so Solotauchgänge in Höhlen mit Rebreathern

Ich habe keine zwei Jahre gebraucht, bis ich das gemacht habe. Das hat jetzt mit Software nichts zu tun. Aber so bin ich halt. Und als ich eben in die Projekte gekommen bin, wie gesagt, ich habe mit 24 angefangen, ich glaube, das so eins der lustigsten Erlebnisse war. Das erste Interview für einen Freelancer und der Kunde war auch so ein bisschen fies an der Stelle. Der wollte zwei Kandidaten haben.

Und holt uns beide gleich sich in den Raum. ist wirklich, wie man sich einen schlechten Film vorstellt. Die sitzen gegenüber in so einem u-förmigen Tisch, vier, fünf Leute gegenüber. Du sitzt zu zweit auf wirklich exponierten Stühlen da und dann sollst du dir da so pitchen. Und dann hat es mein Kollege, Mitbewerber, wie auch immer du den nennen möchtest, angefangen. Er dann erzählt, la la, er macht das, das, das und das. Er ist außerdem seit 25 Jahren in der IT. Hab ich mich umgedreht und gesagt.

Ich bin fast 25 Jahre alt, aber das wird schon. Ich habe den Job aber bekommen. Im Job, ich hatte damals noch nicht die riesen Erfahrungen, es war eine große Softwarefirma und die hatten sehr viele sehr sehr gute Entwickler, also verhältnismäßig. Und dann habe ich mich halt einfach an die abgefahrensten gehängt und mir versucht irgendwie von den Sachen anzueignen, mit denen zusammen zu coden.

In der Zeit war irgendwie Pair Programming, Stream Programming noch nicht so als Begriff etabliert, aber man kannte es schon. Und das haben wir im Endeffekt gemacht und irgendwann weiß wenn man selber auf das Niveau kommt, derjenige, einem gegenüber sitzt, auf Augenhöhe ist und wo man nicht mehr hinterher rennt. Und das habe ich halt eigentlich immer versucht zu erreichen. Das habe ich auch immer erreicht. Das ist so das Ding, was ich auch bei allen meinen Leuten sehe.

Da sitzt keiner da und sagt, ja, irgendwie, ja, was ihr da macht, sobald die neue Technologie, irgendwas Neues kommt, da hat er eine Idee, dass er über super diskutiert und so. Das ist nicht so richtig feindliches Competitive, aber man versucht sich sogar gegenseitig hochziehen, so, ey, kennste das schon, hast du das? Krass, ja, was kann man damit machen irgendwie? Jetzt kamen irgendwie so Compiler Extensions raus in .NET, dann saßen wir also wirklich ein paar Leute im Pool.

alle schon bisschen was getrunken und dann fangen wir an darüber zu diskutieren, also welche Use Cases wir dafür finden und warum wir nicht irgendwie so etwas wie T4 benutzen oder on the fly Generation oder Emitting und so. Das sind halt Themen, die hast du nicht mit Leuten, die das nicht von Herzen aus machen. Nicht falsch verstehen wir alle haben immer noch Spaß im Leben und so, aber wenn wir zusammen Spaß haben, dann passieren halt solche Themen.

Und das passiert dir nicht, wenn du eben, ich sag mal, die None-to-Five Leute da hast. Die halt sagen, ja.

Philipp Deutscher (11:27)
Ja, das ist richtig. Du hast ja auch das Tauchbeispiel eben genannt und hast dann noch beigefügt, ja du weißt nicht inwiefern das jetzt mit deinem beruflichen Kontext zusammenhängt. Ich finde schon, dass das viel aussagt über dich. Also was jetzt deine Haltung angeht, deine Anspruchshaltung an dich selber, aber dann natürlich auch an andere. Man könnte auch sagen, also ich erlebe das beispielsweise bei mir. Ich würde auch von mir sagen, ich habe ein hohes Anspruchdenken an mich selber, eine hohe Erwartung von mir selber und die

übertrage ich auch an andere. Das kann manchmal unfair sein, weil nicht jeder mit dem gleichen Anspruchdenken mitkommt. Auf der anderen Seite würde ich auch sagen, ich finde das nicht unfair, weil ich von jemand anderem nichts anderes verlange, wie von mir selber. Und so ein bisschen höre ich das auch von bei dir raus. Oder würdest du das nochmal differenzieren wollen?

Konstantin (12:13)
Ja und nein, du hast schon damit Recht, aber ich glaube, ist genau der Unterschied zwischen dem, wo man als Entwickler steht und zwischen dem, man, ich bin heute CTO, aber in dem Moment, wo man auch als Teamlead, als Developmentlead, was ich vorher eben schon gemacht habe, das ist genau der Unterschied. Ja, du hast einen so hohen Selbstanspruch, aber du kannst ihn nicht eins zu eins auf jemanden projizieren.

und dann wird es automatisch zum Konflikt kommen. Selbst wenn du Leute hast, die genauso stark oder stärker sind als du, allein in die Tatsache, dass sie ein bisschen anders denken, ein bisschen anders ticken, vielleicht etwas anders versuchen, würde dich, also wenn du das komplett projizierst, in Konflikt bringen. Und das war so eine der Lessons, die hat ein bisschen gedauert, hat auch ein bisschen wehgetan. Deswegen ja und nein.

Philipp Deutscher (13:02)
kann ich mir vorstellen. Wir haben kurz über Staffwerke auch noch gesprochen, auch wie ihr euch im Markt etabliert. Was mich natürlich interessiert ist, was ist die Vision des Unternehmens für die Zukunft? Ihr habt jetzt ja schon gute Projekte, ihr habt ein gutes Maß an Mitarbeitern. Ich höre auch raus, du hast einen gewissen Anspruch da dran und du stellst die Leute auch entsprechend ein. Wo soll die Reise hingehen?

Mehr davon, von dem, was ihr schon macht, es nochmal das Schärfen des Profils und interessantere Projekte. Wo geht eure Reise in Zukunft hin?

Konstantin (13:35)
Also ich freue mich eigentlich auf diese Frage antworten zu können. Aufgrund dessen, wie wir strukturiert sind. Ich habe ja erwähnt die Chefin. Und ja, ich bin Mitgründer, aber wir haben das klar getrennt. Wir haben CEO. Das ist die Anne, Anne Staff. Deswegen Staffwerke. Und ich bin der CTO. Das heißt, ich kann frei sagen, was ich denke. Und sie muss dann gucken, wie sie das ganze geschäftlich unter den Hut kriegt.

Also meine Vision ist tatsächlich, ja, etwas zu wachsen, aber gar nicht so sehr. Ich möchte einfach genau das tun, was wir heute tun. Ich halte es für das Richtige. Auch da muss man ganz klar sagen, finanziell ist es in Ordnung. Ich bin zufrieden, die Mitarbeiter sind zufrieden, die Chefin ist zufrieden. Klar, mehr geht immer. Aber ich habe jetzt nicht den Anspruch, auf Teufel-komm-raus zu wachsen Vor allem wenn es dann

zur Konsequenz hätte, dass wir das verwässern was wir sind. Wer wir sind, was wir tun. Wir hatten schon paar Mal die Situation, wo das im Raum stand, einfach aufgrund der Anfrage, aufgrund der Marktlage und und und und und und und und ich habe mich immer klar dagegen ausgesprochen, also sowohl das Geschäftsmodell in irgendeiner Form zu verändern, bestimmte Kunden unter bestimmten Bedingungen anzunehmen, auch vielleicht solche Dinge, die für uns quasi sehr nahe liegen.

wie eben einfache Profilschachereien in nichts zu machen. Sprich Kandidaten, die wir normalerweise aussortieren würden, die immer noch extrem stark sind. Das muss man auch verstehen. Wenn die Leute bei uns durch den Bewerbungsprozess scheitern, dann heißt es nicht zwangsläufig, dass sie schlecht sind. Damit gehören sie immer noch sehr oft zu den Top-Leuten, die es am Markt gibt. Aber es reicht dann vielleicht in diesem Schritt gerade nicht.

Aber es wäre sehr, einfach für uns zu sagen, haben schon diese Leute, denen wir wissen, das ist nicht der Top-Prozent, sondern die sind in den Top-10-Prozent. Die könnten wir sehr einfach in, ich sag mal, Projekte weitervermitteln. Das tun wir halt nicht. Weil das genau das tun wird, es würde das verwässern was wir sind, wer wir sind, und da verzichten wir einfach drauf. Also wir haben diese klare Ausrichtung. Wir bieten die absoluten Experten, Elite-Teams, wie auch immer du es bezeichnen willst, und ich weiß,

Das sind Begriffe, ständig durch die Gegend geworfen werden. Aber ich lade jeden herzlich dazu ein, das auf die Probe zu stellen. Und da gibt es für uns keine Alternative.

Philipp Deutscher (15:57)
Ja, sehr gut. Wie ist es denn, wenn man auf der einen Seite des CTOs mit nicht wenigen Mitarbeitern und auf der anderen Seite immer noch den Anspruch hat, einer dieser top 1 % Developer zu sein? Das stelle ich mir sehr schwierig vor. Also ich stelle es mir schwierig vor, weil ich auch selber natürlich in der Rolle des CTO war. Ich war in der Rolle des Entwicklers. Ich habe irgendwann eine Entscheidung für mich getroffen, wie ich diese Rolle interpretiere. Und die steht natürlich in dem Widerspruch zu dem, wie du sie interpretierst. Deswegen, wie balancierst du diesen

Konstantin (16:11)
Ja.

Philipp Deutscher (16:25)
Diese zwei Welten.

Konstantin (16:26)
Schwierig. die Balance fällt mir sehr, schwer. Und wenn ich meine Jungs heute frage, dann sagen die, ich soll mal den Code in Ruhe lassen. Sie machen das schon. Sie meinen es dann nett Ich behaupte immer noch, dass ich ganz gut coden kann. Aber ja, in den letzten zwei bis drei Jahren bin ich einfach nicht mehr dazu gekommen, wirklich so intensiv und so tief zu coden, wie ich es früher gemacht habe. Keine Frage. Dennoch mache ich immer noch unendlich viele Code Reviews.

Ich kann jetzt nicht mehr, ich sag mal, die neueste Syntax aus dem FF jederzeit, aber die Strukturen und ähnliche Dinge, die sehe ich schon noch besser als viele andere. Es ist ein schmerzhafter Prozess. Es ist ein bisschen eine Transition. Du hast gesagt, du hast für dich eine andere Entscheidung getroffen, du lebst die Rolle anders, was auch für mich absolut legitim ist. Also ich verstehe, dass es komplett unterschiedliche Führungsstile gibt.

Ich lebe da so ein bisschen, wie ich es nenne, den Cäsarstil. Erster unter Gleichen So war ich oder so bin ich. Ich habe niemals auf irgendwen gehört, der Führungskraft, Lehrer, Auftraggeber, was war, den ich für weniger fähig oder weniger qualifiziert gehalten habe als ich. Den konnte ich einfach autoritär nicht akzeptieren.

Deswegen habe ich auch denselben Anspruch an mich und das beicht sich natürlich schon gewaltig. Du willst auf der einen Seite halt da mithalten können, aber du merkst, natürlich galoppieren dir diese Leute, die wir haben, davon. Wenn du dann nicht, wie gesagt, letzten zwei Jahre war für mich nicht so viel Coding angesagt und wenn wir heute mal irgendwie so kleinere Sessions machen, dann sehe ich schon ein bisschen alter aus. Völlig klar. Aber ich glaube, sie schätzen immer noch, dass ich...

zumindest mithalten, mitdenken kann, mit steuern aber natürlich nicht mehr so schnell schreiben. Für mich war oder ist es immer noch sehr hart. Es gibt so, ich hole da kurz ein bisschen aus, viele, die in die Softwareentwicklung gehen, gehen heute in etwas, was dir schnelles Feedback gibt. Ich sag mal an JavaScript und Co., also sprich Webseiten. Du schreibst zwei, drei Zeilen Code, es fängt an sich was zu bewegen, was zu blinken, du siehst was. Das habe ich nie gemacht. Ich war immer im Backend unterwegs, Backend, Datenbank.

Da siehst du maximal eine Zahl. Und das war damals ein bisschen unbefriedigend, wenn du sagst, du hast jetzt vier Wochen gearbeitet, aber da ist nichts zum sehen, ist nichts anzufangen. Du hast halt das Problem gelöst, du hast jetzt einen geilen Algorithmus geschrieben und so weiter und so fort, aber du kriegst halt wenig Feedback. Und als es dann eben Richtung CTO ging, ist das nochmal eine Stufe krasser geworden. Weil da hattest du irgendwie einen Algorithmus, einen Code, was weiß ich, einen Unit-Test, passt oder...

ein Bug der behoben ist. Du hast halt irgendwas gemacht und in dieser reinen Führungsrolle hast du eigentlich nichts. du steuerst die Leute und am Ende weißt du auch die Entscheidungen, die ich heute treffe, die Konsequenzen davon oder die Auswirkungen davon, die sehe ich nicht heute, die sehe ich nicht morgen, die sehe ich nicht in einer Woche, die sehe ich in drei bis zwölf Monaten. Kommt drauf an, was es halt ist. Und teilweise haben sie auch nicht so

was hast du heute eigentlich geleistet? Also die Fragen stelle ich mir immer noch regelmäßig und denke mir so, ja, können sie jetzt auch einfach ein bisschen coden, wäre auch nett. Also, es ist schon ein harter Konflikt.

Philipp Deutscher (19:40)
Was war für dich der kritischste Moment bei deiner Transition vom Entwickler zum CTO? War es dann der Moment, dem du festgestellt hast, es gibt tatsächlich jemanden in meinem Team, der ist besser als ich? Oder war es was anderes? Ich kann mir vorstellen, dass das schwierig ist, gerade mit deinem kompetitiven Hintergrund dann genau diese Situation zu erleben, aber vielleicht war es ja tatsächlich eine andere Situation.

Konstantin (20:01)
Es ist etwas anderes gewesen. Also ich kann nicht sagen, es war der Moment, es war so einer der Schlüsselmomente. hatte mit zwei von meinen Jungs einen Call gehabt, die beide begnadeten Entwickler sind. Gar keine Frage. Und ich habe in dem Abend dann geweint, ehrlich gesagt. Ich habe den beiden

bestimmte Dinge erklärt, bestimmte Dinge übergeben. Und es hat ewig gedauert. hat... Also nicht, weil sie es nicht konnten. Vielleicht habe ich nicht gut genug erklärt und so weiter. Und es war für mich eisenhart zu wissen, ich darf da nicht eingreifen. Ich darf jetzt nicht selber Hand anlegen. Ich darf jetzt nicht mich hinsetzen und den Code für sie schreiben. Wenn ich das tue, verliere ich sie.

Dann nehme ich denen das weg, was sie sind, das was sie tun. Ich oversteppe und natürlich kann ich so auch nicht skalieren. Ich kann so nicht delegieren. Ich kann so nicht wachsen. Das war schon ein sehr, sehr, sehr bitterer Abend für mich. Auch, das habe ich damals zu meiner Partnerin gesagt, das ist echt hart für mich war zu sagen, ich weiß, ich könnte schneller, ich könnte es besser, weil ich einfach tief in der Materie drin bin. Ich kenne die Technologie besser und, und, und, und. Aber ich muss auf genau das, womit ich mich quasi mein ganzes Leben

profiliert habe oder wie ich mich ausgerichtet habe, darauf muss ich jetzt verzichten zugunsten dessen, was ich halt schaffen will. Das hat schon sehr, sehr weh getan.

Philipp Deutscher (21:33)
War das für dich auch der Moment, in dem du gemerkt hast, du musst deinen Ansatz anpassen? Also vielleicht auch mehr ins Weg bereiten gehen, mehr darin gehen zu sagen, ich bereite die Sandbox innerhalb der sich die Entwickler in dem beruflichen Kontext, in dem sie sich hier bewegen, arbeiten können? Oder war das eher ein schleichender Prozess dahin?

Konstantin (21:41)
Hm.

Der Prozess dahinter hatte schon längst stattgefunden, aber diese Abend war die Manifestation davon. Das war die klare Grenze, wo ich eben von ich bin einer von euch zu ich bin jetzt doch Manager, wo ich mir das auch wirklich eingestehen musste. Da gab es jetzt nichts mehr zu interpretieren, da gab es jetzt nichts mehr zu drehen, zu wenden und zu sagen, das war so

Das war der harte Cut und natürlich hat der Prozess vorher stattgefunden. Also sonst wäre ich nie dahin gekommen. der war halt eben so schleichend. Das war dann halt so... Aber da war es halt wirklich der harte Cut. Also da war es halt völlig klar für mich.

Philipp Deutscher (22:40)
Ich frage mich, wodurch dieser Prozess überhaupt angestoßen wurde. Also war das der Fakt, dass du ... Also du kannst ja auch CTO eines Unternehmens sein, hast dann irgendwie eine Handvoll Mitarbeiter nur und bleibst immer in dieser Rolle und schaffst es auch immer, hands-on zu bleiben und auf dem Niveau zu bleiben, in dem deine Mitarbeiter unterwegs sind. Oder passiert das dann eher mit dem Wachstum des Unternehmens, dass wenn du eine gewisse Größe hast, einfach merkst, dass du das nicht mehr kannst. Oder geht es grundsätzlich nicht?

Konstantin (22:57)
glaub ich nicht...

Ich glaube, das geht nicht. Also wenn du im Herzen Coder bist, dann ist die Zeit, du ins Coding steckst, so brachial, da bleibt dir keine Zeit für was anderes. Also erstens, brauchst diese sehr langen Zeitscheiben. kannst, ich sag mal so, wenn du Manager bist, egal in welchem Rang, du hast eine Viertelstunde einen Call hier, 30 Minuten da, Stunde da, dann redest du mit dem und dem. Du kannst in diesen kurzen Phasen etwas bewegen.

kannst du mit Coden vergessen. Also irgendwie jedem Coder sagen, du hast jetzt mal eine Stunde Zeit, löst aber was. Come on. So funktioniert es halt nicht. Und auch die Zeit, die du in das Coding investieren musst, wirklich gut zu sein, wirklich erfolgreich zu sein, ist brachial. Die hast du einfach nicht mehr. Du hast keine Chance. Wenn du aber in diesem Pfad gehst und sagst, ich will einer von euch bleiben und so weiter und so fort, dann wirst du niemals die Leute führen können. Sie werden dich fachlich vielleicht respektieren, aber du wirst keine Unternehmenserscheidung treffen können und...

Das was ich in meiner Rolle sehe, das ist gar nicht so sehr CTO, diese Lead-Rolle, wie auch immer die dann heißt, Lead-Architekt, Lead-Developer, Team Lead, Tech Lead, lalalala, Titel, Schall und Rauch. Der Unterschied ist eben, dass du die Verbindung zwischen den Entwicklern und den Nicht-Entwicklern schaffst. Dass du beide Sprachen sprechen musst, dass du dein Team schützen musst.

Philipp Deutscher (24:14)
Hm.

Konstantin (24:28)
dass du auf der anderen Seite irgendwie die Stakeholder beglücken musst, dass du diese Balance irgendwie halten musst. Das ist die Hauptaufgabe. Und natürlich ist es geil, wenn man die Möglichkeit hat, dann immer noch technologisch aktiv zu sein, wenn man coden kann. Also zumindest für mich ist das so. Aber aus meiner Sicht ist es eine komplette Illusion, sagen zu können, ja, ich mache genau das, was ich vorher gemacht habe, verhalte mich, wie ich mich vorher verhalten habe und bin jetzt halt Führungskraft. Ich weiß, dass viele Karrieren so ablaufen.

Philipp Deutscher (24:55)
Hm.

Konstantin (24:57)
Aber das sind halt nicht die Menschen, die wirklich ein Team führen können.

Philipp Deutscher (25:03)
Ich versuche das auch immer wieder zu vergleichen mit anderen Beispielen aus der Businesswelt oder aus anderen Branchen. Wenn ich jetzt zum Beispiel mir Profifußball anschaue, bis in die 90er gab es in den ein oder anderen Erstliga-Vereinen in Europa auch mal den Spielertrainer, der tatsächlich beides war. Der war halt der Spieler, der Experte auf dem Platz und gleichzeitig aber auch schon etwas älter und hat dann auch schon angefangen, die Coaching-Rolle zu übernehmen. Ich glaube, es gibt einen Grund.

dass sich dieses Modell eigentlich nicht durchgesetzt hat oder auch jetzt im Jahr 2024 man eigentlich nicht mehr sieht, weil das Maß an Spezialisierung, was man durchführen muss, in der einen oder anderen Bereich zu performen, einfach sehr, hoch ist. Gleichwohl siehst du dann aber ehemalige Weltklasse-Spieler wie ein Xabi Alonso bei Bayer Leverkusen, der ein Weltklasse-Spieler war bei Bayern München, Real Madrid und Liverpool, der

auf einmal eine viel höhere Kredibilität und Reputation hat von Anfang an gegenüber seinen Mitspielern, weil er all das schon mal war und auch immer noch im Training ihnen zeigen kann, wie es richtig geht. ich glaube, das... Also A, du brauchst diese Kredibilität und diese Reputation, die hilft dir sehr, deine neue als Trainer oder auch als CTO auf einem viel höheren Level praktizieren zu können.

Gleichzeitig musst du halt immer wissen, du kannst nicht einfach aus Spielfeld laufen während dem Match und den Elfmeter selber schießen. Oder zumindest solltest du es nicht.

Konstantin (26:27)
Das spricht im Endeffekt an was ich vorhin schon kurz erwähnt hatte. Es gibt verschiedene Führungsstile. Ich weiß nicht, ob es so einfach ist zu sagen, der eine ist besser, der andere schlechter. Ich kenne mich im Fußball tatsächlich nicht besonders gut aus. Aber ich kann deinem Beispiel schon folgen. Ich verstehe natürlich, dass es auch eben Trainer gibt, die halt keine Spieler oder keine Profi-Spieler sind. Sie haben dann noch, glaube ich, durchgehend alle ein Verständnis von Fußball.

Das ist aber tatsächlich etwas, was in der IT gar nicht der Fall ist. Ich bezeichne die IT immer noch als komplett wilden Westen. Wir haben sehr wenig Standardisierung, wir haben sehr wenig Strukturen. Und eine Managementrolle heute in der IT, gar nicht so sehr CTO, egal was, wird sehr oft mit Personen besetzt, die keinerlei technischen Background haben, was aus meiner Sicht katastrophal ist.

Du musst nicht der beste Entwickler der Welt sein, um Gottes Willen. du musst halt irgendwas mitbringen können, du mit deinem Fachpersonal, ach, Deutsch ist so eine furchtbare Sprache, zumindest halbwegs auf Augenhöhe reden kannst oder halbwegs verstehst, was ihre Wehwehchen sind, wo sie hinwollen. Wie kannst du, ich sag mal, Beratung aus dem Team annehmen, wenn du kein Wort verstehst von dem, was sie sagen?

Philipp Deutscher (27:39)
Das bläst in das gleiche Horn, ich auch gerne mal reinblase. Ich glaube, es braucht mehr sehr gute Entwickler, die die Bereitschaft haben, in diese Führungsrollen reinzuwachsen. Warum? Aus genau den Gründen, die du gesagt hast. Denn ansonsten kommen nämlich die Leute, die eigentlich nicht den technischen Background haben und machen es, aber können es dann nicht ganz so gut machen, weil ihnen vielleicht das Verständnis fehlt.

Würdest du das so unterschreiben oder würdest du sagen, naja, aber der gute Entwickler soll doch lieber der gute Entwickler bleiben? Dann dann wäre die zweite Frage, wer soll es denn dann machen?

Konstantin (28:14)
Ich kann es tatsächlich nicht unterschreiben. Schuster bleibt bei deinen Leisten bzw. das Peterchen Prinzip kennt man ja. Ich sehe es ein bisschen anders. Ich bin nicht komplett gegen das, was du da sagst, aber wenn wir uns viele Unternehmen heute anschauen, der klassische Karrierepfad, wenn es denn überhaupt einen gibt, für Softwareentwickler ist, du fängst an als Juniorentwickler, dann wirst du auch ein Entwickler oder

Senior-Entwickler, je nachdem Und der nächste Schritt, den du machst, der heißt dann Architekt. Das macht dich noch nicht zur Führungskraft, aber bis es der Karriere-Schritt, den du machst, das ist da, wo du höheres Gehalt bekommst und eventuell höhere Befugnisse. Und das sehe ich immer wieder. Leute, die grandiose Entwickler sind, werden desolate Architekten oder umgekehrt fantastische Architekten, wenn die Code anfassen. Da wird's finster.

Es gibt Leute, die alles können, natürlich. Es gibt Leute, die auch bereit sind, sich zu entwickeln. Das ist vielleicht auch noch mal so eine Sache, was ich eben einfach lernen musste. Also wie führe ich Leute, wie verhalte ich mich, wie treffe ich meine Entscheidungen und und und. Ich denke, es gibt mehr als genug Leute, einfach nicht bereit sind, das zu tun, weil sie das nicht möchten. Sie werden in vielen Unternehmensstrukturen dazu gezwungen und sie gehen den Pfad. Aber sie sind niemals glücklich in den Positionen.

Und was aus meiner Sicht fehlt, sind einfach auch klare Karrierechancen in der Entwicklung oder im Engineering allgemein, die nichts mit Führung zu tun haben. Und umgekehrt, wenn du Menschen hast, die eben so blöd gesagt BWL studieren, die also theoretisch sollte sie Führungskompetenz beigebracht bekommen, die vielleicht wie auch immer das passiert, die dürften aus meiner Sicht keine Teams oder Abteilungen führen, wo sie keinerlei fachlichen Background haben.

Das heißt nicht, dass sie die krassesten Entwickler sein müssen oder die besten Technologie-Experten der Welt oder oder oder. Aber sie schon ein gewisses Verständnis und es reicht kein grobes Verständnis. Das müssen sie schon haben. Ich Crowdstrike sagt ja was,

Ist es nicht eigentlich ein Armutszeugnis für die gesamte IT?

Philipp Deutscher (30:30)
Dass der Vorfall so passiert ist, wie er passiert ist? Oder was meinst du?

Konstantin (30:33)
Nein, dass Crowdstrike existiert.

Philipp Deutscher (30:35)
Gute Frage. Habe ich jetzt keine Meinung dazu gerade.

Konstantin (30:37)
Also, okay, ich sag dir mein Gedanken, das ist, also ich weiß, das ist bisschen extrem, aber an der Stelle, diese Software macht nichts anderes als, ich sag mal, Updates zu schachteln

Diese Software ist, ich glaube, die am meisten verwendete Software weltweit für diese Problemstellung. Aber diese Problemstellung in jedem Unternehmen ist künstlich geschaffen durch Fehler innerhalb von technischen Entscheidungen im Unternehmen. Wir haben bei uns keine Probleme mit Patches oder Updates noch nie gehabt, werden wir auch nie haben. Wir verwenden kein dediziertes Tool dafür. Wir verwenden da keine verzögerten Updates und so weiter.

Es ist etwas komplexer zu lösen, keine Frage. Zero-Downtime-Update selbst auf einer Entwicklermaschine? Schwierig, machbar. Ist aber eben anspruchsvoll, du musst jemanden haben, der es kann, du musst jemanden haben, es nicht will. Und der Punkt ist aber, CrowdStrike wurde von hunderten, tausend, zehntausend von Unternehmen, auch von Hightech-Unternehmen wie Microsoft selber gekauft. Das heißt, es waren Menschen in der Position, diese Entscheidungen zu treffen.

die nicht das technische Verständnis dafür haben, dass das Problem, was diese Software löst, komplett hausgemacht ist.

Wenn du deine IT anders strukturierst dann brauchst du diese Software gar nicht.

Philipp Deutscher (31:55)
Ja, interessanter Take. Interessanter Take.

Konstantin (31:57)
Ich weiß, es ist hart gerade in Unternehmen wie CrowdStrike und und natürlich gibt

Philipp Deutscher (32:00)
Ich weiß nicht, ob ich denen so mitgehen würde, weil ich glaube schon, es, selbst wenn ihr das könntet, in einer Art Weise, wie es ein Tool wie CrowdStrike nicht kann, und zwar ohne Downtime, solche Updates zu fahren, ist die Erwartungshaltung, dass das auch der Rest aller Industrien, die diese Tools einsetzen, das auch können, ist wahrscheinlich zu hoch.

Konstantin (32:25)
Warum? Crowdstrike zu verwenden ist nicht real.

Philipp Deutscher (32:27)
weil die ab

Ja, der Grad an Expertenwissen geht aber in eine andere Richtung.

Konstantin (32:33)
wie gesagt, es geht mir gar nicht so Crowdstrike oder ähnliche Lösungen, sondern darum dass du eben sehr viele Entscheider heute hast, die technische Entscheidung treffen, ohne einen entsprechenden Hintergrund zu haben. Sie hören dann auf irgendwelche Sales-Leute, Consultant-Leute oder nicht böse gemeint, aber auf irgendeinen YouTuber, anstatt auf die Expertise im Unternehmen, beziehungsweise anstatt dass man sich die Expertise dann dazu holt, falls man sie nicht hat.

Dadurch entstehen halt diese Probleme, die wir heute immer wieder in der IT sehen. CrowdStrike war nicht das erste dieser Art oder auch nicht das letzte dieser Art bleiben. Wir haben ja auch in den Staffwerken aktuell so einen kleinen IT-Test online, wo du so bisschen deine Software Entwicklungseffizient testen kannst. Und manche dieser Fragen werden dem ein oder anderen komplett...

Philipp Deutscher (33:17)
Den habe ich übrigens gemacht und habe festgestellt, ich sollte mich mit euch in Verbindung setzen, um die zu lösen.

Konstantin (33:21)
Naja, schön, freue ich mich drauf. der Punkt ist, einige dieser Fragen erscheinen dem einen oder anderen sicherlich grotesk. das entsteht halt, also diese ganze Fragenkatalogik auch entstanden aus den Jahrzehnten eine Erfahrung, die wir gesammelt haben, wo all diese Punkte tatsächlich sehr, sehr reelle Probleme sind. Und all diese Probleme, oder fast alle sind, hausgemacht.

Philipp Deutscher (33:24)
Haha.

Konstantin (33:48)
Man kann jetzt sagen, okay, Großraumbüro hin oder her, das hat vielleicht andere Geschichten. Aber der Großteil der Punkte, die wir ansprechen, sind in der Vergangenheit entschieden worden. Also, irgendwer hat gesagt, wir machen das jetzt so, obwohl es komplett dämlich ist. Und das können nur Menschen gewesen sein, die absolut keinen technischen Background haben. Das ist es.

Philipp Deutscher (34:11)
Ja, aber nochmal ganz kurz, du hast jetzt gerade die Brücke geschlagen zu einem interessanten Punkt, den wir vorhin schon mal besprochen haben und ich bin ehrlich gesagt mit der Antwort noch nicht zufrieden, weil ich glaube, dass es noch ein Widerspruch da drin ist. Also du sagst auf der einen Seite, braucht diese, also es bräuchte eigentlich mehr Kompetenz in den Entscheidungsfunktionen oder mehr fachliche Kompetenz, die fehlt aktuell. Auf der anderen Seite sagst du, Entwickler bleib bei deinen Leisten.

Konstantin (34:22)
Okay.

Hm?

Philipp Deutscher (34:36)
Und dann wiederum bist du ja selber das lebende Beispiel dafür, dass es ja auch geht. Also was ist die Lösung dazu? Brauchen wir mehr Learning über Leadership und Kommunikation in den Ausbildungsberufen oder in den Studienplätzen für Entwickler? Oder was ist die Lösung für dieses Dilemma?

Konstantin (34:41)
Ja, aber die

Also erstmal, Entwickler bei deinen Leisten sind nicht böse gemeint. Wir haben viel mehr Manager auf dem Markt, die wir nicht brauchen als Entwickler, die wir ganz, ganz händeregend brauchen. Viele treffen die Entscheidung, sag mal, Karrierepfad einzuschlagen und dann dadurch automatisch ins Management zu gehen, weil sie eben Karriere machen wollen. Karriere machen bedeutet in der Regel einfach nur etwas mehr Geld verdienen.

Das heißt, die Leute haben momentan gar keine Möglichkeit aufzusteigen, wenn sie nicht bereit sind, ins Management zu gehen. Das ist das eine Problem. Das zweite Ding ist, ja du sagst, ich bin das lebende Beispiel. Ja, bin ich, aber kann ich mich, wenn ich ganz ehrlich bin, heute noch guten Herzens als Entwickler bezeichnen und zwar nicht, ich code abends oder auch mal mit paar Bier und ein Kumpels oder meine

was-weiß-ich Video-Sammlungsverwaltungssoftware, der Klassiker halt. Und da muss man halt klar sagen, die Antwort müsste nein sein. Denn das, was ich heute beruflich mache, ja, ich reviewer Code, ja, ich lese Code, aber ich schreibe kein Code. Ich bin de facto kein Coder mehr. Ich löse keine Bugs, ich debugge keine Produktivsysteme, ich schreibe keine Prototypen, naja, ab und zu doch. im Endeffekt ist das, was ich heute mache, nicht mehr wirklich coder sein.

Und das ist vielleicht etwas, wo jeder in sich gehen muss und sagen, liebe ich das Coden, will ich beim Coden bleiben, möchte ich Architekt werden, das ist auch nochmal eine ganz andere Geschichte als eine Führungskraft, oder möchte ich Führungskraft in dem Bereich sein. Das sind Entscheidungen, die man treffen muss und das sind Entscheidungen, die man nur sehr schwer bewusst treffen kann, einfach aufgrund dessen, was es an Informationen heute gibt. Ich meine...

Ich weiß nicht, wie alt du warst, aber irgendwann musstest du eine Entscheidung treffen, zu welcher Schule gehe ich oder was studiere ich. Da warst du 15, 16, 17 Jahre alt. Würdest du sagen, dass du damals gute Entscheidungen getroffen hast? Ja, genau.

Philipp Deutscher (36:54)
Man hat Entscheidungen getroffen und ob die dann gut oder schlecht sind, also ich glaube es geht in erster Linie darum, die Entscheidung zu treffen und dann etwas daraus zu machen. Das kann ja bedeuten, dass man die Entscheidung irgendwann rückgängig macht, denn nicht jede Entscheidung, die man im Leben getroffen hat, ist eine One Way Door. Es kann aber auch sein, dass man mit der Entscheidung, die man früher getroffen hat, hat man einen Weg eingeschlagen, den man weitergehen kann oder nicht. Das ist ja erstmal weder gut noch schlecht, also in vielen Fällen. Ob ich jetzt Informatik studiere, ob ich jetzt BWL studiere oder...

Ein Arztberuf ist ja erstmal keine gute oder schlechte Entscheidung, sondern es bereitet einen Weg in die Zukunft.

Konstantin (37:31)
Und jetzt kommt genau aber das Problem, wenn du heute ein Top-Entwickler bist und du triffst die Entscheidung, du möchtest eben jetzt ins Management gehen, dann ist es vielleicht einen Schritt nach oben, vielleicht einen Schritt zur Seite. Aber was dann auf jeden Fall passiert ist, du verlässt die Entwicklung und du verlässt sie halt nicht für 10 Minuten. Du musst sie realistisch für eine längere Zeit verlassen. Zumindest ein Jahr, anderthalb, zwei.

Das ist in vielen Berufen überhaupt kein Problem. Also wenn du Arzt bist, Anwalt bist, Steuerberater bist, dann kannst du zwei Jahre Pause machen. Es wird sich schon was geändert haben, aber nicht viel. In der Softwareentwicklung zwei Jahre, holy moly. Dann brauchst du die nächsten vier Jahre, dahin zurück zu kommen, wo du vorher warst. Das heißt, das ist eine Entscheidung, du triffst, die hat

ziemlich brachiale Konsequenzen und das ist in dem Fall ein One Way Door. Ich sehe das als großes Problem oder auch als großes Risiko. Ich kann heute sagen, aber ist es...

Philipp Deutscher (38:36)
Risiko ja, Problem weiß ich nicht. Also ja, bin bei dir. Das ist eine One-Way-Door, wenn man das so sieht, dass der Weg zurück in die Entwicklung nach einem Jahr nicht entwickeln und nach einem Jahr Führung auszuprobieren schwierig ist und sehr langwierig ist. Und deswegen ist es eine One-Way-Door, da bin ich bei dir. Es ist auch ein Risiko, aber es ist noch eine Chance, oder? Es gibt ja auch Grund, warum sich ein Entwickler aus dem

Moment der Entwicklung weiterentwickeln möchte und sagt, er ist neugierig, was da als nächstes kommt oder er möchte, er sieht ja, wie Management in seinem Unternehmen gehandhabt wird und er ist der Meinung, er kann das besser und mit seinem technischen Background.

Konstantin (39:15)
Aber wie machst du den Schritt zurück? Den kannst du nicht mehr zurück machen. Und das Risiko, was ich, also für dich als Person, du bist jetzt im Unternehmen XY Angestellter guter Entwickler, oder, jetzt sagst ich mach jetzt den Schritt Richtung, was weiß ich, Team Lead, irgendeine Position wird frei, du hast das Standing, du kriegst den Job, und mit zwei Jahren merkst du, hm, hm, also, so ganz glücklich bin ich nicht damit.

Du kannst den Rückschritt gar nicht ohne weiteres machen. Also im Unternehmen kaum. Unternehmenswechsel ist für viele auch gleichzeitig ein Lebenswechsel. Und dann eben, ich sag mal, dieses Rat, alles wieder neu zu lernen oder aufholen zu müssen, ist nicht so einfach. Und das Risiko da drin ist für mich auch aus unternehmerischer Sicht. Das Unternehmen verliert zunächst mal einen sehr guten Entwickler. Und diesen Rat gesät und bekommt

Jemand, der hoffentlich ein guter Manager wird. es ist das Prinzip Hoffnung. Falls er scheitert, auch das Unternehmen gewisses Problem. Ich habe keine pauschale Lösung dafür, ich denke, braucht Karrierepfaden, die ein bisschen flexibler sind innerhalb der Unternehmen. Das ist auch so ein Ding, die dir vielleicht erlauben, ein bisschen Verantwortung zu übernehmen.

Schritt für Schritt, wo du sagst, okay, ich bin jetzt nicht direkt Team Lead, aber ich hab jetzt blöd gesagt zwei Azubis, die ich auch wirklich plane, steuere und so weiter. dass ich daraus so langsam transitionen kann. ist die eine Seite. Die andere Seite ist natürlich, es gibt auch einfach Menschen, die gute Manager sind. Ich weiß nicht, du schon mal mit welchen gearbeitet hast, bestimmt. Und die können sich durchaus auch technisches Zeug aneignen. Nur...

ist das etwas, was wenige Unternehmen anbieten. Wenn es bei uns irgendwann so weit ist, dass wir tatsächlich wirklich Vollblutmanager einstellen müssen, weil es nicht mehr anders geht, dann werden wir auch darauf bestehen, dass die einen gewissen technischen Background bekommen. Du hast unsere Sales ja kennengelernt und mit der habe ich persönlich hunderte von Stunden verbracht, ihr Technologien, ihr Konzepte, ihr Prozesse und ähnliches nahe zu bringen.

Das hat sie zu einer besseren Sales für uns gemacht. Aber genau das gleiche würde ich für einen, ich sag mal, Product Owner oder was auch du für eine Rodde nennen möchtest tun. Ich würde sagen so, hey, okay, du hast jetzt also irgendwie gewisses Management-Potential und du arbeitest aber immer noch mit Entwicklern zusammen. Die sollen auf dich hören, die sollen dich verstehen, du musst sie verstehen. Das heißt, jetzt musst du Technologie lernen.

Jetzt musst du auch vielleicht ein bisschen Coden lernen. Du musst nicht der beste Code der Welt sein, aber du musst wissen, was es bedeutet, ich sag mal, an einer zu langsamen Maschine mit zu wenig Bildschirm und einer mittelmäßigen Source Code Verwaltung zu arbeiten. Du musst diesen Schmerz verstehen. Und das ist für mich eher die Lösung oder der Weg, den man gehen muss. Es wird halt...

Philipp Deutscher (42:02)
Absolut, ja.

Konstantin (42:22)
Das Meiste über das gesprochen haben, das gibt es in Schwarz-Weiß. Aber Grau ist eigentlich viel schöner.

Philipp Deutscher (42:29)
Das ist richtig. Und das Grau ist auch der ausschlaggebende Punkt. ich verstehe auch deinen Anspruch an die CTO-Rolle, an die Führungskraftrolle, dass die technische Kompetenz, du musst nicht mehr der beste Entwickler sein, aber es muss schon sehr nah an der Exzellenz sein, um überhaupt diese Rolle ausfüllen zu können, während ich auch der Meinung bin, dass ein hohes Maß an technischer Kompetenz notwendig ist, aber der...

wo ich diese Messlatte aufhänge, ist wahrscheinlich ein paar Stufen unter dem, wo du es halt aktuell siehst. Und das ist genau auch diesen Graubereich, den ich halt auch sehe in der Interpretation von verschiedenen CTO-Rollen oder wie die CTO-Rolle ausgefüllt werden kann. Aber was mich zum Beispiel noch interessieren würde, wenn du jetzt dir einen ambitionierten Entwickler anschaust, der vielleicht den Weg zur Führungskraft oder zum CTO einschlagen möchte, vielleicht sogar einen ähnlichen Background hat wie du oder einen ähnlichen Anspruch.

Welchen Rat würdest du diesem Entwickler geben?

Konstantin (43:28)
Ich würde ihm keine Rat geben, würde ihm eine einzige Frage stellen und die wäre warum?

Philipp Deutscher (43:33)
Warum möchte er CTO werden?

Dann nehmen wir an, die Antwort ist, ich möchte...

Ich habe den Anspruch, in meinem Unternehmen technische Entscheidungen oder Entscheidungen in meiner Tech-Organisation so getroffen werden, dass sie Sinn machen, dass sie auch besser erklärt werden und dass sie besser aligned sind mit den anderen Businessfunktionen.

Weil ich bin sehr unzufrieden als Entwickler damit, dass offensichtlich Entscheidungen von Managementseite getroffen werden, die ich nicht verstehe, die mir auch nicht erklärt werden, die Auswirkungen auf die technische Halbwertszeit hat, was ich da baue. Und damit bin ich sehr unzufrieden und ich möchte CTO werden, weil ich möchte das ändern. Ich möchte das anders machen. Das ist die Motivation.

Konstantin (44:19)
Darin hinterfrage ich die Motivation. Wir wollen keine philosophische Diskussion führen, aber bei dieser Antwort würde ich sagen, such dir einfach ein besseres Unternehmen oder eins, besser zu dir passt, anstatt dich wirklich komplett auf links zu drehen. Es ist was komplett anderes. Jemand, der den Weg einschlagen möchte, viel Glück, viel Erfolg. Es wird eine harte persönliche Herausforderung werden.

Philipp Deutscher (44:28)
Hm, okay.

Konstantin (44:43)
Ich würde empfehlen, probier es im kleinen Bereich. Schnapp dir ein, zwei Leute und guck, ob du die wirklich führen kannst. Und zwar nicht unbedingt Leute, mit denen du gut kannst.

Die Leute, mit denen wir gut können das ist immer alles einfach. Oder versuch mal Entscheidungen zu treffen, die du normalerweise vielleicht nicht treffen würdest, einfach nur zu sehen, wie schaffst du es, jemanden dazu zu bewegen, mit dir zusammen zu arbeiten, für dich zu arbeiten, obwohl diese Entscheidung nicht dem entspricht, was derjenige möchte. Wie bringst du ihn dazu, dich dennoch dabei zu unterstützen?

Philipp Deutscher (45:12)
Guter Punkt. Wie machst du das? Genau, guter Punkt. ist nämlich die, wie kommunizierst du das mit den Mitarbeitern?

Konstantin (45:20)
kommt drauf an. Es kommt auf die Mitarbeiter an, es kommt auf die Situation. Ich habe keine pauschale Antwort dazu. Ich sag mal, grundlegend sage ich heute, das habe ich aber früher schon gemacht, auch als Entwickler battelst du dich mit anderen Entwicklern, mit einem Stakeholder oder sonst wem. Und solange ich nur Entwickler war, war meine Position folgende, passt auf, das ist mein Standpunkt, das sind meine Argumente.

überzeugt mich vom Gegenteil oder overruled mich. Ich akzeptiere beides. wie auch immer das ausgegangen ist, mal so, mal so. Heute mache ich es ähnlich. Also ich sage, okay, ich sehe es so, du siehst es so, lass uns darüber sprechen und manchmal kommt man zu diesem Konsens, manchmal nicht. Wenn man zu keinem Konsens kommt, muss man leider halt den Bad Cop spielen und sagen, schau mal, ich trage die Verantwortung.

Das heißt, wenn es falsch läuft, es an mir, das Ganze zu kompensieren, wie auch immer das aussieht. Mehr Ressourcen, andere Ressourcen, Neuschreiben, la la la la la. Aber die Verantwortung liegt bei mir. Die liegt nicht bei dir. Wenn du die Verantwortung übernimmst, mit allem was dahinter kommt, sprich auch dann die gegebenenfalls Kosten, Personaländerungen und und und und und, kannst du gerne die Entscheidung tragen. Die wird keiner tragen. Die meisten können sie auch gar nicht tragen.

Philipp Deutscher (46:39)
Interessanter Gedanke. Was würdest du denn... Ja?

Konstantin (46:41)
Aber es ist, also das ist mein Stil. Du hast eben noch gesagt, du siehst die Dinge nicht ganz so extrem wie ich, du hast nicht ganz diesen ganz maximalen Anspruch wie ich. Ich glaube, dass du damit eher Recht hast als ich. Weil desto länger ich das mache, umso mehr merke ich, es ist zunehmend schwerer. Und gerade wenn du auch mehr Leute hast, mit denen du zusammen arbeitest, sind nicht nur meine Mitarbeiter, sondern auch entsprechend mehr Kunden, mehr Projekte und so weiter.

Die Breite des Know-Hows, das du brauchst, wird irgendwann unüberschaubar. Ich bin jetzt schon an dem Punkt, ich sage, da geht es bei mir schon gar nicht mehr reine Softwareentwicklung oder eine einzige Programmiersprache. Ich muss mich jetzt auch über Dinge wie Infrastrukturen zum Beispiel austauschen oder Technologieentscheidungen in Ebenen, mit denen ich eigentlich wenig zu tun habe, wenig beschäftigen will.

Da geht es für mich darum, wo kriegst du den Input her? Wenn ich etwas nicht weiß oder nicht in der Lage bin, eine Entscheidung zu treffen, wie komme ich zu der Entscheidung?

Und auch da, mein Stil ist halt sozusagen, ich habe Leute, denen ich vertraue, mit denen berate ich mich. Also ich mache nicht so demokratische Geschichten, sondern ich weiß, okay, der da, der kann das, das, das, das, das, wie kein Zweiter. Und deswegen höre ich auf den.

Philipp Deutscher (48:03)
Also eine gewisse Art von Meritokratie eigentlich. Also wer schon die Kompetenz hat und schon bewiesen hat, dass er das in einem bestimmten Bereich kann, der wird natürlich eher gehört als derjenige, der es noch nicht hat. Halt dich durchaus für legitim. Also ich finde auch, es geht gar nicht so sehr was ist jetzt richtiger als das andere. Die Frage ist halt, was hilft für welche Situation? Und das ist natürlich auch, jedes Unternehmen hat einen gewissen anderen Ansatz oder ist in einer anderen Situation in seiner Wachstumsphase und braucht auch eine andere Art von Führung.

Von daher, weil das eigentlich hier funktioniert, das nicht, dass es auf der anderen Seite funktioniert. Und genauso heißt es aber auch nicht, dass das, was hier nicht funktioniert, der anderen Seite nicht vielleicht die beste Lösung ist, die es überhaupt gibt. das ist ja das Schöne an diesen Rollen. Du hast irgendwann auch mal zwischendurch gesagt, das ist ja alles diese Namen für die Positionen sind Schall und Rauch. Und da gebe ich dir 100 Prozent recht. Und sie sind aber trotzdem sehr mannigfaltig interpretierbar.

Und die Kunst ist es herauszufinden, was ist der richtige CTO oder die richtige Interpretation des CTOs für das jeweilige Unternehmen in der jeweiligen Situation. Und das ist dann immer richtig und falsch.

Konstantin (49:12)
Ich würde sogar noch einen Schritt weiter gehen. Du hast ja gesagt, was würde ich jemandem raten? Mein Ratschlag ist, eigenen Stil zu finden. Auch das klingt sehr pauschal, sehr blöd. Aber das, was ich tue, so wie ich die Leute motiviere, so wie ich Entscheidungen treffe, so wie ich mich verhalte, ich behaupte, selbst wenn du dich genauso verhalten würdest wie ich, würde es nicht funktionieren.

weil du ein anderer Typ bist als ich. Und genauso umgekehrt, so wie du vorgehst, so wie du Entscheidungen triffst, wenn ich das eins zu eins anwende, würde das auch nicht klappen. Weil es nicht zu mir passt. Es wäre nicht authentisch. Das merken die Leute. Und auch deine Entscheidungsmechaniken funktionieren für dich dann nicht mehr. Das heißt, alles, was wir erzählen, das ist natürlich Input, den die Leute gerne annehmen können. Aber...

Philipp Deutscher (49:39)
Absolut nicht.

Konstantin (50:03)
immer mit einem Grain of Salt. Es muss zum Unternehmen passen. Zurück zu Crowdstrike, gibt durchaus Unternehmen, wo's Sinn macht. Das ist nicht die Pauschallösung für ein nicht existierendes Problem. Genauso ist es den Führungskräften. Für mich ist es essentiell, dass ich mithalten, mitreden kann, dass ich irgendwie ein Sparrings-Partner bin, weil ich mir das auch immer selber so gewünscht habe von meinen Führungskräften, in welcher Form die auch immer existiert haben.

Das heißt nicht, dass es für jeden passt.

Philipp Deutscher (50:32)
Hast du ein Motto oder ein guiding principle, was dich leitet?

Konstantin (50:39)
Whatever it Takes

Philipp Deutscher (50:41)
Whatever takes, that's good. Das kommt glaube ich sogar auch aus dem Sport eigentlich. Meine ich, anyway. ja, Konstantin, sehr, sehr interessante Diskussion. Ich muss sagen, ich mag deinen Ansatz, weil er sich natürlich nochmal eine sehr neue Komponente in dieses, wie wird man eigentlich CTO reinbringt und...

Konstantin (50:47)
Weiß ich nicht. Kann sein.

Philipp Deutscher (51:03)
Dieser Podcast richtet sich ja in allererster Linie an ambitionierte Softwareentwickler, die vielleicht sich überlegen, CTO zu werden oder diesen Pfad einzuschlagen. Und vielleicht haben Sie jetzt natürlich, nachdem Sie jetzt auch unserer Konversation zugehört haben, sagen Sie jetzt, ich will gar nicht mehr CTO werden, ich möchte lieber mit Konstantin zusammenarbeiten und möchte ein besserer Entwickler werden. Also wie können solche Leute mit dir in Kontakt treten und mehr über Staffwerke erfahren?

Konstantin (51:27)
Staffwerke.de Da gibt's mannigfaltige Möglichkeiten. Man kann sich bewerben, alternativ über LinkedIn kontaktieren. Ich bin regelmäßig quer durch Deutschland unterwegs. Kann sich gerne auch ein Bier treffen. Das ist kein Thema.

Philipp Deutscher (51:44)
Sehr gut. Konstantin, herzlichen Dank, dass du heute dabei warst. eine sehr, gute Diskussion. Ja, hoffentlich können wir das an anderer Stelle nochmal fortsetzen. Danke dir.

Konstantin (51:53)
Danke dir für die Einladung, hat Spaß gemacht, ich freue mich aufs nächste Mal.

Philipp Deutscher (51:58)
Alles klar, ciao ciao!

Konstantin (52:00)
Mach's gut