Die Reise der Zalando Reliability Organisation

Sven: Herzlich willkommen zu einer neuen Episode von unserem CTO Need to Know Podcast. Heute sitze ich, Sven Johansson, mit Heinrich zusammen, der ist Senior Principal SRE bei Zalando. Heinrich, erzähl doch nochmal ein paar Worte über dich.

Heinrich: Ja, Hallo Sven, herzlich, also vielen Dank, dass ich hier sein kann, sehr schön hier zu sein. nur ein bisschen über meinen Background. Ich bin eigentlich von Haus aus Mathematiker, in Bonn Mathematik studiert und bin dann irgendwie in der Software gelandet, nach so einer akademischen Phase und meine ersten Experimente waren eigentlich damals so WordPress Blogs aufsetzen und dann auch sie eine Citation Netzwerkseite zu bauen, damals mit viel Python und ja irgendwie Neo4j haben wir irgendwie verwendet, aus irgendeinem Grund. Und damals waren irgendwie diese Reliability Probleme schon sehr präsent. Also hey, wie kriege ich dieses Ding irgendwie ans laufen? warum schmeißt mir mein Sequel irgendwie regelmäßig ab? Und warum informieren mich meine Nutzer darüber, dass die Konferenz Webseite nicht mehr funktioniert? da war eigentlich dieses Thema schon so ein bisschen gesät und das hat sich dann durch meine gesamte Karriere in den letzten 10–12 Jahren eigentlich durchgezogen. Ich war dann noch eine Weile im Koblenz Fachbereich für Informatik als Postdoc und bin dann zu einem Monitoring Vendor in die USA gegangen als Chief Data Scientist. Also ich habe quasi diese Mathematik, so Signal Analysis und ja andere Sachen, die ich da gelernt habe, quasi rübergenommen in die IT und dann vor allen Dingen so Zeitreihenanalysen auf Metriken gemacht mit vielen großen US und Konzernen halt auch irgendwie Anomaly Detection oder eine Anfrage Sprache entwickelt, mit der irgendwie diese Zeitreihenanalysen gut gemacht werden können, die einfach diese operational New Cases abdecken. Und bin dann nach fünf Jahren zu einem unserer Prospects, mit dem ich immer viel zusammengearbeitet hatte, gewechselt, nämlich Zalando. den haben wir lange gesprochen und die waren schon damals sehr präsent auch auf den Konferenzen und haben da innovative Sachen vorgestellt und deswegen waren die schon immer so auf meinem Radar, eigentlich schon seit seit gut zehn Jahren im Operationsbereich. Und ich bin rüber gewechselt, habe dann eine Weile die SRE Abteilung geleitet über zweieinhalb Jahre und bin jetzt quasi zurück auf dem IS Track, I’m Senior Principal.

Heinrich: I’m Senior Principal, IS individual contributor.

Sven: Genau, individual contributor und bin jetzt aber immer noch sehr global bei Zalando an diesen Reliability Themen dran. Also, wie organisieren wir Prozesse und Tools und strategisch, wie richten wir uns aus, um irgendwie die Probleme, die bei Zalando am präsentesten sind und den meisten Impact haben, in den Griff zu kriegen?

Sven: Mhm. Ja, also ich kann auf jeden Fall nur zustimmen, dass bei Zalando dass es schon sehr weit sind und sehr interessante Leute da arbeiten. Also ich hatte auch mal, die haben mich ge- also Zalando hat mich tatsächlich als Consultant geärdet, muss ich sagen, weil es schon so ein bisschen mehr als zehn Jahre her. da hatte ich den Henning. Ich hab vergessen. Henning Jacobs, genau, den habe ich irgendwie kennengelernt und noch so ein paar von seinen Kollegen und damals war es war gerade so diese No-Sequel Zeit. Und ich habe irgendwie gedacht: " ja, ich Datenbanken, Daten, ich kenne mich aus." Wer will mir irgendwas erzlen? Und dann bin ich mit denen so ins Gespräch gekommen und habe ich gedacht, Huch, also wird ganz schön heiß hier. Ich habe doch deutlich weniger Ahnung als ich gedacht habe, ja, in der Tiefe. Da hat mich schon gedacht, okay, ich muss kleinere Schritte machen. Der Henning, der ja Henning ist großartig. er ist jetzt schon seit zwei drei Jahren weg von Zalando, arbeitet bei Facebook. Ah, okay, und muss ich sagen. Er ist aber immer noch so eine große Legacy, ja? Die Leute kennen ihn alle und viele seiner Tools sind noch im am Einsatz. Er hat damals die Kubernetes Migration für Zalando gemacht, sehr viele Tools geschrieben. Und Datenbanken ist tatsächlich ein eine Sache, die extrem gut läuft, wo ich immer noch nicht so ganz verstehe, warum es so gut läuft. Weil wir haben dreieinhalb tausend Datenbanken im Einsatz, die komplett auf Kubernetes laufen mit so einem custom Kubernetes Operator. Ja. Und mein Verständnis von Datenbanken auf Kubernetes immer sehr schwierig und klappt im Prinzip nicht wirklich und aber wie gesagt, es funktioniert und es funktioniert mit einem relativ kleinen Team, was letztlich quasi diese Datenbank Plattformen provided. Und das sind so vier fünf Leute. Und so diese operational Probleme Probleme, die wir mit Datenbanken haben, sind relativ contained. Klar hat man irgendwie Connection Pooling oder Kapazitätsprobleme, Festplatte, also diese Sachen, die so, so Daten Storage Systeme so mit sich bringen, aber wenn ich jetzt vergesse, wie viel Trouble wir mit unserer ein Postgre Datenbank bei dem bei dem Vendor hatten und wie viel Trouble wir mit dreitausend Datenbanken bei Zalando haben, schon so, es ist erstaunlich, dass man damit wegkommt, ja. Ja, also ich muss sagen, damals habe ich auch gedacht, Hui, also der Henning und war noch ein Kollege von ihm, Ja, muss ja wahrscheinlich. Könnte sein, ne? Aber die die waren so super tief in Postgre drin. Die haben Dinge mit Postgre gemacht, habe ich gedacht: “Ach sowas funktioniert, sowas kann man machen.” War schon erstaunlich. Und danach auch, also wie du sagst, Kubernetes wir hatten auch mal beim Kunden so eine sagen mal eine initiative, so eine right sizing Initiative, also wie schaffen wir es unser Cluster ja irgendwie sagen mal besser auszulassen. Und dann haben wir natürlich auch bei Henning geklaut. Der hat interessante Vortrag gemacht.

Sven: Kuberneted Flow, glaube ich, einer seiner seiner Tools.

Heinrich: Ja, ja, kann sein, ja. ja, also auch das ist immer noch ein sehr aktuelles und spannendes Thema, ne? Ressourcenmanagement im Kubernetes Cluster. Und vielleicht sprechen wir nachher so ein bisschen über Fronttiers noch, was gerade so aktuell immer noch ungelöste Probleme sind und für mich ist dieses Ressourcenmanagement auf Kubernetes tatsächlich immer noch so ein Thema, was so ein Vakuum ist, weißt du? Natürlich hat irgendwie ja Kubernetes mit dem Ressourcen Sharing bringt ja auch Effektivitätsvorteile, aber die Frage, wie viele Ressourcen braucht jetzt ein Container wirklich? Und wie habe ich quasi eine Feedback Loop, die dann auch die Incentives setzt, diese diese Ressourcen Requests richtig zu richtig zu schachteln, ist extrem schwierig, weil die Entwickler sind immer eher okay, eher zu groß, weil auch aus reliability Sicht natürlich besser, wenn ich ein bisschen Headroom habe, aber gleichzeitig ja werden größere Kosten verursacht. Da gibt’s extreme ja potentiale, was man holen könnte. Wo man aber gutes Tooling Support braucht, weil gleichzeitig, wenn ein Ingenieur da viel Zeit investieren muss, das manuell zu analysieren, wie viel Headroom habe ich da tatsächlich, ist das wieder ein negative Return of Investment.

Heinrich: Genau, genau. Ja, können wir tatsächlich später vielleicht noch mal aufgreifen, kurz mal rauszoome, weil wir sind ja CTO Need to Know.

Sven: Ja. Wo drüber wollen wir heute reden? Ich hab so ein paar Sachen aufgeschrieben, so was ist SRE allgemein. wie funktioniert SRE bei Zalando. die Reise von Zalando hin zu SRE, beziehungsweise es gibt ja verschiedene Ansichten, wie SRE funktionieren kann. Prinzipien bei euch. wollten so ein bisschen über den Flywheel Effekt, den Reliability Flywheel Effekt sprechen und Warms, also weekly operational Review Meetings und dann müssen wir noch gucken, was wir sonst noch so rein kriegen, also Klassenauslastung, Service Level Objectives, wie geht man mit Daten um. Ja, wie das bei Zalando läuft.

Sven: Genau. Legen wir doch mal los. Was ist überhaupt Zeit Reliability Engineering?

