# Building Self-Sustaining Tech Organizations

**Podcast:** Becoming CTO Secrets
**Published:** 2026-05-12

## Transcript

Hallo und herzlich willkommen zu Becoming CTO Secrets, deinem Podcast für die harte Realität der CTO-Rolle zwischen Tech, Team und Business.
Ich bin Philipp Deutscher, Ex-Sender CTO und CTO-Coach und natürlich auch Gründer der Becoming CTO Community oder dem CTO Circle, wie ich es mittlerweile auch nenne.
Mein heutiger Gast in der Folge ist Tobias Dursberg.
Er ist CTO bei OneStop Pro.
einem Unternehmen für digitale Geräteverwaltung und Ortungslösung und mit einem ungewöhnlichen Werdegang zwischen Startup-Unternehmertum und Scale-Up.
Tobias versteht sich nicht als klassischer Tech-CTO, sondern als Organisationsgestalter mit dem klaren Ziel, ein System aufzubauen, das auch ohne ihn funktioniert.
Das wollen wir alle, die wenigsten schaffen das.
Tobias, herzlich willkommen.
Hallo Philipp, vielen Dank für die Einladung.
Ich freue mich, hier zu sein.
Sehr schön.
Tobias, dein Lebenslauf wirkt nach außen wie ein schneller Aufstieg zum CTO.
Das würden sich viele gerne wünschen.
Ich bin mir aber sicher, das sieht man auch eine ganze Menge noch nicht in deinem Lebenslauf.
Was sieht man da aktuell nicht?
So schnell war es eigentlich gar nicht.
Ich glaube, man sieht einiges nicht.
Im LinkedIn-Cosy steht nicht so viel drin.
Aber ich habe, glaube ich, schon am Studium angefangen, viel...
über Impact nachzudenken.
Mir ist es eigentlich wichtig, dass ich Sachen vorwärts treibe und dementsprechend habe ich auch meine ganzen Stationen ausgewählt.
Also ich habe während des Studiums schon freiberuflich gearbeitet, habe für Sportverbände gearbeitet, bin dann hinterher in der Freiberuflichkeit geblieben und gar nicht so die klassische Entwicklerrolle eingenommen.
Dieses Thema Druck, Verantwortung war eigentlich schon immer da, macht mir auch unglaublich Spaß, braucht es auch irgendwie so ein bisschen.
Ja, Entwickler natürlich, klar, einmal Entwickler, immer Entwickler, aber schon so mit einem bisschen anderen Background, anderen Twist.
Du hast dich ja selber im Vorgespräch auch als Unternehmer in der Entwicklerhülle bezeichnet.
Was bedeutet das denn konkret?
Nimm uns da mal mit, was geht da in dir vor, wenn du in diesen Kategorien denkst?
Ich glaube, ich habe eine andere Sichtweise auf Dinge manchmal.
Also eher so, nicht dieses klassische Entwickler, ich nehme jetzt mal ein Thema und kaue das mal durch bis zum Exzess und schaue, wie ich noch alles zu Tode optimieren kann.
Sondern es ist schon sehr viel Pragmatismus, glaube ich, auch immer drin gewesen.
Gucken, dass ich schnell zu Ergebnissen kommen kann.
Und vor allen Dingen auch immer der Blick auf, wie ich vorhin schon gesagt habe, den Impact auf den Kunden, den Impact auf die Firma, in der ich gerade arbeite.
Eher so die Frage, soll ich Sachen überhaupt machen, statt wie mache ich die Sachen?
Das ist viel hinterfragen und am Ende natürlich auch immer gucken, lohnt sich das, was ich da eigentlich mache?
Sowohl finanziell als auch.
kommt da was raus, wo der Kunde damit was anfangen kann.
Hast du da auch ein Beispiel dafür, also Situationen, wo du das Gefühl hast, da ist der normale Entwickler vielleicht weniger pragmatisch, als er sein sollte und in denen du dich mit Pragmatismus ganz besonders hervortust?
Ich glaube immer dann, wenn es um Optimierung von Sachen geht.
Meinen Schnellschuss raushauen, Sachen schnell auf den Markt bringen, gucken, was bringt das Ganze.
Lohnt sich das überhaupt, das weiterzugehen?
Viele Entwickler, gerade junge Entwickler, haben, glaube ich, dieses Gespür gar nicht.
Ich kann mir auch gar nicht vorwerfen.
Das müssen sie natürlich erst lernen.
Viele lernen es vielleicht bis zum Ende gar nicht.
Ja, aber das ist wieder ein anderes Thema.
Aber ich glaube, gerade in der Anfangszeit, wahrscheinlich während dem Studium, während der Dotcom-Blase auch, ging es darum, einfach schnell Sachen liefern, schnell Sachen live zu bekommen, um dann mal zu gucken.
fliegt das Ganze oder fliegt es nicht.
Hast du dann das erste Mal festgestellt, dass du vielleicht sogar mehr Unternehmer als Entwickler bist?
Gab es da einen bestimmten Punkt in deiner Karriere, an dem du das ganz besonders gemerkt hast oder war das auch ein schleichender Prozess, der sich so über die Jahre vielleicht im Studium begonnen, aber dann irgendwie weiter ausgebaut hat?
Oder war es von Anfang an für dich sonnenklar, ich gehe aus dem Studium raus mit meinem Abschluss?
Am Ende des Tages bin ich aber vielleicht mehr unternehmerisch geprägt als ein eigentlicher Hands-on-Entwickler.
Ich glaube, es ist vielleicht.
Am Anfang, während des Studiums oder direkt nach dem Studium, ist es immer total unerfahren, klar.
Dann macht man halt mal so vor sich hin und sagt mit seinen Erfahrungen und schaut dann, was dann so passiert.
Ich glaube, ich hatte eine Station, die mich sehr, sehr geprägt hat.
Das war...
im Jahr 2006, wo ich bei der Gründung von der Übersetzungsagentur mit dabei war.
Ich habe nicht selber gegründet, aber war von Tag 1 dabei und habe da gelernt, was es heißt, da diese Verantwortung zu übernehmen und wurde da auch schon in dieses Unternehmensgedenken eingeführt und auch so ein bisschen ins kalte Wasser geschmissen.
Es waren sieben Leute.
Das Ganze war eigenfinanziert und wenn da irgendjemand aus der Reihe getanzt hat und nicht unternehmerisch gedacht hat, dann wäre das Ganze nicht geflogen.
Ich glaube, das hat mir so das erste Mal die Augen geöffnet, was es eigentlich bedeutet, Verantwortung zu übernehmen, als Entwickler auch.
Zumal das zu einer Zeit war, da gab es keine POs oder hinter denen man sich verstecken konnte, keine Jira-Boards oder irgendwie was, sondern man hat halt einfach alles gemacht von Anfang an.
Ja und jetzt macht man ja wieder alles in Zeiten von AI.
Da kann man sich irgendwann auch nicht mehr hinter dem Product Manager verstecken, weil da wird von einem ein Product Engineer erwartet, dass er alles gleich von Anfang an mitdenkt.
Oder siehst du das nicht so?
Oder hast du eine andere Perspektive darauf?
Das ist eine spannende Frage.
Also gerade das Thema AI, das ist alles so jung und gefühlt wird jeden Tag irgendwie eine neue Kuh durchs Dorf getrieben.
Von links kommen die Security-Leute und schreien, oh Gott, oh Gott, bitte nicht, alles geht im Bach runter.
Auf der anderen Seite sind vielleicht viele Manager da, die sagen, ja geil, machen wir AI und alles wird schneller und wir brauchen weniger Leute, Sachen zu liefern.
Ganz ehrlich, ich weiß nicht, in welche Richtung das geht.
Wir probieren es selber aus.
Wir spielen mit rum.
Ich glaube, das ist eigentlich...
der momentane Stand.
Und ja, auch da, ich kann es gar nicht sagen.
Ich weiß nicht, in welche Richtung es geht.
Am Ende des Tages weiß es, glaube ich, keiner von uns.
Wir können ja alle nur Mutmaßungen anstellen.
Wir können Theorien ausstellen.
Wir können anfangen, selber auszuprobieren.
Und dann werden wir irgendwann sehen, wohin uns das treibt.
Ich meine, ich glaube, viele haben eine...
haben eine Idee, wohin es gehen kann oder beginnen, Visionen zu entwickeln Richtung, ich habe eben den Begriff Product Engineer mit reingepackt.
Es kann natürlich auch sehr viel in den Bereich Agentik, AI gehen.
Also ja, du hast natürlich völlig recht.
Wissen tun wir das alle nicht.
Wir können aber natürlich ganz aktiv eigene Visionen entwickeln und eigene Thesen aufstellen.
Welche deiner frühen Erfahrungen, die du gesammelt hast?
Du hast ja eben gesagt, Dotcom.
Startups, du hast Exits mitgemacht.
Was hat dich denn da am stärksten bisher geprägt?
Und keine Ahnung, vielleicht kannst du auch noch ein bisschen was zu erzählen zu den Exits, die du mitgemacht hast.
Eigentlich alles so ein bisschen.
Also jede Phase war spannend, jede Phase hatte Learnings.
Also fangen wir an mit der ganzen Dotcom-Blase 2000, 2001, wo man dann irgendwie als Freelancer geheiert wird in irgendeine neu gegründete Firma.
Man kommt dann da rein und als erstes sieht man, wie die Geschäftsführer sich dicke Autos kaufen von der Kohle, die von den Venture Capitalists kommen.
Drei Monate später ist alles wieder rum, weil die Kohle verbrannt ist.
Das war eine komplett wilde Zeit irgendwie, aber ich glaube, da lernt man viel, wie man es nicht macht oder was man nicht machen sollte.
Die Zeit als Freelancer hat mich sehr geprägt, einfach ganz viele verschiedene Sachen zu sehen.
Auch mit der Ungewissheit, wenn ich jetzt nicht performe, dann bin ich gleich wieder weg.
Das ist das Problem eines Freelancers immer.
Fluch und Segen, glaube ich, auch.
Man kann es ja auch andersrum machen.
Aber wie ich vorhin schon gesagt habe, ich glaube, die Zeit in der Übersetzungsagentur war die prägendste.
Einfach zu sehen, wie wird eine Firma skaliert, wie wird eine Firma...
naja, erstmal aufgebaut, wie wird die gemanagt, vielleicht kommt daher auch so ein bisschen meine Neigung zu diesem Organisatorischen da auch.
Der Geschäftsführer damals, ein unglaublich guter Geschäftsführer, der mir auch unglaublich viel erklärt hat, wo ich ihm sehr, sehr, sehr dankbar bin.
Aber dann auch natürlich die Geschichte mit den Exits, einmal mit der Agentur, einmal mit dem Unternehmen danach.
die beide dann an eine ausländische Firma verkauft worden sind, mit ganz anderen Ansätzen.
Also A mal der Clash of Cultures.
Also wie wirken wir Deutschen auf die, sagen wir mal nicht Deutschen.
Selbst polnische Kollegen, spanische Kollegen, belgische Kollegen haben ganz anderes Mindset, ganz andere Kommunikation.
Man tritt sich gegenseitig ganz oft auf die Füße, ohne es eigentlich zu wollen.
Da lernt man, glaube ich, ganz viel draus oder habe ich viel mitgenommen.
Darf ich da mal reingrätschen, wie wirken denn deutsche Techies auf andere?
Also ich habe auch viel internationale Erfahrung und natürlich hast du recht, jede Kultur oder jedes Land wirkt, hat eine bestimmte Wirkung auf andere.
Es hat ja auch viel damit zu tun, welche Klischees hängen einem nach.
Was hast du denn festgestellt, wie deutsche Techies auf andere wirken?
Amerikaner, andere Europäer.
Amerikaner weiß ich jetzt nicht, weil ich bislang noch nicht mit Amerikanern zu tun hatte, aber mit anderen Europäern teilweise als, wie ist das deutsche Wort, unhöflich, ungehobelt vielleicht, was mit unserer Art zu tun hat, einfach direkt zu sein.
Also du als Nordlicht bist, glaube ich, noch ein bisschen direkter als ich als Bayer.
Bin ja kein gewürdiges Nordlicht.
Ich komme eigentlich auch eher aus dem Südwesten von Deutschland, aber egal, mach weiter.
Aber das kommt gerade zum Beispiel bei den Spaniern und in Polen überhaupt nicht gut an.
Hier ist man es gewohnt, in Deutschland, wenn irgendwas nicht gut ist, dann sagt man, hey Leute, das war nicht gut.
Ohne, dass das irgendwie einen Nachhall hat.
Sondern einfach nur, war nicht gut, lass uns besser machen.
In anderen Ländern löst das irgendwie eine mittelschwere Sinnkrise aus und da reibt man sich dann auch ganz gern dran.
Das ist richtig.
Du warst so in diesen Fällen...
wo du in Startups warst und auch zu dem Zeitpunkt Exits stattgefunden haben, warst du zu dem Zeitpunkt angestellt?
Warst du teilweise auch investiert oder hast du Anteile gehabt oder warst du in Anführungszeichen nur als Freiberufler dort unterwegs?
Das heißt, du konntest dann auch nicht von den Exits direkt partizipieren, sondern warst im Endeffekt eine Hired Gun und konntest danach oder musstest danach vielleicht sogar weiterziehen?
Ich wollte weiterziehen zweimal.
Durftest du nicht?
Doch, ich hätte auch dürfen.
Aber nein, ich wollte dann irgendwann, weil ich gemerkt habe, das passt mir nicht.
Beide Käufer waren dann sehr hierarchisch.
Ich bin kein Freund von so starren Hierarchien.
Nee, ich war beides mal angestellt dann.
Also ich habe mich bei der Besetzung dann irgendwann anstellen lassen und habe es nicht sonderlich profitiert davon.
Ich habe sehr viel Erfahrung mitgenommen.
War leider nie beteiligt, aber okay, habe viel gelernt, das reicht schon.
Und trotzdem hast du ja eine ganze Menge gelernt in diesem Startup-Kontext, was viele klassische Entwickler vielleicht nie lernen.
Was war das denn, was du da mitgenommen hast, das dich dann auch nochmal weiter zu dem gemacht hat, den du jetzt bist?
Das, was ich vorhin schon gesagt habe, diese Verantwortung zu übernehmen und zwar ungefiltert, ohne irgendein PO dazwischen.
Teilweise auch die Kunden einfach im Haus.
Das heißt, wenn irgendwas nicht funktioniert hat, stand der Kollege oder die Kollegin am Schreibtisch und hat gesagt, geht nicht, bitte fixen, ohne dass man sich groß verstecken kann, einfach den direkten Impact zu haben.
Ich glaube, das ist etwas, was man gerade auch heutzutage nicht mehr so mitkriegt, weil man immer diese Pufferzone, PO, Pufferzone, Teamlead, Pufferzone, Hierarchien hat.
Ich bin da ganz happy auch, dass ich da in der Zeit angefangen habe, wo es alles noch gar nicht so richtig gab oder zumindest nicht so exzessiv gab wie jetzt.
Das heißt, du nimmst das gerade auch sehr stark wahr.
Du sagst, du verwendest den Begriff Pufferzone.
Ja, man kann das auch irgendwie als...
Ausredenzone auch interpretieren für viele, wenn da Puffer da ist und mal gar nicht so viel Verantwortung nehmen müssen.
Nimmst du das auch so wahr, aktuell noch in den Organisationen, dass da viel zu wenig Verantwortung übernommen wird von Mitarbeitern, Menschen, die eigentlich viel mehr Verantwortung übernehmen sollten?
Ja, ganz stark.
Hat verschiedene Beweggründe.
Teilweise ist es Angst, Fehler zu machen.
Teilweise ist es einfach Unerfahrenheit.
Teilweise sind es aber auch die Strukturen, die dann da sind.
Also man wird, glaube ich, in vielen Firmen oft als Entwickler eingestellt mit dem Satz, du bist Entwickler, du entwickelst da, aber denken tut der PO.
Du kriegst einfach ein Ticket und das Ticket tust du abarbeiten und dann kommt das nächste Ticket und dann kommt das nächste Ticket.
Der PO weiß schon, was er macht.
Also das habe ich in einigen Firmen erlebt so.
Widerspricht mir komplett.
Aber ich glaube, dass das eher noch stärker wird gerade.
Man hat auch nicht mehr so die Vermischung wie früher.
Früher hat man irgendwas gekodet, hat geschaut, dass es einigermaßen fünftig ausschaut und dass es auf irgendeinem Server läuft und im Idealfall nicht abschmiert.
Und wenn irgendwas nicht läuft, dann steht man 18.3 auf und fixt das Ganze.
In der Mittlerweile hat man ...
POs, UX, QA, DevOps, eine ganze Schar von Leuten um sich rum und muss sich eigentlich gar nicht mehr um andere Sachen außer der Reihenentwicklung kümmern.
Mag ein Vorteil sein, ist für mich aber, glaube ich, ein Hindernis, um Seniorität schnell aufzubauen und vielleicht auch in Rollen mit mehr Impact reinzuwandern.
Man wird weniger da reingedrückt.
Nicht wenige sehen die aktuelle Entwicklung dahingehend, dass man weniger von diesen Spezialistenrollen brauchen wird, einfach weil du die immer mehr mit einem Cloud-Code oder was auch immer mit abdecken kannst.
Vielleicht nicht die Expertise in der ganzen Tiefe, vielleicht, vielleicht aber ist das auch etwas, was sich im Laufe der Zeit zeigen wird.
Wen braucht es denn am Ende des Tages, der einen Windsor, einen Cloud-Code oder einen Cursor bedient?
Ist das eher der Product-Mensch?
Ist das eher der CTO?
Ist es eher der Techie, der eine große Produktaffinität hat?
Ist es der Designer?
Das sind wieder ein Punkt, wo du vielleicht sagen würdest, naja, weiß ich alles noch nicht.
Ja, wissen wir alle noch nicht, aber klar, irgendwo, ich glaube, diese Branche wird sich gerade nochmal sehr stark verändern.
Also das, was du geschildert hast.
die Herausforderungen, die du gesehen hast in der Vergangenheit, wo Menschen nicht Verantwortung übernommen haben.
Ich glaube, da wird diese Komfortzone oder diese Pufferzone wird, glaube ich, gerade sehr stark weggenommen, immer mehr.
Gehst du damit?
Ja, ich finde es spannend, wer alles Cloud Code bedient, um jetzt mal bei dem Beispiel zu bleiben.
Ich kann es von uns ein bisschen erzählen.
Ich glaube, die Entwickler gehen sehr vorsichtig damit um, gerade bei uns in der Firma.
Die lassen sich helfen von Cloud Code, lassen sich oder Gemini, was auch immer, lassen sich helfen, lassen sich auch mal irgendwie neue Ideen geben.
Bei uns sind es eher die POs oder ich auch selber.
die einfach mal sagen, hey, wir haben hier irgendeinen Business-Need, wo jetzt die Entwickler jetzt nicht drauf lassen wollen, weil die haben Besseres zu tun.
Jetzt setzen wir uns einfach hin und coden mal.
Und wenn das hinterher funktioniert, sind wir happy, weil das geht gar nicht an den Kunden raus, sondern es sind vielleicht einfach nur interne Tools für uns.
Und dann lassen wir es von A bis Z mal durchlaufen.
Lernen dabei natürlich auch sehr viel, fallen oft auch mal auf die Nase.
Ja, aber die Frage, die du gerade sagst, wie dient es hinterher, wird spannend zu sehen, wer das dann zeigen wird.
Ich glaube, alle wichtig ist aber zu lernen, richtig damit umzugehen.
Ja, absolut.
Du bist jetzt ja selber auch in der CTO-Rolle.
Wie interpretierst du denn diese Rolle für dich?
Jeder CTO ist ein bisschen anders gelagert.
Der eine ist eher technischer, der andere ist eher Organisationsgestalter.
Der eine ist mehr Tech-Nerd, der andere hat mehr Business-Funktion.
Wo orientierst du dich daran?
Oder wie auf der Landkarte der CTO-Möglichkeiten, wo findet man dich dann?
Es gibt einen CTO von der Firma Mayflower hier in München, den Johann Peter Hartmann.
Der hat sich selber mal als Chief Tailwind Officer bezeichnet.
Das finde ich ziemlich cool, also das T für den Rückenwind, der Organisation Rückenwind zu geben, den Leuten.
Die Möglichkeit zu geben, sich zu entfalten, sich eigenständig vorwärts zu bewegen, aber trotzdem noch, das ist ein bisschen poetisch an, aber so die schützenden Hände außenrum zu halten und zu gucken, dass da keiner absäuft.
Die Leute ins kalte Wasser schmeißen, aber immer den Rettungsring nebendran.
Ich glaube, das ist schon das, was so meine Richtung ist.
Ein anderer Kollege hat es mal Hausmeister und Servicekraft genannt.
Es ist eher strategisch mit starkem Blick auf das Produkt selber, mit starkem Blick auf das Produkt auf den Kunden selber und natürlich die Organisation.
Gucken, wie kann ich eine Organisation schaffen, die, wie du es im Intro schon gesagt hast, im Idealfall nicht überflüssig macht.
Was sind denn dann so typische Aufgaben für...
den CTO von One Stop Pro.
Bist du sehr viel in Business Meetings?
Bist du mehr in der Zusammenarbeit mit den Engineers?
Was sind so typische Aufgaben für dich als CTO?
Eigentlich rede ich den ganzen Tag.
Ich wandere von einem Meeting ins nächste Meeting.
Das ist wahrscheinlich auch der Hauptjob da.
Ich versuche vor allen Dingen, Leute zu ermutigen.
Mit einem Freiraum zu geben.
Vielleicht auch Freiraum einfach mal zu schaffen.
Zu sagen, hey, wir nehmen dir jetzt mal ein paar Sachen weg, weil dich interessiert irgendein Thema ganz besonders.
Und dann gucken wir mal, wie wir vielleicht Sachen umverteilen können, dass du da diese Lücke reinstoßen kannst und für dich weiterlernen kannst, für dich wachsen kannst und auch die Organisation nach vorne bringen kannst.
Mit den Entwicklern habe ich natürlich immer wieder Austausch, aber keinen tiefen technischen.
Es gibt ab und zu mal ein paar technische Sachen.
wo ich dann mitspiele, aber nicht, um irgendwie was zu beeinflussen oder in irgendeine Richtung zu schieben, sondern weil ich halt Entwickler bin und manchmal da einfach Bock drauf habe.
Und sehe, hey, hier gibt es eine Chance, irgendwie was zu machen.
Und ich schmeiße dann tatsächlich einfach vielleicht mal Claude an und sage, okay, machen wir mal ein POC und schmeiße es dann in den Entwicklern rüber und sage, schau mal, was ich da gebaut habe, nimm es mir bitte auseinander.
Wenn du siehst, es macht Sinn, dann baust du doch einfach ein.
Du hast im Vorgespräch, glaube ich, auch gesagt, dass du früher zu viel selbst gemacht hast.
Ist da nicht die Gefahr, jetzt auch mit den AI-Augmented-Tools, dass man auch als CTO das wieder verstärkt macht?
Ja, tatsächlich ist es da.
Ich erwische mich auch manchmal, dass ich mich in sowas verliere.
Aber was ist denn früher da schiefgelaufen, an den Stellen, an denen du gemerkt hast, dass du zu viel selbst gemacht hast?
Was genau war das?
Wie hast du es gemerkt?
Und was für Maßnahmen hast du dann ergriffen?
Also der Hintergrund der Frage ist auch, nicht wenige CTOs kommen auch in den Gesprächen zu mir und wir stellen gemeinsam fest, sie arbeiten zu wenig strategisch, sie haben einen signifikanten Teil ihrer Arbeit, der operativ ist.
Das funktioniert eine Zeit lang sehr gut.
Bis es dann irgendwann nicht mehr funktioniert.
Da ist ja genau der Teil, man tut oft zu viel selbst.
Was war es bei dir damals und wann hast du gemerkt, das funktioniert so nicht?
Ich habe es gemerkt in der Station davor, weil ich zumindest am Anfang, als ich gekommen bin, im Team, obwohl ich eine Führungspersonation hatte, der stärkste Entwickler.
Und habe dann angefangen mit zu coden, habe dann angefangen Pull-Requests zu machen.
Weil ich einfach zu ungeduldig war.
Ich habe mich dann eingemisst und habe gemerkt, okay, Leute laufen irgendwie mit 100 Sachen Richtung Wand.
Und habe gedacht, okay, wenn ich es jetzt selber mache und selber umbiege, dann ist es besser.
Das ist aber der große Fehler.
Ich glaube, man muss auch Leute dann auch mal kontrolliert gegen die Wand laufen lassen.
Weil nur so lernen sie, nur so werden juniorige Leute besser und dann seniorig.
am Ende.
Das war, glaube ich, einer der allergrößten Fehler damals, den ich jetzt glücklicherweise mitigiert habe, indem ich einen Text-Stack gewählt habe, wo ich keine Ahnung dran habe.
Das heißt, da kann ich eigentlich gar nicht so viel machen.
Ich glaube, damals war ich einfach viel zu viel Entwickler selber noch.
Ich musste erst in die Rolle reinwachsen.
Ja, das war es wahrscheinlich.
Wirst du denn als CTO zum Bottleneck?
Hast du da ein Beispiel?
Ich hoffe, dass ich es nicht werde.
Aber vielleicht warst du es ja mal.
Ich war es, ja.
Ich war es und zwar in der Station, die ich vorhin beschrieben habe, indem ich den Kernteil der Applikation selber geschrieben hatte.
Weil ich eine Idee hatte und irgendwie mal von der Konferenz zurückkam und im Zug fünf Stunden Zeit hatte und das einfach mal runtergecodet habe und es echt ganz gut war.
Und dann habe ich das ins Team geschwissen und gesagt, so machen wir das jetzt.
Riesenfehler im Nachhinein, aber man muss Fehler machen, um daraus zu lernen.
Und da war ich dann Bottleneck, weil wenn irgendwas nicht funktioniert hat, naja, da war ich derjenige, den sie dann irgendwie versucht haben zu erreichen.
Was dann bei mir dazu geführt hat, dass mein Schreibtisch immer voller und voller und voller wurde.
Und dann am Ende wahrscheinlich dann auch die Qualität drunter ging.
Du hast jetzt eben gesagt, du habt jetzt einen Tech-Stack gewählt, von dem du keine Ahnung hast.
War das vielleicht sogar tatsächlich ein...
Entscheidungskriterium für dich, diesen Stack extra so zu wählen, dass du ihn nicht kennst?
Also wirklich eine ketzerische Frage, weil am Ende des Tages, wenn das ein Entscheidungskriterium wäre, weiß ich nicht, ob es das allerbeste gewesen wäre.
Dann ist es ja egal, ob du einen Tech-Stack nur wählst, weil du ihn gut kennst oder vielleicht sogar absichtlich, weil du ihn nicht gut kennst.
Ich bin mir nicht sicher, ob beides ein gutes Entscheidungskriterium für einen Tech-Stack ist.
Nee, nicht wirklich.
Im Nachhinein bin ich ganz happy, dass ich jetzt nicht so tief im Tech-Stack drin bin.
Ist ja oft so, wenn man eine Sprache kann, kannst du alle.
So ein bisschen.
Aber ich versuche auch gar nicht so unglaublich tief reinzugehen.
Dafür haben wir die Entwickler, die sind viel besser in dem.
Was soll ich da rumfummeln?
Bringt nichts, bringt nur alle Leute durcheinander.
Ne, also eine bewusste Entscheidung nicht.
Aber ich bin auch nicht unglücklich jetzt drüber.
Okay, also war es eine Entscheidung aus anderen Gründen?
die erstmal nichts mit dir zu tun hatten, sondern andere Beweggründe hatten.
Wie erkennst du denn heute, dass du wieder anfängst, oder ob und wenn du wieder anfängst, zu viel an dich zu ziehen?
Ich kriege es gesagt von meinen Leuten.
Das ist das Tolle.
Wir haben einfach eine Organisation bei uns, dass ich dann einfach eins auf die Finger kriege von den POs zum Beispiel.
Wenn ich mich irgendwo einmische.
Gerade irgendwie in den letzten Monaten war ich im DevOps-Bereich so ein bisschen unterwegs, weil ich gesehen habe, hier könnte man noch was verbessern, hier könnte man was machen.
Ich mache die Fehler auch immer noch wieder, klar, aber ich merke es relativ schnell, weil die Leute sagen, du machst deinen Job, ich mache meinen Job, alles gut.
Ja, also ich glaube, das ist viel die Organisation, die sich dann selbst reguliert auch.
Sehr gut.
Ja, genau, vielleicht mal Stichwort.
selbsttragende Organisation.
Das ist ja auch ein Zustand, den viele wollen, von dem viele eine romantische Vorstellung haben, die sehr weit an der Realität vorbeigeht, die aber trotzdem auf dem Papier eine Menge Sinn macht.
Du hast auch gesagt, du bist heute an einem Punkt, wo es kaum einen Unterschied macht, ob du da bist oder nicht oder nicht.
Viele würden das als ein Risiko sehen.
Zum Beispiel jetzt die Tage auf LinkedIn was gepostet zu dem Thema selbstorganisierte Teams.
Da hat er dann irgendwann auch ein CEO geschrieben, naja, dann frage ich mich, warum ich den CTO dann noch brauche.
Trotz allem, warum ist das für dich ein Erfolg, wenn du jetzt an dem Punkt bist, wo du wirklich feststellst, wenn du dich rausziehst, funktioniert das System trotzdem ohne dich?
Kurz zu dem Post, den habe ich heute gelesen, habe mir gedacht, ja, das passt ja eigentlich ganz gut zum Thema.
Ich glaube, so wie du es auch geschrieben hast, das ist ein Trugschluss.
Diese selbstregulierende Organisation oder selbsttragenden Teams, selbstverwalteten Teams, das ist alles schön und gut, aber das muss trotzdem jemand machen.
Und wenn es niemanden gibt, der irgendwie zumindest so ein bisschen den Hut auf hat, dann geht es meiner Meinung nach in die falsche Richtung dann irgendwann.
Da gibt es dann Grabenkämpfe, da will der eine links rum, der andere rechts rum.
Und da muss irgendjemand zumindest helfen, die richtige Entscheidung zu finden.
Zu deiner Frage, warum das für mich ein Erfolg ist.
Der Busfaktor ist nicht da.
Relativ einfach.
Also wenn irgendwie was passiert, ich weiß, dass es weitergeht.
Vielleicht gehen manche Sachen ein bisschen langsamer.
Vielleicht gehen manche Sachen dann in Richtungen, die ich nicht so gern gehabt hätte.
die aber hoffentlich auch nicht dann irgendwie schädlich für die Organisation sind.
Weil, glaube ich, schon für mich das Wichtigste ist, dass das Kernteam an Leuten, die in der Produktentwicklung arbeiten, in eine Richtung geht.
Stellst du das aktiv sicher, dass du dann nicht von den Entscheidungen überrascht wirst und dir dann denkst, naja, also vielleicht mag das im Einzelfall dann eine Entscheidung sein, wo du sagst, die hättest du jetzt anders getroffen, ist jetzt aber okay so.
Wenn du allerdings grundsätzlich merkst, die entscheiden Dinge anders, als ich das für gut finde, dann bewegt sich ja auch langsam die Organisation in eine Richtung, die vielleicht nicht dem entspricht, was du strategisch irgendwie auch vorhast.
Wie sicherst du das denn ab, dass hier die richtigen Entscheidungen auch getroffen werden?
Oder Entscheidungen getroffen werden, die in einem bestimmten Rahmen an Möglichkeiten stattfinden, sodass zumindest mal die Richtung grob stimmt?
Ich glaube, das Wichtigste ist, dass man sich gut abspricht.
Dass man wirklich...
gerade vielleicht am Anfang des Jahres, am Anfang des Quartals, wann auch immer, sich zusammensetzt und sagt, okay, was wollen wir denn eigentlich?
Wo wollen wir hin?
Gerade das Thema Ziele, OKR, OIT, wie auch immer, ist da, glaube ich, sehr wichtig, dass man die zusammen erarbeitet.
Die werden jetzt nicht großartig vorgegeben, sondern wir schauen, okay, was macht am meisten Sinn für die Firma?
Dafür braucht man aber auch diese Leute, die gerade diesen unternehmerischen Gedanken in sich tragen und genauso leben und die Organisation so vorwärts bringen möchten.
Und dann klappt es einfach.
Also ich weiß nicht warum, aber es funktioniert ganz gut.
Und ich habe da auch...
Es ist ja manchmal nicht die Frage, warum das so klappt.
Also hast du, vielleicht kannst du sagen, ich habe einfach saugut eingestellt.
Du kannst ja auch sagen, nee, ich habe, musst du die Leute, die schon so ein bisschen in die Richtung buxieren, dass sie das machen?
Oder funktioniert das auf magische Art und Weise erstmal so?
Keiner kann wirklich sagen, warum.
Es hängt sehr, sehr, sehr viel an den Leuten.
Also man muss die richtigen Leute dafür haben.
Man muss die Leute haben, die den Background haben.
Gerade wenn ich schaue, unsere POs bei uns in der Firma, das sind drei Stück.
Einer von denen ist seit Anfang an dabei und ist nebenzu auch noch freiberuflich tätig gewesen.
Der andere hat mehrere Firmen gegründet, hinterher wieder einen Exit gemacht und der dritte war früher bei einer Unternehmensberatung.
Das sind alles Leute, die so denken mussten in ihren früheren Jobs.
Und wenn man sich solche Leute dann ins Team holt, dann ist die Wahrscheinlichkeit schon mal deutlich höher, dass sie die Richtung verstehen und dass sie dann auch in eine eingeschlange Richtung mitgehen.
Das heißt, du hast Leute eingestellt, die einen gewissen unternehmerischen Background hatten oder eine unternehmerisch geprägte DNA.
Und das hat diese Kombination aus Fachskill und dieser DNA hat dafür gesorgt, dass sie von vornherein schon so aufgestellt waren, dass es in dem Kontext funktioniert.
Gibt es noch andere Bausteine, um eine Organisation so aufzubauen, die du festgestellt hast?
Was ganz spannend ist, ist Entwickler, also wenn ich es mal über Entwickler rede, Entwickler mit dem Kunden zu konfrontieren.
was ich vorhin beschrieben habe, der Entwickler arbeitet in seinem kleinen Silo, kriegt ein Ticket, arbeitet es ab, dann versteht er aber eigentlich nicht wirklich, warum machen wir diese ganzen Sachen.
Warum machen wir irgendwelche Features, warum gehen wir in irgendeine Richtung mit der Organisation.
Wenn man jetzt aber die Entwickler mal zu den Kunden schickt, sodass die wirklich sehen, wie arbeiten die mit dem Produkt, vielleicht auch mal zu einem schwierigen Kunden schickt, der dann sagt, was habt ihr denn hier für Müll gemacht?
dann hat das einen anderen Impact auf die Leute.
Und dann fangen die an nachzudenken und fangen an miteinander zu reden und fangen an mit mir zu reden, mit den POs zu reden und man kommt automatisch in so ein Fahrwasser rein, dass jeder versuchen will, das beste Produkt zu machen.
Das heißt, hier ist relativ einfach und selbstverständlich an, aber es ist nicht selbstverständlich.
Es gibt viele Entwickler, die sagen, bleiben wir mit dem Kunden weg, ich will einfach nur coden.
Und in so einer Organisation, wie wir da versuchen aufzubauen, ist es schwer.
Man sieht auch, dass viele Entwickler auch diese Transition machen zu Entwicklern, die unternehmerisch denken.
Das finde ich unglaublich cool, weil ich merke, dass dadurch die Organisation stärker wird.
und auch das Fundament besser wird und wir dann, um auf deine vorherige Frage wieder darauf einzugehen, Leute ersetzbar sind.
Oder wenn Leute weg sind, es gar nicht so schlimm ist.
Es ist schön, wenn sie da sind, aber es geht trotzdem weiter.
Ich sehe auch zwei Dinge, die da parallel stattfinden.
Auf der einen Seite eine grundsätzliche Verschiebung, die Entwickler, heute sagen sie möchten eigentlich gerne coden, die werden sich tendenziell auch eher am Coden festhalten und das ist jetzt in der aktuellen Situation eine gefährliche Gemengelage.
Wenn du dich allein über das Coding identifizierst, hast du gerade sehr starke Konkurrenz bekommen, die du wahrscheinlich auf Dauer nicht schlagen wirst können, egal wie viel Kontext du hast.
Das heißt, auf der einen Seite werden Entwickler sowieso in die Richtung getrieben, dass sie sich mehr vom eigentlichen Coding wegbewegen müssen.
Auf der anderen Seite holst du dir Leute ins Unternehmen, die von dieser Erwartungshaltung der Selbstorganisation oder selber auch mehr über den Tellerrand hinaus zu schauen, über ihre eigene Idee, dass sie vorher vielleicht noch Angst haben davor.
Wie entwickelst du denn Vertrauen bei diesen Leuten, die vorher eher so geprägt waren?
Ist das was, was du aktiv mitgestaltest?
Oder hast du dann doch am Ende des Tages, versuchst du das ausschließlich oder überwiegend übers Hiring zu lösen?
Nee, man kann ja nicht alle rausschmeißen und irgendwie 50 neue Leute einstellen.
Das geht ja nicht.
Ist ja nicht so, als hätten nicht Unternehmen das schon gemacht, aber gut.
Ja, okay, das stimmt.
Ich glaube, das Wichtigste ist, klare Ziele zu geben und sehr viel Transparenz zu geben.
Zu erklären, warum machen wir Sachen und warum brauche ich genau dich dafür, um irgendwelche Ziele zu erreichen.
Also die Leute mitnehmen, die Leute von Anfang an in Entscheidungen einzubinden.
Ich kann dir vielleicht ein Beispiel geben.
Wir haben vor knapp zwei Jahren angefangen, unsere Fronten komplett neu zu schreiben.
Und die Entwickler haben entschieden, wie die Technologie ist.
Die Entwickler haben entschieden, welches Framework sie verwenden wollen.
Und das ist richtig so.
Das machen wahrscheinlich nicht alle, aber...
Wenn alle Beteiligten von Anfang an involviert sind und ihre Meinung abgeben können, dann wachsen sie daran, dann sehen sie es als ihr eigenes an, haben auch viel mehr Zugang zu den ganzen Themen.
Ich glaube, das ist das eine.
Das andere ist so ein bisschen die Berechenbarkeit.
Also einfach den Leuten das Gefühl zu geben, wenn jetzt irgendwas passiert, wird der Typ vorne dran immer gleich reagieren.
ungefähr gleich reagieren.
Er dreht nicht am einen Tag durch und am anderen sagt, ja, ist mir doch egal.
Sondern sie wissen, was passiert.
Und man muss bei manchen Sachen einfach sehr, sehr sensibel sein.
Wenn jemand Fehler macht, sensibel damit umgehen.
Nicht sagen, ey, du hast einen Fehler gemacht, was ist denn das für ein Scheiß?
Macht das ja nicht nochmal.
Unglaublich viel kaputt.
Und dieses Risiko, dass Leute eingehen, wo dann vielleicht am Ende ein Fehler rauskommt, das werden die dann nicht mehr eingehen.
Ja, warum auch?
Und ich glaube, das ist das Wichtige, um dieses Vertrauen bei den Leuten zu kriegen, einfach zu sagen, hey, wenn irgendwas kaputt geht, okay, dann ist es kaputt.
Lass uns gucken, dass wir es hinterher wieder fixen.
Lass uns einen guten Postmortem hinterher machen und schauen wir, dass wir den Fehler hinterher nicht mehr machen.
Ist das ein Punkt, an dem viele CTOs dann scheitern, deiner Erfahrung nach, wenn sie versuchen, solche Strukturen aufzubauen, dass sie genau diesen Aspekt auch der Kultur, auch der Fehlerkultur, die du gerade angesprochen hast, dass sie den gar nicht so sehr unterschätzen oder vielleicht dem zu wenig Raum geben?
Oder siehst du auch noch andere Aspekte, an denen CTOs Fehler machen?
Jetzt genau, wenn es um solche Strukturen geht, um solche selbstorganisierten Teams oder Bereiche der Organisation, die sich auch selber tragen.
Ich glaube, das ist eher ein Problem der Gesamtorganisation.
Das, was wir da machen, und das sind wir ja nicht exklusiv, das machen ja andere auch, Das geht meiner Meinung nach nur in einem bestimmten Umfeld.
Also in einem Großkonzern kann ich wahrscheinlich nicht so arbeiten.
Da ist es sehr, sehr, sehr hierarchisch.
Ich weiß nicht, ob CTOs daran scheitern.
Ich glaube, dass Organisationen daran scheitern.
Vor allen Dingen an den Hierarchien scheitern.
Ich habe es bei dem letzten Exit gesehen, wo wir von einer sehr, sehr, sehr agilen Firma, nicht agil im Sinne von Agile, sondern schnell und wendig.
zu einer sehr hierarchischen Firma wurden, wo genau diese Fehlerkultur nicht mehr so gelebt wurde.
Hat dann auch dazu geführt, dass sehr viele Leute relativ schnell gegangen sind und gesagt haben, das wollen wir uns nicht antun, weil sie es einfach anders gewohnt waren.
Um auf deine Frage zu antworten, das ist wahrscheinlich kein CTO-Thema, sondern ein Organisationsthema.
Klar, aber wenn der CTO natürlich für diesen Teil der Organisation maßgeblich verantwortlich ist, ist es dann vielleicht doch am Ende des Tages wieder CTO-Thema.
Aber du hast auch ein Thema mit angesprochen im Vorgespräch.
Das fand ich besonders interessant.
Das möchte ich hier nochmal hervorheben.
Und zwar, ich glaube, das haben wir hier im Podcast noch gar nicht besprochen.
Und ich habe es aber selber schon erlebt und ich finde es mega spannend.
Und ich glaube, da sollten wir reingehen.
Und das Thema ist Purpose Vacuum.
Und gerade am Ende von großen Projekten oder nach großen Projekten, nach einem großen Launch, nach einem Relaunch, was auch immer, einem Go-Live, ist immer so ein Peak erreicht an Anspannung, vielleicht auch dann an Erleichterung irgendwann.
Und da besteht die Gefahr, dass Teams anschließend in ein Loch fallen.
Vielleicht sogar als nur Einzelpersonen, vielleicht aber auch ganze Teams, ganze Organisationsteile.
Wie gehst du damit um?
Wie verhinderst du das?
Und woran erkennst du überhaupt, dass es ein solches Purpose-Vacuum konkret im Team überhaupt gibt?
Ich glaube, man muss ein bisschen unterscheiden zwischen den verschiedenen Rollen, die Leute einnehmen.
Also einmal die Führungspersonen, wo jetzt CTOs, Teamleiter, aber auch POs, fachliche Führung mit reinnehmen.
Und auf der anderen Seite die Leute, die eher...
die eher operativ tätig sind oder operativer, also die dann den Code schreiben, die die Infrastruktur machen und so weiter.
Ich glaube, bei der ersten Gruppe ist die Gefahr viel, viel, viel höher, weil die machen in so einem Projekt relativ viel im Tunnel.
Die schauen, okay, lassen Sie dieses Projekt durchbringen, daraus ist ein Jahre, zwei Jahre.
Wir hatten so ein Projekt, das zwei Jahre gedauert hat und da sieht man dann schon, okay, Es wird eigentlich über nichts anderes mehr geredet.
Das ist relativ gefährlich da.
Aber eigentlich willst du das doch als CTO.
Du bist ja froh, wenn sie alle auf ein Ziel eingesporen sind und Fullsteam ahead genau darauf hinarbeiten.
Solange bis das Projekt dann weg ist oder das Ziel dann erreicht ist.
Und dann kommt dann einfach das Problem.
Da kommt dann das, was du gerade gesagt hast.
Diese Lehre, hey, jetzt sind wir da fertig.
Okay, was machen wir denn jetzt?
Jetzt ist dieser Druck nicht mehr da, es fällt der Druck ab.
fällt man natürlich erstmal in ein Loch.
Das ist auch gut, das ist auch okay.
Ich glaube, das muss auch so sein.
Gut ist, dass man da schnell wieder rauskommt.
Ich glaube, was meiner Erfahrung ganz gut hilft, ist, sich dann mal hinzuhocken und irgendwelche kleinen oder größeren Side-Projects anzufangen, die einfach vielleicht gar nichts direkt mit dem Produkt zu tun hatten.
Bei uns war es jetzt zum Beispiel diese ganze Evaluation, gerade von Claude Goat, von anderen KI-Tourists, mal zu sagen, okay, jetzt lass uns mal für einen Moment rausgehen und lass uns schauen, dass wir wieder unseren Fokus woanders hinkriegen, unsere Aufmerksamkeit woanders hinkriegen, sodass der Kopf wieder voll wird mit irgendwelchen anderen Sachen.
Wie lange gibst du da Zeit für diese Phasen?
Das dauert noch an.
Ich habe keine Ahnung, wie lange es dauern wird.
Aber ist das nicht am Ende des Tages dann, also ich verstehe den Effekt, ich habe den selbst schon erlebt, wenn du unter großer Anspannung stehst für ein bestimmtes Projekt, egal ob das jetzt im Engineering-Bereich, im Management-Bereich, was auch immer, und danach ist erstmal diese Anspannung weg und eigentlich willst du vielleicht weitermachen, du hast ja Bock irgendwie nochmal auf das nächste Ding und das ist vielleicht aber gerade nicht da, so habe ich das eher wahrgenommen, wo du sagst, eigentlich möchte ich ja gerne, ich möchte dieses High, nochmal erleben, was du dann hast, wenn du unter Anspannung dieses Projekt machst und dann es schaffst, über die Ziellinie zu bringen.
Und auf einmal findest du das irgendwie nicht.
Es geht ja dann weniger darum, eine Ablenkung zu finden oder ja, dann spiele ich jetzt mal auf der Toolwiese rum, sondern eigentlich geht es eher darum, was ist die nächste große Herausforderung.
Und das würde ich dann eher als ein Leadership-Thema ansehen oder eine Aufgabe der Organisation, hier andere Inhalte mit reinzugeben, die stark genug sind, um das Team wieder auf Speed zu bringen.
Also ich verstehe deinen Punkt zu sagen, ich gebe mal hier, ich gebe denen Zeit, auf der grünen Wiese auch Dinge auszuprobieren.
Okay, fair enough.
Aber ich würde dem wahrscheinlich eher vielleicht irgendwie ein, zwei Wochen dann Raum geben und nicht jetzt einen längeren Zeitraum.
Oder habe ich dich da irgendwo missverstanden?
Ja, ja, schon.
Also was wir natürlich gemacht haben, ist, wir haben das Projekt so ein bisschen ausfaden lassen.
Es war über einen großen Zeitraum wirklich alle Leute volle Pulle auf dem Projekt drauf und sind dann irgendwann dazu übergegangen, uns zusammenzusetzen und zu sagen, okay, was sind denn die nächsten Dinge?
Und jetzt bringen wir die nächsten Dinge langsam rein, sodass wir so einen fließenden Übergang dann auch haben.
Dass die Lehre dann gar nicht so richtig kommen kann, gerade bei den...
Gerade bei den Entwicklern muss man natürlich gut aufpassen, dass es dann nicht zu viel wird, dass es dann 200% Arbeit sind oder auch 150% Arbeit.
Das hilft dann schon auch.
Aber bei der Art und Weise ist Ablenkung einfach gut.
Erlebst du diese Gefahr eher bei High-Performance-Teams oder ist das eine Gefahr der Überlastung, die du dann steuern musst?
Nee, also ich glaube, dass es zumindest in unserem Fall jetzt nicht mit High-Performance oder so zu tun hat.
Ich glaube, es ist eher eine kognitive Überlastung, dass man einfach sagt, ich habe hier dieses Thema, bin dann volle Pulle drin und gehe dann von 100 auf 0 runter.
Ich glaube, dass das das Problem ist, weil dann von 0 wieder hochzukommen ist schwieriger, als wenn es runtergeht und dann von der anderen Seite irgendwie was wieder dazukommt.
Ja genau, vielleicht willst du am Anfang, du willst ja eigentlich von den 120% oder 130% Auslastung, auf der sie dann sind, was eine eindeutig Überlastsituation ist, sollen sie natürlich runter.
Dann lässt du mal zu, dass sie eine Zeit lang auf 80% fahren, Energie wieder auftanken können und danach wieder auf 100% irgendwie gehen können.
Du willst nicht, dass sie zu stark zurückfallen, in so einen Leerlauf reinkommen, weil dann wird es schwer, sich wieder in den eigentlichen Arbeitsmodus zu kommen.
Oder?
So kann man das schon sagen.
Ja, also es gibt immer genug zu tun.
Also es ist nicht so, dass wir jetzt sagen, okay, wir holen uns jetzt hin und drehen einfach mal drei Monate die Däumchen, sondern wir machen einfach Sachen, wo wir sagen, hey, das bringt das Produkt vorwärts, das macht uns Spaß und es hilft uns beim Entwickeln so ein bisschen die Akkus auch wieder aufzuladen.
Ja, ich würde da schon, ich glaube, während wir darüber sprechen, Greift das auch nochmal bei mir im Kopf.
Ich würde da zwei Sachen unterscheiden wahrscheinlich.
Das eine ist der Purpose Vacuum und das andere ist eine klassische Überlastsituation.
Die zwei Dinge sind ja nicht gleichbedeutend.
Das eine ist eigentlich eher, ich bin High-Performer oder ich habe ein High-Performance-Team, ich habe jetzt irgendwo ein starkes Projekt zu Ende gebracht, ich will mehr.
Ich will mehr von diesen Projekten, ich will mehr von dieser Anspannung, ich will mehr von diesen von diesem Purpose spüren, den mir dieses Projekt oder diese Art von Arbeit gebracht hat.
Das andere ist, ich habe ein Projekt zu Ende gebracht, es war super anstrengend, wir sind irgendwie mit 150 Prozent gefahren und jetzt muss ich erstmal diese Überlast kompensieren.
Vielleicht am Ende des Tages resultiert das in ähnlichen Ergebnissen, aber es sind zwei unterschiedliche Symptome, die du dann angehen musst.
Punkt, Fragezeichen, Ausrufezeichen.
Wie gehst du denn mit Leuten um, die eigentlich immer mehr wollen?
Hast du so Leute im Team?
Hast du so Teams, die so strukturiert sind?
Ich glaube, jeder hat solche im Team.
Weiß ich nicht.
Ich glaube, das Wichtigste ist, den Leuten dann einfach Sachen wegzunehmen.
Hört sich dann blöd an und man muss das den Leuten auch irgendwie erstmal erklären.
Aber ich glaube, nur so kommen sie dann auf ein vernünftiges Level.
Ich glaube, wenn man erklärt, was passiert, wenn sie so weitermachen auf diesem Level oder vielleicht sogar immer noch mehr machen, dann verstehen sie es dann auch.
Also das Übliche, Überlastung.
Dann geht es wahrscheinlich manchmal auch noch in Burnout rein.
Irgendwann folgt vielleicht die Kündigung, der Zynismus kommt, irgendwie sowas.
Was man vielleicht auch gar nicht so sieht, ist der Qualitätsverlust.
Also wenn man irgendwie 20 Sachen parallel macht, dann ist die Wahrscheinlichkeit relativ gering, dass 20 mal richtig was Gutes rauskommt.
Und dann mache ich doch lieber 5 Sachen oder 3 Sachen, wo ich dann sage, okay, das bringt hinterher was und es müssen nicht noch 3 Leute drüber schauen.
Das ist wahrscheinlich dann auch viel befriedigender für die Leute.
Sicher, aber wie entscheidest du, wann du Arbeit wegnehmen musst?
Ich glaube, man sieht es, wenn die Qualität runtergeht.
Also wenn man sieht, also A sieht man es, derjenige ist ständig online, schreibt in der Nacht noch irgendwelche Mails, irgendwie Teams und Slack läuft irgendwie amok.
Ich glaube, das sind die klassischen Sachen.
Aber wenn man sieht, es kommen viele Fehler raus, man sieht, wenn jemand in Diskussionen mit drin sitzt, das ist einfach der Output, der dann kommt.
nicht gut ist, teilweise Quatsch ist oder derjenige sich dann vielleicht auch zurückzieht, obwohl er sonst jemand ist, der sonst immer was sagt.
Ich glaube, das sind alles so kleine Warnzeichen.
Das eine große Warnzeichen gibt es, glaube ich, gar nicht.
Da ist es wahrscheinlich auch wichtig, da sensibel drauf zu gucken und so ein bisschen Gespür für die Leute zu entwickeln.
Ja, das ist dann auch Teil deiner Interpretation der CTO-Rolle, hier die notwendigen Antennen zu haben und die auch auf das Team auszurichten, um hier die Signale wahrnehmen zu können und dann auch agieren zu können.
Also auch die notwendige Empathie zu haben, das notwendige.
Ja, aber auch das Team muss natürlich, also du musst ja auch die Visibilität haben, du musst ja auch eine Observability sichergestellt haben, um überhaupt für dieses Team.
in solchen Situationen entscheiden zu können.
Und auch mal sagen zu denen, nein, das machst du jetzt nicht, du hast schon genug um die Ohren.
Das spricht für dich und deine Herangehensweise.
Ihr selber sagt ja oft auch Nein zu Projekten.
Wie triffst du diese Entscheidung konkret?
Oder was unterscheidet ein gutes Nein von einem schlechten Nein?
Also ich glaube, ein schlechtes Nein ist ein politisch motiviertes Nein.
Also einfach nur Nein zu sagen, weil irgendjemand anders es nicht möchte.
Ich glaube, ein gutes Nein ist, wenn ich sowas Nein sage, weil ich ein besseres Ja habe.
Klasse ist irgendein Feature, irgendein Kunde kommt daher und sagt, hey, dieses Feature wäre toll, super, kann ich gerne brauchen.
Und dann schaue ich mir aber erst mal an, wer braucht es denn sonst noch?
Und wenn ich irgendein Feature bauen kann, wo ich dann zwei Kunden oder fünf oder zehn oder hundert Kunden habe, dann mache ich lieber das.
Muss ich halt Nein zu einem anderen sagen.
Aber diese Nines...
nur um es anderen Leuten recht zu machen.
Ich glaube, die sind ein schlechtes Nein.
Sehr gut.
Tobias, wir sind fast am Ende der heutigen Zeit.
Wir sind, wie es auch so üblich ist hier im Podcast, wir haben viel zu viele Themen auf der Agenda, sind nicht dazu gekommen, alle abzuschließen.
Ich habe noch eine abschließende Frage, bevor wir zu den Rapid-Fire-Fragen kommen.
Die finde ich aber gar nicht so untrivial.
Wenn du nämlich heute nochmal von vorne starten würdest, so in deiner Karriere.
Was würdest du schneller machen?
Für mich relativ einfach zu beantworten, sofort aus der Entwicklung raus.
Du würdest gar nicht mehr reingehen?
Du würdest trotzdem Informatik studieren?
Ja, natürlich.
Das ist meine Leidenschaft.
Das kann ich sonst kaum was.
Ein Waschbecken anzuschrauben.
Sobald er in eine Führungsposition reinkommt, sagen wir es so, dann muss man aus der Entwicklung raus.
Ich hatte einen Mitarbeiter mal, der gesagt hat, ich würde gerne eine Teamleiterrolle übernehmen.
Dann habe ich gesagt, ja, überleg dir es.
Das heißt aber, du codest nicht mehr.
Dann war das Thema relativ schnell vom Tisch, weil er dann doch zu sehr Coder war.
Aber ich glaube, das ist das, was ich auf jeden Fall machen würde.
Wo ich dann auch, glaube ich, jemand bräuchte oder gebraucht hätte damals, der gesagt hat, Kollege, nicht mehr coden bitte.
Das erkennt man natürlich selber nicht so gut.
Vor allen Dingen, wenn du der beste Entwickler bist, wie du es dann teilweise warst.
In dem Fall ja.
Das ist dann wirklich schwer.
Aber wenn man das macht, man schadet den Leuten.
Man schadet der Organisation, schadet den Junioren.
Ist nicht gut.
Dann macht man lieber irgendwelche Pet-Projects, baut sich daheim ein Homelab und baut da ein bisschen rum, um sein Entwicklertum zu befriedigen.
Aber lass die Entwickler entwickeln.
Dann lass uns mal noch zu der Tradition der Rapid-Fire-Fragen kommen.
Sehr gerne.
Build versus Buy.
Wie entscheidest du dich?
Buy.
Ich bin tatsächlich immer mehr beim Build anyways, aber sag mal deine Begründung.
Es gibt so viele schlaue Leute da draußen.
Die Wahrscheinlichkeit, dass jemand genau das, was du haben möchtest, schon mal gebaut hat, in einer besseren Qualität, als du es in einer einigermaßen annehmbaren Zeit hinbekommst, ist relativ hoch.
Das stimmt.
Deswegen bei.
Tech-Debt abbauen oder neues Feature shippen?
Dieses Denglish, das ich verwende, ist auch sensationell.
Tech-Debt abbauen, neues Feature, ist aber auch egal.
Dafür leben wir in der Tech-Bubble, das muss so sein.
Das ist eine fiese Frage.
Wenn ich jetzt Feature shippen sage, kriege ich eins von meinen Entwicklern auf den Deckel.
Wenn ich Tech-Debt abbauen sage, kriege ich eins von den POs auf den Deckel.
Ich glaube, Features shippen mit so wenig Tech-Debt wie möglich.
Ah, schöne Antwort.
Was hat ein Kollege mal gesagt?
Lass uns nicht Brände löschen, lass uns Häuser bauen, die nicht brennen.
Auch gut.
Remote oder Office?
Office ohne Zwang.
Also ich halte nicht viel von dem, wir müssen jetzt alle wieder ins Büro.
Und zwar vier Tage die Woche und freitags dürft ihr daheim bleiben.
Ich bin aber ein Freund von lass uns im Büro treffen, wenn es Sinn macht, sich im Büro zu treffen und lass uns von daheim aus arbeiten, wenn es Sinn macht, von daheim aus zu arbeiten.
Sehr gut.
Aber ich selber bin eher, obwohl ich 90% im Homeoffice arbeite, bin ich eher ein Büromensch.
Tatsächlich.
An, letzte Frage für heute.
CTO.
Leader oder Operator?
Leader.
Operator, da wird man relativ schnell wieder zum Entwickler, glaube ich.
Ja, das kann gut sein.
Obwohl, ich habe auch schon andere Beispiele gesehen, die auch gut funktioniert haben.
Aber trotzdem, ich wäre wahrscheinlich auch eher bei deiner Antwort.
Sehr schön.
Tobias, vielen lieben Dank.
Es hat mir großen Spaß gemacht und wie immer ist die Zeit davon gerannt.
Wir hätten noch länger sprechen können.
Die Aufnahmezeit erlaubt es uns nicht.
Es muss halt einfach nochmal herkommen.
Sehr schön.
Mach's gut, Tobias.
Ciao, ciao.
Ich danke dir.
Tschüss.