Luca Fornaroli: Technischer Erfolg — Einblicke in den Aufbau und die Skalierung von Tech-Hubs

Diese Transkription des Podcasts ist KI-generiert und kann Fehler oder Ungenauigkeiten enthalten.

Leszek

Mein Name ist Leszek und ich werde mit Luca Fornaroli über die Skalierung von Teams durch Fusionen und Übernahmen sprechen. Also lass uns mit deiner Reise beginnen. Was hat Sie zu Ihrer aktuellen Rolle als technischer Direktor und Vorstandsmitglied bei Scale Up A geführt? Ja.

Luca Fornaroli

Also erstmal danke für, für die, für die Zeit und für die Gelegenheit. Meine Karriere war ziemlich seltsam. Was ich meine ist, dass ich nur in zwei verschiedenen Unternehmen gearbeitet habe. Ich habe mehr als 10 Jahre bei Viva Ticket gearbeitet, einer Ticketfirma, und im Grunde haben wir das Ticket- und Eintrittssystem für das Park Museum entwickelt, ich meine, was auch immer es braucht, um zugelassen zu werden. Ich habe dort als Junior-Entwickler angefangen und dann, weißt du, bin ich aufgewachsen, bis ich der C, der CTO des Unternehmens wurde. Also weißt du, ich habe wirklich von Grund auf angefangen und dann habe ich das C-Level erreicht. Die C-Level-Position war eine ziemlich unterhaltsame Reise, weil ich sehr, sehr jung war und das Unternehmen stark gewachsen ist.

Also weißt du, es war wirklich eine großartige Gelegenheit, viele verschiedene Dinge in Bezug auf ein neues Projekt, einen neuen Markt, die Arbeit mit einer anderen Kultur, weißt du, die Arbeit in einem sehr anspruchsvollen Sektor wie dem Ticketing zu sehen. Und so habe ich dort gelernt, wie man Teams leitet, internationale Projekte leitet und auch, wie man Teams skaliert, denn als ich zum CTO ernannt wurde, hatte ich 250 Leute hinter mir, sowohl in den Bereichen Technologie, Produkt, Infrastruktur als auch Daten. Also musste ich ziemlich schnell lernen, wie man bei der Arbeit mit sehr großen Aufgaben zurechtkommt. Ja, ja, auf jeden Fall. Ja, das war, das hat Spaß gemacht, weil wir auch durch M und A stark gewachsen sind und im Grunde genommen jedes Jahr ein neues Unternehmen hinzukamen und das war ziemlich herausfordernd und unterhaltsam, weil Sie wissen, Sie müssen anfangen zu verstehen, wie eine neue Software funktioniert, welche Herausforderungen das Unternehmen hatte. Und das Wichtigste war, zu verstehen, wie man alles zusammenführt und wie man auch ein Produkt zusammenführt oder aussetzt, aber gleichzeitig zu verstehen, wie man weitermacht und Teams zusammenführt. Das war also eine gute Schule für mich.

Und dann, nach 14 Jahren, habe ich beschlossen, das Unternehmen zu verlassen, weil ich nach etwas Neuem gesucht habe. Ich war auf der Suche nach neuen Herausforderungen, denn was ich wirklich liebe, ist, sicher zu sein, dass das Unternehmen, die Produkte und das Team wachsen und immer größer werden und im Grunde war meine Reise dorthin so gut wie abgeschlossen. Und dann habe ich beschlossen, einem Startup beizutreten, das Scala Pay heißt, und wir haben ein Fintech, das im Buy Now- und Pay-Bereich aktiv ist. Im Grunde ermöglichen wir unseren Kunden also, in drei oder vier Raten ohne Zinsen zu kaufen. Als ich anfing, war Scalapi ein Startup, aber mit klarem Weg, ein solides Unternehmen zu werden. Ich bin Ende 2021 beigetreten und das Unternehmen wurde 2022 ein Einhorn. Sie wissen also, ich wurde im Grunde genommen beauftragt, das Technologiezentrum in Mailand aufzubauen, weil einer, weil einer von ihnen, weil das Unternehmen von zwei Mitbegründern gegründet wurde, einem Italiener und einem Australier, und der Australier ist auch der CTO.

Ganz am Anfang war das Team also die Basis, das Innere, in Australien, während 99% unseres Geschäfts in Südeuropa lagen. Also Italien, Frankreich, Spanien und Portugal. Also braucht das Unternehmen wirklich einen Entwickler vor Ort und in der Nähe des Unternehmens. Und im Grunde wurde ich beauftragt, ein solches Team und dieses neue, neue technische Zentrum aufzubauen, und das war wirklich, wirklich gut für mich, denn wie ich Ihnen bereits sagte, was ich wirklich liebe, ist, das sicher zu sein und das Unternehmen wachsen zu lassen, das Team wachsen zu lassen, das Produkt wachsen zu lassen. Für mich war das eine Art Neuanfang und es hat mir sehr viel Spaß gemacht, weil, weißt du, du, ich, ich, ich, ganz am Anfang einen Schritt zurückgetreten bin, weil ich, weißt du, viele Leute auf der ganzen Welt geleitet habe, um quasi der erste Techniker in Mailand zu sein. Aber es hat Spaß gemacht, weil Sie wissen, Sie müssen anfangen, das Produkt zu verstehen, Sie müssen anfangen, den Markt zu verstehen, die Regulierung. Ich meine, ich war nie mit Zahlungen konfrontiert und bin im Grunde zu einem Fintech gewechselt, das ein ziemlich komplexer Bereich ist, und das hat Spaß gemacht und weißt du, ich konnte ein sehr gutes Team zusammenstellen, das jetzt sehr, sehr eng mit dem australischen Büro zusammenarbeitet.