Heinrich: Ja, ist eine sehr sehr gute Frage. ich glaube jeder weiß irgendwie, was wie Reliability Engineering ist oder was Operations ist. den IT Betrieb sicherstellen und sicherstellen, dass die Anwendungen alle so funktionieren, wie sie sollen. Auch eine Menge Craftsmanship einfach, ne? Das ist für mich immer noch so eines der der Kern Themen, ne? Ich will ja kein Haus irgendwie aus Holz und Duct Tape bauen, sondern ich will irgendwie wissen, wie proper Engineering, so dass das Ding auch nachher läuft. Und so das als Disziplin, das ist definitiv was was in verschiedensten Formen immer so ein Guiding Theme ist, was sich in vielen Communities auch immer durchzieht. Seit wie Reliability Engineering SRE als diesen Begriff, den gibt’s ungefr seit 2000, also 2014 public, bei Google vielleicht seit 2011 intern und das Buch ist von 2016. Und also dieser dieser …

Sven: Art von Engineering als Disziplin ist ursprünglich eigentlich das Phänomen, dass Google statt tausende System Administratoren einzustellen, um ihre Data Center Operations sicherzustellen und ihre so mal global scale Plattform zu bauen, Software Ingenieure auf diese Operations Probleme gesetzt hat und sehr sehr stark Automatisierung vorangetrieben hat. Sodass also ich meine Borgmon und Borg der, bei bei Google waren ja auch die ersten diese Container Workloads, dann auch die Netflix Plattform auch gemacht haben. Also sozusagen der Vorgänger von Kubernetes ist Borg, ne?

Heinrich: Genau, das ein internes Orchestration Tool. CI/CD war damals bestimmt noch nicht so populär außerhalb von Google und anderen forward looking Unternehmen. Und dieses Movement ist quasi daher entstanden, dass wir, dass wir sagen, wir wir gehen an operational Themen eben mit einer Brille, starke Skalierung, höher Grad an Automatisierung, Reduction of toil und auch einen Ambitionen manche Rollen einfach nicht mehr nötig zu machen. Die haben sehr wenig System Administratoren auf einer modernen Plattform und sehr wenig DBAs. Es sind einfach Sachen, Plattform Capabilities, die so eine automatisierte Plattform zur Verfügung stellt. Und dieser dieser große Trend, dass wir quasi Automatisierung in der Infrastruktur weiter weiter betreiben, der der ist für mich so ein bisschen dieser Kern von SRE. Wir bauen Tools mit Software Ingenieuren um Operations zu automatisieren und zu reduzieren. Gleichzeitig bei Google ist das gepaart mit einer SRE Rolle, die tatsächlich eine große Flotte von Operations Engineers sind, die bei ihnen für den globalen Betrieb von den großen Tools und Cloud Offerings ja und customer facing Tools natürlich auch zur Verfügung steht. Und das ist around the world distributed und da gibt’s hohe Standards, dass ein Tool tatsächlich SRE Support bekommt. Die haben sonst dieses you build it you run it, aber haben eine gewissen Scale on board, die quasi auf diese SRE Operation die, ich glaube, um die 10.000 Mitarbeiter hat, also wirklich eine sehr sehr signifikanter Headcount. Die Frage, was das SRE ist jetzt für mich auch in dem Industrie Kontext, in dem ich mich bewege, ja, wir sind keine bei Zalando sind wir keine Firma mit 10.000 Mitarbeitern, wir haben 3000 Mitarbeiter und wir haben bestimmt keine 10.000 Mitarbeiter oder auch nur 100 Mitarbeiter, die mit auf diese SRE Rolle auf dieser SRE Rolle zu finden sind. Und deswegen ist es für mich wirklich eine eine sehr gute Frage und eine reiche Frage, was ist SRE eigentlich und was welche Praktiken und welche Bedeutung hat das für für uns als Industrie? Und ich denke tatsächlich, dass dieser diese DevOps Ideen mit you build it you run it mit Software Ingenieuren, die für den IT Betrieb zur Verfügung stellen und Automatisierung, die wir im IT Betrieb vorantreiben, dass das so dieser Kern ist als als als Praxis, der auch unter dem SRE Label gut aufgehoben ist. aber man muss auch auch sagen, dass dieses Modell wir haben wir haben diese nein ein großes Operations Team, was on call ist und diese diese Applikationen supported, dass das kein Modell ist, was ich als kopierbar herausgestellt hat. Das sehen wir eben nicht, sondern ist halt eher dieser Spezialisierungs Mix, den Software Ingenieure dann im Zweifel haben, der in diesen Operations Themen tief geht. Ja, also ist nicht kopierbar, ist ein guter Punkt. Meinst, wir kopieren ja immer gerne in der in der IT Industrie. Netflix kommt und sagt wir machen Microservices und dann machen ganz viele Netflix Style Microservices und wundern sich, dass man so in Probleme läuft. und bei SRE, ich bin auch schuldig, ja, das Buch kam raus und habe ich auch gedacht, ah, total super. wir machen jetzt auch wir machen auch ein SRE Team mehr. Und auch Kunden haben gesagt, wir machen ein SRE Team und sind sozusagen so blind rein gelaufen. Irgendwann kam dann ein Buch von vielen Leuten, seeking SRE hieß es und auch der Pionier Rabenstein, der früher mal bei Google war, der hat mal so ein Vortrag gemacht, you are not Google, ja, also man muss halt sehen, welche Organisation ist man. Und entsprechend muss man dann anpassen. Wie war es denn dann bei bei Zalando? Also du bist du bist als Head of SRE eingestiegen?

Sven: Ich bin als Principal eingestiegen, aber dann relativ schnell Head of SRE geworden, ne?

Heinrich: Ja. Und Head of SRE hört sich an nach SRE Organisation. Ja, also so im Prinzip Google nachgebaut oder wie muss ich es mir vorstellen?

Sven: Ja, es ja, also es gibt, ich glaube, fünf verschiedene Arten, wie man SRE so ein bisschen aufstellen kann. Wir waren in einer Phase, wo wir es als zentrales Consulting Team hatten. Wir hatten damals ein Team, das hieß früher einfach SRE Team. Das waren so fünf, sechs Personen und das ist dann zusammen mit den Telemetrie Systemen, die auch von Teams supported wurden, in der Abteilung überführt worden. Also wir hatten dann am Anfang ich habe drei Teams, ein Team, was sich um Log in Logging Systeme gekümmert hat, ein Team, was sich um Matrix und Tracing Systeme gekümmert hat, ein Team, was sich um den Incident Prozess gekümmert hat und dann hatten wir zwei Consulting Teams, ein globales Consulting Team und ein Consulting Team, was sich um den Transactional Bereich gekümmert hat.

Heinrich: Transactional Bereich.

Sven: Das heißt für uns Check out Payments, alles was so, wo es um diesen Payment Flow geht, ja, wo letztlich dieses oder ja, wo Geld im Spiel ist, wo Reliability entsprechend auch einen höheren Business Value hat als z.B. eine Logistik oder am Anfang, wo Offas erstellt werden. Also das war das war die Konstellation, die ich übernommen habe und es kommt aus einer historischen Entwicklung, wo die Teams gerade im Transactional Bereich, also alles was mit Check out Card zusammenhängt, sehr früh erkannt haben, welches große Potential in diesen SRE Geschichten steckt. Und die hatten so ein Grassroot Movement, was sich dann in diesen Teams gebildet hat, und wo es wirklich sehr sehr gute Ingenieure gab, die die Systeme mit aufgebaut haben, die z.B. Distributed Tracing eingeführt haben und Zmorn mit aufgebaut haben, unsere In-House Matrix Datenbank und Monitoring System, wo auch Henning beteiligt war, ein paar Jahre früher. Die haben Innovation getrieben und haben erkannt, wie wichtig ja dieser dieser Automatisierung in dem Bereich ist. Und das ist auch so ein bisschen, glaube ich, immer noch ein ganz typisches Bild, dass Ingenieure, die wirklich an der Front sind, die diese Systeme bauen, die wirklich Load Bearing sind, das beste Verständnis für Operations mitbringen, die auch das Firefighting regelmäßig machen. Und was dann passiert ist, dass die vier, fünf Leute, die diese Stärke hatten, dieses Interesse hatten, dass die irgendwann zu einem Team zusammengeschlossen wurden, um auch das Knowledge weiter zu spreiden. Und dann nachher sind sie noch in den zentrale Abteilung gekommen, die jetzt auch gar nicht mehr so nah an diesen System eigentlich ist. Und genau, da können wir vielleicht dann diese Trade-offs dann auch gleich reingehen, was dann die Vor- und Nachteile sind und wie die Evolution dann weiter gegangen ist.

Heinrich: Ja, also fünf Leute für wie viele wie viele Services habt ihr?

Sven: Wir haben so jetzt 3.000 Services, aber es ist natürlich nicht so, dass diese SREs dann on call sind für alles.

Heinrich: Genau.

Sven: Sondern es ist you build it you run it. Das war bei Zalando damals schon ein dieser operational Modell. Okay, okay, weil also meiner meiner Erinnerung als wir losgelegt haben sozusagen, war ja du hast ein SRE Team und diese SREs die werden praktisch den Teams abgesteilt. Also ich habe jetzt einen halben SRE meines wegen oder ich habe, weil ich besonders kritisch bin, habe ich drei SREs und fünf Entwickler z.B., aber das war bei euch nie der Fall, also es war immer you build it you run it und das SRE Team war sozusagen war halt hat von außen Consulting dann schon immer gemacht.

Heinrich: Genau. Also ich meine, es kam natürlich aus den Ingenieuren, die in den Teams waren und halt auch on call Rollen hatten, insofern, also es waren fünf oder?

