Case Study: digitale Transformation der Metro

Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Innovate or Die Podcast von Digitalkompakt. Mein Name ist Joel Kaczmarek und in der heutigen Folge wirst du mitnehmen, wie die Metro als super spannendes, großes Unternehmen seine eigene Digitalisierung stemmt. Das heißt, wir machen heute mal so eine kleine Folge, wo wir das, was wir bisher mit dem guten Boris Lokschin schon alles aufgearbeitet haben, mal in der Praxis anwenden. Und als besonderen Bonus haben wir einen Live-Mitschnitt von unserem Panel, was wir, Boris und ich, auf dem DCD zusammen mit dem Nils gemacht haben. Der ist bei der Metro der Domain-Owner. Da haben wir schon ganz viel über die Praxis gesprochen und weil wir einen noch breiteren Blick haben wollten, haben wir heute den Timo sitzen, der als CDO von der Metro, glaube ich, auch einen super spannenden Blick hat. Also, du wirst heute vollgestopft mit Wissen über KPIs, über Agilität, wie mache ich das, IT-Org-Charts und Co. So, wenn ich Leute jetzt nicht heiß gemacht habe, weiß ich auch nicht, aber first things first. Hallo lieber Boris, schön, dass du mit dabei bist.

Boris Lokschin: Hallo.

Joel Kaczmarek: Was hast du denn für Berührungspunkte zur Metro, by the way?

Boris Lokschin: Wir arbeiten zusammen mit der Metronom an einem super spannenden Projekt. Einfach so eine Kombination aus vielem, was wir in den vorigen Folgen auch besprochen haben, wo das, was sozusagen Timo und sein Team versuchen, in die Organisation zu bringen, an agiler Methodik, Org-Chart, kombiniert wird jetzt auch nochmal mit der Technologie, mit dem Spiker-Commerce-OS, was wir dazugeben für das Traders-Business, was ein ganz spannender Business-Bereich ist

Joel Kaczmarek: bei der Metronom. Bist du ein bisschen biased oder darfst du trotzdem auch mal kritisch bis sich nachfragen?

Boris Lokschin: Ich probiere es.

Joel Kaczmarek: Gut, so, jetzt haben wir schon ganz viel das Wort Metro fallen lassen. Lieber Timo, herzlich willkommen, schön, dass du da bist. Erzähl doch mal ein bisschen was über dich. Was bist du für ein Typ? Wo kommst du her? Was machst du eigentlich? Wir sind neugierig auf dich.

Timo Saldsieder: Gut, ja, Timo Saldsieder. Ich bin der ganz schlimme Titel CIO, CSO. Das steht für Chief Information Officer und Chief Solution Officer, wobei mir das CSO besser gefällt, weil ich nämlich für Product, User Experience und Engineering zuständig bin bei der Metro. Das heißt, knapp zweieinhalbtausend Mitarbeiter in dem Bereich an acht Standorten weltweit. Also relativ große Unit, die wir da im Hintergrund mitfahren. Hintergrund ist, wie es für einen Informatiker gehört, Informatikstudium. Ganz klassisch, dann diverse Stationen in Deutschland gehabt und dann auch das Payback-System mit aufgebaut. Zusätzlich noch größere E-Commerce-Shops gebaut in den letzten Jahren, bevor ich zum Metro ging. Bei der Burda-Gruppe tätig gewesen, da so Companies mit in der Betreuung gehabt, wie eine Holiday-Check oder Elite-Partner mit begleitet als CTO. Und wie gesagt, jetzt seit knapp zwei Jahren in dieser Rolle bei der Metro.

Joel Kaczmarek: Und? Kinder? Teure Autos?

Timo Saldsieder: Kein tolles Auto. Im Gegenteil, ich versuche irgendwie günstig von A nach B zu kommen. Kinder zwei Stück. Ja, glücklich verheiratet, Frau. Und ich versuche Hotel zu sprengen, bin Schwabe. Was glaube ich in Berlin schwierig ist, wenn ich es richtig im Hinterkopf habe.

Joel Kaczmarek: Ja, erlebe ich auch immer. Gehen mir freche Busse auch rumfahren. Anyway, okay, wir lernen. Ein bodenständiger Mensch mit schon viel Erfahrung in der Branche, sehr sympathisch. Was ist denn so genau deine Aufgabe? Ich habe es dir erstmal konkret falsch vorgestellt. Du bist CDO, sondern du bist CIO und CSO. S steht in dem Fall für Solutions, auch neu. Ich kenne es immer nur als Sales Officer sonst. Was genau ist deine Aufgabe? Was tust du eigentlich in der Metro?

Timo Saldsieder: Also da kommt jetzt dieses ganz schlimme Schlagwort, das ich überhaupt nicht mag. Also ich wurde geholt, um das Thema digitale Transformation anzuschieben. Und wie gesagt, ich mag das Wort eigentlich in der Form gar nicht, weil am Ende haben wir ja immer schon irgendwas mit digital gemacht. Also um es einfach darzustellen, immer schon ist bei uns Strom im Einsatz gewesen, ob es an den Kassensystemen ist oder an sonstigen Supply Chain Lösungen und so weiter. Aber es geht ein bisschen darum, auch hier Mindset natürlich mit zu verändern. Ich glaube, wir werden auch gleich noch über Agile und so weiter sprechen. Und natürlich ist die Metro eher ein klassischer Brick-and-Mortar-Anbieter mit klassischen Märkten, die man so kennt. Und ja, sind halt sehr international unterwegs, das heißt in 25 Ländern. Und ja, aber haben halt bisher mit digital nicht ganz so viel gemacht. Aber in den letzten Jahren ist da relativ viel passiert. Das heißt, das sogenannte Belieferungsgeschäft bei uns, das heißt, dass wir tatsächlich Restaurants etc. jetzt von der Metro aus direkt mit LKWs etc. bedienen, ist für uns ein sehr stark wachsendes Geschäft und im Umfeld sind wir also sehr stark unterwegs. Das heißt, ganz klar einen Omnichannel-Weg, den wir eingeschlagen haben und da ist meine Aufgabe, eben dieses Omnichannel-Business mit anzuschieben.

Joel Kaczmarek: Und wie muss ich dieses Konstrukt Metronom verstehen, damit wir einmal uns alle sauber abgeholt fühlen? Was ist das? Wie passt das bei euch in die Gesamt-Metro hinein?

Timo Saldsieder: Also die Metro ist erstmal super dezentral aufgestellt. Das heißt, sehr viel Hoheit bei den Ländern. Was es für eine Corporate-Funktion, wie jetzt eben die Metro-IT in Anführungsstrichen, relativ schwer macht. Es gab vorher mehrere IT-Units innerhalb der Metro. Die haben wir zusammengefasst unter einem neuen Namen, Metronom, den wir ziemlich heftig eingeführt haben. Also eine knackige Guerilla-Marketing-Kampagne. Und dann haben wir hier in Berlin gefahren, was uns auch mit Start-up-Verbänden und so ein bisschen Ärger bereitet hat, auch dazu geführt hat, dass ich mal mit Zalando ein Entschuldigungsabendessen machen musste mit dem CTO. Aber eine neue Firma in der Form nicht wirklich gegründet, aber eine neue Brand aufgesetzt. Und inzwischen kommt es dem Unternehmen sehr, sehr gut an, weil wir auch da sehr viel Kultur mit reingebracht haben und einfach dafür sorgen, dass es jetzt nicht mehr die verstaubten Schmuddelkinder aus dem Keller sind, sondern dass es halt Leute sind, die durchaus Businessverständnis haben und die auch cool sein können und die auch das Business mit nach vorne bringen.

Joel Kaczmarek: So und was muss ich mir vorstellen, wenn du jetzt irgendwie ein Headhunter holt dich, Olaf Koch trifft dich irgendwie auf dem Golfplatz zum Vorstellungsgespräch, also du merkst dich über Spitze. Was hat der dir denn gesagt, was seine Organisation als Digitalisierung eigentlich versteht? Du hast gesagt, findest du doof, aber was erwartete man von dir?

Timo Saldsieder: Ne, wir haben ehrlich gesagt gar nicht so sehr über das Thema Digitalisierung gesprochen damals und zwar nicht auf dem Golfplatz, korrekt. Sondern wir haben uns ganz normal im Büro unterhalten, wo sich das Thema so nach hinten bewegt. Und das war ehrlich gesagt auch der Grund, warum ich dann hier angefangen hatte. Weil als ich angesprochen wurde. vor jetzt knapp drei Jahren, weil die Metro für mich relevant ist, war meine erste Reaktion, no way, also das klang nicht attraktiv. Soll ich allerdings jetzt die Vision der Metro anschauen, also ein Plattformgeschäft werden soll, wo man also Restaurants über digitale Kanäle mit uns vernetzt, wo das Ganze dann auch noch weitere Kommunikation mit aufbaut. Dann ist es schon ein Thema, das ich erstmal sehr spannend finde. Das heißt, ich bin jetzt nicht so sehr von dem bestehenden Geschäft angelockt worden, sondern es ging darum, gemeinsam hier mit einem ziemlich schlagkräftigen Team und auch verschiedenen Startups, die wir jetzt in unserem Umfeld gerade mit aufbauen, hier einfach das Thema digital mit anzuschieben. Das bedeutet nicht nur, dass wir klassisch Fleisch und Wurst hier an der Theke verkaufen, sondern dass wir eben auch digitale Services mit anbieten, um beispielsweise unsere Kunden, also sprachmäßig Restaurantbesitzer als Beispiel, die halt mit digitalen Produkten und Tools auszustatten.

Joel Kaczmarek: Gut. Lieber Boris, ihr habt ja jetzt schon ein bisschen was miteinander zu tun. Bevor ich jetzt Timo mal löchere, wie die Organisation aussah, als er ankam und wie sie mittlerweile aussieht. Wie nimmst du denn das Unternehmen wahr? Wo steht man dort? Was ist so bei all den Dingen, die wir schon als typisch in dem Segment besprochen haben, was ist da bei der Metro anzufinden, was nicht?