Also war, ich meine, es hat viel Spaß gemacht, um ehrlich zu sein. Das ist eine kleine Herausforderung, weißt du, aufgrund des Zeitunterschieds zwischen Mailand und Sydney. Aber wissen Sie, in diesem Fall habe ich wirklich, sehr schnell gelernt, wie man offline arbeitet, wie man alles dokumentiert, wie man, Sie wissen schon, Teams und Menschen von zwei verschiedenen Orten der Welt ermöglicht, weiterhin zusammenzuarbeiten. Das ist also meine Reise.

Leszek

Bevor wir zu Ihrer Rolle, Ihrer Rechenschaftspflicht und der Ausweitung des Unternehmens übergehen, möchte ich eine weitere Frage zu Ihren Ausführungen stellen: Was war das Geheimrezept für die Integration so vieler Unternehmen in so kurzer Zeit? Sie sagten, Sie hätten eine Akquisition pro Jahr hinzugefügt, und das muss eine ziemliche Herausforderung gewesen sein, um sie tatsächlich erfolgreich zu machen. Gibt es eine geheime Zutat, die Sie in diesem Zusammenhang mit uns teilen können?

Luca Fornaroli

Mein Geheimtipp war also, von Anfang an involviert zu sein, denn wissen Sie, ich war Teil des Teams, das die gesamte Due Diligence durchführte und, Sie wissen schon, von Anfang an versuchte, eine Beziehung zu den wichtigsten Stakeholdern aufzubauen. Und ich habe viel Zeit damit verbracht, zu reden und die neuen Büros zu besuchen. Du weißt schon, versuche zusammen zu bleiben, Leute zu treffen, zu reden, mit Leuten zu reden. Und ich habe auch gelernt, dass man, wenn man Menschen davon überzeugen will, zusammenzuarbeiten, erklären muss, warum und welche Vorteile es hat, wenn man ein bestimmtes Verhalten ändert oder ein gemeinsames, gemeinsames Muster anpasst oder annimmt. Denn wissen Sie, die wirklich große Herausforderung bestand darin, dass wir Unternehmen aus anderen Teilen der Welt akquirierten, die unterschiedliche Programmiersprachen verwendeten, die unterschiedliche Geschäftstätigkeiten verfolgten, die einen anderen Geschäftsansatz verfolgten. Also weißt du, das war der bessere Teil. Also, was ich jedes Mal gemacht habe, war okay. Lasst uns versuchen zu verstehen, wie sie funktionieren und ob es Sinn macht, dass sie zu einem gemeinsamen Muster übergehen oder ob wir unseren gemeinsamen Weg anpassen können.

Aber weißt du, nimm dieses Unternehmen und auch dieses Team an und versuche es.

Leszek

Um das Beste aus beiden zu behalten. Irgendwie. Irgendwie das Beste von beidem. Ja, nimm das Beste von beiden.

Luca Fornaroli

Ja. Und versuchen Sie auch, alle über den Fortschritt des Unternehmens und den Grund für jede Entscheidung, die das Unternehmen getroffen hat, auf dem Laufenden zu halten. Ich meine, wenn Sie klar sind und wenn Sie offen und transparent mit Menschen umgehen, wird uns das sehr helfen, wenn Sie auch Menschen, Teams und Produkte integrieren müssen.

Leszek

Ich würde gerne mit Ihnen sprechen, in Ihre Rolle eintauchen und bin neugierig auf Ihre Verantwortlichkeiten, Ihre Rechenschaftspflicht und vielleicht eine weitere Frage. Wie schneiden sie im Vergleich zu einer Rolle als CTO ab?

Luca Fornaroli

Ja, also wie ich Ihnen bereits gesagt habe, bin ich jetzt zum technischen Direktor hier in Scala Bay ernannt. Und meine Verantwortung besteht im Wesentlichen darin, sicherzustellen, dass alle Teams das liefern, was das Unternehmen will, und auch mit dem CTO zusammenzuarbeiten, um das zu gestalten. Darüber und über die technische Roadmap. Was ich also im Grunde täglich mache, ist, dass ich sicher sein muss, dass mein Team glasklar ist, was es tun muss. Und es gibt keine und es gibt keine Blocker. Und versuche auch, dem Team so viel Verantwortung wie möglich zu übertragen, denn ich liebe es zu arbeiten, dass wir, ich möchte, dass das Team für einen bestimmten Teil unseres Workflows verantwortlich ist, wie du weißt schon, Zahlungen, Checkout, was auch immer das ist. Und dann arbeite ich mit ihnen zusammen, versuche es und fordere sie heraus, die volle Verantwortung für diesen Teil in Bezug auf Anforderungen, Erfassung, Entwicklung, Zuverlässigkeit und Einhaltung der KPIs zu übernehmen.