Sven: Es waren drei, vier Teams, ja, in denen diese die in diesen Bereich, die diesen Kern gebildet haben, des ersten SRE Teams. Dann gab es ganz weitere Bereiche, wo dieser Trend sich nicht so Fuß gefasst hat, ja. Aber ja, es kam im Prinzip aus einer Community Bewegung, es kam aus vier, fünf Ingenieuren aus dem Bereich, die da wirklich sehr stark waren und auch das Management bei uns dann irgendwann hat, zu sagen da bauen wir ein Team rum, wir müssen auch da Tools weiter entwickeln und die supporten und wir müssen Consulting und Evangelisation machen, Leuten erklären, wie es los funktioniert. Und da gab es genug Substanz, um dann ein Team drum herum zu bauen.

Heinrich: Ja, ich bin trotzdem gerade ein bisschen überrascht, also wenn man ein Team macht, dass so viele andere Teams potentiell unterstützen kann, das fünf Leute hört sich weniger an. Ja, also ich meine, es war auch nicht in der Lage, alle Leute zu supporten, ja, es kam halt erstmal aus dieser Area und man sie natürlich eher lokalisiert in dem Bereich. Und die Tools stehen natürlich allen zur Verfügung und dann wird eben geguckt, wie weit ist die Adoption eigentlich und so weiter. Aber die Idee, dass man dann mit allen Teams gleichzeitig arbeiten kann auf einer high touch Basis, das ist natürlich nie der Fall gewesen. Ja, okay. Okay. Also ihr habt dann sozusagen so ihr habt es gibt eine gewisse App

Sven: …area, also diese Payment System und da gucken wir primär drauf. Für die bauen wir primär unsere Tools. Und wenn der Rest dazu kommt, dann kommt er dazu, aber wir ignorieren, also wir helfen auch, wenn wir Zeit haben, aber im Grunde genommen sind die erstmal außen vor.

Heinrich: Ja, ich meine, wir gucken natürlich jetzt auf so eine dynamische Entwicklung, die sich einfach über einen Zeitraum von sechs, sieben Jahren abgespielt hat. Und als ich dann kam, war wirklich das Modell, wir haben Platform Tools, die wir bereitstellen, unsere Telemetrie Systeme, unser SLO Tooling, unsere Alerting Tools, den allen Entwicklern offen stehen. Da gibt’s Dokumentationen und Enablement Material drum rum. Und dann haben wir ein Consulting Team, was projektgetrieben arbeitet. Das globale Consulting Team. Das kann z.B. sein, wir gehen in einen Bereich rein und räumen die SLO aus, oder wir räumen die SLO auf, oder wir etablieren SLOs zum ersten Mal. Das kann sein, wir helfen On-Call Teams ihre Alerts zu kriegen. Müssen vielleicht noch einmal kurz, wir gehen ja später noch mal auf SLOs ein, aber SLOs sind sozusagen die, vielleicht, kennt, also es kennt ja nicht jeder, sind sozusagen Anforderungen an Verfügbarkeit oder an an Performance, so grob gesagt, die wir einfach tracken.

Sven: Ja.

Heinrich: Genau, ich würd’s einfach Reliability KPIs nennen.

Sven: Okay.

Heinrich: Also, es ist einfach ein KPI, normiert zwischen 0 und 1, der dir sagt, wie reliable war dein Service. Ja. Und dann kannst du natürlich Objectives dran dran dann packen und zu sagen, okay, wie reliable möchte ich denn sein. Aber es ist im Prinzip wie so Business KPIs, die dir einen Top-Down View ermöglichen, ja.

Sven: Okay.

Heinrich: Genau. Und dieses projektgetriebene Arbeiten im Team und das dritte Team hat eben auch ein bisschen mehr mit einem fixen Satz an Teams zusammengearbeitet, war da ner dran. Hat auch teilweise Zeremonien organisiert, die dann regelmäßig stattgefunden haben mit den, mit den Dealern und vielleicht auch in diesem Operational Review Kontext hat ein bisschen anderen Charakter, aber die haben dann auch einfach Datenanalysen gemacht und sich so cross-team um Probleme gekümmert, die für die Teams selber immer zu klein waren, als dass er da Ressourcen für hätten.

Sven: Mhm. Welche Datenanalysen?

Heinrich: Das kann z.B. Bottleneck Geschichten gewesen sein, wie irgendwie ein Load Balancer mit den Sachen umgegangen ist. Das können Incident Patterns sein, wo so ein bisschen geguckt wird, okay, wir haben jetzt hier drei, vier Probleme mit irgendeiner Integration, lass uns mal verstehen, wie funktioniert diese Integration das ein bisschen auseinanderzunehmen und Observability irgendwie Libraries einzubauen.

Sven: Mhm. Solche Themen.

Heinrich: Okay. Ja. Aber ich meine, die Journey ging dann bei uns weiter, dass wir diese Consulting Kapazitäten eigentlich abgebaut haben. Und das kam aus Kostendruck im Wesentlichen. Also Zalando ist aus der Pandemie rausgegangen mit einem relativ stagnierenden Wachstum. Wir kamen aus einer Zeit, wo wir über zehn, zwölf, 15 Jahre mehr zweistellig gewachsen sind, wo einfach sehr viel ausprobiert wurde und Ressourcen auch da waren. Mhm. Und ich bin dann in der Zeit in die Management Verantwortung gekommen, wo wir einfach eine Stagnation hatten und wo auch die Bereitschaft in die Infrastruktur zu investieren einfach deutlich zurückgegangen ist, wo ein bisschen so eine Fokussierung auf die Kernprodukt Themen da war. Und das hat dann, das war nicht wirklich so ein Management Decision, dass wir das jetzt nicht mehr wollen, aber es war einfach die Staffing Situation hat sich einfach so entwickelt, dass wir diese Stellen nicht nachbesetzt haben.

Sven: Okay, okay.

Heinrich: Und es gab auch gleichzeitig Probleme mit diesem Consulting Modell. Also gerade wenn man projektgetrieben arbeitet, eine Sache, die uns mehrfach passiert ist, dass wir einen großen Incident hatten irgendwo. Und dann war allen klar, okay, wir müssen da was tun, lass uns das SRE Team da reinholen und dann machen wir jetzt ein Projekt. Und das Projekt ist dann so drei, vier, fünf Wochen so langsam angelaufen und hat ein bisschen Fahrt aufgenommen, aber dann waren wieder ganz andere Themen wichtig, dann kam irgendwie eine große Kundenintegration, die noch passieren muss und drei, vier andere Sachen. Und dann war so, dass die Teamkapazität von dem Reliability Thema abgezogen. Und als Consultant, wenn du kein Buy-in vom Team hast, kannst du nicht viel machen. Man muss auch sehr vorsichtig sein mit Code Contributions, wenn man nachher nicht Owner von diesem Code ist. Man ändert das immer über und man ist eher so ein bisschen an der Seite und das war eigentlich nie möglich von Consulting Team diese ganzen Projekte einfach eigenständig durchzuführen, sondern das war immer eine Kooperation. Vielleicht mal in einem embedded Kontext, dass man für eine Weile auch in dem Team mitgearbeitet hat, aber es war nie okay, wir liefern was für euch und das ist fertig. Mhm. Und das ist das eine Problem dabei. Und das zweite Problem ist Hiring für diese Rollen. Sobald du ein Consulting Team hast, du musst irgendwie Leute finden, die die das können und das ist extrem hard to find, weil du sehr, sehr großen Spike in Kommunikation und Projektmanagement brauchst und gleichzeitig Software Engineering sehr strong.

Sven: Ja, genau, genau, ja.

Heinrich: Und das dritte, was passiert ist, dass die Teams in dem Consulting sind von den Frontlines wegkommen, weil sie natürlich nicht mehr on call sind, oder nur in Sonderkonstellationen. Und das macht’s dann langfristig schwierig, auch das Know-how, das du vielleicht mal hattest, dann auch wirklich frisch zu halten. Ich erinnere mich, also ich habe nliche Probleme miterlebt. Genau.

Sven: Ja.

Heinrich: Ja. Auf jeden Fall interessant. Also, dass ihr auch ja, Leute embedded habt, Consulting gemacht habt, im Prinzip so aus Team Topologies Sicht habt ihr sozusagen dieses Konzept Enablement Team, ja.

Sven: Ja.