Boris Lokschin: Also ich glaube, was im Verhältnis zu vielen anderen Kunden oder auch Partnern schon ganz deutlich ein Unterschied ist, ist, dass das ganze Thema digital und am Ende auch das Organisationsmodell und auch das Level an Agilität wird schon stark im Top-Down vorgelebt, ja, durch Timo und Co. und sein Team. Das ist nicht immer so. Ja, man hat häufig so versprengte einzelne gallische Dörfer in Unternehmen, die dann versuchen, sich entsprechend zu organisieren. Dann gibt es irgendwie einen guten Product Owner oder mal einen guten E-Commerce-Leiter oder vielleicht einen smarten CTO und dann vielleicht nochmal ein, zwei Developer. die dann ganz große Schwierigkeiten haben, eigentlich über ihr Level hinaus nach oben jegliche Art von Arbeitsmodus, Budgetierung, Tooling etc. zu transportieren, schreiben dann für jede Wiki-Lizenz Business Cases und, und, und. Das ist hier schon anders. Das ist, glaube ich, auch deutlich, deutlich einfacher dann vorzugehen, wenn das top-down durch die Organisation fließt. Auch natürlich die Menge an Leuten. Es geht nicht darum, hier zwei, drei, vier, fünf Leute aufzubauen, sondern wenn man sich anschaut, Timo hat es ja gerade gesagt, knapp 2.000, 2.500 Leute, die dort jetzt zusammengefasst wurden. Das ist auch schon mal eine Ansage. Ich glaube, es gibt nicht allzu viele Unternehmen, auch große Unternehmen, die ein Digital-Team oder Digitalisierungsteam dieser Größenordnung haben in Deutschland. Da fallen mir zumindest nicht allzu viele ein. Und dann natürlich auch die Vision. jetzt nicht einfach nur, auch das hat Timo gerade schon kurz angesprochen, dieses Plattformgeschäft aufzubauen und jetzt nicht zu sagen, wir wollen jetzt einfach 0,01% unseres Umsatzes nicht mehr über Fax, sondern über über online abzuwickeln. Ich glaube, dass es zumindest vom Ambitionslevel,das ist, glaube ich, eine super wichtige Voraussetzungbei Digitalisierung, dass das Ambitionslevel stimmtoder das Angstlevel, beides gut,sage ich auch mal, Ambition oder Angst,beides gute Trigger, um Dinge zu tun. Ambition natürlich erstmal per se positiver behaftet,das heißt, ich bin Category Leader im Bereich A, B, Cund ich möchte das jetzt auch digital werdenund ich sehe meine Fälle davon schwimmenund ich muss jetzt Dinge tun. Also Ambitionslevel, richtiges Org-Chart,sozusagen Top-Down-Approach und einfach auchdie Größenordnung ist, glaube ich, schonein deutlicher Unterschied zu vielen anderen,die sich da versuchen aufzustellen.

Joel Kaczmarek: Und jetzt mal Hand aufs Herz, was hast du da für eine Organisation vorgefunden, als du angefangen hast?

Timo Saldsieder: Ja, es war schon eher klassisch. Also wie gesagt, es war verteilt ein bisschen in unterschiedliche Funktionsbereiche, aber es gab eben klassisch, wie man es in einem großen Konzern kennt, Abteilungsleiter, Hauptabteilungsleiter, Bereichsleiter, also die ganze klassische Hierarchie, die man so kennt. Es gab allerdings auch schon, wie Boris gerade gesagt hat, auch so eine versprengte Unit, die sich mit dem Thema digital beschäftigt hat. Die waren schon ein bisschen moderner auch aufgestellt. Da ist auch das Thema Agile schon seit zwei, drei Jahren aktiv gewesen. Das heißt, Agile ist jetzt für die Metro jetzt nichts Neues, sondern machen wir schon seit ein paar Jahren. Aber die Aufgabe ist halt jetzt dafür zu sorgen, dass da mehr oder weniger alle mitziehen, was nicht für alle Bereiche Sinn macht. Ich glaube, eine große SAP-Implementierung jetzt agil umzusetzen, würde relativ wenig Sinn machen. Deswegen ist es ursachengerecht, muss man halt die jeweilige Methodik einsetzen, aber ein Großteil der Organisationen ist inzwischen agil mit unterwegs. und organisatorisch haben wir inzwischen eine Struktur, die sehr, sehr flach ist, weil wenn du mal versuchst, 250.000 Leute über drei Hierarchie-Ebenen abzubilden, dann ist das schon mal eine Ansage. Und das gelingt uns durch sehr viel Kommunikation, das gelingt uns durch auch wirklich flache Hierarchien in der Form, dass wir auch vorleben, wie so ein Team mitzuleiten ist. In der Vergangenheit ist halt so, dass Karriere bei der Metro gemacht, indem du halt einfach fachlich sehr, sehr gut warst. Und inzwischen zählen da noch andere Dinge. Das heißt Leadership, Kommunikation, strategisches Denken sind alles Themen, die vorher nicht so wirklich relevant sind, wo wir aber sehr großen Wert drauf legen. Wir haben ein Strategieframework eingeführt namens WMOSA, steht für Vision, Mission, Objective, Strategies and Actions. Kann ich also jedem empfehlen. mal danach zu suchen. Da sind inzwischen alle unsere Solutions, auch alle Organisationseinheiten, danach mit strukturiert. Also haben sehr, sehr viel gemacht. Das ist jetzt nur eins von vielen Beispielen, wo wir tatsächlich diese Transformation anschieben. Und das hat neben den organisatorischen Auswirkungen auch kulturelle Auswirkungen.

Joel Kaczmarek: Das musst du nochmal langsam sagen. Wimosa war was? Vision?

Timo Saldsieder: Vision, Mission, Objectives, Strategies and Actions.

Joel Kaczmarek: Und was musst du dir darunter genau vorstellen? Also wie hilft dir das weiter?

Timo Saldsieder: Das ist so, dass wir quasi jegliche Führungskraft oder auch Teams gezwungen haben, dieses Wimosa-Framework auszufüllen. Das heißt, jedes Produkt bei uns, jede Organisationseinheit hat dieses Wimosa-Framework ausgefüllt. Das heißt, ich weiß zu dem Online-Shop, was die Vision dieses Online-Shops ist, was die Mission dazu ist, was die Objectives sind, also die Ziele, die dahinter liegen und Strategien, was in den nächsten ein, zwei Jahren angegangen werden soll. Und Actions sind dann kurzfristige Themen, das heißt, was in den nächsten sechs Monaten angepasst wird. Und das Dokument entwickelt sich weiter. Es ist also jeweils ein Einseiter, der dann auch dem Unternehmen bekannt ist. Und dazu machen wir sehr viel Kommunikation und das treibt einfach so eine strategische Denke.

Joel Kaczmarek: Was genau ist denn mal der Unterschied? Ich finde das ja immer schwer auseinanderzuhalten zwischen zum Beispiel Vision, Mission und Strategie. Das ist ja irgendwie so ein bisschen auch fließender Übergang, oder?

Timo Saldsieder: Ja. Wir sehen es eher in Zeitschreiben, das heißt so eine Vision ist ja so sehr langfristig betrachtet, also man denkt eher so Richtung 10, 12 Jahre. Eine Mission geht eher so Richtung 5 bis 8 Jahre und Strategies sind für uns eher so 2 Jahre. Dazwischen kommen noch die Objectives, wo wir sagen, okay, das ist so die Zielausrichtung. Wir führen in der gesamten Unternehmen gerade Objectives and Key Results ein, also OKRs, und da orientieren wir uns eben sehr, sehr stark in diesem Objectives-Ansatz. Das heißt, wir versuchen, Outcome getrieben zu arbeiten, nicht Output getrieben. Ein paar Schlagworte hier reinschmeißen, aber das sorgt dafür, dass das Unternehmen im Augenblick ein bisschen anders tickt. Also in der Vergangenheit war es so, dass ein IT-Projekterfolg war, wenn es in Time und in Budget abgeliefert wurde. Ob das tatsächlich irgendwas gebracht hat, hat niemand interessiert. Und jetzt eben durch diese neue Herangehensweise ist es halt so, dass wir uns sehr, sehr stark darauf konzentrieren, dass das, was wir machen, tatsächlich einen Mehrwert liefert. Das heißt wirklich Value-Added-Services bereitstellen. Und das sorgt einfach dafür, dass die IT am Ende des Tages anders arbeitet und auch in der Form eigentlich keine IT mehr ist, sondern eine Produktorganisation. Wir liefern Produkte.

Joel Kaczmarek: Da sind wir schon mittendrin in dem ganzen Aufbaubereich und wie es quasi misst. Wenn du eben gerade sagst, Outcome versus Output, kannst du das mal für jemanden spezifizieren, der das irgendwie noch nie sich so auseinandergedacht hat?

Timo Saldsieder: Also nehmen wir mal Logistikbereich, vielleicht ist das nicht für jeden so greifbar, aber da habe ich ein schönes Beispiel. Also ein Output wäre, bitte implementiere Feature A, B, C, also zum Beispiel Multi-Order-Picking, was ja so ein Fachbegriff ist, dass also ein Picker, der in einem Logistikbereich Produkte aus dem Lager pickt, dass er also für mehrere Order gleichzeitig anfängt, Produkte zu picken. Das wäre so ein Feature, was eigentlich erstmal nicht relevant ist. Outcome wäre, wir steigern die Effektivität oder Effizienz eines Pickers um 30%. Das heißt, ob das jetzt über Multi-Order-Picking passiert oder über eine andere Methodik, ist eigentlich erstmal gar nicht gesetzt, sondern es geht erstmal darum, was möchte ich als Ziel erreichen, messbar. Und wie es umgesetzt wird, ist nicht mehr die Aufgabe der Stakeholder, sondern Aufgabe der Metronome in dem Falle. Das heißt, wir arbeiten Outcome-getrieben. Uns interessiert nur noch das Resultat, wie man da hinkommt, ist erstmal völlig egal. Das heißt, auch einen sehr experimentierfähigen Ansatz, dass wir also sehr viele Varianten fahren, um einfach zu schauen, wie wir diesen Zielwert möglichst schnell nach oben treiben. Und wie gesagt, messbar, wird auch quasi wöchentlich reported von unseren Leuten, sehr transparent. Und das ist eine komplett andere Arbeitsweise als in der Vergangenheit, wo sich IT quasi für Monate zurückgezogen hat. Dann kam irgendein Produkt heraus und es hat niemanden interessiert. Super frustrierend, sowohl für das Business als auch für die IT-Leute. Aber das war so, ja, eigentlich Status Quo in der Vergangenheit.