Das ist also meine Hauptverantwortung. Wie ich Ihnen schon sagte, kommt der CTO im Grunde vom anderen Ende der Welt. Ein Teil meiner Pflicht besteht also auch darin, sicherzustellen, dass ich, wenn es ein technisches Problem gibt oder das Unternehmen eine technische Antwort benötigt, dies tue. Ich meine, wenn ich kann, werde ich es tun. Sonst warte ich darauf, dass er, zu, zu, aufwacht. Aber im Grunde mache ich ein Software-Shield vor ihm, weil das Geschäft wirklich, wirklich anspruchsvoll ist und wir versuchen wirklich, so unabhängig wie möglich von den täglichen Aktivitäten von ihm zu sein. Denn der wahre Unterschied zwischen meiner Rolle und der CTOI-Rolle besteht darin, dass meine Aufgabe darin besteht, sicherzustellen, dass die Teams ihre Arbeitsfristen einhalten und die Plattform verfügbar ist, ist, verfügbar ist.

Sie wünschen sich also eher eine Ausführung, während die Rolle des CTO derzeit aus zwei Hauptgründen eher eine strategische Rolle spielt. Der erste ist, dass er einer der beiden Mitbegründer ist, der natürlich Teil der großen Strategie des Unternehmens ist, aber auch, weil er sich auch wie der Chief Product Officer verhält. Im Grunde genommen ist er derjenige, der sich mehr mit dem Geschäft befasst, um zu verstehen, was das nächste Feature ist oder welche neuen Änderungen oder neuen Produkte wir auf den Markt bringen wollen. Im Grunde trage ich die volle Verantwortung für die beiden Tech-Ups, den italienischen und den australischen. Außerdem arbeite ich sehr, sehr eng mit dem Produktdirektor und dem Direktor der Angebotsinfrastruktur zusammen, während QA im Grunde genommen Teil meiner gesamten Verantwortung ist.

Leszek

Okay, und wie organisiert man ihre Teams? Es gibt ein paar von ihnen. Wie bringt man sie zusammen, wie passt man sie an? Wie orchestriert man im Grunde all diese Teams so, dass sie gemeinsam auf ein Ziel hinarbeiten?

Luca Fornaroli

Ja, wir arbeiten also so, dass wir viele kleine funktionsübergreifende Teams haben, die sich aus einem Product Owner, einem technischen Leiter, je nach Bereich ein oder zwei Entwicklern und einem QA-Mitarbeiter zusammensetzen. Und im Grunde sind sie für die Verwaltung einer einzelnen Branche unserer Plattform verantwortlich. Es gibt also ein Team, das sich dem Zahlungsverkehr widmet, eines, das sich dem Checkout widmet, eines, das sich dem Risiko widmet, eines dem Marketing. Und im Grunde hat dieses Team das volle Eigentum an seiner Domain. Der Product Owner arbeitet also mit, mit dem, mit dem Unternehmen zusammen, um das herauszufinden und die Arbeit zu versenden. Und dann arbeitet der Product Owner mit dem technischen Leiter zusammen, um das Lösungsdesign zu erstellen. Und sobald dies vereinbart ist, ist das Team in der Lage, das zu entwickeln und zu liefern, was zwischen dem Geschäftsleiter und dem technischen Leiter vereinbart wurde.

Natürlich gibt es viele Teams, die miteinander verbunden sind, denn wenn Sie eine neue Funktion starten möchten, die vielleicht an der Kasse vorgestellt wird, müssen Sie mit dem Zahlungsteam oder dem Serviceteam sprechen. Wir arbeiten also so, dass wir sechs Wochen im Voraus planen und im Grunde jedes Team eine Liste von Aktivitäten bereitstellt, die in jeder Woche durchgeführt werden. Und bevor wir es festschreiben, teilen wir dieses Board mit dem gesamten Team und jedes Team kann alle Abhängigkeiten, alle fehlenden Punkte oder alle Verbindungen löschen, die nicht nur zwischen den Teams, sondern vielleicht auch in der Infrastruktur oder mit dem Datenteam hergestellt wurden. Wir versuchen also wirklich, die Verbindung und Interaktion auf visuelle Weise herzustellen. Wir verwenden also eine Spiegeltafel mit einer Schwimmlinie für jedes Team und im Grunde gibt es Pfeile, die von einem Team zum anderen gehen, um zu sagen, okay Leute, wenn ich das in Woche drei liefern muss, dann brauche ich von diesen anderen Teams etwas in Woche zwei. Okay, wenn du das brauchst, dann brauche ich dieses Stück Infrastruktur dazwischen. Also, weißt du, wir verbringen in der ersten Woche viel Zeit damit, alles herauszufinden, was wir brauchen.