Heinrich: in allen Varianten durchgespielt, kann man fast sagen. Genau, es ist diese diese Enablement Team Idee und ich glaube, dass sie erfolgreich sein kann. Ich glaube, dass sie aber so ein bisschen Rotation erfordert um wirklich erfolgreich zu sein, auch langfristig. Ich denke, es sollte ein Team sein, wo Teammitglieder immer mal wieder ein Softwareentwickler Rollen rein rotieren und dann in die, in die in das Team zurückkommen. Ich glaube, wenn man fünf Jahre in dem Consulting Team ist, das ist schwierig. Ja, ich bin, ich würde mal sagen, vielleicht die letzten fünf Jahre oder so bin ich eigentlich irgendwie immer in einem Enablement Team manchmal so Platform Team noch. Ja. Aber mir fällt, mir fällt’s auch auf, irgendwann bist du zu weit weg vom vom Doing. Also du wir, jetzt bei zwei Kunden haben wir gesagt, wir, wir brauchen selbst irgendeinen Service, den wir betreiben, ja. Weil das ganze Tooling, was wir bauen, wir müssen es ja auch spüren, ja. Wenn du es nicht spürst, dann wie hatten halt so Situationen, Leute kommen und sagen, ah ja hier also so machen wir Pipeline und so weiter. Ja. Und dann am Anfang können wir noch Auskunft geben, aber irgendwann sind diese Teams so weit, ja. Da kommen die mit Fragen und müssen sagen, so weit haben wir nie gedacht, ja. Da ist schon ganz schön abgefahren und da habe ich auch gemerkt, wir sind einfach, wir müssen, also an rotieren haben wir nie gedacht, also einfach bei so einmal vertraglicher Situation dann irgendwie ausgeschlossen haben. Und dann ist es auch schwierig, weil wie du sagst, man muss diese Leute auch finden, die so in Enablement machen wollen und wenn du ich sag mal, wenn ich jetzt sag, hey, ich würde gerne bei euch im Team mitarbeiten, jetzt brauchen wir aber jemand, der aus dem Team rausgeht und sozusagen mit vielen Teams arbeitet. Da haben dann viele dann auch eher keine Lust drauf, ja, dass sie halt sagen, oh nee, lieber also so viel Kommunikation und möchte ich nicht, ja.

Sven: Ja, schwierig, schwierig. Wie habt ihr es gelöst mit der mit der Rotation oder habt ihr es schon gelöst?

Heinrich: Da sind wir nicht hingekommen. Also, wir haben diese Teams einfach abgebaut. Und ja, es ist eher so die Diagnose, wenn ich das noch mal starten würde, wie würde ich hingehen. Weil ich glaube, das für einen super erfolgreichen Startpunkt hatten, wo wir wirklich diese Leute, die eine extrem hohe Kompetenz haben, Frontline Erfahrung, wirklich an den kritischsten Services bei Zalando mitgearbeitet hatten, eine super Reputation und Netzwerk und die konnten dieses Thema einfach tragen und das halt innerhalb von zwei, zwei, drei Jahren tracings auf der gesamten Zalando Plattform ausgerollt, SLOs über die gesamte Business Value Chain, die customer facing Value Chain ausgerollt mit drei, vier Leuten für ganz Zalando. Wahnsinnig high impact und so. Das kann wunderbar funktionieren. Und dann bin ich halt zwei, drei Jahre später gekommen und wir haben irgendwie minimale Fortschritte mit SLOs gemacht und viele von den Projekten sind so ein bisschen versandet, wo dann auch aus Business Sicht ich sage ja, der Business Case für das Team ist nicht mehr so, so stark wie er früher war. Ja. Und das ist keine schlechte Entscheidung zu sagen, okay, wir machen es anders. Das Problem, was sich einfach jetzt ergibt oder die Situation, die sich jetzt ergibt ist, wir hatten ganz viele super Operations Experten verstreut in der Company, die einfach in den Teams arbeiten. Und wir haben teilweise Lösungen für und wir haben ein Platform Team, was auch stark ist, aber was sehr stark auf die Technologien eben fokussiert ist, ne? Die bauen Observability Tools oder die bauen Prozess Tools, aber die sind selber nicht an den Frontlines. Jetzt, was irgendwie Low-Bearing Services angeht und haben dieses, Kommunikation Skillset nicht unbedingt und dieses Enablement Skillset und so nicht nicht so abrufbar. Und wie gehen wir der Situation um auch Cash Constraint, ja? Ich kann irgendwie nicht irgendwie fünf Leute einstellen, um was Neues zu booten. Und wo wir gerade sind, das ist ein Projekt, was wir die letzten zwei Jahre also design haben und jetzt in den ersten Phasen des Rollouts sind. Wir nennen das SA

Sven: Also wir wir wir beobachten, es gibt überall verteilt auf der Company einfach diese world-class SRE Experts, die einfach dieses hands-on Knowledge haben, sie verstehen, wie diese Systeme betrieben werden müssen, um irgendwie sehr gute Reliability Erfolge zu haben. Und haben höchstes technische Proficiency.

Heinrich: und wir haben Redundanzen, also Ineffizienz, weil wir in verschiedenen Domänen dieselben Probleme wieder und wieder lösen, weil dieses Platform Team ist nicht schnell genug diese cutting-edge Themen aufzugreifen. Sie sind eher beschäftigt mit Okay, wir müssen die Plattform weiterentwickeln und haben auch diese Exposure zu diesen Hot Topics gerade nicht. Beispiel z.B. Mobile. Wir haben keinen einzigen iOS Engineer in der Plattform. Natürlich nicht. Aber wie sollen wir denn Observability im Mobile Bereich lösen?

Sven: Ja. Und das ist die Situation und vielleicht nur eingehakt, wenn du sagst neue neue Probleme, also beim

Heinrich: Ja.

Sven: Ich war auch mal Teil von einem Platform Team und ich versuche gerade zu verstehen, ob das nliche Probleme waren. Wir haben halt einfach damals nur sagen können, wir also wir bieten eine Plattform an für ein ziemlich eingeschränktes Problemfeld, sozusagen. Also sagen wir dann, sagen wir im Motto, wir bieten Kubernetes an, wir bieten Pipelines an, Secret Management, Service Templates vielleicht noch alles darum.

Heinrich: Wenn ihr aber z.B. ihr wollt AWS Lambda machen. Sorry, können wir euch nicht unterstützen, ja. Data Pipelines für Data Scientists, sorry, das schaffen wir einfach nicht.

Sven: Ja. Neues heißes Topic kommt, sorry, wir sind irgendwie noch, wir sind mit unserem Kram beschäftigt. Ist das das, was du meinst? Dass sie das neue Themen kommen, aber die neuen Technologien kommen, aber du kannst diese neuen Technologien nicht also nicht in die Plattform integrieren. Kannst keine keine Platform Services z.B. anbieten für sagen mal AWS Lambda oder eventgetriebene Architekturen.

Heinrich: Ja, also ich glaube, es überlappt sich sehr sehr stark, was du beschreibst und was ich beobachte. wir haben mit ZETMON eine relativ alte Codebase und die relativ komplett ist, relativ komplex ist, also mit vielleicht zehn Microservices.

Sven: Ja.

Heinrich: Und die müssen im Wesentlichen gerade neu geschrieben werden in vielen Teilen und einfach auf ein auf ein neues Level gebracht werden. Wir müssen auch von Python 2.7 irgendwann mal runter und das ist alles irgendwie user-contributed Code, tausende, tausende Checks, die ausgeführt werden. Das sind komplizierte Transitioning, Change-Management und Engineering Probleme, die gelöst werden müssen und das Team ist relativ klein. Wir haben jetzt sieben, acht Leute drin und die haben noch eine Menge mehr Aufgaben als sich nur um ZETMON zu kümmern.

Sven: Ja, genau. Ja. So und jetzt Thema Mobile Observability. Wie willst du das überhaupt angehen? Thema Data Operations. Wie willst du das überhaupt angehen? Du hast niemanden, der die Kapa hat in dem Team und du hast niemanden, der die Expertise hat in dem Team. Die kriegen, würden das alle raus kriegen, wenn wir denen ein halbes Jahr Zeit geben würden mit einem Team Embedded zu arbeiten und diese Probleme zu verstehen.

Heinrich: Ja.

Sven: Aber das ist kein Investment, was wir in dem Team machen können. Wir müssen jetzt eher gucken, wie bringen wir die Plattform weiter, die bestehenden Toolset. Wir haben sehr stark produktgetriebenes Platform Engineering, wo wir so unseren auch sehr genau verstehen, was ist so das Need von 90% von unserem Kunden auch immer mehr so onboarding. Das Kunden sind die Entwicklungsteams.

Heinrich: Genau.

Sven: Die inneren Entwicklungsteams, also zweieinhalb tausend captive audience, ne? Aber das ist glaube ich vom Return of Investment eine sehr wichtige und korrekte Priorisierung, dass wir einfach schauen, wie können wir diese User Journeys sauber und frictionless aufsetzen.

Heinrich: Wahrscheinlich der einzige Weg, ja.

Sven: Ja. Also noch noch mal ganz kurz gefragt, also die Platform Teams, also ist wirklich, ist ein Produkt bei euch mit Produktmanager und Ja.

Heinrich: Genau. Also das ist die Idee und das ist auch so ein bisschen die Maturity Scale von einem von der Plattform. Ich glaube, man fängt natürlich immer erstmal an, was zu bauen, dann brauchst du ein wesentlichen Software-Engineer, ne?

Sven: Ja.

Heinrich: Und dann wir haben in vergangenen Jahren relativ viel Produktmanager geleistet, das ist ein bisschen zurück gefahren, aber dieses Mindset ist auf jeden Fall da, dass man das braucht. und ich vergleiche das immer so ein bisschen mit einer Mini-Company, die man in der Company hat. Und letztlich muss man alle die Funktionen aus ausbilden, die eine Company, eine kleine Company auch braucht. Und das ist, was du sofort brauchst, ist immer Engineering und Support. Das sind die die diese Teams kriegen das normalerweise hin. Die Frage wäre dann irgendwann, wann braucht ich denn Customer Success als Organisation? Man braucht dann Support-Engineers, die das Team supporten mit so First-Line Support und so. Ist eine Sache, die man zum gewissen Zeitpunkt vielleicht ausbauen möchte. Und genau und dann dann kommen wir halt auch in diese in diese Fragen mit Produktmanagement und Produktmanagement, ich habe das auch aus der Erfahrung in der Small Company ist nicht zu unterschätzen. Entwickler verlieren sehr sehr schnell so den den das Verständnis für User Experience und sie verlieren auch sehr schnell dieses Verständnis für, wer sind eigentlich meine Kunden, wenn sie es überhaupt jemals gewinnen, weil das einfach eine komplett andere Lebensrealität ist, denn man sich befindet, wenn man immer in den Produkt badet. Und deswegen also wir haben relativ wenig, aber die sind sehr gute Produktmanager einer Plattform ist sein sein Geld wert in Gold.