Joel Kaczmarek: Aber habe ich das richtig verstanden, dass ihr Outcomes und Outputs dann sozusagen trennt, voneinander separiert? oder muss jeder Output auch immer gleichzeitig eine Outcome-Vision aufzeigen?

Timo Saldsieder: Wir betrachten Output in der Form gar nicht mehr. Das heißt, Output ist das, was automatisch passiert, aber es wird nirgendwo mehr irgendwie dokumentiert oder protokolliert, sondern wir protokollieren nur noch quasi die Zielerreichung und das ist schlussendlich dann der Outcome.

Joel Kaczmarek: Boris, du bist ja der Erfahrene. Auf so einer Best-Practice-Skala von 1 bis 10, ist das eher schon so im oberen Drittel? oder wie verortest du das?

Boris Lokschin: Das ist eher schon im oberen Drittel. Ich glaube, das ist super wichtig. Auch eine ganz wesentliche Beobachtung, dass sehr häufig diese versprengten Teams, über die ich vorhin gesprochen habe, selbst wenn die maximal es hinbekommen, sich sozusagen agil aufzustellen und vielleicht auch die entscheidenden Stakeholder überzeugen können, dann wird es am Ende des Tages ganz häufig diese unsichtbare Decke geben.bei der man dann eben dann doch reinläuftin so klassische Management Reporting,Risk Management Frameworks,bei denen schaut dann jemand drüberund entscheidet dann eben nur rein nachCost KPIs oder nachist der Scope erfüllt KPIsund ihr arbeitet doch so lange daranund nur was kostet dasund tatsächlich wirddas eigentliche Ziel aus dem Auge verloren. Ich glaube, das ist auch super wichtig, weil so ein bisschen umgekehrt wird, wer eigentlich, es ist ja auch eine Form von Spezialisierung, am Ende des Tages entscheidet eine bestimmte Organisation darüber, was ist die beste Lösung für ein Problem. Das Business hat ein Problem zu formulieren und sagen, ich bestelle sozusagen eine höhere Produktivität für diesen Picker, ich bin aber nicht mehr derjenige, der zwangsläufig am besten aussagekräftig oder aussagefähig ist über die Lösung, über den Lösungsweg und gibt das in dem Fall jetzt von Timo an die Metronome ab und die Kollegen haben die Lösungsfindungskompetenz dann an den Tisch zu bringen, was glaube ich gerade bei so zunehmend komplexer werdenden Problemen, ich meine, das war jetzt gerade ein einzelnes Feature-Beispiel, aber es gibt ja auch, wenn man das alles so ein bisschen hochskaliert, wenn man sich überlegt, wie komplex Themen wie Logistik oder auch Kundenfacing-Themen heutzutage sind, Ist eigentlich für einen Business-Stakeholder schwer definierbar, wie die Lösung sein soll. Er kann formulieren, einfach entlang so klassischer Business-KPIs. Ich möchte Kundenzufriedenheit steigern, ich möchte Umsatz steigern, ich möchte meinen Online-Prozentansatz steigern, ich möchte vielleicht irgendwie andere betriebswirtschaftliche oder Commerce-related KPIs steigern. Aber wie ist eigentlich nicht mehr machbar. Da sehen wir ganz wenig Business-Stakeholder, die diese Lösungskompetenz haben.

Joel Kaczmarek: Das will ich jetzt genauer verstehen. Wie genau bildet ihr das prozessseitig ab? Weil du brauchst ja gefühlt immer einen, der den Hut auf hat, der das ganze Projekt irgendwie managt, kontrolliert. Wenn man dann mehrere Stakeholder hat, der eine gibt irgendwie eine Vorgabe an und sagt, ich hätte gern, wie jetzt gerade das Beispiel mit dem Picker hatte, da mehr Performance, mehr Effektivität, mehr Effizienz, mehr whatever. Und jemand anders macht sich über die Lösung Gedanken und dann hat man vielleicht noch eine dritte Partei, die in der Umsetzung mitbegriffen ist. Dann schieben die sich auch mal gegenseitig einen schwarzen Peter zu, wo es jetzt gehakt hat. Das ist ja irgendwie schwer zu steuern. Wie macht ihr das?

Timo Saldsieder: Also wir haben, als ich angefangen hatte, war die Situation die, dass aus mir nicht ersichtlichen Gründen ein auch mir unbekannter Algorithmus im Hintergrund war, wer welches Projekt umsetzt. Das heißt, irgendjemand kannte den Schwager von dem und dann hat man halt dieses Projekt umgesetzt und da haben wir relativ schnell eingegriffen in der Form, dass wir ein Portfolio-Management eingeführt haben. Es war jetzt nicht sowas wie safe und wie ein riesen komplexes Ding eingeführt wird, sondern es war sehr, sehr pragmatisch. Wir arbeiten bereits zeitscheingesteuert, das heißt, alle sechs Monate wird eine neue Priorisierung gemacht. Das heißt, klingt jetzt ein bisschen formal, aber es wurden Projektanträge eingereicht, die dann einfach priorisiert wurden nach drei Kriterien, nämlich ein Business Score, das heißt, was bringt es wirklich betriebswirtschaftlich, einem Strategy Score und einem IT Score. Das heißt, es gab jeweils Leute, die dann auch einen Wert abgegeben haben, um schlussendlich dann auf eine Liste zu kommen, die nach einer Reihenfolge umgesetzt wurde.

Joel Kaczmarek: Wer macht das? ganz kurz, diese Scores? Wer bewertet das?

Timo Saldsieder: Die Business-Scores wurden aus dem Finance-Controlling-Bereich herausgemacht. IT, überraschungsfrei aus der IT. Also sprich, irgendwelche Architekten sitzen da drauf und bewerten das. Und Strategy-Score war am Anfang die Strategieabteilung. Das hat man aber irgendwann zur Chefsache gemacht. Das war wirklich das Board, das schlussendlich dann diese 80 Anträge einmal im Halbjahr durchgegangen sind und dann schlussendlich Werte vergeben haben. Die waren dann getrittelt aufgeteilt und dann gab es halt einen Gesamtscore. Und das war dann die Reihenfolge, in der wir aus IT-Sicht heraus Dinge abbilden sollten. Da gab es natürlich Dependencies zwischen den verschiedenen Projekten, sodass auch mal was von einem anderen umgesetzt wurde, wo ein bisschen ein Fragezeichen aufkam. Das führen wir jetzt gerade über, weil es halt noch die klassische Projektmanagement-Methodik war, jetzt eben in einen OKR-Ansatz. Ganz tolles Wort kreiert, hatte ich mal einen Kreativschub. Poker wird das jetzt genannt, steht für Priorisierten Objects and Key Results. Und dieser Poker-Einsatz sorgt halt dafür, dass wir jetzt priorisierte Objectives umsetzen und die eben messen in Form von Key Results. Und das ist ein sehr klassischer Prozess, also diejenigen, die OKRs nicht kennen, das ist also ein Prozess, der auch bei Google und LinkedIn etc. zum Einsatz kommt, um einfach A mehr Transparenz zu haben und B aber auch einen klaren Fokus zu haben. Das heißt, die Teams committen sich auch nur zu bestimmten Dingen, wo sie auch die Kapazität dazu haben. Und da kommt eben dieses P bei dem Poker dazu, dass einfach auch Prioritäten dahinter liegen. Das heißt, es kann durchaus sein, dass da 60, 70 Outcomes eingefordert werden und wir halt nur 30, 40 davon umsetzen können, weil wir einfach die Kapazität dazu nicht haben.

Joel Kaczmarek: Ich wollte gerade sagen, wenn ihr da 80 Anträge habt, das heißt, man muss ja wahrscheinlich ein Stück weit parallelisieren manche Dinge und ganz viele Sachen bleiben irgendwie auf der Strecke. Wie fängt man sowas ab?

Timo Saldsieder: Da hilft uns natürlich, dass erstmal vom Board auch die Unterstützung da ist. Das heißt, es ist schon so, dass wir regelmäßig auch Stakeholdern sagen, das werden wir die nächsten halben Jahre nicht anfassen. Und das sorgt klar für ein bisschen Unmut, aber da hilft einfach, das ist auch von Boris angesprochen, so ein bisschen Top-Down-Ansatz. Das heißt, wenn ich eine klare Priorität aus diesem Prozess heraus habe, dann fängt auch keiner das Motzen an, auch wenn natürlich vielleicht ein Land mal eine andere Priorität auf so einem Thema sieht, als das Board das sieht. Aber am Ende sind wir eine Gruppe und müssen halt dafür sorgen, dass das aus dem Gruppeninteresse möglichst sinnvoll umgesetzt wird.

Joel Kaczmarek: Okay, ich meine, wenn man drei Entitäten hat, die quasi drei unterschiedliche Scores vergibt, dann hat man ja auch irgendwie sozusagen eine Herleitung.

Boris Lokschin: Verstehe. Ist ja am Ende auch immer eine Opportunitätsentscheidung. Ich glaube, das ist super wichtig. Ich glaube, wenn man halbwegs sein Business im Griff hat, dann gibt es, glaube ich, egal ob ich so in einem Commerce-Business bin, wir hatten jetzt letzte Woche bei uns ein internes Meeting mit unserem Product- und Technology-Team. Das ist immer am Ende eine Frage von was lässt du liegen. Wenn ich mir den Backlog anschaue, den unsere internen eigenen R&D-Teams generieren, dann übersteigt er unsere Capacity. Wenn ich mir dazu nochmal zusätzlich den Backlog angucke von den Product-Teams, was würden sie gerne bauen, übersteigt dieser Backlog die Capacity. Wenn ich mir angucke, was bestellen Kunden an Dingen oder an Features und Partner bei uns, dann übersteigt dieser Backlog die Capacity. Jeder Einzelne für sich, ja. So, und wenn du die drei dann zusammenführst, dann hast du nochmal ein paar Ideen, dann hast du noch ein paar strategische Dinge, dann hast du noch ein bisschen Support. So, dann ist das am Ende eine Prioritätsfrage, ja. Du kannst quasi nicht, du musst das entsprechend aussteuern, du musst dir wirklich überlegen, ja, was, in welche Gewichtung tust du das. Und ich glaube, das ist auch ein super wichtiges Merkmal, so dieses, also wir nennen das relativ simpel bei uns, diese Let it go Mentalität. Also man muss einfach, das klingt leichter als es ist, ja, aber man muss in dieses Meeting kommen und muss einfach weitergehen. allen klar sein, dass irgendwo die Linie gezogen wird. Und umso besser ich das strategisch oder wirtschaftlich oder an welchen Parametern auch immer für mich priorisieren kann, umso besser ist es. Und dieses Verständnis ist bei weitem, auch wenn es so leicht klingt, nicht in allen Chefetagen so. Also ich habe jetzt keinen statistischen Wert, aber so gefühlt wirklich 80, 90 Prozent der Gespräche, wenn du mit den Fachteams sprichst und die dann hinterher Projekte intern pitchen, dann ist das, was sozusagen das Management,die Eigentümer, die Geschäftsführer einfordern,schon von vornherein nicht realistisch,weil das entweder die Kapazitätoder die gegebene Zeitoder das von ihnen selbst bereitgestellte Budgeteigentlich schon sprengt. Und wenn du dann noch so ein paartechnische Risiken noch mal draufhängst,dann auf solche Projekte,dann ist das deutlich zu viel.