Aber dann hat das Team fünf Wochen Zeit, in denen es sich wirklich, wirklich darauf konzentriert, zu liefern, weil alles glasklar ist und jedes Team genau weiß, was Sie liefern müssen, um kein anderes Team zu blockieren. Aus technischer Sicht haben wir auch eine Art Ausschuss eingerichtet, der das neue, das neue Feature vom technischen Standpunkt aus billigt oder ablehnt. Sobald das Team die Lösung genehmigt hat, ist das Team in der Lage, sie bereitzustellen, und niemand aus dem anderen Team kann sagen, Leute, es gefällt mir nicht oder warum ihr so rein, rein, rein gemacht habt. Das haben wir letztes Jahr implementiert, weil, wie Sie wissen, oft passiert ist, dass die Leute mit der Lösung nicht zufrieden waren. Im Grunde genommen verbrachte das Team also viel Zeit mit der Umsetzung, und dann waren sie es, sie wurden am Ende mit der Lösung herausgefordert. Also beschlossen wir, diese Art von Arbeit einzustellen. Und das hat uns geholfen, die Lieferzeit um ein Vielfaches zu verkürzen, weil Sie wissen, wir können genehmigte Mittel entwerfen, okay, andere Änderungen sind nicht erlaubt.

Und so wurde alles viel einfacher für uns.

Leszek

Dazu habe ich zwei weitere Fragen. Also, wer ist im Ausschuss und was ist sozusagen der Polarstern, um diese Entscheidungen zu treffen? Geht es um Geschäft, Umsatz, Nutzer, technische Machbarkeit? Was ist die Art, du weißt schon, die Art und Weise beschreibt, wie sie diese Entscheidungen treffen?

Luca Fornaroli

Ja, der Ausschuss besteht also aus mir, dem CTO, den beiden technischen Managern, demjenigen, der den italienischen Hub leitet, und dem, der den australischen leitet, dem Chefingenieur und zwei Leuten von der Infrastruktur. Und im Grunde überprüft dieser Ausschuss das Lösungsdesign, das uns der technische Leiter vorlegen muss. Vor dem Schreiben einer Codezeile im Grunde auf, auf einer neuen, auf einer neuen Funktion. Und was wir wollen, ist sicherzugehen, dass wir, wissen Sie, ein gemeinsames Muster für verschiedene Dinge verwenden. Dass wir uns um Datenbanken in Bezug auf Namenskonventionen, Skalierbarkeit und Interaktion gekümmert haben, dass wir uns um die Beobachtbarkeit gekümmert haben und dass wir uns auch um Tests und KPI gekümmert haben. Was ich wirklich jedes Mal frage, ist okay Leute, es ist okay. Aber wie können wir messen, ob das, was wir liefern, den Wert bringt, den wir erwarten?

Und welche Dashboards planen wir zu erstellen, um diese neue Funktion oder diese neue Infrastruktur auch in Zukunft zu überwachen? Das sind also die Aspekte, um die wir uns kümmern. Und außerdem, wissen Sie, ist dieser Ausschuss auch dafür zuständig, zu entscheiden, ob eine neue Technologie, ein neuer Dienst oder ein neues Tool in unsere, in unsere Codebasis aufgenommen werden kann. Um Ihnen ein Beispiel zu geben: Letzten Monat haben wir beschlossen, OpenSearch als Datenbank einzuführen, weil wir in unserem Toolkit keine Art von Index hatten. Das Team war damals eines, das dafür verantwortlich war. Okay, es zu verstehen, macht Sinn, wenn nicht, wie können wir es üblicherweise in unsere Codebasis integrieren? Wer aus dem Infra-Team ist für die Implementierung, Wartung und Überwachung verantwortlich?

Dieses Team ist also auch wirklich der Kern unseres Entwicklungs- und Softwareentwicklungszyklus.

Leszek

Cool, danke dafür. Und nur eine Folgefrage dazu, die für mich immer interessant ist. Warum hast du sechs Wochen gewählt? Hast du es mit verschiedenen Arten von Zeitboxen versucht und diese funktioniert besonders für dich oder ist es zufällig passiert? Können Sie uns die Gründe dafür nennen.

Luca Fornaroli

Ja, also die Grundidee war, dass sechs Wochen mehr als genug sind, um ein Feature von Anfang bis Ende abzuliefern. Also haben wir damit angefangen und festgestellt, dass das der richtige Zeitpunkt war. Und außerdem, weißt du, dass es, es könnte ein bisschen länger erscheinen. Und die Realität ist, dass das stimmt, ein bisschen länger ist, aber das, weißt du, ermöglicht es uns, uns auch um die technische Tiefe zu kümmern oder auch um all die Nebenaufgaben zu kümmern, die mit einer Funktion verbunden sind, weil du weißt schon, vielleicht in drei Wochen und dann haben wir die zusätzlichen zwei oder drei, um das Dashboard zu erstellen, die Analysen zu überprüfen, die richtige Dokumentation zu erstellen. Und das ist der Grund, warum wir uns für die sechs Wochen entschieden haben. Cool.

Leszek

Können Sie uns einen kleinen Einblick geben, wie es ist, ein Unternehmen wie dieses zu leiten und zu leiten, das gleichzeitig ein wachsendes Unternehmen ist? Es befindet sich in einem Bereich, der stark reguliert ist. Wie ist es, Ingenieurteams in einer solchen Umgebung zu leiten?

Luca Fornaroli