Sven: Ja. Einfach Interviews machen, den Entwicklern zeigen, wie diese Produktprozesse ablaufen. Die zu strukturieren, den Kontakt zu den zu den Nutzern herstellen, Feature Request priorisieren, sehr sehr wichtig. Ja, wir haben es auch da auf den auf die harte Tour gelernt, dass wir das brauchen. Also auch bei mir ist irgendwie so ein Wir trifft ein bisschen ab, aber als ich mal verstanden habe, wir haben immer über DevEx gesprochen, also Developer Experience und als mir bei mir irgendwann mal der Groschen gefallen ist, DevEx, also das ist UX. Also der Entwickler ist einfach ein User, der braucht vielleicht kein schöne bunte UI, sondern der braucht vernünftiges Kommandozeilen Tool oder Dokumentation und Templates und wie auch immer. Und man kann eine Plattform als Produkt genauso bauen, wie man Zalando als Produkt baut, ja. Ist halt ein bisschen andere also vielleicht ein kleiner Tweak im Denken, aber im Grunde genommen ist es exakt das gleiche. Super analog. Einzig der richtige Unterschied ist, es ist eine captive audience, die können nicht weglaufen. und es ist ein kleinerer Pool in aller Regel, ja. und was ich jetzt gerade noch mal anzukucken, weil das wirklich glaube ich einen einen großes Missverständnis ist was viele Entwickler haben, ne? Wie habe ich Impact als ein Platform Team? Was ich immer sehe ist okay, wir haben Features gebaut und damit sind wir jetzt fertig.

Sven: Das ist ungefr die Hälfte der Arbeit, das Feature zu bauen und die Release Notes vielleicht noch zu schreiben, ja? du hast damit überhaupt keinen Impact und dieses Fehler diesen Fehler habe ich einfach in als als Vendor einfach so oft gemacht. Wir hatten irgendwie eine neue Query Language mit neuen neuen Tools irgendwie fünf, sechs neue Funktionen implementiert, ja. Okay, ich hab’s dokumentiert, ich hab’s eingechecked, so meine Arbeit ist getan. Und dann guckst du, wir hatten noch nicht mal gute Usage Metrics auf den Dingen und guckst du ein halbes Jahr später hin und niemand verwendet das. Und so Okay, hatte ich überhaupt Impact? Nein, ich hatte natürlich überhaupt keinen Impact.

Heinrich: Ja. Und bei Platform ist es genau dasselbe, nur weil du eine tolle Plattform hast, wenn die niemand benutzt, hat das überhaupt keinen Impact.

Sven: Und dann okay, Dokumentation, wie werde ich dann, wenn ich noch ein Tutorial schreibe, ja? Das ist super ekelig. Wow, ich muss irgendwie tippen, ne? Keine Ahnung. Aber das sind dann die Sachen Sales und Marketing und Enablement. Das sind diese Funktionen. Es ist Dissemination, wie erfahren die Leute überhaupt, dass es da ist und dann dieses, wie kann ich sie an die Hand nehmen, damit sie dann wirklich diesen Wert auch kriegen? Dann gibt’s viel Projektmanagement, wo ich einfach sage, da kommt die captive audience ins Spiel, ja? Ich beschließe einfach, wir sind jetzt in zwei Jahren auf 50% und dann treibe ich halt ein Migrations Projekt durch, nämlich im Projektmanagement Bereich. aber ich bin halt einfach viel im Sales und Marketing Bereich. Und die Sachen muss man alle mitdenken. Wenn man nachher Impact haben möchte, dann muss ich immer meine Accountability hört wirklich bei Penetration auf, wo ich den wo ich den Impact wirklich in in der in der gesamten Company getrieben habe und es ist einfach extrem traurig, wenn man nur die Engineeringbrille drauf hat und diese Funktionen, Marketing, Projektmanagement, Sales komplett vergisst, weil die haben auch sehr viel Wert. Ich habe das selten gesehen, dass es Positionen waren, die ausgetauscht wurden, wo man oder spezialisierte Rollen geschaffen hat, einfach Platform Marketing oder sowas.

Heinrich: Ja. Aber das muss irgendwie abgebildet werden. Ja, also mit meiner Kollegin Anja Kammer hatte ich mal ein Vortrag praktisch über diese Journey gemacht, die wir als Produktteam so erlebt haben, also es im Prinzip genau so sehr nlich zu dem was du sagst. Also wir wir wir bauen eine Plattform, also wir haben erstmal ein Problem, ja. Und dann sagen wir, okay, die Lösung ist wir stellen eine Plattform bereit. Dann stellen wir die Features bereit und dann denken wir so, ja niemand nutzt die. Ja und dann denken wir, okay, was können wir machen, dass die Leute die nutzen? Oder wir machen ein bisschen Marketing und Sales und dann machen wir das und dann sehen die Leute, es eigentlich das, was wir brauchen. Und sagen wir okay, jetzt müssen wir vielleicht irgendwie anders daran gehen und mehr sagen mal mehr besseres Requirements Engineering machen und die Sachen mehr rein tragen und dann machen wir das. Und dann wie praktisch dieses ganze Spiel dann läuft und dann merken wir, ah jetzt haben wir hier wieder ein Problem. Wir fangen aber mit einem kleinen Team an, dann funktioniert dieses kleine Team, dann rollen wir es ein bisschen aus und dann gibt’s wieder neue Probleme. Das ist auf jeden Fall ziemlich interessant. Und wir, um noch mal den Schwung zu SRE zu bekommen, also unsere Idee war auch unser Marketing und unser Requirements Engineering.

Sven: haben wir tatsächlich über SAEs gemacht. Also Leute, die in den Teams waren, haben die Probleme gesehen und haben es praktisch zurückgespielt.

Heinrich: Ja.

Sven: Ja, da können wir vielleicht noch mal noch mal einhaken, weil diese SAE Champion Idee, über die wir da vorher schon gesprochen haben, greift doch diesen Gedanken so ein bisschen auf.

Sven: also zum einen, um den, um das gerade noch mal aufzugreifen. Also die Grundsituation war, okay, wir haben keine zentralen Consulting Teams mehr, sondern wir haben diese federated Experts quasi überall und wir haben Redundanz in den Problemen. Und die Idee ist eigentlich sehr simpel. Ich will eine Community schaffen, in dem diese Leute verbunden werden und gemeinsam diese Probleme lösen.

Sven: Und das ist kein keine Team Basis fulltime, sondern es ist peer exchange und einfach Austausch. Und es sind vielleicht kleinere Projekte, die sich vielleicht innerhalb von sechs Wochen abbilden lassen, wo man sagt, okay, man steckt jetzt die Köpfe zusammen und baut jetzt was zusammen.

Heinrich: Aha, okay, okay. Also so initial habe ich gesagt, es ist eine Community of Practice.

Heinrich: Ja.

(Sven) aber es ist, also mein Verständnis von Community of Practice ist, Leute sind in Feature Teams.

(Heinrich) Ja.

(Sven) Ja. Und wir sind verantwortlich in den Feature Teams. Also wir sind die Champions für SAE. Wir ja, wir kennen uns damit aus und wir unterhalten uns untereinander. Was wir gerade so machen, versuchen auch so ein bisschen ich sag mal so, gemeinsame Prinzipien auszuarbeiten und so weiter. Aber hier ist anders. Die Leute kriegen tatsächlich mehr Zeit, um gemeinsam z.B. Tooling zu bauen.

(Heinrich) Ja, das ist Teil der Idee. Also wir wollen Innovation treiben. Wir wollen auch genug Momentum und Sponsorship dahinter kriegen, dass wir z.B. so ein Thema wie Data Operations auf ein neues Level kriegen.

(Heinrich) Ja.

(Sven) Und für jedes Team ist das Investment einfach viel zu groß. Die können irgendwie keinen Data ETL Tool bauen.

(Heinrich) Genau.

(Sven) Sondern ja, die bauen halt irgendwie ein Consortium und der macht halt irgendwas. Und da ist dann, ich meine, man kann noch mit Freelancern arbeiten und Resource Pooling machen von verschiedenen Organisationen. Aber man kann auch einfach sagen, okay, man hat drei, vier Ingenieure, die einfach an einem nlichen Thema arbeiten, dass uns die mal zusammenbringen. Lass uns überhaupt mal einen Strategie Workshop machen. Was sind denn im Data Bereich jetzt die großen Themen, die wir sehen?