Joel Kaczmarek: Jetzt ist ja spannend noch zu verstehen,du hast gesagt, 2500 Mitarbeiter an acht Standorten. Wie managt man das von der Struktur her? Also es ist ja ein Riesenbrett,was man da eigentlich fährt. Wie habt ihr die Hierarchien gebaut? Wie habt ihr die Kommunikationsprozesse etabliert? Wie muss ich mir das vorstellen?

Timo Saldsieder: Vielleicht mit Kommunikation anfangen. Wir machen wahnsinnig viel Kommunikation. Das heißt, wir haben so alle sechs Wochen so ein sogenanntes Townhall-Meeting, wo wir also dann wirklich groß auf der Bühne von ein paar hundert Mitarbeitern, dann Video gebroadcastet in die Welt hinaus, die 2000 Mitarbeiter erreichen. Sehr interaktive Session, das heißt, über ein Online-Tool kann man auch Fragen einreichen, die wir dann live on stage, was ein gewisses Abenteuer immer ist, weil du nicht weißt, was vorher kommt, einfach dann auch mit beantworten. Ich selber schreibe alle zwei, drei Wochen einen internen Blog, von dem 600, 700 Leute folgen, wo ich dann auch solche Themen wie Product Management, aber auch mal kritische Themen, wie wir mit Homeoffice-Regelungen umgehen, tatsächlich anspreche. Also sehr breit gestreut. Wir machen eine sogenannte Solution Expo zweimal im Jahr. Das heißt, es ist so ein Marktplatz, wirklich mit Ständen in einer unserer großen Hallen, wo also auch hier dem Corporate-Volk quasi gezeigt wird, was wir alles gerade bauen. Da sitzen also auch dann die Leute da. die Produkte erklären und das sorgt inzwischen sogar so für Anklang, dass da Leute aus der Welt anreisen, um schlussendlich in Düsseldorf im Headquarter sich diese Solution-Expo anzuschauen. Also wahnsinnig viel Kommunikation ist die Lösung. Hierarchien, wie gesagt, sind wir ziemlich radikal rangegangen, haben das jetzt auf drei Hierarchien beschränkt. Auch sind so von den klassischen Titeln wie Hauptabteilungsleiter und so abgegangen. Das heißt, auch jetzt metrospezifische Titel hier geformt. Es gibt also sogenannte Domain-Owner. Nils hast du vorher angesprochen, ist einer davon. Es gibt Unit-Owner und das war's. Also das sind die zwei Ebenen und dann eben noch die Geschäftsführung obendrauf. Und das sind die Strukturen, die wir jetzt gebildet haben. Deswegen Kommunikation und Struktur ist ein Thema, aber auch klare Prozessvorgaben.

Joel Kaczmarek: Wie bewertest du das?

Boris Lokschin: Ich glaube, es ist erstmal, also jede Company muss für sich ein Modell finden. Ob das jetzt das Modell ist oder andere Organisationsmodelle, hängt immer super stark davon ab, was man für eine Firma ist. Wir haben jetzt, wenn ich mal ein bisschen schaue, wie das bei uns organisiert ist, ist das ähnlich. Ist erstaunlicherweise nicht ganz so flach. Ich glaube, wir haben auch, weil wir kleiner sind, irgendwie zehnmal kleiner Unternehmen. Mehr Levels, ja, ist aber, wie gesagt, dem Business, glaube ich, selber überlassen. Wenn das gelingt und wenn die Kommunikation trotzdem funktioniert und wenn sich auch jeder fachlich und, also wenn jeder eine saubere Karrierefahrt hat, das ist, glaube ich, immer so ein super wichtiges Learning Team, hat es vorhin gesagt, das Initial und das ist bei vielen Firmen ja so, dass wirklich nur das Thema Fachkompetenz entscheidet. Es gibt noch einen zweiten Parameter, ganz häufig gerade bei großen Firmen, was da ist, ist Headcount. Da gibt es Leute, die sich einfach nur über Headcount definieren, die rumlaufen und glauben, nur weil sie viele Leute haben, die an sie reporten, sind sie wichtig und wichtiger, was natürlich ein kompletter Käse ist. Also da wird sozusagen der individuelle Leverage komplett rausgenommen. Also wir haben eine Sache, die, glaube ich, dem sehr ähnlich ist. Bei uns sind sozusagen die Titel, die vergeben werden, hängen nicht an zwangsläufig an der Fachlichkeit. Ich kann einen Title haben, also ich kann jetzt unsere Office-Managerin nehmen, die einen ähnlichen Title hat, die vielleicht jemand, der zuständig ist für ein Product Management, also damit immer der individuelle Leverage auf die Organisation abgebildet. Also ich kann einen hohen Leverage haben, trotz meiner Position. Es ist nicht zwangsläufig bei uns vorgegeben, dass nur weil ich ein Entwickler bin, ich zum Beispiel weniger verdiene als mein Teamlead oder mein Teamlead weniger verdient als der Architekt. Also auch die Gehaltsgefüge hängen sozusagen nicht mehr an dieser Leiter, sondern immer noch persönlich Leveraged. Wenn ich zum Beispiel einen super uniken Skill habe, der schwierig ist im Markt zu bekommen, dann ist es absolut fine, dass ich oder wenn ich ein Architekt bin, der einen ganz hohen Leverage hat, weil ich an dem wichtigsten Produktteil arbeite, dann ist es bei uns zum Beispiel so, dass das absolut mehr Leverage einem gibt und ich dann in meinem Title auf einem ähnlichen zum Beispiel Director Level sein kann wie jemand anderes. Ich könnte also auch In unserem Beispiel könnte auch unsere Office-Managerin einen Director-Titel tragen, wenn wir der Meinung wären, dass sie einen hohen Leverage auf die Organisation hat und wenn sie fehlt und hier die Prozesse alle nicht mehr laufen und das irgendwie total katastrophal für uns wäre. Also das ist die Ideologie dahinter, dass man es halt entkoppelt von nur Fachlichkeit oder nur Headcount oder nur von so vorgeschriebenen Karriereleitern, dass immer der, der über mir ist, automatisch wichtiger ist und mehr verdienen muss.

Joel Kaczmarek: Wie messt ihr Leverage?

Boris Lokschin: Wird auch trianguliert über verschiedene Parameter, wird trianguliert über Skills, also was ist das für ein Skill, wie rar ist er, wie schwierig ist er, wie sehr würde es uns das wehtun, wenn dieser Skill nicht mehr in der Organisation wäre. Social ist ein ganz wichtiger Parameter, also wir bewerten ganz stark auch durch 360 Reviews, wie hoch ist sozusagen der individuelle Score. Du kannst halt Leute haben, die toxisch sind, aber brillant in dem, was sie machen. Das sind dann Leute, die ganz schnell zur Tür herausbegleitet werden bei uns in unserer Organisation. Ist aber bei weitem nicht so. Es gibt Leute, die in Sales-Organisationen zum Beispiel ganz häufig oder auch im Engineering dann auch behalten werden, weil sie eben sehr, sehr gut sind. Wir haben für uns festgestellt, dass eben toxische Leute andere Leute runterziehen, die Motivation runterziehen und dann kannst du noch so brillant sein, dass das halt einfach eine Eigenschaft, die dann nicht passt. Also Fachlichkeit, also Leverage, Social Skills und dann kommen dann natürlich so die klassischen Dinge nochmal dazu, wie viel Verantwortung trage ich, habe ich Responsibility über andere, kann ich Guidance geben? Bei dem Responsibility-Thema zum Beispiel wird ganz hoch gewichtet, ist mein Leverage stark genug dadurch, dass ich Leute entwickeln kann? Wir haben zum Beispiel verschiedene Profile, es gibt Leute, die sehr, sehr gut sind als Individual Contributor, die sehr, sehr gut sind als Manager, wo du sagst, hey, der Joel, der ist gut darin, diese drei Leute zu managen, gut im Fall, also gleich effizient. Aber der ist nicht gut darin, diese drei Leute weiterzuentwickeln. Und das bewerten wir zum Beispiel für uns intern und sagen, hey, die Leute, die andere leveragen und fördern können, kriegen halt einen höheren Score. Gibt ja so dieses bekannte Beispiel von dem Steve Jobs, so A-Player hire A-Player, B-Player hire C-Player, C-Player hire D-Player. Da glauben wir zum Beispiel sehr stark daran, dass wenn du eben Leute reinholst, die B-Player sind, also die einen netten negativen Score haben oder Leverage auf die Leute unter ihnen, dann sind das genau die Leute, die immer ihre Leute künstlich uninformiert halten, künstlich dumm halten, fern von Entscheidungen, Dinge nicht erklären, sie nicht fördern, weil sie einfach immer befürchten, dass derjenige schlauer, besser wird, da eine eigene Position einnimmt. und wir versuchen für uns genau das eben daraus zu filtern durch dieses Modell und sicherzustellen, dass wir eigentlich immer so ein A-Player-Environment aufrechterhalten.

Joel Kaczmarek: Timo, wie lange würdest du sagen, dauert es denn, eine Organisation so umzustrukturieren, wie du es jetzt gesagt hast? Also wir hatten irgendwie einen Vimosa, wir hatten irgendwie Outcomers in eure Richtung, ihr habt irgendwie Poker, ihr habt in drei Ebenen Hierarchie über zweieinhalbtausend Leute. Das ist ja alles Change Management. Wie lange muss ich mich mehr verschreiben, um so eine Prozessgruppe aufzusetzen?