Ja, das ist eine gute Frage. Und dazu kommt noch die Tatsache, dass wir erst vor einem Jahr ein reguliertes Unternehmen geworden sind. Und so haben wir auch den Schock, von einer völlig ungeregelten Arbeitsweise zu einer vollständig regulierten Arbeitsweise überzugehen. Im Grunde genommen macht es ziemlich viel Spaß, deine Frage zu beantworten, weil, weißt du, wir versuchen, der OKR-Arbeitsweise zu folgen, und deshalb erstellen wir OKR für jedes Quartal. Aber das Geschäft läuft wirklich, sehr schnell. Und so kommt es oft vor, dass sich OKR, weißt du, ändern oder anpassen, wenn du das möchtest. Es ist also eine herausfordernde Zeit für die Teams, denn wie ich Ihnen bereits sagte, versuchen wir, im Voraus zu planen.

Also, wissen Sie, wenn die Unternehmen ihre Meinung ändern, müssen wir verstehen, was zu tun ist. Ich meine, müssen wir das, was wir tun, zu Ende bringen? Müssen wir, du weißt schon, ein neues Projekt von vorne beginnen, wie erklärt man das dem Entwickler? Und das ist also der herausfordernde Teil. Ich denke, dass, weißt du, alles mit der Art von Leuten zusammenhängt, die du mitbringst, die du mit an Bord bringst. Ich meine, unser Team ist ziemlich jung und es gibt eine Menge talentierter Leute, die auch wütend sind, wenn man das wünscht. Also, wisst ihr, es ist auch einfacher für sie zu sagen, okay, das funktioniert nicht, lasst uns zum nächsten Projekt übergehen, oder okay, Leute, wir arbeiten im Miniab, um das zu liefern.

Aber wissen Sie, jetzt sahen wir ein anderes Geschäft, eine andere Geschäftschance. Deshalb denke ich, dass unser Team es jetzt ziemlich gewohnt ist. Ganz am Anfang war es etwas schwieriger, vor allem, weil das Unternehmen in den letzten anderthalb Jahren viel stärker gewachsen ist und das Team im Grunde auch ein bisschen gestresst und gestreckt war. Also, weißt du, ich denke, dass es Teil meiner Arbeit ist, dem Team noch einmal den Grund dafür zu erklären. Und sobald Sie in der Lage sind, genau den Grund dafür zu erklären, ist es für sie einfacher, mit an Bord zu gehen und, Sie wissen schon, zu einem anderen Projekt zu wechseln. Und was wirklich, wirklich gut funktioniert, zumindest für mich, ist, ihnen ihre Ergebnisse der Welt zu zeigen. Was ich damit sagen will, ist, dass ich sie während der Entwicklungsphase sehr herausfordere, um sicherzugehen, dass das, was sie tun, irgendwie messbar ist und es einfacher ist, KPIs für das Feature zu erstellen.

Also, weißt du, wenn sie zu einem anderen Projekt wechseln und dann das, das, das Projekt liefern und du ihnen zeigen kannst, nimm, nimm, nimm, schau dir das Ergebnis an, das du erreichst. Dann ist es beim nächsten Mal einfacher, sie in ein anderes, in ein anderes Projekt zu bringen. Kurz gesagt, versuchen Sie, den Grund dafür zu erklären, denn jedes Mal, wenn wir den Plan ändern, gibt es einen Grund dafür. Dann könnte es einen guten oder einen besseren Grund dafür geben, aber zumindest gibt es einen Grund dafür. Und zeigen Sie, wenn das Projekt abgeschlossen ist, den wahren Nutzen, den es gebracht hat. Das hat mir also sehr geholfen. Der Übergang von einem nicht regulierten Umfeld zu einem regulierten Umfeld war eine Herausforderung.

Eine Herausforderung, weißt du, weil du es musst. Unser Kern, unser zentraler KPI zu der Zeit, als wir ein reguliertes Unternehmen wurden, war okay. Lassen Sie uns so schnell wie möglich wachsen und vielleicht lassen Sie uns ein bisschen die Datenqualität opfern oder die, Sie wissen schon, die Art der Kontrollen oder wie streng wir waren. Als Sie ein reguliertes Unternehmen wurden, müssen Sie sich um die Datenqualität kümmern. Sie müssen sicherstellen, dass alle Kästchen in Bezug auf die Einhaltung der Vorschriften, die Identitätsprüfung usw. aktiviert sind. Und das hat unser Wachstum ganz am Anfang ein bisschen gestoppt, einfach weil es einen Teil des Unternehmens gab, der immer noch auf das Wachstum drängte, während es einen anderen Teil des Unternehmens gab, der sagte, okay, es ist okay zu wachsen, aber wir müssen wirklich darüber nachdenken, weil es sonst ein großes Problem sein wird. Also haben wir diese Reise in den letzten quasi eineinhalb Jahren hinter uns. Jetzt ist es viel besser.

Und wieder einmal, was sich geändert hat, war, dass wir anfangen, besser zu erklären, warum einige Checks da sind, warum die Datenqualität so wichtig ist und so weiter. In diesem Fall war es also wieder meine Verantwortung, dass wir alle an einem Strang ziehen, einige KPIs und Kennzahlen extrahieren und dann darüber diskutieren, wie sauber das ist.

Leszek