(Sven) da die Stakeholder zusammenzubringen und all das sind Diskussionen, die wir über dieses SAE Champions Programm hoffen und diese diese Sachen abbilden. Und also eine eine Sache, die ich bei Communities of Practice immer oft gesehen habe, das ist so eine, okay, wir unterhalten uns mal, ja? Das ist ein Chatraum, wo unstrukturierte Diskussionen stattfinden und das ist nicht so zielorientiert. Und ich meine, ich kann nicht behaupten, dass das alles, dass wir das alles rausgefunden haben, oder dass das ist was man jetzt einfach als Konzept kopieren kann. Aber ich glaube, dass die grundlegenden Überlegungen sound sind und die die Prinzipien oder die diese Gains holbar und real da sind. Also Resource Pooling Orientierung Strategie, wie ich quasi welche Themen ich jetzt als Company angehen möchte und ja, und dann dieses output-driven Vorg, wir haben, wenn du als SAE Champion onboarden möchtest, das Prinzip, dass du immer ein deliverable brauchst. Du musst immer irgendwas selber machen. Du bist nicht nur so, okay, ich will mal gerne dabei sein und da mich zu dem Ding ein, sondern es ist du commitest dich, dass du eine operational Improvement sei es jetzt bei dir lokal oder vielleicht auch contribtest zu einem zentralen Tool. die musst du einfach selber machen und dann kriegst du eine Eintrittkarte für ein Jahr in diese Community. Und der Deal ist, ja, du kriegt best Company Support. Wenn du in die Community eintrittst, werden wir alle Hebel in Bewegung setzen, dass die Top Experten, die wir companyweit haben, auf diesem Thema mit dir sprechen und dich supporten, dass du dein deliverable möglichst schnell und frictionless durchgibst.

(Heinrich) Okay, ja.

(Sven) Und umgekehrt, wenn du Teil der Community wirst, commitest du dich anderen in nlicher Form zu helfen und wenn wir best practices Dokumentation schreiben oder Tools schreiben zu contributieren.

(Heinrich) Ja, ich muss sagen, also ich bin begeistert und sag wunderbar out-of-the-box gedacht, ja? Also, weil ich ich guck mir halt die Möglichkeiten an, die es gibt und denk dann okay, wenn man so eine eine Community of Practice funktioniert so oder es gibt unterschiedliche Möglichkeiten, ja? Und denk okay, dann diese Variante ist die ideale für uns. Aber wir sind z.B. nie so auf die Idee gekommen, das mal so ein bisschen aufzubrechen, so wie du es jetzt beschreibst, ja. Also ich find’s ganz finde wirklich ziemlich interessant. Also, ich sag jetzt nicht, ich bin copycat, aber ich versuche es einfach mal aus in dem Kontext, wo es funktioniert, weil ja, ich denke also man kann davon mir, der ist bei ING Niederland, und die fahren sehr starken Ansatz mit Community of Practice und die sagen halt auch, also das was du sagst, es ist es bringt nichts, wenn man sich einfach nur trifft und sich irgendwie austauscht oder so. Also dann dann dann besser als nichts, ja? Aber im Grunde genommen mal kommen Leute, mal kommen Leute nicht, es ist sehr lose, wie gesagt, ist besser als nichts, ja, ist schon eine gute Idee, aber wenn du wirklich einen outcome haben willst, dann muss du sozusagen bonus relevant sein. Da muss jemand irgendwie eine Unterschrift setzen und sagen, die Leute stelle ich ab. Diese Person ist der Leader von diesem Ding, ja, und der sorgt dafür, dass das irgendwie läuft, ja. Also die Meetings sind immer da, die Vision ist da, die deliverables sind da, aber du hast halt nur so ein kleinen also da dran habe ich mich auch immer so ein bisschen orientiert. Ja, ich sag okay, wie die es machen ist eigentlich, also so so nlich muss es auch laufen. Aber auf die Idee zu kommen, wir haben hier mal ein bisschen mehr zu tun und jetzt ziehen wir uns noch mal so zusammen um jetzt vielleicht nicht mehr gut 95 % in unserem Projekt zu arbeiten, sondern nur noch 50 und 50 % im SAE Team, also in der SAE Champion Gruppe, finde ich auf jeden Fall interessante Gedanken, ja. Also eine Sache, die wirklich gut funktioniert hat, war am Anfang des Jahres hatten wir so ein Focus Thema Data schon mal für uns identifiziert. Und da hat unser VP of Engineering gesagt, so, wir wollen jetzt da ein paar Sachen aufräumen, vor allen Dingen SLOs irgendwie hin kriegen und Strema Valdierungs Sachen. Und der wollte das mit Deadlines haben, ja, und dann das war so ein so ein Pilotprojekt, wo wir das mal ausprobiert haben und das hat eine ganze Weile so an Überzeugungarbeit und so dieses diese diese Zeremonien mal irgendwie aufzubauen, ein bisschen gedauert, aber letztlich haben wir die Maschine ans laufen kriegt und dann quasi so rund 20 kleinere Reliability Improvements im einem Zeitraum von einem halben Jahr wirklich einfach implementiert kriegt. Und das war dann wirklich auch so ein Tracker, wo wir deliverables dann irgendwie hatten, die verschiedenen Teams sich committed hatten und wir haben dann erst erst mal einen biweekly Reporting Cycle aufgespannt, wo wir jedes Mal an eine Gruppe von 15, 16 Direktoren diesen, diesen Report geschrieben haben und mit der Visibility kam eben auch das Sponsorship, weil keiner der Direktoren wollte auch aus seinem Bereich so ein bisschen zurückfallen. und ja, ein bisschen der Zug zum Tor, ne? Man wollte irgendwie fertig werden mit dem Zeug. Und das ist eine Sache, die wir dann in diesem SAE Champion Kontext auch kopieren. Also jeder SAE Champion, wie gesagt, ist mit seinem deliverable dabei und wir reporten einmal im Monat jetzt einfach auf den Status von den deliverables. Und das hat zwei Funktionen, einmal natürlich irgendwie Attention und Sponsorship, dass die Sachen nicht einschlafen, da gibt’s irgendwie so eine Ampel ob wir genug Ressourcen haben oder nicht. und gleichzeitig auch Awareness und Opportunity für andere, die vielleicht sagen, hey, okay, wir haben in unserem Bereich sollten wir auch mal gucken, ob wir nicht das irgendwie machen und guck mal, die haben das doch gerade, die machen das doch gerade. Guck mal, ich spreche mal mit dem und guck irgendwie ob das was für mich ist. Und so diese diesen Effekt wollen wir gerne haben und erzeugen einfach durch diese dieses Reporting Geschichten. Und dass ich gerade noch mal über diese weekly reliability, weekly operational Review Meetings sprechen, weil das in dem Kontext auch relevant ist. Also wir haben unter anderem ein weekly operational Review Meeting jeden Mittwochmorgen auf Direktor Level, wo also zalando techweit alle Organisationen vertreten sind auch mit ihrem Leader. Und da gucken wir eben systematisch um auf auf Reliability Themen. Und da passieren zwei Sachen. Zum einen haben wir also eine Liste von Incidents, die passiert sind und wir fragen uns immer, was sind Patterns, die wir sehen. und da sind unsere executive principals am aktivsten die scannen diese Incidents durch auch mit dem Kontext, okay, was ist in den letzten Monaten alles passiert und was sind so Focus Themen, die wir irgendwie haben. Und die Idee ist, dass wir mit dem SAE Champions Programm einen Angel haben, um diese Patterns wirklich zu adressieren. Also, wenn wir jetzt irgendwie merken, hey, zum fünften Mal irgendwie Data oder Mobile oder irgendwelche Schema Fragen oder Datenbank Pools, dass wir dann wirklich auch crossorganisationsmäßig zusammenarbeiten. Wie können wir diesen Problem auf den Grund geben.

(Sven) Und dann haben wir wieder diese Reporting Loops, wenn dann wir erst du ganz natürlich in dieses Meeting reporten irgendwie jeden Monat oder wenn es fertig ist, ne, was haben wir denn gemacht und du kannst solche sponsorie Probleme. So wie groß ist das Problem eigentlich, ja? Wie viel Ressourcen brauche ich, um es zu lösen? Ist uns das wert? Was ist quasi jede Organisation, die das betrifft, bereit zu geben, ja? Haben wir vielleicht in der Organisation mit 100 Leuten, eine halbe FTE die wir davon abstellen können. Das ist schon eine Frage auf dem Level werden viele Sachen machbar. Wenn du mit einem Team sprichst und sagst, kann ich irgendwie eine halbe FTE von euch haben.

(Heinrich) Genau.

(Sven) Das klappt dann. Ja. Ja. Ja.

(Sven) Und also ich will nicht behaupten, dass die ganzen Sachen alle bereits rundlaufen. Wir haben vielleicht jetzt so zehn Working Groups, wir haben so vielleicht 30 Ingenieure, die da mitmachen aktuell. Noch nicht diesen Snowball Effekt, dass wir eine gute Prozentsatz von unseren Ingenieuren enrolled hätten, aber wir haben das Programm auch im Juni erst gestartet und ich denke es ist vielleicht auch gar nicht schlecht, den Scope erstmal kleiner zu lassen und vielleicht uns auf diesen Datenbereich zu fokussieren, um das einfach auch zu verstehen, wir müssen diese Social Dynamics ablaufen, weil das ist so ein Multi- Multi-Stakeholder Problem, wo quasi jeder muss irgendwie was davon haben, wenn man nichts davon habt, schläft’s irgendwie ein. Und gerade merken wir noch, dass wir diese diese SEA Champion Rolle einfach besser verkaufen müssen und die attraktiver machen für die individuellen Contributors von die Ingenieure, dass wir so eine Gravity dahin kriegen, hey, ich will da irgendwie dabei sein und machen spannende Sachen da. Und das auch für den Karrierepfad eben interessant ist, ne?