Timo Saldsieder: Also wir machen das jetzt seit zwei Jahren, sind aber noch lange nicht angekommen, wie ich mir das vorstelle. Das heißt, wir sind eigentlich noch mittendrin. Wie lange das noch dauern wird, kann ich jetzt gar nicht sagen. Hängt natürlich auch ein bisschen von der Ausgangssituation ab. Wenn du jetzt ein Unternehmen wie die Metro, die 50, 60 Jahre im Markt ist, wo du auch Mitarbeiter hast, die seit 20, 30 Jahren im Unternehmen sind, wo du auch naturgemäß, weil der Mensch an sich ist halt einfach ein Gewohnheitstier, Verwendungsbereitschaft eher gering ist, dann ist es einfach ein längerer Prozess. Wenn du jetzt, glaube ich, ein Unternehmen umbauen möchtest, das irgendwie fünf Jahre im Markt ist und da eine andere Kultur einführen möchtest, dann kann ich mir das relativ schnell vorstellen. Bei uns ist jetzt nach zwei Jahren schon relativ viel passiert, also auch gerade die von Boris angesprochenen Themen betreffen uns natürlich auch. Wir sind sehr radikal reingegangen, beispielsweise gibt es bei uns keinen individuellen Bonus mehr, komplett gekillt. Wir haben aber auch zum Beispiel Titel abgeschafft, das heißt es gibt keinen Junior, Senior etc. mehr. Also von daher sehr aggressiv auch in bestimmte HR-Themen reingegangen. Jetzt bestellt uns gerade intensiv das Thema Performance Management, was echt ein dickes Brett ist, also super schwer zu lösen. Wir sind im Thema Employee Engagement radikal rangegangen. Das heißt, wir führen nicht wie früher einmal im Jahr eine Mitarbeiterumfrage durch, sondern wir führen die einmal im Monat durch. Das heißt, einmal im Monat bekommen alle Mitarbeiter von uns einen kurzen Fragebogen zugeschickt, komplett toolgestützt. Und daraus messen wir dann wiederum 14 KPIs, um sicherzustellen, dass auch da die Führungskraft einen guten Job macht, was wie gesagt nicht bonusrelevant ist, weil wir keinen Boni haben. Aber ich kann sehr genau sagen, an welchem Standort sich welche Mitarbeitergruppe wie gerade fühlt, wo die Führungskraft einen guten Job macht und wo nicht. Das heißt auch sehr viel Kommunikation über so ein Tool, weil als Mitarbeiter kann ich dann auch nicht nur einen Wert abgeben auf die Umfrage, sondern auch einen Kommentar. Der kommt anonym bei der Führungskraft an und die Führungskraft hat dann die Möglichkeit, nicht anonym wieder zu antworten, sodass also auch über das Tool auf einmal sehr viel Kommunikation stattfindet. Also von daher sehr viel Tooling eingeführt, sehr viele Prozesse eingeführt, aber wir sind noch nicht da, wo ich mir das vorstelle.

Joel Kaczmarek: Wie inzentiviert ihr, wenn ihr keine Boni mehr habt?

Timo Saldsieder: Über Purpose. Das heißt, unsere Leute sollen, also erstmal geht es darum, ich glaube nicht, dass, nehmen wir mal einen Entwickler, ein Entwickler darüber motiviert ist, wenn er am Ende des Jahres nochmal 2.000 Euro mehr Bonus bekommt. Das glaube ich nicht, dass es funktioniert. Deswegen wird er unter dem Jahr nicht schneller programmieren oder kreativer sein oder sonst was, sondern er muss sich mit der Aufgabe identifizieren. Und deswegen glaube ich, dass dieses Purpose-Thema viel wichtiger ist, als irgendwelche Boni auszuschütten. Und auch so ein Jahresendgespräch, wo du dann versuchst, krampfhaft den Mitarbeitern nochmal Feedback zu geben, was über das Jahr hinweg gut oder schlecht lief. Meistens fällt dir dann eh nichts mehr an, wenn du in so einem Meeting drin bist. Deswegen auch Feedback-Kultur. Wir haben gerade ein 360-Grad-Feedback-Ding eingeführt. Ich selbst bin relativ schlecht leider am Feedback geben, sodass ich also für mich, also das ist auch so eine Strichliste für, dass ich versuche einmal die Woche irgendwelche Mitarbeiter zur Seite zu nehmen und kurz Feedback zu geben. Mit der Regel sieben von zehn Feedbacks sollten positiv sein. Also Feedback heißt nicht immer nur Mitarbeiter mal zusammenfalten, sondern im Gegenteil eher positives Feedback zu geben. So und mit diesen Mechanismen arbeiten wir grundsätzlich. Und die eben angesprochenen Maßnahmen sorgen einfach dafür, dass ich so eine selbst große internationale Organisation wie wir so langsam aber sicher dreht. Also ich bekomme gerade zum Beispiel auf die Blogs, die ich schreibe, gerade aktuell Homeoffice-Regelung, wo wir super frei umgehen. Das heißt, bei uns ist wirklich keinerlei Begrenzung, was Homeoffice angeht. Und da könnte man erstmal sagen, okay, jetzt bleiben quasi alle zu Hause. Realität ist, dass damit sehr ernst umgegangen wird. Nichtsdestotrotz gibt es ein paar schwarze Schafe, die das vielleicht auch mal negativ mit ausnutzen. Und dann greift die Organisation ein. Das heißt, ich habe das ja an so einem Blog angesprochen und dann kriege ich halt 30, 14 Kommentare und sehe auch, dass die Teams selbst regulierend damit umgehen. Das heißt, wenn an einem Freitagnachmittag einertelefonisch nicht erreichbar ist und wahrscheinlichihr gerade beim Rasenmähen oder sonst was macht,dann reagiert das Team. Und das kriegst du haltregulatorisch top-down nicht in den Griff. Das musst du tatsächlich hieran den Mitarbeiter delegierenund da arbeiten wir dran.

Joel Kaczmarek: Ja, ich habe auch die Tage irgendwie gelesen,dass ja damals Marissa Meyer das abgeschaffen hatbei Yahoo und immer nur danach ging so nachwie oft hat man sich eingeloggtund dass das eigentlich eine total dämliche Metrik istfür Performance. Wo du sagst Tools, was benutzt ihr denn fürtechnische Werkzeuge, um euch zu steuern? Welche Lösungen setzt ihr ein?

Timo Saldsieder: Ich weiß nicht, ob ich die Frage richtig verstehe, aber wir

Joel Kaczmarek: Dann sagen wir mal Software zum Beispiel. Also so ein Fisman zum Beispiel sagt, sie machen ganz viel über Asana beispielsweise. Du hast eben von so einer Art Engagement und Mitarbeiterzufriedenheit Software irgendwie was angedeutet. Vielleicht kannst du ja so ein paar mal nennen.

Timo Saldsieder: Also wir setzen für Employer Engagement, also diese vierwöchigen Umfragen, ein Tool namens Picon ein. Das ist intensiv, ohne Werbung machen zu wollen. Meine vorherige Firma hat einen Office-Swipe im Einsatz, auch gut. Picon für uns besser, weil europäische Firma, sitzt in Kopenhagen, in mehreren Sprachen verfügbar, deswegen dort eingesetzt. Ansonsten setzen wir Classics Jira als Haupt-Tool ein. Ansonsten sind wir gar nicht so wahnsinnig Tool-gestützt. Also das läuft relativ frei, aber das sind so mit die wesentlichen Tools, die wir natürlich einsetzen. Klar, den Confluence, um Dokumentation zu machen, aber dass wir jetzt irgendeine Riesenbatterie an Tools einsetzen. Ansonsten haben wir die klassischen HR-Tools im Einsatz, ein selbstgebautes 360-Grad-Feedback-Tool, das wir selbst mitnutzen. Und ansonsten denken wir gerade darüber nach, die HR-Suite nochmal komplett neu aufzusetzen. Das heißt, da könnte dann sowas wie SuccessFactors oder Workday, also die großen modernen Tools zum Einsatz kommen. Aber das sind im Wesentlichen die Tools, die wir verwenden.

Joel Kaczmarek: Was hat das für einen Impact, Boris? Merkst du, dass irgendwie, also haben solche technischen Tools großen Einfluss auf die Arbeitsweise oder ist das eher ein Hygienefaktor?

Boris Lokschin: Haben schon Einfluss auf die Arbeitsweise. Ich glaube, am Ende des Tages sind die Tools zur Bewertung super relevant. Das ist auch eine ganz große Best Practice, sowas zu haben. Das ändert auch sehr viel Arbeit.Kultur, weil in den allermeisten Firmen,also das Tool ist gar nicht so entscheidend,bei den allermeisten Firmen wird ja damitdas erste Malquasi bottom-up bewertet. Klingt jetzt leichter als es ist,es ist komplett unüblich bei den allermeisten,gerade großen Unternehmen,dass Mitarbeiter den Chef bewerten. Der Chef gibt Feedback,dein Vorgesetzter gibt dir Feedbackund du gibst deinem Untergebenen Feedbackund so weiter die Karriereleiter runter. Ja, aber dass wirklich top down, sorry, dass bottom up es eine Bewertung gibt mit Kommentaren, dass es irgendeine Form von Pulsfühlen oder Temperaturmessungen gibt in regelmäßigen Abständen, dass du auch ähnlich wie du auch bei dem NPS-Scoring das auch über die Zeit verfolgen kannst und schauen kannst, hey, ja, so dem Joel haben wir jetzt in diese Position gebracht. und wie entwickelt sich das Team, wie entwickelt sich das relativ zu anderen Teams, wie entwickelt er sich selber als Vorgesetzter, was sind denn da noch, was sind da Themen. Das ist, glaube ich, ein super wichtiges Werkzeug. Das, glaube ich, würde uns in anderen Bereichen der Gesellschaft auch guttun. Mein ältester Sohn soll jetzt bald eingeschult werden. Ich frage mich, warum gibt es das in den Schulen immer noch nicht? Warum gibt es niemanden, der den Lehrer bewerte? Wenn ich an meine Schule zurückdenke, da würden ganz viele durch so einen Raster fallen, weil sie einfach über einen konstanten Zeitraum hinweg durch verschiedene Klassen, verschiedene Jahrgangsstufen einfach schlecht bewertet werden würden für ihre pädagogischen Eigenschaften und eigentlich nicht in diesem Beruf arbeiten dürften. Und sicherlich auch in anderen Bereichen. Von daher, sowas ist, glaube ich, super relevant. Am Ende, wie man seine Task organisiert, das ist, glaube ich, erst mal relativ wenig relevant. Da muss man erst mal auch auf ein Level der Sophistication kommen, dass man da im Detail auch Unterschiede zwischen den Tools für sich herausarbeiten kann.