Okay, aber danke dafür. Ich habe eine weitere Frage, die lautet, dass es für mich einfacher ist, mir vorzustellen, die Ausrichtung über OKRs in Umgebungen oder Kontexten vorzunehmen, die einfacher zu messen sind. Ich kann mir zum Beispiel vorstellen, dass es einfacher ist, KPIs für die Infrastruktur festzulegen, bei denen es sich entweder um Durchlaufzeit, Zuverlässigkeitskennzahlen oder was auch immer handelt. Aber es ist schwieriger, normalerweise schwieriger, KPIs zu ermitteln, die sich auf das Produkt selbst beziehen, weil einer von ihnen normalerweise hinterherhinkt. Ich meine, bei den Ergebnissen, die Sie beobachten, beispielsweise bei der Bereitstellung eines Features, dauert es einige Zeit, bis Sie sie tatsächlich sehen, dass Sie im Grunde genommen relevante Stichproben haben können. Und zweitens, bevor es tatsächlich soweit ist, dauert es einige Zeit, bis die Daten eintreffen. Und für mich ist es wirklich schwierig, diese Produktkennzahlen sozusagen in Okrs eingebettet zu haben und, Sie wissen schon, verdaulich zu sein, sie für die Teams verdaulich zu machen.

Und ich habe mich gefragt, wie man Produktkennzahlen für das Entwicklungsteam einbettet, Sie wissen schon, OKR, damit es funktioniert, sie verstanden werden, ein angemessener Zeitrahmen überprüft wird usw.

Luca Fornaroli

Ja. Also ich denke, wir haben eine gute, eine gute Balance gefunden. Also was passiert ist, ist, dass unser Führungsteam ihnen ein Ziel gesetzt hat, wissen Sie, die Anzahl der aktiven Kunden zu erhöhen, die Anzahl der monatlich aktiven Kunden um 10% zu erhöhen oder Sie wissen schon, ein neues Monetarisierungsprojekt für X Millionen zu finden. Und das ist also die Art von Ziel, das sich das Führungsteam vorgibt. Und dann ist jedes Team in der Lage, zu verstehen, was zu tun ist, um dieses Ziel zu erreichen. Das Team ist also dasjenige, das das wichtigste Ergebnis im Zusammenhang mit diesem Ziel erzielt. Die Art und Weise, wie wir das machen, ist jetzt ziemlich einfach.

Was ich meine ist, dass wir viele Experimente durchführen, um unsere, unsere Idee zu validieren. Nehmen wir an, wir wollen die Anzahl der monatlich aktiven Kunden erhöhen. Also sagt das Team okay, ich möchte diese testen, ich möchte diese testen und ich möchte das testen. Also führen wir ein sehr einfaches Experiment durch und dann fangen wir an, einen Prozentsatz unseres Kundenstamms einzubeziehen, und dann sehen wir Ergebnisse, die auf diesen experimentellen Ergebnissen basieren. Dann können wir sagen, okay, das scheint zu funktionieren und das sind die Verbesserungen, die von uns erwartet werden. Okay, das funktioniert nicht, also lassen Sie uns es parken oder okay, wir führen dieses Experiment durch, das uns ein Softwareergebnis liefert, das wir nicht erwarten. Schauen wir uns das mal genauer an.

Also im Grunde ist es das Team, das das wichtigste Ergebnis erzielt. Natürlich gibt es auch einige KPIs, die eher technologiebezogen sind, wie Sie wissen, die Verfügbarkeit der Plattform oder die Kosten der Plattform oder was auch immer, sodass diese auf eine andere Art und Weise behandelt werden. Wir als Engineering-Team richten also diese Art von KPI ein und überprüfen sie wöchentlich und sagen, okay Leute, das ist unser Ziel. Lassen Sie uns in unseren Scorecards sehen, wo, wo wir sind. Und im Grunde genommen, wenn einer von ihnen fehlt, wird er Teil sein, es wird etwas werden, das man in der nächsten Staffel hinzufügen kann. Das ist die Kollektion dieser Woche, über die wir für ein bestimmtes Team gesprochen haben. Auf diese Weise nähern wir uns einem sehr interessanten Zeitraum von sechs Wochen.

Leszek

Kann ich also diese beiden Konzepte, nämlich den sechswöchigen Zyklus und die experimentelle Art der Produktentwicklung, miteinander verbinden? Soweit ich weiß, bestehen einige dieser Ziele für diese sechs Wochen einfach darin, Experimente zu implementieren und zu veröffentlichen, manchmal ein, manchmal mehrere, und dann rückwirkend und dann einfach die Ergebnisse der vorherigen Experimente zu betrachten, indem ich diese Ergebnisse irgendwie transparent mache, damit das Team sie verstehen kann. Habe ich es richtig oder richtig gemacht?

Luca Fornaroli