(Heinrich) Mhm.

(Sven) Ich denke es ist alles möglich, aber es ist , das sind so diese dieses Feintuning was wir hinbekommen müssen.

(Heinrich) Ja, wenn man schon mal beim Feintuning. Also man muss erstmal dahin kommen, dass das Feintuning überhaupt interessant wird. Also ich finde schon interessant, dass ihr diese das bei euch schon läuft mit diesen weekly operational review, was so gut läuft. Weil wir

(Sven) ich hätte jetzt auch gesagt, so vor fünf sechs Jahren habe ich zum ersten Mal davon gehört bei AWS, also ich hab so ein paar Spione bei AWS und und aber bei AWS macht’s ja genauso, ja? Also die haben auch diese weekly review meetings und es wird sehr unangenehm, wenn du da zum zweiten, dritten Mal sitzt als als Teamlead oder Director und muss halt schon wieder irgendwie schlechte schlechte Zahlen sozusagen liefern. Dieser Peer Pressure. Und ich fand es auch eine gute Idee bei bei zwei Kunden, dass wir versuchen sowas zu sowas nliches zusammenzubauen. Also Copycat ist immer so ein bisschen schwer, aber so die Idee wie können wir es, wie können wir es so

(Heinrich) Ja.

(Sven) wie können wir überhaupt zum zum Fliegen bekommen. Also dass das ein Thema ist, dass alle also das ist jetzt alle interessieren, es vielleicht ein bisschen zu viel, ja, aber dass wir sowas nliches haben, wo dieses Thema Reliability wöchentlich oder bei uns jetzt eher monatlich ja auf den Tisch kommt. Ja.

(Sven) Ist eigentlich bei allen Gelegenheiten froh, weil es gibt immer in jedem Unternehmen gibt’s immer irgendwelche großen Probleme, ja, bei manchen funktioniert’s nicht, weil du hast keine Entscheidung, weil du kannst keine Entscheidungen treffen, weil die die Incentives fehlen für die Leute, ja. Also ich bin Produktmanager und mir ist Reliability egal. Okay, dann muss ich jetzt ab nächstem Jahr sind die Bonusregelungen anders, dann ist die Reliability nicht mehr egal. Und überhaupt sowas mal ans Fliegen zu kommen, das fand ich schon immer schwierig genug, ja, dass das überhaupt so läuft.

(Heinrich) Ja.

(Sven) , lass mich zwei Sachen dazu sagen. Also zum einen die Zaland interne Story, wir wollten dieses Ding glaube ich seit sieben acht Jahren machen und als kleinere Organisation, wenn du irgendwie als Head of Engineering kommst und irgendwie zum VP läufst. Ich hätte gerne, dass du dich jedes jede Woche mit all deinen Direktoren eine Stunde hinsetzt und über Reliability sprichst. Dann sagt er auch junge, das diesen Wunsch haben glaube ich viele für ihren Bereich, ja. Und das wird nicht fliegen, wenn der VP nicht genau versteht, was die was der Benefit daran ist und warum das wichtig ist. Die zweite Sache, würde ich einfach so ein Stück einfach noch mal zurück gehen und einfach so über die Dynamiken von Engineering Organisationen und die Incentives sprechen und typischerweise, ich glaube auch korrekterweise ist immer sehr viel Incentive auf Produkt und Business Value, den man irgendwie am Customer produziert auch aus gutem Grund. Also das Business generiert Geld, ist letztendlich darum wo es geht. wenn man das jetzt auf extrem betreibt, dass man quasi sagt okay, Feature Delivery ohne Kompromisse move fast and break things. wo kommt so dieser dieser forcing Faktor? Wo kommt die Balance zustande, ja? Und das sind zwei zwei Aspekte. Der erste Aspekt ist Reliability. Sobald mir zu viel um die Ohren fliegt, wird diese diese Strategie nicht mehr funktionieren. Das heißt zu irgendeinem Zeitpunkt muss Management sich auch mit Reliability befassen.

(Heinrich) Mhm.

(Sven) Ein zweiter Punkt ist Technical Depth und vielleicht Engineering Excellence as a whole. Man schaufelt sich einfach ein immer größeres Problem, wenn man alles nur mit dem heißen Nagelstrick und nie konsolidiert. Und das denke ich, das sind Themen, die alle Managementebenen zu gewissem Grad verstehen müssen. Die müssen verstehen, wie viel Technical Depth habe ich gerade und wie ist meine Reliability. Und die müssen in der Lage sein diesen Tradeoff zu navigieren. und das ist Kernaufgabe fürs Management. Und ich denke, dass es eine Diskussion, die man auch mit Senior Management haben sollte, ist, wie möchte ihr, dass eure Management Chain damit umgeht. Und eine Antwort, die man bei Reliability zumindest objekt, also implizit häufiger kriegt ist: Na ja, das sollen die Teams machen. Es gibt irgendwie viele Sachen, über die sich vielleicht Senior Management irgendwann keine Gedanken mehr machen will, die man sich ums Produkt kümmern. Und ich glaube bei Reliability ist das was, was nicht unbedingt funktioniert, wenn du es wirklich nur auf Team Ebene siehst, weil auch viele der Investments einfach über längere Zeiträume sind, auch wie Paydown of technical depths. das kann man nicht nur in einem ganz kleinen Kreis beantworten, sondern es geht’s ein bisschen auch um Strategie Fragen.

(Heinrich) Mhm.

(Sven) Meinst du, also uns fällt’s jetzt gerade wieder auf. Es ist Reliability wir können als als Team den Service bereit stellen, wir sind ja auch wir können ja nur so verfügbar sein, wie unsere Dependensies verfügbar sind. Und wenn diese, also wenn ich keine Möglichkeit habe auch auf ich sag mal problematische Dependencies einzuwirken, dann habe ich immer ein Problem, ja. Also

(Heinrich) Ja.

(Sven) und deswegen finde ich auch gut, dass man als Firma sagt: Uns ist das wichtig. Wir wollen gesamt. Wir bieten ein wir bieten ein super teures Produkt an, ein Luxusprodukt. Also hatten wir jetzt bei einem Kunden, wir haben ganz tolle Produkte, ja, was Hardware angeht, aber Software, da denken wir irgendwie noch nicht so. Wir müssen, wir denken jetzt Software auch in dieser Exzellenz und dafür müssen müssen sich alle ver Verantwortlich fühlen. Ja, weil wir hatten halt auch immer gefragt, also irgendeiner muss sich doch für das gesamte verantwortlich fühlen, damit es hier funktioniert. Immer nur auf unseren Inseln wird’s dann funktionieren, ja.

(Heinrich) Ja.

(Sven) Ja, also ich meine als kleiner Ingenieur oder als Consulting Firma, wird man die ganz großen Incentive Strukturen oft nicht beeinflussen können, aber letztlich glaube ich, dass Firmen das lösen müssen. Und das ist eine der Kernaufgaben auch von von von Senior Management diese Accountability Boundaries sinnvoll zu setzen. Und was wir ja irgendwie durch Agil gelernt haben ist, dass Accountability die die entlang der Software Delivery Delivery Chain gebrochen ist einfach nicht funktioniert. Du kannst keine Softwarearchitekt Abteilungen haben, mit der separate Reporting Line von den Entwicklern, mit der separate Reporting Line von den Operations Folks. Wenn du das machst, dann fällt’s einfach komplett auseinander. Genau, sondern dass der einzige Weg, der mir sinnvoll erschienen ist, ist end-to-end Ownership entlang von Product Experience, wo du einfach sagst okay, dieser VP ist quasi oder ist end-to-end verantwortlich für die Product, ja, Experience von diesem Teil der User Experience. Und da gehört natürlich Reliability auch dazu. Da gehört also alle Features und Velocity und so weiter natürlich auch und natürlich hast du viele Dependensies, die quasi verstreut sind, aber das ist dann ein Stakeholder Management Problem. Wo du irgendwie sagst okay teilweise habe ich mit Vendors, den ich arbeite, wo ich Teile meiner Funktionalität herkriege dann muss ich halt gucken mit Vendor Negotiations, ob ich meine SLAs und meinen Preis und meine Performance kriege, die ich brauche. Genauso muss ich mit internen Teams gucken, kann ich den Service verwenden, kann ich einen anderen Service verwenden. Sind die in der Lage, wenn sie das einzige Team ist, mir diesen Service zu bieten? Falls nein, wie muss ich dieses Team supporten, damit es das hinbekommt? Mit wem muss ich reden, damit die entsprechend gestafft werden? Das ist letztendlich alles in deiner Verantwortung und das ist Aufgabe von Senior Management diese diese Balancing irgendwo hinzukriegen.

(Sven) Also ich denke, dass, weil du eben Technical Depth erwnt hast. ich finde bei Technical Depth war’s das war ja auch lange Zeit war’s so eine Sache, wo die Leute gesagt haben, es interessiert mich nicht, programmierst du einfach richtig, ja, oder es mir egal.

(Heinrich) Ja.

