Wir sprechen heute über Robin Manuels neue Rolle als Director
AI and Cloud. Aber was steckt da eigentlich
dahinter, also jenseits von dem Titel?
Wie sieht sein Alltag in der neuen Rolle aus, wie wird Erfolg
in der Rolle definiert und wieviel Zeit bleibt ihm
eigentlich noch fürs Coden? All das erfahren wir in dieser
Podcast Folge. Hallo und herzlich Willkommen zu
einer neuen Folge vom to do Cast, dem deutschen Developer
Podcast. Mit Malte Lantin Malte Lantin
ist Strategic Solutions Engineer bei Github und mit mir Robin
Manuel Thiel. Ihr habt es im Intro schon
gehört, ich bin Director AI und Cloud beim E Commerce
Unternehmen Jtl. Was genau das bedeutet, darum
geht es ja diese Folge diesen Podcast hier machen wir aber
privat und teilen hier unsere Erfahrungen aus echten
Kundenprojekten in unserem Alltag und diskutieren hier
Themen, die die Developer Welt. Bewegen.
Aber bevor wir in das Thema, also dein Job, einsteigen,
müssen wir natürlich noch danke sagen.
Und diesmal geht ein herzliches Danke an Steffi für einen
Kaffee, den du uns ausgegeben hast.
Herzlichen Dank dafür. Danke.
Und damit steigen wir direkt ins Thema ein und stellen uns
gemeinsam die Frage, die ihr wahrscheinlich alle hattet.
Als Roman Manuel seinen Job gewechselt hat, bist du jetzt
eigentlich noch ein Nerd? Ja, ich, ich hoffe doch schon.
Ich hoffe, das definiert sich auch nicht nur über den Job.
Ich bleibe auf jeden Fall der Nerd Welt erhalten und ich
glaube, ich bin auf jeden Fall privat in meiner Freizeit noch
ein ganz ganz doller Nerd und muss das jetzt natürlich im
Alltag so ein bisschen balancieren zwischen auch hin
und wieder mal ein bisschen weniger technischen Aufgaben,
aber nichtsdestotrotz bleibe ich natürlich auch gerade in der
Developer Welt und. Und der techy Welt auf jeden
Fall erhalten. Ja, dein Titel ist ja jetzt
Director AI und Cloud. Ich hoffe den konntest du dir
selber mit aussuchen, aber uns interessiert natürlich was sich
dahinter verbirgt. Also was macht man denn
eigentlich als Director I und Cloud?
Ja, also ich konnte mir so richtig aussuchen.
Natürlich nicht, aber. Weil bei der Firma, bei der ich
arbeite, JTS Software, die baut Halt e Commerce Software und da
gibt es eben einfach die Rolle eines Directors.
Ich bin nicht der einzige Director da, sondern ich bin
eben für den Bereich von KI und Cloud verantwortlich.
Und bedeutet vor allem in erster Linie, Ich bin verantwortlich
dafür, die Cloud Transformation und die KI Transformation von
der Jtl Gruppe. Das sind mehrere Firmen die
darunter stecken, das ist teilweise Akquisitionen,
teilweise Kooperation und so weiter von all diesen
Gruppenunternehmen darf ich eben die Cloud Transformation nicht
nur verantworten, sondern auch gestalten, das ist auch das was
mich daran reizt, wer die Folge gehört hat über meinen
Jobwechsel, ich war ja vorher 10 Jahre lang bei Microsoft und.
Habe das auch sehr sehr sehr genossen immer.
Bei Microsoft kannst du aber nicht so viel gestalten, da
kannst du höchstens mal irgendwie durch einen Hi Ring
von einer Schlüsselperson noch irgendwie was gestalten, aber
Struktur die wird häufig aus den USA hervorgegeben und das ändert
sich jetzt. Ich kann jetzt eben
Entscheidungen treffen, Strukturen schaffen, Risiken
eingehen, Teams aufbauen und das heißt vor allem das, was mich
jetzt ein bisschen gereizt hat, mal einfach auf eine andere
Seite. Oder auch von einer anderen
Seite, eigentlich auf unsere Industrie zu blicken.
Und du hattest gerade gesagt, gerade dieses selber gestalten
findest du spannend. Aber da gibt es dann auch
technische Themen, wo du gesagt hast, das hatte ich vorher nicht
so, da möchte ich gern hands on tiefer einsteigen.
Ich glaube, du hast ja vorher schon ganz viel mit AI und Cloud
gemacht, dementsprechend hört sich das jetzt eigentlich nicht
so neu an. Ja, es ist eher so ein bisschen,
dass ich halt mich jetzt nicht wirklich festlegen muss auf ein
technisches Thema, sondern dafür, dass ich jetzt so ein
bisschen die Flughöhe nach oben hin gewechselt habe, kann ich
mich eben mit viel, viel mehr Themen auseinandersetzen, als
das vorher ging. Ich kann ja ein bisschen
ausholen und also das, was wir da jetzt machen, was ich
eigentlich tue, ist, ich baue gerade so 45 Teams auf, denn die
Cloud Transformation und Cloud und KI Transformation, die wir
bauen, die. Sieht am Ende eigentlich so aus,
dass wir Plattformen schaffen, die dann die Gruppen unternehmen
und die ganzen Software Teams. Wir haben eine ganz ganz viel
großes Portfolio und Software dann verwenden können und da
gibt es zum anderen eine Cloud Plattform, auf der wird eine
SARS Lösung gebaut, es gibt eine KI Plattform, bei der wird
zentralisiert ein KI Gateway bereitgestellt, KI Modelle
bereitgestellt, Sicherheit und Compliance und veredelte AI
Services gebaut. Es gibt eine developer
Plattform, die ganz viel Plattform Engineering macht, die
Zentrale Libraries schreibt, die wiederverwendet werden, die zum
Beispiel auch über ein Backstage Dinge aufsetzt, wo dann sich
Templates und fertige, fertig konfigurierte Repositories
gezogen werden können. Es gibt eine Data Plattform und
es gibt unten drunter auch eine Infrastruktur Plattform, die
dann verschiedene Cloud man das ja so Landing Zones, also Cloud,
fertige Cloud Umgebungen anderen Teams bereitstellt.
Und beim Aufbau von all diesen Plattformen kann ich halt in all
diese Themen immer mal wieder reingucken und mir fast schon so
ein bisschen aussuchen, wie tief ich da reingehen möchte oder
teilweise auch muss, weil die meisten Teams davon befinden
sich noch im Aufbau. Oft muss ich auch noch selber
irgendwie so ein bisschen ran und dadurch ist es jetzt so ein
bisschen breiter als in meiner vorherigen Rolle, das war ja so
ein bisschen halb technisch halb vertrieb, da wurde sich dann
halt auch immer oft saisonal oder was halt gerade irgendwie
so das Thema war, sehr auf eine Sache fokussiert und.
Und jetzt? Wie gesagt, bin ich glaube ich
nicht mehr so tief wie vorher drin, aber in mehr Themen drin.
Ich glaube, ganz viele der Themen, die du gerade
angesprochen hast, hatten wir schon mal im Podcast und einige
hatten wir, weil wir uns tagtäglich damit
auseinandersetzen. Aber einige der Themen haben wir
uns natürlich auch eingelesen, haben mit anderen Leuten drüber
gesprochen und ich glaube, es ist super spannend, jetzt
vielleicht auch in mehr Themen Hands on reinzugehen und da auch
Einfluss zu haben und. Mich würde interessieren, wie
eigentlich so ein typischer Tag jetzt von dir aussieht.
Also was machst du den ganzen Tag, wieviel Technik hast du
tatsächlich noch in deinem Alltag und wieviel ist
eigentlich nur noch Koordination und Meetings?
Ja, Meetings ist ein gutes Stichwort.
Also Meetings haben mich, haben mich überrascht, also ich höre
viel mehr, ich mache viel mehr Meetings, als ich gedacht habe,
das sind. Natürlich auch Abstimmungen,
auch natürlich viel Reporting in so einer Rolle muss man dann
natürlich auch irgendwo ans Management und ans Leadership
einen Statusreport abgeben und vor allem wenn man irgendwas
nicht läuft, da auch eine Erklärung zu finden und Pläne
vorlegen, wie man das dann irgendwie korrigieren möchte.
Dazu kommt natürlich, wenn man irgendwie ein Team aufbaut und
mitarbeiten, da hat irgendwelche.
Team Meetings natürlich, also irgendwelche Touchpoints, wo man
sich regelmäßig als Team zusammensetzt.
Auch One on Ones und mit den Leuten direkt zu sprechen, da
gibt es natürlich auch viele Teams, in denen vielleicht mal
Konzepte erklären oder diskutieren muss, gerade die
Dinge, die man neu einführt, es müssen Entscheidungen getroffen
werden, also die sind also ganz, ganz viel.
Konzeptarbeit ist eigentlich auch was, was irgendwie eine
große Rolle spielt. Das heißt, ich setze mich auch
viel hin, teilweise mit Leuten, und arbeite Konzepte aus oder
Reviewer Konzepte, die andere ausgearbeitet haben darüber, wie
wir die Developer Plattform aufbauen darüber, von welchem
Cloud Anbieter wir welche Modelle nehmen und wie wir sie
absichern. Und oft ist es so, dass ich gar
nicht mehr, dass ich gar nicht mehr unbedingt dieses Konzept
dann schreibe, sondern dass ich mehr oder weniger so ein
bisschen. Die Konzepte bei den Auftrag
gebe, die wird dann von meinem Team erledigt mit Research und
die tauchen dann richtig tief ab, formulieren dann nachher da
oft eine bei uns eine Confluence Page draus, die ich dann wieder
Reviewer oder eine Planung mache.
Wie soll so eine Infrastruktur aussehen, dass man da grob Dinge
mit gibt und dann halt irgendwann wieder da am Ende
sein Review zu abgibt oder sich oft irgendwie meinen Senf danach
noch dazu abgeben, indem ich Dinge kommentiere, indem ich
schaue, dass in die Richtung gegangen ist die, die ich mir
vorgestellt habe und. Das ist so ein bisschen der
technische Teil. Es gibt diesen personellen Teil,
also vor allem viel mit Meetings, Entscheidungen,
Reportings, es gibt viel diese Konzeptarbeit, die ist dann oft
irgendwie technisch, da geht es aber weniger um die Umsetzung,
mehr um die Konzepte, und da geht es natürlich noch um so
einen strategischen Teil, da geht es um Priorisierung, um
Kostenkontrollen natürlich auch, und um was machen wir wann, um
welches unternehmerische Ziel zu erreichen.
Und als allerletztes, was es natürlich auch ein Teil von
meinem Tag aus Macht, ist dedizierte Zeit zum Lernen.
Das habe ich ja schon immer so gemacht, habe ich auch in frühen
Podcast folgen mal immer wieder geteilt, dass ich mir ganz
dedizierte Blogger setze für Fokusarbeit oder für lernen, die
wirklich in meinem Kalender sind, wo ich dann auch keine
Termine annehme, weil ich mich da eben weiterbilden muss.
Kannst du uns ein paar Beispiele geben für technische
Entscheidungen, die ihr im Team trefft und bei welchen Dingen du
sagst? Da möchte ich selber die
Entscheidung treffen, weil die sind vielleicht so kritisch,
dass ich gar nicht möchte, dass jemand anders dafür am Ende
vielleicht gerade stehen muss, wenn es schief geht.
Technisch schauen wir im Team, treffen als Beispiel so aus der
Developer Welt. Wir brauchen, wir bauen gerade
Feature Flags zum Beispiel ein, Wir haben sogar meine eigene
Folge zu Feature flags gemacht, fällt mir da fällt mir da ein,
die kann man natürlich gerne mal nachhören.
Und da brauchen wir den richtigen Anbieter für, und da
haben wir so zwischen zwischen 23 ausgewählt, da war irgendwie,
ich glaube so Launch Darkley kommt vielen direkt irgendwie in
den Kopf, wenn man, wenn man über Feature Flags nachdenkt
gibt man auch Post Hawk und viele andere und da ging es
jetzt zum Beispiel einfach darum, die richtige Plattform zu
finden, das Gleiche für wir machen gerade
Berechtigungsmanagement ein, auch dafür muss die richtige
Plattform gefunden werden. Uns war relativ klar, dass wir
es wahrscheinlich nicht selber bauen werden, aber auch das wird
evaluiert. Das sind solche Dinge, die, da
bin ich in der in dieser Konzeptphase oder in der
Definition von so einem Proof of Concept beteiligt, das
entscheide ich aber nachher nicht selber.
Also das sind einfach Sachen, wo ich sage, Hey, das Team, was
nachher einen Feature flages Service zentral in unserer
Developer Plattform baut und den anderen Teams, Abteilungen und
Gruppenunternehmen bereitstellt, das soll auch bitte komplett
frei selber entscheiden, welchen Services ich gucke, so ein
bisschen am Ende noch mal auf die Kosten drauf und ob das.
Und ob das unseren Security Anforderungen entspricht, mache
ich aber auch nicht wirklich selber, sondern gebe das dann
eher ins Security Review von unserem Security Team rein.
Ob das GDPR Compliant ist und so und solche Dinge.
Also das ist so eine typische Entscheidung wo ich sage ich
kriege mit, dass da eine Entscheidung getroffen wird.
Ich muss bestimmt auch irgendwo mal Anforderungen reingeben,
Security Reviews anstoßen oder ein Kosten approval machen.
Aber das ist das Developer Team, also dass sie dem Developer Team
zum Beispiel komplett selbst überlassen, was sie damit, was
sie am Ende entscheiden, das möchte ich auch eigentlich so
haben, weil da sind die ja viel, viel näher dran an dem Problem.
Eine Sache, die ich selber entscheide, sind oft Dinge, für
die ich auch selber gerade stehen muss, das sind dann zum
anderen, woran ich zum Beispiel gemessen werde, auch unter
anderem ist natürlich die Verfügbarkeit von den Systemen,
die wir bauen. Das heißt, eine Entscheidung,
die natürlich auch irgendwo Komplexität, aber auch Kosten
mit sich zieht. Ob man einen gewissen Service in
einer entsprechenden Redundanz aufbaut, ob wir den in die Cloud
schieben oder ob wir den auf eigenen Rechenzentren betreiben.
Wir haben auch eigene Rechenzentren, wir haben eigene
Hardware, teilweise auch, die wir betreuen, das sind dann oft
Entscheidungen, wo ich am Ende dann auch dran gemessen werde
und wo ich mich, die ich natürlich nicht selber treffe,
da hole ich mir natürlich schon die Argumente der einzelnen
Teams rein und. Aber das ist dann was, wo ich
einfach auch letzten Endes die Entscheidung treffen muss, weil
ich selber, weil es meine Aufgabe ist, abzuwägen, was ist
der Kosten oder quasi Ruf impact, den sowas hat, wenn es
irgendwie ausfallen würde, was ist wenn es hoch verfügbar über
mehrere Regionen hinweg betrieben wird, das hat
natürlich ganz ganz weite Auswirkungen, oder dass mich
welche Cloud Plattformen wir verwenden oder wo wir unseren
Code hosten sowas. Das sind dann glaube ich schon
Dinge, die ich gerne mitentscheiden würde, weil ich
am Ende auch dafür verantwortlich bin, wenn es
nicht funktioniert. Und ohne jetzt irgendwelche
Internas preiszugeben, ist ja ein Unternehmen, was schon
einige Jahre alt ist, aber durch Akquisitionen, was es vorhin
gesagt, immer weiter gewachsen ist, gibt es dann besondere
Aufgaben, die gerade aufgrund dieser Struktur jetzt gerade in
deinem Alltag eine große Rolle spielen.
Ja, die die Struktur ist deswegen spannend, weil
natürlich, wenn so ein Unternehmen von sich aus wächst,
der Textdac wahrscheinlich halbwegs ähnlich innerhalb des
Unternehmens ist. Und durch Akquisitionen kannst
du oft den Textdac dann nicht mehr so ganz beeinflussen.
Das heißt, wir haben einen relativ bunten Blumenstrauß
eigentlich bei uns an Technologien, wir sind sehr,
sehr, sehr, sehr starker.net Shop, wir machen ganz ganz viel
Sea Shop, wir haben aber auch. Recht viel PHP.
Wir haben Java Script im Frontend, wir haben aber auch
verschiedene Cloud Anbieter, auf denen vor allem andere
Gruppenunternehmen unterwegs sind und das alles jetzt
irgendwie einzufangen unter einen Hut zu bringen ist doch
dann oft ein Migrationsaufwand. Also ich muss, muss ja wenn die
Entscheidung treffen möchte ich den Overhead haben, verschiedene
Cloud Cloud Anbieter zu haben oder wenn ich die Entscheidung
treffen sollte, dass wir alle auf einen Cloud Anbieter gehen
oder alle Ihre Git Lab Repositories zu github umziehen
oder oder so weiter. Muss ich mir natürlich auch
Bewusstsein, dass das natürlich auch das Tagesgeschäft aufhält,
dass das ein richtiges Migrationsprojekt ist und dass
ich da vielleicht irgendwann mal Kosten spare durch die
Konsolidierung, aber das vielleicht jetzt erstmal die
Kosten hebt, weil wir Dinge parallel machen müssen oder weil
was anderes irgendwie dann hinten überfällt.
Auf der anderen Seite habe ich da vielleicht aber irgendwann ja
einen produktivitäts Boost davon, also ich verspreche mir
natürlich vielleicht auch irgendwas von so einer.
Migration wie Früh möchte ich das?
Möchte ich davon profitieren und einplanen und dann ist das ist
eigentlich das knackige und das mache ich natürlich auch nicht
alleine, sondern in Abstimmung mit dem Leadership, wann machen
wir was, was ist eigentlich, wie wichtig ist es jetzt hier
wirklich wichtig, den letzten Euro zu sparen oder ist es
wichtig, so möglichst früh von der von der Produktivität zu
profitieren, dadurch, dass wir alle irgendwie einheitlich auf
dem gleichen Text Tag unterwegs sind.
Das würde zum Beispiel bedeuten, dass wir auch Talente und
Developer vielleicht von dem einen Projekt auch mal in das
andere schieben können, wenn man da irgendwie aushelfen muss,
weil es gleich gemacht ist, haben wir diesen Anwendungsfall
überhaupt, und das macht meinen Alltag eigentlich spannend und
ist natürlich alles in dieser Tech Welt, aber heißt natürlich,
dass ich dann bei diesen Entscheidungen auch nicht
wirklich irgendwie Code schreibe, sondern eher
eigentlich so diesen developer Alltag, den ich ja aus meiner
Erfahrung kenne, bewerten muss und dann daraufhin eben
Entscheidungen treffe. Du hast gerade schon so ein paar
Kriterien genannt, an denen dein Erfolg bemessen wird.
Du hast über Uptime gesprochen, aber was ist für dich jetzt in
der Rolle Erfolg, also wann hast du das Gefühl, ich mache einen
guten Job und wie würden andere das in der Firma, also dein
Leadership Team beurteilen? Das ist eine gute Frage.
Ich glaube, ich hoffe, dass das nicht allzu weit auseinander
geht, wie ich das definiere und wie das meine Chefs beurteilen.
Am Ende gibt es natürlich Dinge, die sind super schwer messbar.
Also eine Sache, die wo ich ich dann am Ende glaube, dass ich
erfolgreich bin, ist, dass ich zum Beispiel die Produktivität
gesteigert habe bei uns, in der im Gruppenunternehmen Developer
Produktivität zu messen ist. Aber was, was brutal schwierig
ist, wir hatten da sogar auch mal eine Podcast Folge zu, wenn
ich mich richtig erinnere, da haben wir sozusagen, glaube ich,
diesen längeren Mc Kinsey Artikel, den es damals gab, als
Aufhänger genommen, das ist was, ja das.
Muss man irgendwie versuchen zu erheben.
Das ist aber ganz, ganz, ganz, ganz schwer, in eine Zahl
wirklich zu zu gießen oder sowas wie ist für mich natürlich
persönlich wichtig, Zufriedenheit von meinen
Mitarbeitenden bei mir im Team und natürlich auch dann in deren
Teams, die die die aufbauen, was viel einfacher zu messen ist,
ist natürlich wurde wurde Uptime eingehalten oder irgendwie in
der SLA und deswegen glaube ich würde ich so zusammenfassend
sagen, ich Messe meinen Erfolg jetzt gar nicht irgendwie so
dran wie. Total modern wir jetzt irgendwie
unsere Cloud und unsere KI aufgebaut haben, das machen wir
natürlich auch, aber das ist ein Nebenprodukt, sondern eher, wie
sehr die Dinge, die meine Teams bauen, das Geschäft
beschleunigen, also konkret so auf 3 Ebenen, so was sind die
wirklich, was sind denn die Business Outcomes, die wir jetzt
hatten, das kann natürlich so was sein wie Tank to market, Wir
haben irgendwie geschafft Feature schneller zu launchen
oder irgendwas schnell zu bauen oder von irgendwas zu
profitieren, vielleicht was ein anderes Team schon vorher gebaut
hat und das war vorher nicht der Fall.
Es kann sowas sein wie Stabilität in Peak Zeiten,
gerade im E Commerce im Black Friday, Weihnachtsgeschäft und
sowas natürlich wahnsinnig wichtig.
Das sind dann natürlich auch irgendwie so wirklich Metriken
der Plattform, Verfügbarkeit Developer Produktivität, wie
lange dauert das von einer Idee zu einem POC zu einem echten
produktiven Use Case und dann vielleicht aber auch irgendwie
sowas wie organisatorische Nachhaltigkeit, wenn du es so
nennen willst. Also.
Ich versuche auch irgendwie massiv Wissensvermittlung zum
Beispiel voranzutreiben, Automatisierung, Security, weil
wir natürlich von den ne, wir haben jetzt in den letzten
Folgen auch oft über irgendwelche.
Über sie npm Pakete gesprochen, die dann große Security Lücken
hatten. Das ist dann natürlich auch
sofort auf meinem Schreibtisch, wo ich sagen muss okay, wir
haben jetzt hier eine Developer, eine developer Plattform, kann
die denn überhaupt eine Aussage darüber treffen, ob wir davon
betroffen sind und ob wir das schon gefixt haben und ob es
noch Repositories gibt die das die updaten müssen und sowas und
ich glaube das Skalieren zu können auch vielleicht mal über
noch weitere Akquisitionen in der Zukunft.
Ohne ständig alle auszubremsen. Das wäre was, wo ich sage, ey,
dann sind wir erfolgreich. Also wenn, wenn wenn wir
schneller liefern, wenn wir weniger Reibung haben, wenn wir
stabil sind, wenn wir compliant sind und wenn es natürlich Spaß
macht, irgendwie mit dieser Plattform zu arbeiten, und das
ist, glaube ich, was, wie ich Erfolg definieren würde an
meiner langen Antwort kann man aber schon sehen, das müsste ich
jetzt wahrscheinlich für meine persönliche Messbarkeit von
meinem Management eigentlich noch in.
Ja, konkrete Zahlen Gießen, und das ist deutlich schwieriger.
Ich würde gerne noch mal einen Schritt kurz zurückgehen, bevor
wir auf die konkreten Zahlen eingehen, weil ich eine Sache
ganz spannend fand. Du hast gerade über das Thema
Developer Productivity relativ lange gesprochen und als ich
deinen Jobtitel gesehen hatte, hatte ich gedacht, das ist
bestimmt. Außerhalb deiner Verantwortung.
Also da gibt es sicher ein separates Developer Plattform
oder Developer Experience Team, bedeutet das in deiner Funktion
also in der Verantwortung für AI und Cloud gehört das ganze Thema
Developer Experience mit dazu. Ja, in meinem Fall jetzt schon.
Hast du nicht recht, das stimmt jetzt, da stimmt ja der Jobtitel
eigentlich nicht mehr so ganz und ich hoffe wir müssen jetzt
aber auch nicht noch noch noch länger machen, aber ja, also von
diesen. Eigentlich so 3 großen
Plattformen, die wir aufbauen. Das ist halt die die Cloud
Plattform, die KI Plattform und aber auch die Developer
Plattform, die das alles irgendwie zusammenhält und da
überall irgendwie so ein bisschen mit Reinspielt.
Also in meinem Fall ist es schon so, dass wir ein developer
Plattform Team haben, dessen Aufgabe es auch ist, die
Produktivität von Entwicklerinnen und Entwicklern
bei uns zu steigern und das kann natürlich durch KI sein, das
kann natürlich durch Cloud Services sein, die wir verwenden
können, dadurch, dass wir nicht mehr alles selber bauen müssen
und sowas. Also das hat immer schon
irgendwie was mit einer von beiden oder beiden Themen zu tun
ist. Ja, eigentlich auch sinnvoll,
die Themen immer zusammen zu denken, weil ich meine am Ende
das, was die Developer bauen, ist ja über so einen Def Ops
Prozess immer ganz eng mit der ganzen Betriebsumgebung auch
verknüpft und das dann in unterschiedliche Bereiche
aufzuteilen macht gar nicht so viel Sinn und von daher finde
ich das. Sehr gut, dass du auch an dem
Thema Developer Experience da dran ist, weil da dran bist,
weil da natürlich für uns auch im Podcast in der Zukunft,
glaube ich, einige spannende Themen rausfallen können, die du
dann in deinem Alltag siehst. Gerade wenn man so eine
Plattform ausrollt. Wir haben ja vor einiger Zeit
mal über Plattform Engineering gesprochen und solche Developer
plattforms und da war das so ein bisschen trockenübung und jetzt
hast du die Möglichkeit, das ganze Mal auf einem gewissen
Maßstab selber auszurollen und zu schauen, wie.
Viel Produktivitätsgewinne kann man wirklich erreichen durch
sowas und da wäre ich tatsächlich auch.
Nachdem du ein bisschen weiter drin bist an den
Echtwelterfahrungen interessiert.
Hey, können wir gerne mal machen.
Das ist natürlich auch was, was wir gerade erst einführen, also
diese ganze Plattform Engineering, da freue ich mich
sehr, dann da irgendwie mal so Real World Erfahrungen mitgeben
zu können. Du hast jetzt gerade gesagt,
dass diese developer Plattform natürlich mitgedacht wird in all
diesen Sachen stimme ich dir vor allem deswegen zu, weil ich
gerade auch versuche. Mehr so ein You Build it you run
it Konzept irgendwie einzuführen, sondern dass
wirklich halt die Teams, die die Software bauen auch dafür
verantwortlich sind, sie zu deproyen und am Ende auch zu
betreiben. Also wirklich Def und Ops als
Def Ops zusammengebracht und gerade dann bist du ja ganz ganz
schnell schon bei der Cloud eben an sich wenn voraus ist
natürlich das Run IT ist in der Cloud.
Aber deswegen, glaube ich, macht das schon Sinn, dass diese Teams
sich auch eng abstimmen und in meinem Fall jetzt auch in der
gleichen Abteilung sind. Von daher freue ich mich schon,
dass wir da eben ganz, ganz enge Developer Experience Bindung
auch eben an diese Plattform, an diese KI und Cloud Plattform
haben, die wir da bauen, weil letzten Endes sind es developer,
die damit arbeiten und die das als Ziel.
System verwenden um da rein zu deployen und vielleicht auch
dort ihre Sachen zu testen oder von dort ihre KI Modelle zu
beziehen. Und deswegen glaube ich, dass
man das gar nicht so so scharf trennen kann und sollte.
Lass uns mal kurz das Thema Messbarkeit abschließen.
Du hattest gerade schon so ein paar Dinge genannt und hat
gesagt. Die sind relativ schwer zu
messen. Hast du auch ganz harte
Metriken, die ihr gemeinsam als Team definiert habt, die ihr
regelmäßig Messe? Du hast gesagt, Developer
Produktivität ist schwer zu messen, aber vielleicht habt ihr
andere, die vielleicht das ganze Thema indirekt abbilden und die
ihr aktuell schon erfasst. Ja, da muss ich natürlich ein
bisschen gucken, wieviel ich davon teilen kann.
Aber ich kann es so ein bisschen mal grob umschreiben.
Also am Ende sind wir eine Software Company und am Ende ist
auch das, was jetzt meine Abteilung macht, irgendwo
Softwareentwicklung. Wenn man so was wie
Bereitstellung von Cloud Infrastruktur als
Softwareentwicklung mit dazu zählt.
Aber zumindest entwickeln wir irgendwas, wir bestellen eine
Plattform bereit und. Und da ist Erfolg am Ende auch
dadurch definiert, ob man fertig geworden ist und ob man auch in
der angedachten Zeit fertig geworden ist.
Das heißt, wir haben schon auch eine gewisse Sprintplanung
Quartalsplanung und sowas, wo wir Aufgaben und Outcomes und
Deliverobles definieren, die in einer gewissen Zeitspanne
gemacht werden soll. Das ist vor allem deswegen
wichtig, weil auch oft dann andere Teams davon abhängig
sind, wenn mein Team jetzt dieses diesen zentralen Feature
Flag Service baut, dann. Dann ist das andere Team, was
die Feature Flex verwenden möchte, natürlich darauf davon
abhängig, dass wir in der entsprechenden Zeit, die wir
kommuniziert haben, fertig werden.
Und das ist natürlich schon relativ messbar.
Es gibt noch eine ganz andere, es gibt auch eine komplette
Software Development Abteilung bei Jtl, mit der habe ich gar
nicht so wahnsinnig viel direkt zu tun und die baut dann
wirklich die Produkte, die nachher zum Beispiel auf der
Cloud gehostet werden, aber auch mein Developer Plattform Team
baut natürlich irgendwo Komponenten die dann.
Das Engineering verwendet, und das ist ja schon durchaus
messbar, ob man da in einer gewissen Zeit seinen Burn Down
Chart richtig runter gerockt hat und das ist natürlich schon was,
wo am Ende auch ich daran gemessen werde und eine andere
Komponente ist auch was die ich natürlich auch irgendwo
vielleicht auch eher indirekt beeinflusse, und das sind
natürlich einfach Unternehmensziele, das kann
Wachstum, Umsatz oder sowas sein, das ist natürlich super
schwer alleine zu beeinflussen. Weil da hängt natürlich auch
daran, ob das Engineering ihre ihre Ziele schafft.
Das hängt natürlich an von von Sales und von Go to Market und
von eigentlich von allen Abteilungen, aber da ist
natürlich auch ein Teil der Dinge, worüber man meinen Erfolg
misst, ist, ob ich eben entsprechend beigetragen habe zu
diesen, zu diesen Unternehmenszielen, und dazu
gibt es natürlich noch mal so ein paar ganz persönliche Ziele,
die ich dann mit meinem Management definiere und was
natürlich auch immer. Ja gut, kommt ist irgendwie eine
gewisse extra Meile, wenn man vielleicht noch irgendwie sagt,
ich habe hier außerhalb der eigentlich vereinbarten
Wirkungsbereiche noch irgendwo vielleicht irgendwas mitgemacht.
Bei mir hat der Weihnachtsfeier als Nikolaus verkleidet und
Geschenke ausgeteilt oder so, aber genau also ich glaube so
setzt sich dann ungefähr meine Zielvereinbarung zusammen.
Aber zumindest machst du ja einen developer Podcast und
hilfst dann auch bei der Weiterbildung.
Was glaube ich nicht verkehrt sein kann.
Aber vielleicht nachdem wir jetzt lange um das Thema herum
geredet haben, wieviel kommst du eigentlich noch zum Coden, ist
das etwas was du als extra Meile machst?
Wenn du dann irgendwie abends Feierabend machst, setz dich hin
und entwickelst Software und kannst dann dadurch dich
weiterbilden und auch einen Beitrag leisten oder ist das
etwas, was im Moment so ein bisschen in den Hintergrund
gerückt ist, weil du den ganzen Tag in.
Meetings netzt. Ich glaube, ich glaube, das
Engineering würde mir den Kopf abreißen, wenn ich da einfach
abends noch mal so ein bisschen Code committed, zumindest zu den
den Hauptprodukten, die die Jtl baut.
Da schreibe ich keinen Code, nee, aber ich bin natürlich
trotzdem noch mit meinen Händen auf der Tastatur in Visual
Studio Code unterwegs, manchmal auch eher ungewollt.
Also ich habe ja vorhin erzählt, das Team befindet sich massiv im
Aufbau. Das bedeutet, es gibt auch
einfach manchmal Aufgaben, da haben wir noch keinen oder
keine, die das machen kann. Oder wir haben einfach zu wenig
Leute und dann bin ich natürlich schon auch dabei und schreib mal
irgendwie ein terraform Skript oder Review, mal die ein oder
andere Cloud Konfiguration oder muss dann doch noch mal
vielleicht selber hier und da die kleine Cloud Architektur zu
Ende bauen oder sowas durch Personalmangel oder Urlaub und
sowas passiert das natürlich schon und.
Ganz ehrlich, es raubt mir natürlich viel Zeit, aber es
macht natürlich auch immer wahnsinnig viel Spaß, das ist ja
da, wo ich herkomme und trotzdem genauso wie wir diesen Podcast
irgendwie in der Freizeit aufnehmen, werde ich mich, werde
ich mir auch nicht nehmen lassen, in der Freizeit kurz zu
schreiben und Projekte zu bauen, einfach, das ist halt wie bei
den meisten Developern ja auch aus einem Hobby entstanden, ich
baue auch zum Beispiel gerade eine Software, die ich dann auch
vorhabe, bei uns im Unternehmen zu verwenden, ich bastel gerade
an so einem github Manager, also an der Software.
Die regelmäßig hingeht und schaut, ob Projekte entsprechend
unserer Vorgaben ja in Anführungszeichen Compliance
sind. Da geht es aber gar nicht so
sehr darum, ob sie irgendwelchen Security Richtlinien folgen,
sondern ob sie einheitlich sind, also ob sie alle eine bestimmte,
also ob sie alle in der Read me eine how to get it running
Instructions zum Beispiel haben, das könnte man dann irgendwie,
da versuche ich irgendwie so gerade so ein Dashboard zu bauen
und mit der Guitar API zu arbeiten und fairerweise ist die
Hälfte auch gewipe Codet davon aber funktioniert relativ gut.
Und das würde ich mich natürlich freuen, wenn wir das nachher
sogar im Unternehmen einsetzen können.
Und das hilft mir natürlich aber auch irgendwie nah an der in der
Coding Realität zu bleiben oder das irgendwie in unseren eigenen
Sachen auszuprobieren. Genau das heißt, in meinem
Berufsalltag würde ich sagen, bin ich gerade deutlich weniger
am Coden als vorher in meiner Freizeit aber deutlich mehr als
vorher, weil ich es auch ein bisschen vermisse, und ich werde
es mir auch nicht nehmen lassen. Also ich will, ihr habt jetzt
überhaupt keine Lust da ein reiner.
People Manager zu werden, sondern ich habe auf jeden Fall
Lust, irgendwie ganz nah an der Technik zu bleiben und werde mir
das nicht nehmen lassen. Du hast es ja so ein bisschen
schon gerade gesagt, was du dir vorstellst, wie du diese Rolle
ausfüllst. Aber was macht jetzt diese Rolle
für dich so spannend? Ich glaube, du bist ja ein
leidenschaftlicher Softwareentwickler, auch und
auch wenn du jetzt ein bisschen ins Vibe Coding abgerutscht
bist, schreibst du ja immer noch selber gerne Code.
Aber hast dich jetzt bewusst für eine Rolle entschieden, wo du
sehr viel Zeit mit Menschen verbringst und weniger Zeit mit
Code. Was reizt dich genau an dieser
Rolle und warum hast du dich dafür entschieden?
Ich verbringe ja trotzdem noch viel Zeit mit Technologie und
ich glaube, das ist auch das, was mich immer am meisten
eigentlich fasziniert hat. Also natürlich Code ich für mein
Leben gerne, aber das Faszinierende.
Weil eine Software Software Entwicklung ist ja kein
Selbstzweck, das macht man ja nicht um Software zu entwickeln,
sondern immer um irgendwas zu erreichen und das ist auch oft
ein Unternehmen und oft ein unternehmerisches Ziel oder um
eine coole Technologie zu bauen und ich glaube was mich reizt
ist das, was ich auch eingangs mal gesagt habe, so ein
bisschen, dass ich die Flughöhe etwas gewechselt habe und
dadurch eben eben all diese Themen reinstecken kann und ich
jetzt, ich bin nicht der Chefentwickler bei uns oder der
Lead Cloud Architekt, da haben wir Leute, die können das besser
als ich und. Ich muss aber high Level
Entscheidungen treffen jetzt, die vor allem auf meiner
Erfahrung beruhen. Also ich glaube, ich habe schon
recht viel gesehen und wir sind ja beide auch in unseren
Kundenprojekten und so immer viel rum gekommen und auch durch
diesen Podcast eine Vielfalt an Themen schon irgendwie
beleuchtet und ich glaube, das kommt mir jetzt zugute, weil wir
in ganz, ganz vielen Sachen schon mal und so wie angefangen
haben, eine Expertise aufzubauen und das kann man dann jetzt halt
irgendwie doch wieder auch wieder weiter verwenden und dann
irgendwie alles so. In einem Strang
zusammenzubringen, das Macht, das ist, das ist eigentlich
irre, dass das geht, und das ist jedes Mal wahnsinnig
faszinierend, gerade wenn man mit vielen Menschen arbeitet,
dass das dann doch irgendwann zu irgendwas zusammenkommt, und
dann kriegt man eine Produktdemo, wo man sieht, dass
die KI Plattform, die man dann irgendwie zentral im Unternehmen
bereitgestellt hat, wird dann hier von einer anderen Abteilung
oder von einem anderen Gruppenunternehmen eingesetzt
und man sieht dann da ein Feature.
Hat dann sieht dann das erste Mal die Demo von den Feature
Flags, die das Developer Team gebaut hat.
Sieht das erste Team was vielleicht jetzt auf einmal
anfängt Pull Requests zum Review in der Cloud Umgebung zu
deployen die das Infrastruktur Team bereitgestellt hat, sieht
das erste Mal Dashboards die vom die vom Data Team kommen die auf
einmal angefangen haben über Produkte hinweg Metriken
aufzusammeln und darauf Insights zu ziehen und.
Vielleicht merkt man es gerade gerade schon oder hört so ein
bisschen, da leuchten mir irgendwie so ein bisschen die
Augen davon und das hat man, finde ich, hatte ich das in der
Freiheit nicht so sehr gehabt, wenn man sehr in einem einzelnen
Detail drin ist, was mir auch immer ultra viel Spaß gemacht
hat, sehr tief im Detail drin zu sein, aber jetzt eben dieses
Zusammenkommen von diesen ganzen Strängen und dazu natürlich dann
auch irgendwie. Ja, zu priorisieren, welcher
Strang da jetzt vielleicht ja welche Ressourcen irgendwie
bekommen, in welcher Reihenfolge gemacht werden muss, das finde
ich schon, das gibt mir irgendwie was und ich habe es,
also ich bin ja noch nicht lange dabei, ich mache das ja jetzt
seit 2 Monaten erst. Ich habe aber heute noch immer
das Gefühl, ich freue mich, also ich freue mich Freitagabend auf
Montag, ich habe natürlich auch ein cooles Wochenende, aber ich
habe Bock am Montag irgendwie irgendwie weiterzumachen.
Weil ich bin noch auf nichts gestoßen, was mich müde macht,
sondern es sind natürlich auch Herausforderungen.
Da gibt es natürlich auch Blocker identifizieren und
lösen, und diese Blocker sind nicht mehr nur technisch, die
können auch manchmal menschlich sein, und das sind ganz andere
Herausforderungen, die man vorher vielleicht nicht hatte,
aber es macht immer noch Spaß, das zu lösen, und ich habe
bisher auch nur coole Leute kennengelernt da und von daher,
im Moment ist es zumindest für mich so, dass ich sage, ich
kann. Genieße das sehr irgendwie,
diese breiten, diese breite Übersicht zu haben und dann am
Ende auch zu sehen, dass irgendwie alles zusammenkommt
und funktioniert. Ja, wir hatten uns ja auch im
Vorfeld schon so ein bisschen über die Rolle unterhalten und
auch als du dich umgeschaut hattest, hatten wir die ersten
Gespräche dazu, aber ich habe tatsächlich jetzt erst das
vollständige Bild verstanden und finde es super spannend, gerade
auch für den Podcast, weil ich glaube, da fallen am Ende ganz
viele spannende Themen raus, die du jetzt.
Einfach mal durchlaufen kannst und wo dann auch unsere Hörer
und Hörer von profitieren können, wenn du oder wir
gemeinsam davon berichten, was ihr auch für Erfahrungen
gesammelt habt. Es muss ja dann auch nicht immer
wirklich exakt auf euren Unternehmens Case gemünzt sein,
sondern man nimmt ja ganz viel, so meta Informationen mit, wie
man halt so etwas macht, gerade wenn man zum Beispiel eine
developer Plattform aufbaut. Und da freue ich mich echt
drauf, da auch ein bisschen tiefer reinzugehen in einer der
kommenden Folgen. Ja, ich glaube, es ist für alle,
die hier zuhören, natürlich sinnvoll, auch bewerten zu
können, woher unsere Erfahrungen kommen und womit wir uns
irgendwie jeden Tag beschäftigen, um natürlich das
auch in einen Kontext zu setzen oder auch nicht zu wissen, woher
haben wir denn diese Information, was ist denn unser
Setup und sowas. Ich glaube, das hilft natürlich
immer, das zu bewerten, ich finde es.
Auch immer wichtig, wenn ich irgendwo auf einem Meetup bin
oder auf einer Konferenz einen Sprecher oder eine Sprecherin
sehe, dann ist es natürlich auch immer relevant zu gucken, wo
kommt die Person her, was macht die eigentlich in ihrem Alltag,
wie muss ich das, was die Person mir jetzt erzählt, natürlich
auch irgendwie einordnen. Und ja, ich freue mich, wenn wir
das irgendwie geschafft haben, da vielleicht einen Einblick in
meinen Alltag zu gewähren und. Und damit du nicht den
Werbeblock machen musst, vielleicht kurz die Erwähnung,
dass du natürlich auch du hattest.
Auch in der Vergangenheit schon mal erwähnt, dass du natürlich
weiterhin dein Team ausbaust und gerade aktuell auch.
Auf der Suche bist nach Kolleginnen und Kollegen, die
sich mit dem Thema Azure auskennen, als Architektinnen,
Architekten, Administratoren und dementsprechend natürlich dich
freuen würdest, wenn einige der Hörerinnen und Hörer das
spannend finden. Und ich glaube, da packst du
tatsächlich dann auch noch mal einen Link in die Show Notes,
damit man sich da informieren kann, welche Rollen es aktuell
auch in deinem Team gibt. Genau so ist es also, wenn ihr
Lust habt, da mitzuarbeiten von dem, was ihr jetzt hier gehört
habt. Ich freue mich sehr auf eine
Initiativbewerbung, ich habe die.
Stellen noch nicht ausgeschrieben was einfach auch
an Zeitmangel im Moment liegt, werde ich aber im neuen Jahr
sofort im Januar machen. Aber ihr könnt gerne jetzt schon
irgendwie mir eine E Mail oder natürlich auch direkt über die
offizielle Jtl Jobbörse mir eine Initiativbewerbung schicken.
Ich würde mich wahnsinnig freuen hier mit Hörerinnen oder Hörern
vom Podcast zusammenzuarbeiten. Und damit sind wir am Ende der
Folge angekommen. Und wenn euch dieser 40 minütige
Werbeblog gefallen hat, dann würden wir uns natürlich freuen,
wenn ihr nicht nur eine Bewerbung bei Robin Manuel
Abgebt, sondern auch eine Bewertung für den Podcast da
lasst. Das könnt ihr auf Spotify machen
ihr könnt uns auch gerne auf Apple Podcasts bewerten oder
natürlich einen Daumen nach oben auf Youtube da lassen.
Ja, wenn ihr das als 40 Minuten werbeblog empfunden habt, dann
tut es mir natürlich leid. So war das nicht gemeint.
Dann schreibt uns das gerne, also wenn ihr sagt, das ist
also, das interessiert uns ja hier in einem developer Podcast
mal gar nicht, dann lasst uns das gerne als Kommentar da, denn
ich hatte eigentlich gerade vor vorzuschlagen, dass wir den
ganzen Spieß auch mal rumdrehen und ich für euch mal den Malta
ausfrage, was einen Strategic Solutions Engineer bei github
eigentlich macht. Ich glaube da können sich auch
nicht alle was drunter vorstellen.
Wenn ihr sagt, Oh nein, bitte bloß nicht oder wenn ihr sagt,
Ey, das wäre ja wirklich mal irgendwie cool, dann lasst uns
das gerne wissen, gebt uns da gern Feedback in den Kommentaren
oder gebt uns natürlich auch gerne irgendwie einen Kaffee
aus, wenn ihr Lust habt, da findet ihr die Links.
Zu Bimir Coffee auch in der Beschreibung von der Folge.
Und wie immer freuen wir uns, wenn ihr auch nächste Woche
wieder mit dabei seid. Der to do Developer Podcast
erscheint wöchentlich immer abwechselnd mit einer
Themenfolge wie dieser und einer News Folge dementsprechend.
Nächsten Montag geht's weiter und wir freuen uns auf euch.
Bis dahin habt eine gute Zeit, schreibt viel Code, solange ihr
noch könnt und eine gute Woche macht's gut.
Bis dann.