Und wenn wir entscheiden, welche Experimente für einen Mann sinnvoll sind, tun wir auch was, was wir auch tun, okay, wir wollen dieses Experiment durchführen, um diese Hypothesen zu validieren. Also sammeln wir Daten, um zu sehen, ob unsere Hypothesen richtig sind oder nicht. Außerdem wissen wir, welche Auswirkungen es auf den gesamten Kundenstamm haben wird, wenn wir dieses Experiment von einem Experiment in ein Feature aus der Luft in ein Feature mit drei Luftbildern umwandeln. Wir ermöglichen es den Teams also, bei der Durchführung der Experimente vielleicht ein bisschen schneller zu sein. Also, wissen Sie, es gibt nicht den ganzen Prozess, den ich zuvor mit Ihnen besprochen habe, wie, Sie wissen schon, das Softwarearchitektenkomitee und all diese Dinge, weil, wissen Sie, wir wollen wirklich gehen, dass das Experiment ziemlich schnell, schneller von der Tür geht, Daten erfassen und dann entscheiden, ob es sinnvoll ist, es auf die richtige Art und Weise zu implementieren oder nicht. Das ermöglicht es uns, viele Experimente durchzuführen, vielleicht auch, weißt du, 10 pro Staffel, aber dann entscheiden wir, okay, wir machen diese 10, wir haben gesehen, dass zwei von ihnen Sinn machen, um ein echtes Feature zu werden. Also konzentriert sich das Team in der Woche, in der darauffolgenden Saison darauf, diese beiden umzusetzen und zusätzliche Experimente durchzuführen, um die nächste Phase unserer Arbeit zu verstehen.

Leszek

Nett. Ich denke, das Einzige, was ich dem noch hinzufügen kann. Ich gratuliere. Ich glaube nicht, dass du erwähnt hast, dass es irgendwie einfach oder simpel ist. Ich glaube nicht, dass es das tatsächlich ist. Ich glaube nicht, dass es so einfach ist, ein Unternehmen wie dieses zu leiten. Es ist manchmal kontraintuitiv.

Ich weiß, es gibt viele Bücher und Podcasts und, Sie wissen schon, Quellen, die diese Idee beschreiben, aber ich denke tatsächlich, dass sie einfach umzusetzen ist. Also herzlichen Glückwunsch dazu. Danke. Ich habe noch eine Frage zur Strukturierung von Teams. Ich habe mich gefragt, wie sich Ihr Ansatz zur Strukturierung im Laufe der Jahre entwickelt hat. Hat es sich dramatisch verändert oder gab es vielleicht einige wichtige Wendepunkte auf dem Weg?

Luca Fornaroli

Ja. Um Ihre Frage zu beantworten: Ganz am Anfang war das Unternehmen ein echtes Startup. Im Grunde gab es also nur ein Team, das sich aus ein paar Leuten zusammensetzte und sich im Grunde um alles kümmerte, von der Entwicklung über die Qualitätssicherung bis hin zur Bereitstellung, Infrastruktur und so weiter. Und weißt du, auch unsere Codebasis Was war, war anders. Wir haben mit einem monolithischen Ansatz begonnen, weil wir schnell vorgehen und so schnell wie möglich versenden wollten. Als wir dann beschließen, das Technologiezentrum in Mailand zu eröffnen, beschließen wir, auch unsere Arbeitsweise zu ändern. Denn weißt du, wenn du das Team skalieren willst, musst du das auch skalieren — das ist die Art zu arbeiten.

Und im Grunde haben wir angefangen, verschiedene Teams zu strukturieren, und wir haben auch angefangen, das Monolithikum in verschiedene Microservice- und Geschäftslogik aufzuteilen. Und das ermöglichte es uns im Grunde, verschiedene Teams zusammenzustellen und zusammenzustellen, die sich um eine einzelne Vertikale unserer Plattform kümmern, weil ihnen auch das jeweilige Repository gehört. Das Zahlungsteam ist also für die Zahlung als Domain zuständig, aber auch das Repository, das sich um Zahlungen kümmert. Das war also die größte Änderung, die wir vorgenommen haben, als wir beschlossen, unser Team zu skalieren. Etwas, das wir in den letzten Monaten geändert haben, war auch, dass sich keine einzige Person der Qualitätssicherung widmet. Aber wir geben den Entwicklern die Möglichkeit und zwingen sie, den Test ebenfalls durchzuführen. Dies liegt daran, dass es auf zwei verschiedene Arten helfen wird.

Ich denke, die erste ist, dass der Entwickler wachsen kann, weil meiner Meinung nach Aerial Full Stack-Entwickler auch Tests verstehen und sich darum kümmern sollten. Nicht nur Einheit, sondern auch, sondern auch Ende an Ende. Und es beschleunigt auch die Entwicklungszeit erheblich. Denn wissen Sie, eine einzige Person in einem Team zu haben, die für das Testen verantwortlich ist, bedeutet das, okay, der Entwickler entwickelt, und wenn es fertig ist, muss er der Qualitätssicherung alles erklären und dann kann die Qualitätssicherung beginnen. Wenn Sie die Entwicklung unterstützen und durchsetzen, können sie sich auch während der Implementierungsphase um Tests kümmern. Ganz am Anfang betrachteten wir das Team auch als eine Art Statik, auf statische Art und Weise. Das heißt, okay, wenn du im Zahlungsteam angefangen hast, wirst du für immer im Zahlungsteam bleiben.

Aber ich bin kein großer Fan davon. Also fing ich an, weißt du, zu versuchen, alle paar Monate eine Art Bewegung innerhalb des Teams zu haben. Und das hat auch geholfen, weil Sie wissen, je mehr Sie die Plattform kennen, desto besser ist es, denn wenn Sie etwas entwickeln müssen, wenn Sie eine klare Vorstellung davon haben, wie die Plattform funktioniert, dann können Sie damit beginnen, es so zu programmieren, dass es bereits erweiterbar ist, das heißt, Sie wissen schon, einfach für Benutzer oder leicht von anderen zu konsumieren ist. Natürlich ändern wir nicht alle Leute, weil, weißt du, Zahlungsfähigkeiten sind wirklich, wirklich schwer zu bekommen. Aber weißt du, mindestens eine Person alle paar Monate kann die Dinge ändern. Und das erlaubt mir auch, wissen Sie, die Unternehmenskultur zu schaffen und durchzusetzen, weil Sie wissen, dass Sie mit mehreren Personen zusammenarbeiten. Wir arbeiten mit verschiedenen Stakeholdern, unterschiedlichen Product Ownern und unterschiedlichen Aspekten der Fintech-Welt zusammen.