(Sven) Und irgendwann macht’s halt, also irgendwann knurrst ziemlich heftig. Und dann, also ich habe das Gefühl die letzten Jahre ist diese Idee von Technical Depth Management

(Podcast Einleitung)

Sven: …die läuft einfach viel besser, ja, als meine wegen noch vor zehn Jahren. Ja.

Heinrich: Ja.

Sven: Und bei Reliability, , dass man das ein bisschen strukturierter angeht, also vielleicht vor zehn, fünfzehn Jahren haben die Leute auch gesagt, programmiert doch einfach so, dass funktioniert, ne, dass immer funktioniert.

Heinrich: Ja.

Sven: Und hier habe ich aber jetzt auch das Gefühl, dass die Leute merken, das ist Teil von UX, ja. Also es ist Teil oder CX, Customer Experience, ich muss mich da drum kümmern.

Heinrich: Ja.

Sven: , ich kann’s den, ich sag mal, den individuellen Teams überlassen, ja, das muss so company-wide Fokus sein. Ja.

Heinrich: Ja.

Sven: Ja, also ich meine, du willst letztlich ökonomische Entscheidungen treffen. , es gibt Systeme, die sind perfekt reliable, Motor Steuerung z.B. oder irgendwie Düsen Jet F16 oder F15, Firmware die in solchen Sachen drin ist, die sind natürlich ohne Ende reliable, wo auch Menschenleben dranhängen.

Heinrich: Mhm.

Sven: Was natürlich extrem viel Geld kostet, aber du musst es machen. Ja. Jeder Ja, jeder

Heinrich: Ja, ja.

Sven: Pup kostet extrem viel Geld, ja, kein keine gute Art und Weise Software zu bauen für E-Commerce, keine gute Art und Weise irgendwelche Intranets zu bauen mit diesem Standard von Software Engineering.

Heinrich: Ja.

Sven: Und , es ist was hingegen eine sehr productive Art und Weise, es ist einfach ein Perl script auf einen CGI Ordner zu werfen und einfach ein Problem zu lösen, oder wie lange Zeit irgendwie ich glaube, ein Teil der europäischen Aviation Traffics irgendwie durch eine durch eine Emacs Instanz gelaufen ist, weil irgendeinen Hacker irgendwie in Emacs so ein weiß ich Flight Scheduling oder Dings Tool gebaut hat, was irgendwie ewig lang verwendet wurde. Good enough, fast, high value. Also so wollen wir das. Ja, wir wollen Fucking dirty, auf Deutsch, Value for the Customer. das ist the economic decision making.

Heinrich: Ja.

Sven: Irgendwann kommt halt die Frage Reliability, Technical Debt und dann halt auch Engineering dadurch, so dieses Engineering Excellence Thema, weil jeder weiß irgendwie, dass auf einem Server ein Emacs Programm laufen lassen mit irgendwie Emacs Lisp, was niemand maintainen kann, dass das auf Dauer nicht funktionieren kann, irgendwann muss ich daran und das neu schreiben auf einem auf einem Static Typing, Typing and Unit Testing und irgendwie einem anderen Qualitätsstandard.

Sven: Und ich glaube, dass man immer diesen Balancing Act machen muss in einem Softwareunternehmen, dass man immer versteht, muss ich gerade schnell, muss ich gerade konsolidieren, auch wenn ich welche Growth Rate ich gerade habe, wir schwenken bei Zalando halt von High Growth auf auf jetzt eher flaches Growth, und das ist natürlich eine Zeit, wo man Effizienzen holt, wo man Sachen nochmal rearchitected oder vielleicht sich Innovation treibt und neue Märkte erschließt, aber ein bisschen mit einem anderen Approach, als wenn ich einfach okay, VC Money ist not an issue or money is not an issue, just grab the market, ja.

Heinrich: Ja.

Sven: Ja, ich sag mal, klar, es ist immer unterschiedliches, also Engineering funktioniert unterschiedlich, wenn ich jetzt irgendwie schon in einer gesättigten Product Organisation bin oder ob ich noch überhaupt ein Product-Product Market Fit finden will, ja, also da, da ist immer ist immer ein bisschen anders.

Sven: Okay, , lass uns da gerade noch mal ein bisschen länger bleiben, weil jetzt ist dieses Thema warm und wie etabliere ich das. , die die grundlegende Frage, die man sich stellen muss, ist, wenn man jetzt versteht, dass Engineering Management im Prinzip ein Balancing Act ist, ne? Die Frage ist, wie enable ich das Management diesen Balancing Act effizient auszuführen und tatsächlich das Problem, was Mittel- und Senior Management hat, dass sie einfach blind sind, was Operations angeht. Die kriegen vielleicht den Mega Incident mit, aber die haben kein High Level Verständnis, wie Reliability aussieht, weil sie einfach nicht in diesen Teams drin sind, bei einem gewissen Scale schaffst du es einfach nicht mehr selbst, wenn du es willst. Und , was man wenn man jetzt operational practices verbessern möchte, auch global in der Company, verstehen muss, ist, wie kannst du dein Management enable, mehr Sichtbarkeit zu haben auf diesen Themen. Und das ist wo SLOs ins Spiel kommen, einfach als KPIs, die wie du so ein Business KPI wie du den reportet, auch am besten automatisch gemessen, das ist wohl der Incident Prozess mit auch geschriebenen Postmortems ganz wichtig werden, die eine gewisse Qualität haben und einen gewissen Standard, so dass das Management die lesen kann, und vielleicht später auch Vice-Management und solche Sachen. Und ja, das muss dann nachher nicht in einem unbedingt in einem Report zusammengefasst werden, das muss nicht unbedingt ein Dashboard sein, das muss nicht unbedingt ein weekly operational Video Meeting sein, sondern da würde ich wirklich gucken, welche Zeremonien funktionieren in der Company, wo hast du willingness auf welchen Management Layer auch immer in diese Themen reinzugucken und welche Feedback Loops bieten sich quasi an, wo kann ich vielleicht, wo gibt’s schon ein Business Review Meeting, wo ich vielleicht zehn Minuten dranhängen kann, um um Reliability Review noch zu machen. Und eine Sache, die bei uns mega erfolgreich war, die wir wirklich gelernt haben, ist, wir haben einen automatisiertes Reporting Format entwickelt für diese Reliability Themen, was wir an alle Management Ebenen jede Woche tatsächlich zirkulieren, und das ist kein PDF Report irgendwie in einer Email hängt, sondern es ist ein Google Doc, was bei Zalando standardmäßig verwendet wird, um Meetings zu treiben. Du kannst mit diesem automatischen Report einfach einen Meeting aufsetzen und sagen, wir lesen den Report zusammen und sprechen darüber, und du hast ein gutes Review Meeting. das sind alle Informationen zusammengeetragen und das enable einfach dieses layering auf sehr elegante Art und Weise und skalierbare Art und Weise, und ich denke, dass es eine eine Trajectory, die ich auf jeden Fall empfehlen würde, wenn man jetzt als Consultant oder auch einfach als Engineer, der da Interesse dran hat, der Company zu helfen, da würde ich so einsteigen, versuchen diese Reliability Messungen zu automatisieren, versuchen den Incident Prozess zu verbessern und dann diese Awareness zu schaffen in irgendeiner Form, natürlich auf der höchsten Management Ebene, die dir zuhört, ja, also…

Heinrich: Ja.

Sven: Ja, also bei uns, also bei einem früheren Kunden war tatsächlich so, da hat einer der, zumindest mal der, ich sag mal, der Chief, war der Chief Digital Officer auf jeden Fall im im technischen Bereich einer der der Top Dogs. Also der wollte tatsächlich auch immer regelmäßig diese Reports haben, ne.

Heinrich: Ja.

Sven: , der hat die eingefordert. Jetzt bei einem anderen Kunden, probieren wir, im Grunde genommen so, das was nliches was du gesagt hast, es gibt da schon Management Meeting und da sagen wir einfach, wir reservieren X Minuten. Also kommt natürlich immer drauf an, manchmal guckt man drauf, also X Minuten sind für Reliability eben reserviert, manchmal guckst du drauf, alles grün. Ja, manchmal guckst du drauf und sagst so wie im Moment. Ja, so kann’s weitergehen, ja. Also wir haben jetzt zu große Probleme, und ich glaube auch das ist relativ, wir sind noch nicht so automatisiert, weil Automatisierung kostet natürlich auch Zeit und Geld. , so semi-automatisierte, aber ich denke auch, dass so ein Low-Level Einstiegspunkt.

Sven: Ich gucke gerade auf die Uhr. , wir haben schon ordentlich Zeit hinter uns gebracht im positiven Sinn. Es gibt noch so viele Themen, über die man sprechen könnte. , ich würde sagen, wir machen einfach noch mal einen weiteren Podcast, vielleicht ein bisschen technischeren Podcast würden wir dann vielleicht bei Case publizieren, also Case is conversation about Software Engineering, ist wahrscheinlich da kann man ein bisschen tiefer in die Technik gehen.

Heinrich: Alles klar.

Heinrich: Gut, wunderbar. Ich fand’s total spannend. Ich hoffe die hat Spaß gemacht. Ich hoffe allen Zuhörern, die zugehört haben, sind auch so gebannt, ja. Einblicke in die in die SRE Welt bei Zalando, super spannend. Vielen Dank. Ja, danke dir sehr. Hat großen Spaß gemacht. Ciao.

Sven: Ciao, ciao.