Joel Kaczmarek: Jetzt können wir uns mal rüberrobben zu einem Thema, was uns eigentlich dauerhaft begleitet, Agilität, so Boris. Und du bist ja immer so ein Verfechter von irgendwie Trial and Error als ultimative Methode für so ein bisschen Best Practice. Warum ist das so und welche Rolle spielt da vielleicht auch Technologie? Also wie bilde ich das in so einer Organisation ab? Warum ist Trial and Error irgendwie etwas für Agilität so Zentrales?

Boris Lokschin: Relativ simpel. Man muss da so ein bisschen runterbauen von dem Oberbegriff Kundenzentrierung, glaube ich. Das haben, glaube ich, jetzt mittlerweile alle verstanden, dass in einer kundenzentrischen Zeit, in der ich eben nicht von unten nach oben denke, sondern vom Kunden rückwärten, mir überlege, was macht denn Sinn? Nicht so diese klassische Asset-Verwertungssicht. Ich habe doch jetzt hier meine Läden oder meine Märkte oder meine Lieferflotte. Wie kann ich die denn noch einsetzen, sodass es einen digitalen Charakter bekommt? Sondern einfach, hey, was macht denn Sinn für den Kunden? Das ist ja eine Möglichkeit, direkt auch neue digitale Modelle zu bauen. Und da ist auch das OKR-Thema ein gutes, weil das erstmal nach dem Sinn fragt, nach dem Ziel fragt und nicht sofort irgendein Tool vorgibt. Wenn ich akzeptiere, dass wir in einer kundenzentrischen Zeit leben, dann akzeptiere ich auch, dass der Kunde, und das sind am Ende ja wir alle auch, relativ flüchtig ist und relativ springend in seinen Bedürfnissen und zwar über alle Bereiche hinweg. Welchen Service bevorzuge ich? Über welche Kommunikationskanäle möchte ich sprechen? Welches Device nutze ich für welchen Teil meiner Customer Journey? Heute finde ich das iPhone super, morgen finde ich das Android-Telefon toll. Heute ist Sprach, der Sprach ist ja noch doof und kann noch nicht genug, aber zwei Updates später ist er gut genug, um den Wecker zu stellen, um nach dem Wetter zu fragen und noch zwei Updates später kann ich auf einmal meine Rasierklingen und Wattepads bestellen. Also Technologie, Kundenbedürfnisse und andere Dinge, Wettbewerb verändern sich sehr schnell heutzutage in der digitalen Welt und das bringt mich in eine doofe Situation, weil das einfach vom Zyklus her auf einmal entkoppelt ist von dem, was man eben normalerweise an IT-Umsetzungsgeschwindigkeit vorher gewohnt ist, natürlich insbesondere durch Technologie. In der ERP-Welt, da hat Timo schon recht, da muss man auch scharf unterscheiden, Agilität, Trial and Error und Co. Wo brauche ich das? Brauche ich das in meiner Backend-Welt, in meiner ERP-Welt? Vermutlich nein. Es gibt einen guten Grund, warum es Standardsysteme gibt. Es gibt einen guten Grund, warum es Standardprozesse gibt, die gerade zum Beispiel in der Finanzbuchhaltung, die Regeln, Gesetzen und anderen regulatorischen Auflagen fördern. Da brauche ich keine 10 Deployments pro Tag zu machen. Da brauche ich auch keine MVP auszurollen. Das funktioniert einfach nicht gut. So, da bin ich sehr gut beraten, mich nah an diesem Standard zu orientieren. By the way, auch ein guter Link in Richtung dieser ganzen gescheiterten SAP-Projekte, wo hunderte von Millionen Euro versenkt werden, was schon für mich per Definition häufig keinen Sinn ergibt, wenn ich eine Standard-Applikation kaufe und dann, wie gestern gesehen, hat hier jemand wieder 90.000-Mann-Tage, 90.000-Mann, muss ich mir die Zahlen mal überlegen, sozusagen an Customizing auf sein SAP-System gestülpt. Das passt konzeptionell nicht, ja. Aber in dem Teil, wo man sich schnell ändern muss oder wo man sich sozusagen den Markt schnell anpassen muss, da muss ich flexibel darauf reagieren. Das ist keine Frage von, ob Timo und ich das cool finden oder jemand anders, sondern ich habe halt keine andere Wahl. Mir hilft PowerPoint nicht, mir hilft nicht zwölf Monate lang warten, mir kann McKinsey nicht sagen, wie mein Kunde in 24 Monaten wird kaufen wollen und welches Device Apple rausbringt und wie schnell sich irgendwie ein Sprachassistent entwickelt und ob Kunden per WhatsApp Customer Support machen wollen. Ich muss mir das erschließen. Und dieses Erschließen ist am Ende einfach eine ganz klassische Portfolio-Strategie. Genauso wie ich in Aktien investiere oder genauso wie ich als Pharmaunternehmen auch nicht nur ein Medikament zehn Jahre entwickle, sondern verschiedene Pferde im Rennen habe, überlege ich mir sehr Hypothesen getrieben und dafür, da kommen dann diese ganzen Themen Agilität, MVP, alle zusammen. Ich überlege mir, was möchte ich beweisen, was ist meine Business-Hypothese, was ist der kleinstmögliche Versuch, das zu tun, was ist die Metrik dahinter, die mir hinterher idealerweise Aussage gibt, ob dieses eine erste Experiment erfolgreich war oder nicht. Und dann ergibt sich quasi als Summe daraus dieses Trial-and-Error-Thema, dass ich dann eben die besagten zehn Versuche mache. Also es wird häufig verwechselt, auch in den Gesprächen habe ich das Gefühl, dass häufig Leute unter Agilität, MVP glauben, dass dadurch jetzt irgendwie irgendwas günstiger wird zum Beispiel. Das ist gar nicht der Fall, das ist gar nicht das Ziel. Das ist mehr so eine ROI-Optimierung. Ich versuche einfach statt einer großen Wette in zwei Jahren 20 kleine Wetten im selben Zeitraum zu machen. Ich gebe dadurch nicht weniger Geld aus, ich habe nicht weniger Ressourcen, die ich darauf allokiere, sondern wirklich ganz klassisch Portfolio-Strategie. Wohl wissen, dass ich eben nicht die Zukunft voraussagen kann, dass ich eigentlich gegen zehn sich drehende Räder performe. Wenn es in einer statischen Welt oder in einer Welt, in der ich 24, 36, 48 Monate Zeit hätte, das ausgedachte zu implementieren und dann den Erfolg zu messen, bräuchte ich das nicht. Die Welt ist aber nicht so. Die Welt ist deutlich schneller und deutlich kurzlebiger und insbesondere natürlich in der Technologie rotiert sich das einfach schneller. Deswegen Try and Error einfach als einzig mögliche Best Practice, die mir die Chance, das ist auch keine Erfolgsgarantie, die mir die Chance gibt, am Ende des Tages die zwei, drei, vier Konzepte, Ideen, Features, Produkte zu finden, die wirklich darauf einzahlen. Und der Florian Heinemann hier von Project Day, der hat das, glaube ich, in einem anderen Podcast auch mal ganz gut gesagt. Viele Unternehmen starten ja unter den denkbar schlechtesten Voraussetzungen, was die Digitalisierung angeht. Sie sind nicht in einer Digitalhauptstadt, was auch immer die ist. Sie sitzen nicht auf Geld, was sie komplett frei allokieren können, sondern müssen nicht das verdienen, müssen das ihren Eigentümern, Shareholdern erklären. Sie haben nicht Zugang zu unendlich digitalen Talent. Sie haben vielleicht nicht die richtigen Tools, Methodiken. Und dass gerade diese Unternehmen dann trotzdem der Meinung sind, komm, ich mache jetzt mal hier ein 36-Monats-Projekt und ich limitiere jetzt hier einmal eine responsivee Webseite oder einen Shop. Also ich wette jetzt mal auf eine einzige Sache, das ist schon sehr schwer nachzuvollziehen. Obwohl wir wissen, dass gerade diejenigen, die sie ja kopieren oder diejenigen, die denen die Marktanteile wegnehmen, die Emissions und Salar und so weiter in dieser Welt es genau umgekehrt machen. Ich habe die letzte kurze Anekdote dazu, ich erinnere mich gut. Ich bin hier gut vernetzt auch mit dem Zalando-Team und in den Anfangszeiten von Spryker. Wir hatten viele Kundengespräche und die Leute haben dann auf Zalando geschaut. Und Zalando hat zu dem Zeitpunkt ganz, ganz viele mobile Strategien. Die haben responsiv gemacht. Die haben angefangen mit Single-Page-Applications. Die haben native Apps. Und da haben die Leute immer gesagt, bei Zalando, die sind so schnell gewachsen, da ist alles außer Kontrolle geraten. Da hat keiner mehr den Überblick. Die machen drei, vier Sachen gleichzeitig. Da ist überhaupt gar nichts außer Kontrolle. Die machen das ganz bewusst so, die vertesten die Dinge und am Ende wird halt das gewinnen, was einfach die beste Performance bringt. Oder man wird herausfinden, wo ich an welchem Touchpoint was tue. Das ist meine Customer Journey. Aber mir ist jetzt kein anderer besserer Weg bekannt.

Joel Kaczmarek: Timo, hartes Ding. Wie macht man sowas? Viele Deployments, MVP-Geschichten, um Agilität zu steuern. Das musst du jetzt auf eine 2500-Mann-Organisation an acht Standorten hämmern, wo der Vorstand erstmal oder sozusagen das Board 80 so eine Anträge dann irgendwie alle sechs Monate durchdüngeln muss. Wie kriegt man das hin?