Auf diese Weise kann ich sicher sein, dass das gesamte Team zusammenarbeitet und gut zusammenarbeitet, einfach weil sie in der Vergangenheit vielleicht im selben Team waren, also etwas geteilt haben und es dann einfacher ist, zusammenzuarbeiten.

Leszek

5%, 100%. Könnte nicht mehr zustimmen. Meine letzte Frage lautet: Was ist Ihr Führungsansatz? Ich denke, Sie haben uns ein bisschen Vernunft gegeben, als wir über M- und A-Aktivitäten gesprochen haben oder uns darauf bezogen haben. Du hast erwähnt, du weißt schon, transparent zu sein. Sie haben erwähnt, die Leute zu kennen und die andere Seite zu verstehen. Aber ich denke, das war vielleicht ein Hinweis darauf.

Aber ich gehe trotzdem gerne aus Ihnen raus, Ihrem Führungsansatz. Vielleicht einige wichtige Lektionen, die ich in dieser Zeit gelernt habe und die sich dabei ereignet haben.

Luca Fornaroli

Ja, sicher. Ja, meine Art von Führung ist eine Führung mit gutem Beispiel, wenn Sie so wollen. Und ich liebe es auch wirklich, Menschen zu stärken. Ich versuche also, über die Aktivitäten des Teams auf dem Laufenden zu bleiben, aber gleichzeitig versuche ich, ihnen so viel Verantwortung und Eigenverantwortung wie möglich zu übertragen. Also, weißt du, ein Entwickler und auch ein technischer Leiter lieben das wirklich, weil, weißt du, sie haben das Gefühl, dass ihnen vertraut wird und dann sind sie diejenigen, die zu dir kommen, wenn sie eine Idee oder Zweifel haben oder Hilfe benötigen. Also, weißt du, das hat mir geholfen, weißt du, Zeit für alle zu haben, weil ich nicht zu 100% in das Programmieren involviert bin, wenn ich eine Entscheidung getroffen habe. Ich meine, ich versuche zu bleiben und auf einer höheren Ebene zu bleiben, aber auf der anderen Seite sehe ich, dass die Leute wirklich wachsen, weil sie das Gefühl haben, dass ihnen gehört, was sie tun.

Diese bringen also viele neue Ideen mit sich und helfen auch dabei, talentierte Mitarbeiter an sich zu binden. Ich habe meine Arbeitsweise ein wenig geändert. Ich meine, besonders ganz am Anfang, als ich zum CTO ernannt wurde, war ich sehr, sehr jung. Also, weißt du, ich hatte, wie soll ich sagen, ein bisschen Angst vor Leuten, die mehr wissen als ich. Jetzt ist es das Gegenteil. Ich meine, ich versuche Leute an Bord zu holen, die sehr gut wissen, dass sie Dinge tun können, zu denen ich nicht in der Lage bin. Also, weißt du, das ist ein, das war ein wirklich verändernder Teil für mich, weil, weißt du, ich fange an, von Menschen zu lernen und ich fange an, auch anderen Menschen zu erlauben, zu wachsen. Also, weißt du, als ich anfing, die Teams in Scala Pay zusammenzustellen, jedes Mal, wenn ich ein Interview gab, fragte ich mich, ob dieser Typ in der Lage ist, etwas zu tun, was ich in den USA nicht tun kann, wenn die Antwort ja war, okay, er ist die Art von Person, die ich gerne in, in, in, im Team haben würde.

Und sobald du diese Person im Team hast, ist es einfach, weil du weißt, du musst ihr vertrauen, weil sie mehr weiß als du. Und deshalb musst du ihnen vertrauen. Natürlich musst du sie herausfordern. Sie müssen, wissen Sie, sicher sein, dass sie verstanden haben, dass sie ein klares Bild haben. Und das eine ist der andere Teil der Führung, der okay ist. Verstehen Sie, was das Führungsteam will, und lassen Sie uns versuchen, es in eine Sprache zu übersetzen, die das Entwicklungsteam verstehen und verstehen kann. Lassen Sie uns sie dann so weit wie möglich abschirmen, denn wenn den Leuten vertraut wird und sie gestärkt werden, können sie Lösungen finden, die meiner Meinung nach fantastisch sind. Das ist also mein Ansatz in Bezug auf die Führung.

Leszek

Geht gut. Luca, vielen Dank für deine Erkenntnisse, für deine Weisheit und dafür, dass du heute Zeit für mich mit mir verbracht hast und diese Diskussion geführt hast. Ich danke dir vielmals.

Luca Fornaroli

Dann Eintritt. Danke.

Leszek

Folgen Sie Matt und Leshek auf LinkedIn.

‍