Timo Saldsieder: Erstmal sind 2500 Männer und Frauen bei uns, die da arbeiten. Ganz wichtig, weil ich das Thema einfach bei uns in der Organisation wichtig erachte. Ja, wie kriegt man es hin? Wie gesagt, es sind eh nicht alle, die sich damit beschäftigen, aber wir haben natürlich die Thematik, dass wir sauber balancieren müssen zwischen großen strategischen Initiativen, wo ich auch sage, okay, dass wir jetzt ein Omnichannel-Unternehmen werden, wollen werden. Das ist natürlich ganz klar. Aber es ist schon so, dass wir versuchen, jetzt diese agilen Prozesse von der Basis aus einzuführen. Das heißt, dass erstmal verstanden wird, okay, was ist denn Scrum? Also ein sehr methodischer Ansatz. Das ist durch eine Organisation. Ich glaube, die Organisation hat verstanden, wieso eine Methodik an sich funktioniert. Viel schwieriger ist bei dem agilen Thema einfach Mindset. Das heißt, dass eben auf einmal outcome-getrieben arbeite, dass ich sehr konzentriert arbeite, dass ich Experimente fahre, wie es Boris eben gesagt hat. Wobei man auch da sagen muss, dass Experimente halt nicht in allen Szenarien wirklich sinnvoll sind. Man stellt sich ein Kassensystem vor und auf einmal ist der Button nicht mehr links unten grün, sondern rechts oben rot. Als A-B-Test, das findet so ein Kassierer oder Kassiererin überhaupt nicht lustig. Also da macht zum Beispiel Experimente begrenzt Sinn, sondern da musst du so ein Programm einführen, da musst du die Mitarbeiter sauber schulen, weil sonst einfach die Effizienz losgeht. Das heißt, wir haben schon so ein paar Grundthematiken, wo agil nicht immer Sinn macht. Aber zurückkommen zur Frage. Wir sind schon schwerpunktmäßig damit beschäftigt, das methodisch einzuführen. Und das sorgt dafür, dass das ganze Unternehmen jetzt in diese Richtung auch mit tickt. Punkt.

Joel Kaczmarek: Und woher weißt du vorher, ob ein Bereich agil tauglich oder sozusagen affin ist oder nicht?

Timo Saldsieder: Also ich glaube, ein klares Kriterium ist erstmal, dass es Customer-Facing-Applikationen sind. Das heißt, wenn ich Endkunden drauf loslassen kann, und da haben wir aufgrund unserer Größe über 20 Millionen Kunden weltweit bedienen, dann natürlich entsprechend Traffic drauf, weil wenn du eine Webseite in Indien launchst und dann kriegst du relativ schnell da auch Traffic drauf, um sicherzugehen, dass es auch da vernünftig funktioniert. Da macht dann AB-Test automatisch Sinn oder Experimente, wohingegen es macht überhaupt keinen Sinn, wie gesagt, in einer SAP-Implementierung. Das heißt, aus meiner Sicht ist relativ klar ersichtlich, wann es Experimente tatsächlich als sinnvolles Paket dahinter Sinn macht. Manchmal macht es halt, wie gesagt, gar keinen Sinn und dann müssen wir auch das Start besser sein lassen. Also eine SAP-Implementierung auf Basis von Experimenten einführen, das würde man ziemlich sicher nicht tun.

Joel Kaczmarek: Okay, das ist simpel, aber wenn du dich intern verbessern willst in deinen Prozessen, was jetzt nicht Customer-Facing ist, woher weißt du da, was irgendwie sinnhaft ist zu testen und was nicht?

Timo Saldsieder: Jetzt drehen wir uns im Kreis, weil am Ende ist Outcome. Das heißt, wir versuchen alles zu messen und wie gesagt, beispielsweise vorher diese Picking-Geschichte, die wir hatten, da geht es schon eher darum, dass wir ja jetzt nicht versuchen, mehrere Picking-Applikationen den Pickern bereitzustellen, sondern wir fahren halt wahnsinnig viele verschiedene Applikationen parallel. Auch in verschiedenen Märkten, in verschiedenen Ländern, um zu schauen, welcher am besten funktioniert. Aber dass wir jetzt Experimente in der Form fahren, dass ein Picker x verschiedene Versionen parallel irgendwie bekommt und die ändern sich alle 10 Minuten, das passiert nicht.

Joel Kaczmarek: So, dann sollten wir uns mal KPIs ein Stück weit noch vornehmen, vielleicht so als einen der letzten Faktoren. Wie messt ihr all das? Zum Beispiel Agilität wäre so ein Faktor. Wie messt ihr, wie agil ihr seid oder wie schnell ihr in der Anpassung seid?

Timo Saldsieder: Wir versuchen super datengetrieben zu sein. Allerdings, dass wir jetzt Agilität messen in Form von Belastet, von Teams oder sowas, also das machen wir nicht. Deswegen Agilität als jetzt Kennzahl. Wir haben also eine Selbsteinschätzung der Teams gemacht, wie die sich denn so auf der Agilitätsstufe wahrnehmen. Und ich weiß jetzt nicht, wie repräsentativ das war, aber ich glaube, das war nicht wirklich aussagefähig. Deswegen, wir messen also grundsätzlich eher in die Outcomes, das heißt, was wirklich die Resultate der Applikationen sind. Aber dass wir jetzt die Agilität der Teams messen oder unsere Prozessqualität messen, das machen wir so in der Form nicht. Das heißt, wir messen zwar jetzt das Thema Employee Engagement, das hatte ich vorher gesagt, über 14 Kennzahlen. Und da sind auch so Themen wie Autonomy drin oder Kommunikation durchs Management. Also solche Kennzahlen messen wir schon auch. Ansonsten sind es halt harte Business Facts, wie zum Beispiel eben so eine Picking-Effizienz oder eine Conversion-Rate auf der Webseite. Solche Kennzahlen laufen rauf und runter. Wir versuchen auch den Teams das Thema Metrik gesteuert zu arbeiten, sehr nahe zu bringen, indem man idealerweise in jedem Team da ein Dashboard an der Wand hängt, wo ich nach jedem Deployment auch sehe, ob sich das Dashboard mit bewegt. Da sind wir noch ganz am Anfang, muss ich allerdings gestehen. Aber dieses datengetriebene Arbeiten, kundenzentriert arbeiten, das ist einfach so eine Grundkommunikation, die wir ins Team bringen, die in jedem Townhall-Meeting mehr oder weniger angesprochen wird. Und deswegen steht da Tropfenhüll den Stein und in die Richtung arbeiten wir halt.

Joel Kaczmarek: Oder vielleicht sollte man es auf so ein höheres Level heben. Was würdest du sagen, Boris, sind Daten, Informationen, die man mit KPIs erheben sollte? Woran erkenne ich sozusagen, was ich messen sollte und was nicht? Weil Interpretation von Daten ist ja dann immer so. das nächste Thema.

Boris Lokschin: Ja, das ist super abhängig davon, was sozusagen mein Business Objective ist. Was wir häufig sehen, ist, dass tatsächlich immer noch sehr, sehr hart fundamental Cost, Scope, Timeline betrachtet werden. So ein Team hat ja gerade ein paar Beispiele gebracht, aber gerade im Commerce oder im E-Commerce ist ja sozusagen Tracking sei Dank, kann ich ja wirklich alle betriebswirtschaftlichen Metriken mir angucken. Ich kann ein Feature bauen unter der Annahme, ich möchte eine Conversion Rate erhöhen. Ich kann ein Feature bauen unter der Annahme, ich möchte meine Absprungzahlen im Warenkorb senken. Ich kann ein Feature erhöhen, indem ich sage, ich möchte die Geschwindigkeit oder die Zahl der Produkte erhöhen oder die Geschwindigkeit, die die Zahl der Klicks, die ein Kunde braucht, um von, er ist auf die Seite gekommen, bis er etwas im Warenkorb oder er ist ausgecheckt erhöht. Ich kann aber auch strategischere Themen anwenden. Ein schönes Beispiel zum Beispiel, wenn ich mir überlege, gerade aus dem Online-Marketing, ich habe so einen Performance-Marketing-Mix und ich überlege mir, welcher Kanal taugt für Kundenakquisitionen, was sind Kundenakquisitionskosten pro Kanal? Jetzt denke ich nicht vom Feature auf, sondern umgekehrt und sage mir, wo kann ich unterproportional günstig Traffic einkaufen mit relativ wenig Aufwand? So, jetzt wieder dieses Beispiel von vorhin mit dem Thema Voice. Ich kann relativ günstig heute einen Skill bauen, einen Alexa-Skill, und ich kann sehr, sehr günstig sozusagen auf der Marketing-Vermarktungsskala den sehr hoch ranken lassen in dem entsprechenden Store, in dem entsprechenden App-Store. Also ich kann einen relativ guten Login erzeugen, also es ist deutlich leichter für mich, den, weiß ich nicht, ja, Wetterabfrage oder den Zeitungs-Abo-Nachbestell-Skill in irgendeiner Kategorie in den Top 3, 4, 5 erscheinen zu lassen. Viel, viel leichter und viel, viel günstiger, relativ zu den Kosten, die ich, bräuchte, um im SEO zum Beispiel erfolgreichoder im SEA mich hochzubekommenoder Geld für Amazon oder Facebook-Marketing auszugeben. Das heißt, ich habe auf einmalfür einen sehr klar umrissenen technischen Taskbaue mir den Skill A, der soll das und das könnenund der besteht aus zehn User-Storiesund da gibt es natürlich eine Schätzung dranund ein Budget habe ich irgendwie eine ganz, ganz andere Metrik, sondern ich möchte in den Top 3 ranken. oder ich möchte, dass 10% unserer Kunden über den WhatsApp-Customer-Service-Bot laufen oder ich möchte so und so viel Market-Share haben in dem Bereich Voice oder ich möchte so und so viel Market-Share haben in dem Mobile-Thema. Also umso strategischer ich mich dem zuwende, umso leichter ist auch alles andere darunter. Also da sind OKRs schon, glaube ich, ein sehr guter Ansatz. weil ich dann aus den Köpfen dieses Cost-Center-Sein rausbekomme. Ich glaube, das ist das, was auch am Ende, die wir uns, glaube ich, schön gesagt haben, mit dem Purpose für Developer, das kann ich auf jeden Fall unterstreichen, dieses Gefühl, ich bin Cost-Center, ich werde daran gemessen, ich muss einen Business-Case einreichen, da kommt jemand und sagt, uns geht es nicht gut, deswegen mache ich einen Cut, In der IT schmeiße ich jetzt irgendwie einen Developer raus, in einer Zeit, in der momentan, was die Digitalisierungsambitionen angeht, Leute nicht genug hiren können, weil einem klar ist, umso mehr kompetente Software-Ingenieure sich auf Themen tue, umso mehr kann ich in einer Trial-and-Error-Welt gleichzeitig vertesten, umso höher meine Wahrscheinlichkeit, auch die zwei, drei Dinge zu finden, die was bringen. Also da wird sozusagen auch der Wert von Engineering, von Product Management ganz anders eingeschätzt. Da bist du eben nicht die Kostenstelle, sondern bist du eigentlich auf der Value-Generierung-Seite der P&L. So, das ist, glaube ich, ein Prozess, der, und der muss wirklich top-down kommen, Wir hatten ja auch über dieses Thema Greenfield und Co. gesprochen. Manchmal gelingt es nicht oder nicht schnell genug,gerade in großen Unternehmen, diesen Prozess herbeizuführen. Was einfach dazu führt, dass man dann über kurz oder lang aus dem Markt ausscheidet. Und wenn das nicht so ist, dann ist einfach die beste Empfehlung,dann schafft euch Szenarien oder schafft euch Umgebungen,bei denen ihr legacyfrei eine Organisation bauen könnt,die nach solchen Parametern auch inzitiviert werden kann. Weil wenn am Ende des Tages der Geschäftsführer, der dann drüber sitzt,wenn sein Jahresbonus nur von Umsatz und eben derart ziehen abhängt,dann kann er noch der größte Verfechter seinund auf internen Messen sich coole Produkte angucken Wenn er merkt, das läuft nicht und da ist jetzt der fünfte Versuch, der gerade nichts gebracht hat, dann wird er relativ schnell da die Reißleine ziehen und einem relativ schnell das Budget hinziehen und relativ schnell einen Fixpreis einfordern. und relativ schnell ist McKinsey im Haus und macht mal eine kleine Review von dem Ganzen, was da passiert. Was ja auch ein Stück weit menschlich ist, das kann man demjenigen gar nicht vorwerfen. Dieser Appell geht wirklich mehr an die Eigentümer, an die Family Offices, an die Gesellschaft, an die Aktionäre. Wir brauchen grundsätzlich andere KPI, um in einer digitalen Welt zu steuern. Das sind dann nicht nur Umsatz oder Rentabilität, sondern das müssen eben auch andere Parameter sein, ja, so. Sonst werden es viele Unternehmen nicht schnell genug durch diese Transformationsprozesse schaffen.

Joel Kaczmarek: Timo, der letzte Punkt, den Boris jetzt angesprochen hat, Leute dazu zu animieren oder anzuregen, auch scheitern quasi in Kauf zu nehmen, also sich in so einen Prozess von Trial and Error zu begeben. Wie schaffe ich denn sowas über KPIs zu inzentivieren? Ihr habt jetzt gesagt, ihr macht keine Boni-Zahlungen mehr. Und wir haben vielleicht über euer Vimosa und die Outcome-Denke schon einen Teil der Antwort bekommen. Aber habt ihr trotzdem noch Werkzeuge, wie man quasi Leute inzentiviert, auch auf der KPI-Basis, Innovationen zu fördern und genau solche innovative Denke anzuregen?

Timo Saldsieder: Ja, also wie gesagt, inzentivieren ist bei uns jetzt nicht so sehr das Schlagwort. natürlich so Sachen ein, wie sogenannte Fuck-up-Nights, wo sich Leute auch hinstellen und sagen, ja, okay, das habe ich falsch gemacht. Da stehen auch Leute wie ich dann direkt auf der Bühne, um so ein Thema mit anzusprechen. Das heißt, wieder ein sehr kulturelles Thema, um einfach mal grundsätzlich auch die Ängste zu nehmen, dass es erlaubt ist, Fehler zu machen. Das heißt, bei uns fliegt keiner raus, weil er einen Fehler gemacht hat, sondern, gut, rausfliegen ist eh das falsche Wort, aber bei uns kriegt man eher Druck, wenn man versucht, Also Fehler sogar zu vermeiden, sondern wir möchten, dass die Leute sich positiv entwickeln. Und positiv entwickeln heißt halt, dass ich lerne. Und ich lerne halt am schnellsten, wenn ich Fehler mache. Und deswegen versuchen wir schon, uns in diese Richtung auch kommunikationsmäßig reinzubewegen. Ansonsten muss ich sagen, wir versuchen einfach sehr viel auch von oben vorzuleben. Also auch gerade das Beispiel Agile, was du vorher auch angesprochen hast. Wir sind in der Richtung unterwegs, dass wir auch hier zum Beispiel unser Management hier auf Board-Ebene, gab in der Vergangenheit eigentlich kein Board-Niveau, wo das Wort Agile nicht gefallen ist. Allerdings oft missverstanden. Also Agile als irgendwie chaotischer, schneller Prozess, der irgendwie deutlich mehr Geschwindigkeit bringt als das Wasserfallmodell. Realität sieht, wie Boris auch vorher gesagt hat, irgendwie ganz anders aus. Von daher ist es schon so, dass wir also auch da versuchen, sehr viel Training und Education zu machen. Sogenannte Tech-Masterclasses haben wir eingeführt, wo wir dann auch mal einen Nachmittag lang hier die Top-Management-Lego-Bausteine hier irgendwelche Sachen bauen, um einfach festzustellen, dass es eigentlich viel besser geht, wenn ich wiederum. Outcome getrieben, kundenorientiert auf einmal mit Legio versuchen, ein Haus zu bauen, wie wenn ich jetzt hier top-down wieder zum Thema annäher. Das heißt, diese gesamte Denke Richtung Agilität, was wie gesagt nicht immer die Lösung zu allen Problemen ist, die versuchen wir eigentlich gesamteilig in unserem Leben einzubringen. Und deswegen ist auch das Thema Objectives and Key Results, was am Ende auch eine agile Methodik ist. Etwas, was wir versuchen gerade im Gesamtunternehmen einzuführen. Das heißt, auch unser Top-Management ist jetzt nicht inzentiviert nur auf Umsatz und EBIT, sondern auch da laufen Business-Kennzahlen, die man so normalerweise nicht sieht. Also beispielsweise NPS ist bei uns eine Kennzahl, wo das Top-Management inzentiviert ist, aber auch so Business-Kennzahlen wie Stock-Days. Das heißt, wie lange ist ein Produkt bei uns auf Lager, also Schlage-Umsatz-Häufigkeit ist bei uns da so ein Kennwort. Und entsprechend sind wir da auch kennzahlenmäßig in ein bisschen einer anderen Welt inzwischen unterwegs, also nur über Umsatz und EBIT.

Joel Kaczmarek: Vielleicht sagen wir nochmal ein, zwei Sätze zum Thema OKRs. Also steht für Objectives and Key Results. Man verschreibt sich selber Zielsetzungen und hinterfragt, was sind sozusagen Ergebnisse, mit denen ich diese Objectives als erfüllt ansehen würde. Eine Methode, die, glaube ich, von IBM entwickelt wurde, wenn ich mich richtig entsinne, und durch Google bekannt geworden ist.

Timo Saldsieder: Intel.

Joel Kaczmarek: Intel, danke schön. Und ich habe es immer so verstanden, dass das auch ein Tool ist, um sehr viel Transparenz herzustellen und auch so ein bisschen so eine Gleichschaltung. Also nicht Gleichschaltung im Sinne von, wir sind jetzt alle gebrainwashed, sondern wir arbeiten gemeinsam auf Ziele hin. Wie setzt ihr das konkret bei euch um? Was braucht es dafür?

Timo Saldsieder: Die Herausforderung bei diesem Thema OKR ist, ein Alignment hinzukriegen zwischen Management und Mitarbeiterebene. Und zwar, wir machen einen Top-Down, also einen Bottom-Up-Ansatz. Das heißt, es gibt strategische Objectives, die von oben vorgegeben werden. Das heißt, wir versuchen jetzt die nächsten zwölf Monate, uns auf diese fünf Objectives zu konzentrieren. Und dann arbeitet das Unternehmen in diese Richtung. Und gleichzeitig ist es den Teams erlaubt, dass sie quasi mit eigenen Objectives kommen, die ideal sind, auf diese fünf Top-Level-Objectives einzahlen. Und dann gibt es relativ aufwendig Alignment-Meetings, die wir in sogenannten Chapters organisieren. Das heißt, wir haben einzelne Bereiche, weil wir einfach so groß sind, wo dann irgendwie 40, 50 Teams zusammengeschaltet werden in einem Chapter und dort dann versuchen, tatsächlich sich zu alignen, weil das Thema Dependency-Management ist somit das Komplexeste. Das heißt, es kann durchaus sein, dass ein Team in Richtung A marschiert und ein anderes Team in Richtung B. Und deswegen helfen also die Alignment-Meetings, dass wir da sauber abgestimmt sind. Und am Schluss kommt da ein großer Objective and Key Results-Tree zustande, auch toolgestützt. Da ist jetzt im Augenblick noch ein Tool, eines Uprace heißt. Aber wir sind gerade dabei, uns ein sehr schickes Tool von einem kleinen Startup aus München anzuschauen, namens WorkPath. Kann ich also wärmstens empfehlen, sich das mal anzuschauen. Das ist halt sehr transparent. Also eine Webseite, wo ich mich dann durch die gesamten Objectives und Key Results der gesamten Firma durchklicken kann. Die Resultate komplett transparent für jeden Mitarbeiter sind. Dort auch Check-Ins gemacht werden alle zwei Wochen, um einfach darzustellen, wo wir im Augenblick sind. Das heißt, sehr viel Kommunikation auch über das Tool, wo ich also auch Kommentare abgeben kann und auch Kommunikation mit Mitarbeitern führen kann, meine Kennzahlen regelmäßig aktualisieren kann. Und das hilft einfach, dass die Mannschaft sich sehr stark fokussiert und einfach auch gemeinsam in eine Richtung marschiert.

Joel Kaczmarek: Spannend. Ich glaube, wir hatten heute eine extrem hohe Informationsdichte, haben viel abgegrast.