Software Engineering im Startup vs. im Corporate

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek. Ich bin der Geschäftsführer von digital kompakt und heute habe ich wieder Björn Wagner zu Gast. Ihr kennt Björn, der ist VP Engineering bei SAP Signavio. und wenn Björn und ich zusammensitzen, dann reden wir mal fleißig über Product und Engineering. So, wir haben uns für heute vorgenommen, dass wir mal ein Stück weit das Tuch der Praxis sozusagen lüften, weil wir machen öfters so, das machen wir mal gerne, wenn wir eine Reihe bauen am Anfang, dass wir ein bisschen mehr theoretische Themen erklären, damit ihr draußen versteht, wie Sachen gehen. Und dann legen wir so die Praxis nach. Und heute reden wir mal darüber, wie funktioniert denn eigentlich Product Engineering im Startup versus im Corporate? Weil Björn hat beides schon durchgemacht. Einmal bei Signavio ja selbst. Das ist ja von SAP gekauft worden und da kennt er natürlich beide Extreme. Wie war es ganz am Anfang und wie ist es jetzt als große Organisation? Aber auch schon in weiteren Organisationen, der hat auch SAP Signavio eine Zeit lang mal verlassen und kam dann wieder zurück und kennt daher quasi viele Ecken. So, und wir haben uns vier Punkte genommen, die wir uns anschauen wollen bei diesen beiden Ebenen. Also wir vergleichen Startup versus Corporate einmal bei der Geschwindigkeit, bei den Prozessen, bei der Kommunikation und beim Risiko. So, und ich glaube, da hat Björn auch heute wirklich ein paar schöne Praxisgeschichten mit und da bin ich schon neugierig drauf. Von daher, schön, dass du wieder da bist, Björn. Moin, moin.

Björn Wagner: Moin, moin, hallo.

Joel Kaczmarek: Hast du denn einen Favoriten? Was hat dir mehr Spaß gemacht, als eher im Startup-Eck oder eher im strukturierten Corporate-Eck zu arbeiten?

Björn Wagner: Ja, ich tue mich da sehr schwierig, ehrlicherweise zu sagen, A oder B ist besser. Ich glaube, es hat alles Vor- und Nachteile und man lernt andere Sachen und das ist so ein bisschen das, was zählt. Also mir macht beide Spaß auf jeden Fall. Es kommt auf die Umgebung an. Ich glaube, da gibt es noch ganz viele andere Faktoren, die mit reinziehen. Aber ich würde mich sehr schwer tun, Startup oder Corporate vorzuziehen an der Seite.

Joel Kaczmarek: Ich glaube, es macht doch immer einen Unterschied, wo man selbst auf der Reise ist. Ich glaube, wenn man, sage ich mal, als Startup schon ein bisschen ausgecashed hat, also wenn wirtschaftliche Unabhängigkeit da ist, dann hat man auch nochmal einen anderen Blick auf alles, als wenn man so völlig noch in der Luft hängt. Das ist ja manchmal, was wichtig ist, dass man Gründern so eine Unabhängigkeit gibt, wirtschaftlicher Art, dann kannst du ja auch ganz anders entscheiden. Also selbst sowas mag eine Rolle spielen. Aber gut, auf dem Luxus-E, auf dem Luxus-E sind wir jetzt hier gerade gar nicht, sondern wir sind ja tief im Maschinenraum, was Technologie angeht. Und dann lass uns doch mal straight rein starten. Also wir haben ja gesagt, erster Punkt, Geschwindigkeit. Ist jetzt eine naheliegende Vermutung, Schnellboot versus Tanker. Ist es so simpel?

Björn Wagner: Ja, also man hat schon viele, viele Geschichten, sage ich mal, wenn man so reflektiert. Gerade wenn man halt so im Corporate-Kontext ankommt oder auch als ich angekommen bin, war immer so viel in der Reflexion, wow, ist das jetzt kompliziert. Und haben wir das nicht früher einfach alles viel besser und schneller gemacht? Das ist so ein bisschen das Gefühl, was mitschwingt. Und wenn man dann darüber nachdenkt, also man findet schon viele Punkte, wo das drauf zutrifft. Um einfach mal ein Beispiel zu nennen, wenn wir halt im Startup-Kontext, gab es schon mal die ein oder andere, den ein oder anderen Kollegen, Kollegin, die haben dann auf dem Weg zum Kunden, zur Kundenpräsentation für die Demo, haben die noch Features im Zug gebaut mit allen. Also da war irgendwie, das wurde dann sehr stark mit der heißen Nadel gestrickt, man wusste, okay, der Kunde, der will das unbedingt haben, dann hat man das noch irgendwie so reingehackt, sage ich mal, dass man es zumindest relativ gut demonstrieren konnte, auch wenn das vielleicht noch nicht ganz fertig war. und das ist so typischer Startup-Kontext. und wenn man sich das anschaut, okay, wie werden Kundendemos im Corporate-Kontext gemacht, da gibt es ja eine eigene Abteilung, normalerweise Pre-Sales, die haben dann voraufgenommene Demos mit riesigen Narrativen, vorbereiteten Skripten, dass irgendwie auch alle eine gleiche, ähnliche Story erzählen, das ist quasi so, dass Andere extrem. Jetzt kann man sich überlegen, natürlich von der Geschwindigkeit her ist das vielleicht Startup besser, ist natürlich auch ein bisschen stressiger, sage ich mal und nicht immer von Erfolg gekrönt auf der anderen Seite. Aber das ist so ein guter Indikator, wenn man auf jeden Fall in der Startup-Welt, wenn man noch im Zug oder auf dem Weg zum Kunden sich überlegt, was baut man jetzt noch schnell ein ins Produkt und was denn nicht.

Joel Kaczmarek: Woran, was ist sozusagen der Hauptgrund, dass das im Corporate nicht mehr geht? Also ist das ein Legacy-Thema, ist das ein Prozesse-Thema, ist das ein, ich sag mal, organisationsseitiges Thema? Woran liegt es, dass du diese Geschwindigkeit dann halt irgendwann verlierst?

Björn Wagner: Ja gut, in der Regel ist es auch ein anderer Zyklus meistens im Lifecycle des Produkts. Also wenn man eine Pre-Sales-Abteilung hat, dann ist es natürlich ein Produkt, Was schon, sage ich mal, sehr weit ist, sehr viel Umsatz macht und wo einfach viel mehr Leute auch in der Lage sein müssen, halt das Produkt zu demonstrieren. Wenn man halt selber noch die Features reinbaut, dann gibt es wahrscheinlich den Produktmanager und ein paar Entwickler und da gibt es noch keine Go-to-Market-Organisation, die vielleicht weiß, wie man das überhaupt verkauft oder wie man das überhaupt demut und so weiter. Das heißt, man ist eigentlich noch viel, viel früher da. im, sag ich mal, Lebenszyklus des Produkts, wo man auf einer viel, viel kleineren Skalierung arbeitet, auch noch viel enger mit den Kunden zusammenarbeitet und noch gar nicht darüber nachdenkt, okay, ist das jetzt ein Feature, was irgendwie zumindest 10% meiner 1000 Kunden irgendwie schlau finden oder gut finden oder wertvoll finden vielmehr, sondern die Diskussion ist eher, hey, lass uns mal mit den zwei, drei Pilotkunden, die wir gerade versuchen zu akquirieren, ein erstes, wie man immer so schön sagt, Minimum Viable Product bauen, Und deshalb hat man da natürlich am Anfang auch eine viel, viel höhere Geschwindigkeit am Ende drin.

Joel Kaczmarek: Wie ist es so mit den ganzen Feedback-Zyklen auch? Also es ist ja dann, je größer du wirst, desto mehr Köpfe oder jetzt mehr Köche kochen am Brei, sage ich mal.

Björn Wagner: Genau, also das ist natürlich auch, wenn wir mal bei dem Beispiel bleiben, man hat hauptsächlich Produktmanager und vielleicht einen Entwickler, der zum Kunden geht, dann hat man sehr direktes Kundenfeedback. Wenn man jetzt hauptsächlich ein großes Go-to-Market-Team hat, was denn vielleicht noch, wo die Pre-Seller, Consultants oder Customer Success hauptsächlich mit dem Kunden interagieren und die ganzen operationalen, kundenspezifischen Fragestellungen lösen und adressieren, dann sind dadurch in der Regel Product Manager, Engineers, Designer relativ weit weg. Das heißt, der Zyklus wird halt schwieriger. Im großen Setup. Und man muss sich natürlich dann auch Gedanken machen, also häufig ist es ja so, gerade bei Organisationen von mehreren hundert Leuten, dann fokussiert sich jeder auf einen Teil des Produkts. Aber wenn ich jetzt mit einem Kunden spreche, dann interessiert den Kunden ja relativ wenig, was mein Fokusteil ist, sondern wenn der gerade irgendein Riesenproblem mit dem Produkt hat, was vielleicht ganz woanders bei einem anderen Team liegt, dann wird er mir das trotzdem erzählen und da wartet halt auch dafür eine Antwort. Und genau, was man dann halt schauen muss, also ich glaube, man ist viel näher am Kunden, man kriegt viel direkteres Feedback. Allerdings kriegt man natürlich auch Feedback von weniger Kunden. Das ist meistens sehr ausgewählt. Und während man halt im, sage ich mal, Corporate-Kontext dann eher von der, sage ich mal, Prozessseite, Plattformseite schauen muss, wie kann man denn, es reden ja immer noch ganz, ganz viele Leute mit dem Kunden, wie kann man denn deren Wissen quasi zurückführen, so strukturieren, dass es dennoch wieder an den, sage ich mal, richtigen Ort im Entwicklungszyklus kommt. Und dann gibt es zum Beispiel dann Produkte, ich glaube, haben wir schon vorher mal drüber gesprochen, sowas wie Product Board, wo sowohl interne als auch externe Leute irgendwie quasi strukturiertes Feedback geben können, dass das dann auch bei den richtigen Teams zum richtigen Zeitpunkt ankommt und man nicht halt, wenn man dann mal so einen, sage ich mal, sehr kurzen Blick hat, wenn man dann mal mit dem Kunden spricht, dass man halt eher so ein sehr, sehr breites Bild bekommt von, hey, was wollen denn eigentlich die Kunden in der Masse und nicht nur die Kunden, mit denen man vielleicht die letzten zwei guten Termine hatte an der Stelle.

Joel Kaczmarek: So jetzt haben wir das ja verstanden, also Startup-Welt ist eher so, man programmiert die Sachen teilweise noch im Zug, das ist ja jetzt überspitzt formuliert, aber ich sag mal mit einer gewissen Kurzfristigkeit. Du hast die Kundengespräche, weswegen du sehr kurze Feedback-Zyklen auch hast. Wie sind denn diese beiden Faktoren, also so Programmiervorgehen, vielleicht auch Zeitachse und nah am Kundensein im Corporate dagegen aufgestellt?

Björn Wagner: Wie ich gerade schon meinte, also Corporate ist halt, da muss man ja schauen, wie kann man das Wissen in die Masse reinbringen. Also da hat man jetzt nicht irgendwie eine kleine Anzahl an Leuten, die mit ein paar Pilotkunden zusammenarbeiten, sondern dann arbeiten große Organisationen, sowohl aus der Produkt- als auch aus der Go-to-Market-Seite mit verschiedenen Kunden zusammen. Da muss man halt schauen, wie kann man dieses Wissen, das Feedback, was man bekommt auch strukturiert an die richtigen Leute zurückführen. Das ist dann vielmehr so ein prozessorganisatorisches Thema. Dann sitzt man halt nicht mit drei Leuten beim Kunden, macht Notizen und überlegt sich, was ist im nächsten Release drin, sondern der Prozess wird halt deutlich aufwendiger und komplexer an der Stelle. Und es ist natürlich auch, dadurch, dass man so viel Feedback beachten muss, gehen dann halt andere Sachen verloren. Dadurch kommt halt dieses Gefühl zustande, dass halt die Sachen länger dauern. Um ein anderes Beispiel zu nennen, kurzer Feedback-Cycle. Das, was mich, ich glaube, bis heute noch am meisten beeindruckt hat, wir haben mal bei einer meiner früheren Firmen, war so ein B2C-SaaS-Startup, wo wir für Forschende Software gebaut haben, die es ihnen halt einfacher gemacht hat, Paper zu schreiben. Und wir hatten, es war auch nicht so ganz einfach, das zu verwenden oder die Leute onzuboarden. Und wir hatten irgendwie richtig schlechte Zahlen im Onboarding. Da haben wir uns gefragt, hä, wir haben doch extra so ein Step-by-Step-Guide ins Produkt eingebaut. Warum macht das denn keiner? Warum versteht das denn keiner? Warum registrieren die sich und kommen danach alle nicht wieder? Das war so das Problem, was wir hatten. Und wie wir das im Startup gelöst haben, wir haben dann relativ kurzfristig ein Tool eingeführt, ich glaube, das hieß Hotjar oder so. Und damit hat man von Kunden so eine Art Screen Recording bekommen, man konnte dann wirklich dem Kunden live zuschauen und man hatte dann auch nicht so viele Kunden. und dann guckt man sich halt mal die 10 Nutzer am Tag an, wie interagieren die eigentlich mit dem Produkt. und das war, ich glaube für das gesamte Team, wir waren da vielleicht 6, 7 Leute, die daran gearbeitet haben, unglaublich augenöffnend. Darauf geschaut und hast gesehen, oh mein Gott, wir hatten die besten Intentionen, aber die Nutzer haben halt was komplett anderes gemacht. Die haben halt verzweifelt versucht, unseren Onboarding-Prozess irgendwie abzubrechen, weil wir sie in so einen Funnel reinführen wollten, was sie aber eigentlich gar nicht machen wollten. Und dann haben wir relativ schnell gesehen, irgendwie nach zwei, drei Tagen, wow, das macht überhaupt keinen Sinn, wie wir da die Nutzer versuchen ins Produkt zu holen. Dann hat aber jeder auch gleich verstanden, nachdem man das gesehen hat, kamen ganz viele Ideen hoch, okay, was verändern wir denn jetzt? Und dann haben wir halt innerhalb von ein paar Wochen einfach komplett den Onboarding-Prozess umgebaut in einen deutlich weniger invasiven Prozess, wo der Nutzer quasi so ein bisschen an die Hand genommen wurde, aber dann selber entscheiden konnte, wann er denn bestimmte Produkte macht. Und das hat dann, wie gesagt, in ein paar Wochen die Onboarding-Zahlen deutlich verbessert. Und das ist halt sehr nah am Kundensein, wenn du nimmst eine kleine Anzahl an Leuten mit und hast jetzt irgendwie auch kein großes Committee, was irgendwie jetzt sagt, hey, das macht Sinn, was du machst, sondern du kannst halt super schnell agieren. Und dann in kurzen Iterationen Sachen fixen. Und ich sag mal so, also das ist sehr, sehr stark im Startup. Man kann das auch natürlich im Corporate haben, aber im Corporate wird es halt schwieriger oder in großen Organisationen wird es halt schwieriger, sobald man halt, sag ich mal, mehrere Teams mitnehmen muss. Die Best Practices sind ja die gleichen. Schwierig wird es halt nur, wenn man halt plötzlich viel mehr Leute mitnehmen muss. Wenn man plötzlich was bauen muss, was irgendwie eigentlich super einfach ist. Und das wäre vielleicht so das Gegenbeispiel. Es gab eine neue UX-Komponente. Man hat ja, jede Anwendung hat irgendwie so ein Header zum Beispiel oder eine Standard-Navigation. Im Startup haben wir vor ein paar Wochen die kompletten Onboarding-Prozesse auf links gezogen, neu gebaut und messbar verbessert. Hier wollten wir eine sehr einfache Änderung an der Navigation machen, aber da waren irgendwie 30 Teams involviert, dann dauert es halt mal ein Jahr. Trotzdem besten Wissen, weil dann hat jedes Team hat dann irgendwie Natürlich hat dann andere Prioritäten, hat andere Ziele, dann andere Tech-Stacks, dann treten plötzlich Probleme auf und dann hat man für eine vergleichweise relativ einfache, eine einfache Änderung, die auch Sinn macht, braucht man dann plötzlich ein, anderthalb Jahre, um die gesamt umzusetzen, aber es sind nicht fünf Leute dabei, sondern halt 500 und das ist halt genau der Unterschied.

Joel Kaczmarek: Crazy. Anderthalb Jahre, um den Button von links nach rechts zu setzen, meistens überspitzt gesagt.

Björn Wagner: So schlimm ist es meistens nicht, aber es fühlt sich auf jeden Fall sehr langsam an, das kann ich sagen.

Joel Kaczmarek: Aber ich meine, sowas wächst ja auch. Darf man ja auch sagen, es geht ja gar nicht nur darum, dass die Organisation größer ist, sondern das Produkt auch wächst. Also ich denke gerade so, wenn ich so Office Suite hätte, dann hast du ja Leute, die seit Jahrzehnten irgendwelche Excel-Prompts kennen. Und dann kannst du jetzt nicht hingehen und kannst sagen Ja, nee, die Formel lautet jetzt nicht mehr, wenn, Klammer auf, dann, sondern so und so. Also das kann ich mir schon vorstellen, dass das so eine unglaubliche Komplexität einnimmt. Was sind denn so deine wichtigsten Learnings beim Thema Geschwindigkeit, wenn du dir beide Sphären nochmal anguckst?

Björn Wagner: Also ich glaube, was halt wichtig ist, was ich gerade schon versucht habe anzudeuten, man muss halt, egal in welchem Kontext man ist, also die grundsätzlichen Regeln und Arbeitsweisen sollten sich halt eigentlich ändern. Man sollte halt versuchen Wenn man ein großes Team hat, muss man halt die Teamgrenzen schlau schneiden, dass die Teams möglichst unabhängig voneinander arbeiten können und möglichst viel Kundenwert produzieren können, ohne halt mit zehn anderen Teams zu reden und sich abzustimmen. Weil dann wird es halt extrem langsam. Das ist, glaube ich, somit das Wichtigste. Man muss halt irgendwie kontinuierlich versuchen, egal wie groß die Organisation wird, die Art und Weise, wie man arbeitet, so anzupassen, dass man möglichst schnell releasen kann, möglichst schnell Kundenfeedback bekommt. Und dann möglichst schnell darauf reagieren kann. Und interessanterweise ist das teilweise auch gegensprüchlich. Ich habe noch eine interessante Erfahrung, man sagt ja viel, also eigentlich wenn man jedes Engineering, jedes moderne Engineering Buch liest, angefangen von agiler Entwicklung, sagt man, man muss häufig releasen. Und ich glaube jeder im B2C Bereich ist das halt auch so, im B2C Bereich ja super verbreitet, dass man neue Features irgendwie, wenn man halt Millionen Nutzer hat, wie auf Instagram, wenn Instagram eine größere Änderung macht, dann werden die das erstmal mit einem kleinen Nutzerkreis ausprobieren, dann messen die da die Metriken durch, macht das Sinn, funktioniert das, verbessert das die Sachen? Und wenn ja, dann wird das halt Stück für Stück ausgerollt. Oder wenn die halt ein neues Feature entwickeln, dann wird das erstmal an einer kleinen Nutzeranzahl freigeschaltet und dann verbessert, verbessert, verbessert und dann entweder eingestampft oder an einer großen Nutzeranzahl freigeschaltet. Im B2B reden wir viel über, auch mit dem Till haben wir viel über Kundenfokus geredet. Und spannenderweise sind teilweise die Kunden die, die gar keine häufigen Updates haben wollen, weil im B2B ist es halt so, wenn ein großes Update kommt, dann müssen die Kunden es erstmal testen, dann sind 100 Leute eingearbeitet, das Produkt in einer bestimmten Art und Weise zu nutzen. Wenn wir jetzt selbst nur den Button von links auf rechts ziehen, dann loggen sich da 100 Leute ein und die finden ihren Button nicht mehr, dann rufen die erstmal bei ihrer IT an und sagen, wo ist denn der Button. So und dann kommt das hoch und dann kommt irgendwie beim Produktmanager an, ja wie könnten ihr so releasen, wir wissen gar nicht mehr, wie wir euer Produkt bedienen können. Und hier muss man natürlich schauen, dass man jetzt sagt, jetzt kann man sagen, okay, jetzt releasen wir nur noch einmal im Jahr, aber das ist dann natürlich auch nicht im Sinne des schnellen Learning und Feedback Cycles und man muss dann halt die Kunden schon mit auf die Reise nehmen, das ist ja so klassisch auch. Von On-Prem in die SaaS-Welt oder von On-Prem in die Cloud-Welt war das ja auch am Anfang sehr, sehr viel Pushback, die Daten in der Cloud, oh mein Gott, das geht ja gar nicht, gerade in Deutschland und Europa. Inzwischen in den letzten zehn Jahren hat sich dort auch viel entwickelt, auch an Mindset und die Leute werden halt auch oder die Kunden gewöhnen sich halt auch im B2B-Bereich halt dran, okay, es gibt häufiger Features und natürlich muss man es den Kunden halt auch einfacher machen, irgendwie ihre Leute zu trainieren wiederum, dass sie dann die neuen Features halt auch entsprechend verwenden können.

Joel Kaczmarek: Ja, aber ich glaube dir das sofort. Ich habe hier mit dem Christian Bredlow mal eine Folge gemacht. Der berät halt immer Unternehmen oder hilft denen dabei, dass die quasi die Digitalisierung voranbringen. Der sagte doch mal, die kriegen Nervenzusammenbrüche, die Unternehmen. Wenn auf einmal dein Outlook Sachen, die du immer so gemacht hast, auf einmal völlig worden ist. Die arbeiten damit jeden Tag und auf einmal ohne Ankündigung ist es komplett umgestellt. Und mit so einem Stolz auch noch so, ja, das ist komplett neu. Jetzt die Version so und so. Und du denkst so, wo ist denn? aber einfach nur, ich will da den BCC-Knopf wiederfinden. Wo ist der gelandet? Krass. Gut, okay. Aber Bereich 1, Geschwindigkeit, Haken hinter. Prozesse als zweites Thema. Ah, das liebt ja jedes Startup-Not. Was ist da so, wenn du drauf guckst und beides vergleichst, was unterscheidet sich?

Björn Wagner: Ja, auch ein sehr spannendes Thema. Wir haben auch schon viel über Rollen und Produktteams gesprochen. Das ist dann, sobald man über Rollen und Skalierung redet, kommt man dann ziemlich schnell in diese Bereiche. Aber spannend war, ich war, ich glaube, einer meiner ersten Jobs war bei Signavio wirklich Werkstudent zu sein. Das war, weiß ich nicht, 2008 oder so, glaube ich. Und damals gab es eigentlich, es gab keine Prozesse, es gab auch keine irgendwie festgelegten Rollen oder so. Es gab halt viele Entwickler und wir haben halt in einem Raum gesessen und viel miteinander gesprochen und dann hat man halt Ideen gehabt und die in gewisser Weise umgesetzt. Natürlich hatten die Gründer damals schon, gab es schon irgendwie Ziele, okay, das wollen wir reich, wir müssen bestimmte Sachen bauen, aber da gab es jetzt keinen Product Owner, der Sprints geplant hat oder da gab es auch relativ wenige Designer, die mit involviert waren, sieht man manchmal noch an der einen oder anderen Stelle, aber grundsätzlich gab es eigentlich keinen Prozess, keine festen Rollen, du hattest halt glaube ich sehr viele Leute, die Wir haben es in der letzten Folge viel drüber gesprochen, wie die so die Probleme gut verstanden haben und das dann einigermaßen okay in ein gutes Produkt umsetzen konnten. Aber wie gesagt, da gab es keine Prozesse, keine großen Strukturen, super spannend, war eine richtig spannende Zeit, extrem viel gelernt. Und wie gesagt, glaube ich, auch super effizient und schnell am Ende gearbeitet. Das heißt aber nicht, dass es immer so ist. Ich habe noch ein anderes Beispiel. Ich habe dann, ich glaube, 2015 für mein erstes Startup selber, haben wir dann gesagt, ist ja super. Ich habe viel mit einem Co-Founder zusammengearbeitet. Wir haben so viele Auftragsentwicklungen eigentlich gemacht. Jetzt haben wir so viele Projekte, dass wir gesagt haben, großartig, jetzt stellen wir mal ein paar Leute ein und die machen dann einfach ein bisschen die Arbeit mit. Hat ja früher auch gut funktioniert. Da hat man aber ziemlich schnell gelernt, wenn man halt, haben viele Leute auch frisch von der Uni geheiert und dann war dann plötzlich nicht die Erfahrung da oder quasi dieses Verständnis, okay, wie lösen wir denn das Kundenproblem? oder haben dann wirklich so ein paar fundamentale Dinge, wie mache ich denn so DevOps, wie deploye ich denn beim Kunden und wie arbeite ich denn vielleicht im Team. Das haben dann viele zum ersten Mal gemacht, weil es vielleicht in der Ausbildung bisher nicht drin war und dann hat das plötzlich gar nicht mehr so gut funktioniert, ohne komplett, ohne Prozesse, ohne Rollen. Dann hat man schon gemerkt, okay, jetzt brauchen wir hier jemanden, der irgendwie die Leute erstmal mitnimmt, denen erstmal irgendwie klassisches Training in so Basics gibt. Man muss halt schon schauen, welche Leute hat man, was haben die für einen Hintergrund, was haben die für Erfahrungen, in welchen anderen Umgebungen haben die schon gearbeitet. Das heißt, immer alles super, Startup, keine Prozesse, keine Rollen funktioniert, ist halt auch nicht immer so. Und das ist halt dann selber in der Corporate-Welt, man braucht halt schon die richtigen Leute und man merkt dann ziemlich schnell, okay, wenn es halt so gar nicht funktioniert, dann braucht man halt die Struktur, dann braucht man halt jemanden plötzlich, der mal vielleicht so ein Jira-Ticketsystem aufsetzt und mal ein bisschen runterschreibt, was wir eigentlich machen wollen, ein bisschen priorisieren wollen und so weiter. Also ich glaube, es ist halt nicht, mein Hauptpunkt ist glaube ich nicht nur Startup Corporate, es hängt halt auch sehr, sehr viel von den Leuten ab, wie die Leute arbeiten wollen und genau wie tief sie wirklich das Kundenproblem verstehen und halt auch im Produkt drin sind.

Joel Kaczmarek: Nehmen Sie mal ehrlich, meinst du manchmal der Zeit hinterher, wo ihr alle mit der Pizza auf dem Schoß im Raum saßt und gemeinsam geplant habt, war das manchmal auch ein bisschen cooler?

Björn Wagner: Also mit Pizza haben wir heute auch noch, würde ich sagen. Also an der Pizza scheitert es nicht. Aber ja, es war damals, also wie gesagt, ich tue mir schwer, das zu vergleichen. Also es war eine ganz andere Zeit, eine andere Stimmung natürlich auch, die man irgendwie hatte. Und es war ein bisschen, alles ein bisschen leichter, so gefühlt. Weniger Aufwand, weniger Struktur. Es hat auf jeden Fall was, sage ich mal so. Ja.

Joel Kaczmarek: Und wenn du jetzt nochmal so die Corporate-Decke lüftest, was würdest du sagen, wie sehen solche Prozesse da so aus? Also du hast ja gerade schon gesagt, hier Ticketing-Systeme, Sprint-Planning, ist das sozusagen jetzt der neue Standard oder sogar auch noch viel mehr? Wie sieht sozusagen das andere Extrem aus?

Björn Wagner: Also ich glaube, gerade wenn man so wächst als Organisation, das haben wir ja auch sehr, sehr viel gemacht, es gibt ganz, ganz viele Leute, die tendieren dazu, wenn ein Problem auftritt, dann füllen wir mal einen Prozess und eine neue Regel ein und dann muss am besten noch irgendein hoher Manager was approven. Mein bestes Beispiel ist, wir hatten das, ich glaube, vor anderthalb Jahren, da gab es mal einen größeren Outage, ich weiß nicht, bei SAP Signabio, aber Ein guter E-Mail-Kollege war da involviert. und die haben dann halt, was war das Learning aus dem Outage? Da haben wir uns gesagt, okay, jetzt muss Senior Management jedes Deployment approven. Die haben irgendwie eine neue Version ausgerollt, haben gesagt, das ist jetzt was schief gelaufen, haben gesagt, okay, dann dürft ihr das nicht mehr selber entscheiden, sondern bitte jetzt hier. Jetzt muss der CTO, der ganz große Boss, muss halt immer sofort wie jeden kleinen Change approven, weil wir halt Angst haben, natürlich, wenn mit einem neuen Update viele Probleme auftreten, beschweren sich viele Kunden, hat potenziellen Business Impact und dann wird das halt gemacht. Und das ist halt, glaube ich, genau das Falsche, dass man versucht, Sachen mit Prozess zu lösen. Oder ich habe ein anderes Beispiel. Wir können ja, in großen Firmen können die Leute irgendwie selber Sachen bestellen, ne? Und dann kriegt man als Manager, kriegt man dann mal ganz viele tolle E-Mails, wo dann drin steht, hey, guck mal, deine Leute haben die Sachen bestellt, weil unter einem bestimmten Betrag muss man das nicht approven. Aber man kann trotzdem viel Quatsch bestellen. Und wenn man dann mal raufguckt, sieht man, gibt man dann so ein bisschen Feedback den Managern und dann sagen die sofort, oh mein Gott, jetzt müssen wir sofort mehr Regeln einführen, sag ich mal, zum gewissen Teil und irgendwie sagen, hey. Jetzt müssen wir die Leute mehr kontrollieren und da ist jetzt was schief gegangen. Aber ich glaube, man muss eher schauen, hey, also was kann man denn daraus lernen? Was sind wirklich die Gründe? und wie kann man das Problem denn lösen, ohne neue Regeln und Strukturen einzuführen? Weil damit wird am Ende alles nur wieder langsamer, um zum Thema Geschwindigkeit zurückzukommen als vorher. Also wenn man Je nachdem, welche Bücher man liest. Das Buch sagt, es ist sehr einfach, klingt sehr einfach in der Theorie, ist halt, wenn die Komplexität steigt im Unternehmen, dann sollte man die nicht mit Prozess erschlagen, sondern dann sollte man die halt versuchen mit Leuten, die mit der Komplexität umgehen können, zu erschlagen. Das heißt, man braucht dann auch Leute mit der Erfahrung, um das halt entsprechend zu machen. Natürlich braucht man ein bisschen mehr Prozesse und ein bisschen mehr Struktur ab einer gewissen Größe. Weil man kann die meisten Probleme, kann man mit Prozess erschlagen. Das Problem ist, sobald man halt Prozesse, Strukturen, drei neue Approvals einführt, wenn sich dann der Prozess mal ändern soll, dann wird alles unglaublich schwierig, kompliziert und teuer. Und dann man verliert so viel Flexibilität, dass man dann einfach auf Veränderungen nicht mehr reagieren kann. Ich weiß, das sagt sich sehr einfach, es ist sehr, sehr schwierig, die Leute zu finden und das wirklich so durchzuziehen, was glaube ich eine sehr natürliche Reaktion ist, zu sagen, oh jetzt ist was schief gegangen, jetzt lass uns hier mal mehr Kontrolle und mehr Struktur und mehr Prozess einführen, damit das in Zukunft nicht mehr so passiert.

Joel Kaczmarek: Ja, ich habe gerade so drüber nachgedacht. Ich habe gerade an Star Trek gedacht. Dann gibt es so diesen Supercomputer, der alle Bedürfnisse aufnimmt und dann Sachen baut. Dann habe ich gerade gedacht, naja, so weit sind wir ja gar nicht von weg. Könnte man mit KI solche Sachen jetzt mittlerweile auch pimpen? Dass man sagt, ich programmiere bestimmte künstliche Intelligenzalgorithmen und einfach darauf hingeht, dass wir irgendwie die Kundenbedürfnisse auf der einen Seite halt sehr gut kartografiert haben und auf der anderen Seite das, was wir erreichen wollen und was die neuen Features, worauf die abziehen sollen. Weil dann hast du ja auf einmal so eine Integration, dass diese Reibung ja so ein Stück weit Ist sowas schon im Einsatz? Tut sich sowas? Siehst du sowas kommen?

Björn Wagner: Also es gibt natürlich auch im Bereich, also es geht ja so ein bisschen wieder auf den Bereich Feedback, Produktmanagement, was sagen eigentlich die Kunden, was für Features bauen wir denn dafür? Gibt es natürlich Sachen. Gerade wenn man jetzt, also bestes Beispiel ist ja, eigentlich alle Produkte machen ja in einer gewissen Art und Weise Messen Customer Experience. Da gehört dann sowas zu wie Net Promoter Score oder Customer Satisfaction Score oder Und man kennt es, man kriegt in der Regel eine E-Mail oder so oder es ist im Produkt, wo drin steht, hey, würdest du denn das Produkt deinen Freunden empfehlen? 0 bis 10 und dann schreibt man noch ein paar Kommentare dazu. Und wenn ich jetzt irgendwie Millionen Nutzer habe, dann kriege ich natürlich Millionen Kommentare und da steht sehr viel wichtige Information drin, aber nun kann ich mir nicht jeden Monat Millionen Kommentare durchlesen. Und dann gibt es natürlich schon, kann man Gen AI nutzen, um gewisse Sachen zu clustern, zusammenzufassen, zu interpretieren quasi, um dann halt den gesamten Input, den man halt bekommt, irgendwie besser mappen kann auf, hey, was sind denn jetzt die Sachen, also was sind denn gerade die großen Kundenprobleme? und worauf sollte ich mich denn fokussieren, wenn es halt zum Thema Priorität oder um das Thema Prioritätsstrategie geht. Also absolut, da gibt es was. Ich glaube, wo halt, also Gen-AI, wenn es halt um wirklich kreative Sachen geht, so ein Kundenproblem im Detail zu verstehen und jetzt irgendwie kreative Lösungen vorzuschlagen, ich glaube, da ist noch ein sehr, sehr, sehr, sehr großer Gap. Also es hilft halt viel im Tooling, gerade um, sage ich mal, so einen Produktmanager oder auch den Engineers bestimmte Informationen besser aufzuarbeiten. Aber ich glaube, der kreative Anteil, wie man denn jetzt wirklich mit der aktuellen Technologie das umsetzt, das ist, glaube ich, was auch langfristig AI nicht helfen wird.

Joel Kaczmarek: Ich meine, wir sind ja auch bei dem spannenden Thema dabei, eigentlich Kommunikation, unser dritter Block. Also, dass man ja eine große Aufgabe darin hat, dass quasi an der einen Seite der Firma das gleiche verstanden wird wie an der anderen. Von daher, zu Startup-Zeiten wart ihr da alle noch in einem Zimmer, ne? Das ist jetzt wahrscheinlich ein bisschen schwerer.

Björn Wagner: Ja genau, also natürlich gibt es auch Startups, die verteilt arbeiten, auch von Anfang an, aber ich glaube, man redet ja auch viel über Return to Office, also gerade wenn man halt am Anfang, wenn so viele Sachen unklar sind, wenn man ganz schnell lernen muss, viel mit dem Kunden zusammenarbeiten muss, wirklich sehr sehr eng und sehr sehr kurze Zyklen haben will, dann hilft es ungemein wirklich in einem Raum zu sitzen. Weil es ist immer so, wenn man in einem Raum sitzt, dann hat das zwei Sachen, zum einen wenn ich ein Problem habe, dann gehe ich halt rüber und frage den Kollegen, die Kollegin kurz, Zum anderen ist es auch häufig so, viel Vertrauen, der Satz kommt nicht von mir, ich glaube Simon Sinek hat das gesagt, Vertrauen wird zwischen den Meetings aufgebaut, das heißt im Team geht es ja nicht nur um, wie lösen wir Probleme, sondern auch viel, hey, wie bauen wir Vertrauen auf. und in einem kleinen Team, was eng zusammenarbeitet und da gibt es auch sehr viel Theorie zu, auch aus dem Startup-Bereich, wo man irgendwie so ein gemeinsames äußeres Feindbild hat, dann hat man ein sehr enges Team, großes Vertrauen und kann irgendwie, sehr schnell weiterarbeiten. Man merkt sehr schnell, wenn es Leuten nicht gut geht, auch als Manager, hey, die Leute haben Probleme, dann kann man viel, viel besser darauf eingehen, wenn man mit einem kleinen Team im Raum ist. Wenn man irgendwie eine Veranstaltung organisieren will fürs Team, ist das super einfach. Ich habe es erst diese Woche wieder gehabt, plane gerade einen großen Event. Ja, das ist sicher halt da. Schreibt die Assistenz das vor, dann reviewt man das, dann geht das ans Leadership-Team, gibt es dann ein Word-Dokument, wo alle Feedback geben können, wo man dann die E-Mail formuliert. Dann muss das nochmal mit den Organisatoren abgestimmt werden, dass halt auch alle Fakten genau stimmen. Und dann hat man alleine um die E-Mail rauszuschicken an ein paar hundert Leute und dass man natürlich auch erstmal das Leadership Team mitnimmt, die wissen was sie denn ihren Leuten erzählen, dann hat man schon mal zwei Stunden Aufwand damit verbracht, was man vorher vielleicht in fünf Minuten in einem kleinen Meeting oder kurz vorm Mittag erzählt hat. muss man jetzt natürlich auch auf einer viel größeren Skalierung viel genauer kommunizieren. Man muss viel mehr Leute mitnehmen. Wie gesagt, wenn man größer ist, dann gibt es auch mehr Missverständnisse. Da muss man viel, viel mehr Aufwand und Zeit reinstecken, das halt zu machen. Und so sitzt man dann halt da und schreibt dann halt sein Wort, wie gesagt, was vorher halt zwei Minuten kurz mit allen Reden war. Und das sind dann schon Unterschiede, die man halt so in größeren Organisationen irgendwie beachten muss.

Joel Kaczmarek: Und wie löst ihr das? Habt ihr dann da irgendwie so ein Jira, Slack, irgendwas in der Art am Start? Arbeitet ihr mit OKRs? Also was ist denn so? die Vergleichskomponente von früher in einem Raum an den Schreibtisch des Kollegen gehen versus heute, die Kollegin sitzt halt irgendwie vielleicht in einem anderen Land sogar?

Björn Wagner: Ja, ich glaube, man braucht einen Mix aus verschiedenen Kanälen. Die Leute ticken ja auch anders. Manche Leute finden es super gut, irgendwie ganz viele E-Mails zu bekommen und die zu lesen. Andere lesen gar keine E-Mails. Die mögen dann sowas wie ein Slack oder ein Teams-Channel, wo irgendwie Announcements quasi gemacht werden, drüber kommen. OKR ist, glaube ich, ein sehr gutes Tool, um einfach quasi Ziele, Strategie auf die verschiedenen Ebenen zu kaskadieren. Auch hier interessantes Learning für mich, ich hatte auch eine Organisation bei SAP Signal, die ist sehr, sehr stark gewachsen. und wenn eine Organisation wächst, dann kommt man irgendwann an den Punkt als Manager, ich habe jetzt hier fast 20 Direct Reports und irgendwie kann ich mich gar nicht mehr richtig um die kümmern, dann wird es vielleicht Zeit, okay, wir führen doch nochmal einen, sage ich mal, Layer ein, was man natürlich immer vermeiden möchte und Und setzt da nochmal dedizierte Manager rauf, die dann kleinere Organisationen quasi besser managen können. Da gibt es ganz viel Theorie zu. Der Dunbar's Number. Ich glaube, die Theorie sagt, man kann lose Beziehungen mit bis zu 120 Leuten haben. Das ist so ungefähr, vielleicht weiß ich nicht mehr deinen Namen, wenn ich dich in der Kaffee-Ecke treffe, aber wir haben uns schon mal gesehen und ich weiß, du arbeitest irgendwie in dem Team. Das sind so 100, 120 Leute. Das ist so die Theorie. Was ich selber gemerkt habe, wenn man so ab 80 Leuten nimmt es sehr stark ab, dass man sich noch als ein Manager mit den verschiedenen Teams, deren Managern, deren Leuten auseinandersetzen kann. So ab 80 so eine Größe erreicht, dann hat man so viele andere Sachen zu tun. und dann sind es so viele, dass man nicht mehr die Zeit hat, sich wirklich intensiv mit den Bedürfnissen, mit den Problemen oder mit den spannenden Features der einzelnen Teams auseinanderzusetzen. Und dann geht man halt hin, okay, man führt dann halt, man splittet die Organisation, man führt so ein neuen Layer ein, das hilft dann erstmal, dann setzt man dort erfahrene Manager rauf, sag ich mal, die quasi dann die Unterorganisation führen können und da hat man plötzlich ein Problem. Man hat vorher sehr gut mit OKRs gearbeitet, weil man hatte irgendwie ein Produktlevel und darunter, sag ich mal, acht Teams hängen. So, jetzt hat man aber ein Produktlevel, noch ein Level und dann die Teams und plötzlich ist halt alles viel aufwendiger und komplizierter, weil wenn du die Sachen durchkaskadierst, musst du mit dem Level sprechen, du hast ja dann immer Feedback, was du sozusagen top-down reingibst, du willst dann aber auch Feedback von den Teams haben und das geht dann aber durch einen Level mehr durch, dann dauert das nochmal alle zwei Wochen länger, was man macht. Und dann muss man halt auch schauen, wie kann man denn die Kommunikation, die vorher dann vielleicht direkt von mir oder von einem Manager an die Teammanager ging und dann zu den Teams kam, geht jetzt halt noch durch einen Schritt weiter und dann geht immer was verloren. Und dann sind die Leute alle neu und dann kriegt man da schon mehr Reibung rein, und muss halt schauen, wie schafft man es quasi, das ganze Thema, also zum einen die Leute mitzunehmen, zum anderen aber auch nicht die Sachen super ineffizient zu machen. Was wir dann zum Beispiel gemacht haben, wir haben uns angeschaut, okay, vielleicht sollten wir nicht auf jeder organisatorischen Ebene OKRs einführen, weil dann brauchen wir irgendwie sechs Wochen, um alleine die Kaskadierung von oben nach unten und wieder zurück zu machen, sondern dann schaut man sich halt eher an, okay, vielleicht kann man das schlauer zusammenfassen, vielleicht kann man dort Effizienzen finden, wie einfach quasi man bestimmte Probleme oder so zusammenfassen kann und es dann effektiver im Sinne von OKRs umsetzen kann, um halt nicht diese Alignment-Zeit zu weit zu strecken. Ich glaube, da gibt es keine Silver Bullet, wie man so schön sagt. Da muss man wirklich schauen, was macht für die Organisation drin, was brauchen auch die Teams und wie stellt man sicher, dass man eine gute Struktur hat, ohne jetzt zu viel, sage ich mal, Overhead dort zu erzeugen an der Stelle.

Joel Kaczmarek: Ich kann mir das aber auch so liebhaft vorstellen, ich weiß noch, bei meinem Magazin früher, am Anfang konntest du halt alles einfach selber entscheiden, sagst, komm, wir machen mal ein geiles Netzwerkevent, dann hast du es einfach gemacht. Und irgendwann kam es dann an den Punkt, dass du gesagt hast, ja okay, warte mal, also redaktionell betrachtet wollen wir das jetzt so haben. Dann haben wir das Event-Team, das sagt, naja, müssen wir mal so machen, dann hast du das Sponsoring-Team, was das Geld damit verdient, also hast du schon mal drei Interessen, die ganz unterschiedlich teilweise auflaufen konnten. Und es ist ja in der Tech-Szene wahrscheinlich nochmal, es wäre nochmal viel, viel komplexer. Was mich jetzt noch beschäftigt ist so die Frage, was ist denn so deine Erfahrung, wie man dieses Alignment dann hinkriegt, weil man hat ja auch so gerne so diese Videofatig oder Meeting-Fatig, wenn du dann dauernd immer nur so die Kacheln ansiehst und du hast irgendwie 100 Kacheln vor der Nase und du willst aber eigentlich Feedback von den Leuten, du willst wissen, was haben die sozusagen an Know-How aufgeschnappt, vielleicht an der Front. Du willst irgendwie auch erreichen, dass die, sag ich mal, also mitkriegen, ob alle auch alles verstanden haben. Da gibt es ja so viele Faktoren. Was ist da so, was du beobachtest? Vielleicht, wie macht ihr das auch? Was ist da wichtig dann?

Björn Wagner: Also, was für mich ehrlicherweise super weird war am Anfang, sobald man irgendwie mit einer größeren Organisation interagiert und das war vor allem so in den Covid-Zeiten, da waren ja alle komplett remote. Und das Setting, also ich sitze halt in meinem T-Shirt und Jogger quasi vor meinem Screen und mache halt mein One-on-One oder du redest halt mit 150 Leuten und versuchst dir halt gleichzeitig irgendwie eine Vision zu erklären oder Strategie-Update zu geben oder einfach so eine Ask-me-anything-Session zu machen, wo Leute Fragen stellen können. Und gefühlt für dich als Setting ist das eigentlich alles das Gleiche. Wir haben natürlich auch Events, wo man sich dann in Persona trifft und wenn man auf einer Bühne steht vor 150 Leuten oder vor 500 Leuten oder so, ist es dann schon irgendwie eine ganz, ganz andere Nummer. Aber die Kommunikation oder was man macht, ist ja eigentlich das Gleiche. Und auf der anderen Seite bekommt man halt, wenn man auf einer Bühne steht, kriegt man ja viel direkter Feedback auch. Man sieht, wie die Leute reagieren anhand der Gesichtszüge, ob applaudiert wird oder ob es eher so super still ist und man merkt, hey, die Leute driften irgendwie weg. Es ist sehr, sehr schwierig, das in dieser virtuellen Welt zu haben. Das heißt, wie kommuniziert man? Auch wieder verschiedene Mittel. Man versucht irgendwie Sachen aufzuschreiben, strukturiert. Manche Leute mögen es lieber aufgeschrieben. Man versucht viel mit visuellen Mitteln zu arbeiten. Interessant ist auch, man hat Also, wie sammelt man denn Feedback ein, ne? Und dann ist ja so die Standardantwort, ja, wir machen mal eine Survey, ne? Und es ist dann, gibt es ja auch einen Begriff für Survey Fatigue, die Leute kriegen so viele Surveys geschickt, die wissen am Ende gar nicht mehr, was sie irgendwie machen sollen und warum. und dann kann ich mich wahrscheinlich eine Stunde in der Woche oder zwei hinsetzen und nur Surveys ausfüllen, wenn ich das möchte, ne? Das heißt, was häufig sehr gut funktioniert, ist, wenn man so Tools hat, mit denen man Live-Feedback einsammeln kann. Das kann man auch teilweise in PowerPoint einbauen. Ich glaube, Mentimeter heißt das. Also A, können die Leute in einer großen Audience Fragen submitten. Weil wie gesagt, wenn man ein paar hundert Leute drin hat, dann trauen sich viele auch nicht, einfach selbst im virtuellen Setting zu sagen, hey, ich hebe mal die Hand und unmute mich und stelle eine Frage. Sondern eher anonym kann man das machen. Dann kann man die abvoten und dann sieht man das gleich. Oder man kann den Leuten halt auch Fragen stellen. Also was ich ganz häufig mache, was auch ein super Feedback-Kanal ist, Wenn man so eine Strategiepräsentation macht, gibt es eine neue Strategie, gibt es ein Update, stellt man sich jetzt hin, hat man sich ganz viel Mühe gegeben, drei Monate daran gearbeitet und jetzt präsentiert man das vor 100 Leuten oder 500 Leuten. Dann weißt du ja nicht, sagen die jetzt alle, das ist irgendwie das beste seitgeschnitten Brot, endlich sagt es mal einer, wann können wir damit anfangen? oder sagen die, oh mein Gott, jetzt kommt hier wieder der Manager um die Ecke. der seit drei Jahren nicht mehr mit dem Kunden gesprochen hat und will uns hier irgendwelche krummen Ideen verkaufen. Also was ich häufig mache, ist, in diesem Mentee stellt man so drei Fragen. Hast du verstanden, was die strategische Richtung ist? Findest du die gut oder bist du excited, wie man so schön sagt im Englischen? Und verstehst du, wie du in deinem täglichen Job dazu contributen kannst? Und dann, keine Ahnung, gibst du einen QR-Code, dann können die Leute voten einfach und dann kriegst du live so ein Bild und siehst dann live halt, okay, Auf einer Skala von 0 bis 10 oder so, wie würden das die Leute beantworten? Und das ist super, weil das ist in Real-Time, du schickst den Leuten hinterher irgendwie eine Survey nach drei Monaten oder selbst nach einem Tag, wo sie es schon wieder vergessen haben, worüber wir eigentlich gesprochen haben und dann kriegst du so relativ gut Feedback. Aber wie gesagt, das ist halt auch wieder Aufwand, muss man sich Gedanken machen, muss man auswerten. Und im Startup hätte ich irgendwie die drei Leute im Raum gefragt, ob das jetzt Sinn macht oder nicht. Und das ist schon was anderes. Natürlich hat man auch einen viel größeren Impact. Also wenn man quasi mit der großen Mannschaft, sage ich mal, arbeitet und rausgeht, dann kann man auch für Kunden halt am Ende des Tages viel, viel mehr bewegen. Aber den Aufwand in mehr Kommunikation, andere Feedback-Kanäle, den muss man halt auch irgendwie natürlich reinstecken.

Joel Kaczmarek: Was sind so deine wichtigsten Learnings im Bereich Kommunikation nach all den Jahren?

Björn Wagner: Also ich glaube, Kommunikation, je größer die Firma wird oder die Organisation, desto exponentiell mehr muss man damit reinstecken. Und das Allerwichtigste, was ich eigentlich gelernt habe, ist Wiederholung, Wiederholung, Wiederholung. Man sagt ja immer, Strategie ist am Ende nur so gut, wie man sie auch kommuniziert bekommt. Und das ist, glaube ich, super wichtig. Wie kann man eine Vision, die die Leute mitnimmt, wie kann man eine Strategie auch an die Leute kommunizieren, dass sie irgendwie dabei sind. Wie gesagt, im Startup-Kontext geht das ganz einfach, wenn man irgendwie 10, 20, 30, 50 Leute ist, gibt es ja so die typischen alten Google-Beispiele, einmal in der Woche kommen die Founder, da kann man Fragen stellen, die präsentieren, was haben die Kunden irgendwie die Woche über erzählt, was waren die neuesten Entwicklungen? und man ist sehr, sehr nah zusammen im Team. In diesen größeren Kontexten muss man dann viel mehr Zeit reinstecken, in irgendwie Materialien vorbereiten, die verteilen, interaktive Sessions haben oder auch wie gesagt Sachen zum Lesen anbieten, damit man halt alle Leute mitnimmt und so ein bisschen in dieselbe Richtung quasi bekommt an der Stelle.

Joel Kaczmarek: Tja, es gibt ja immer diese Sprüche, wenn du denkst, die können es nicht mehr hören, ihnen bluten die Ohren. Ich habe es schon so oft gesagt, dann musst du es noch einmal mehr sagen. Oder ich glaube siebenmal war der Punkt, den ich auch mal gehört habe. Siebenmal muss man etwas gesagt haben, bis es wirklich verstanden wurde. Das unterschätzt man immer massiv. Nun gut, kommen wir zu unserem letzten Bereich, Risiko. Würdest du sagen, dass Product Engineering in einem Startup versus in einem Corporate mit anderem Risiko behaftet ist?

Björn Wagner: Ja, absolut. Also Risiko und halt auch Verantwortung vielleicht das andere. Also wenn ich halt mein Startup mit zehn Leuten habe, wahrscheinlich gar keinen oder relativ wenig Umsatz, so klassischerweise, muss ich mir ganz, ganz andere Fragestellungen stellen. Wir haben ganz am Anfang schon so ein bisschen über auch Geschwindigkeit gesprochen. Als Startup habe ich ja vielleicht ein, zwei, drei Kunden und wenn ich jetzt nochmal eine größere Änderung im Produkt mache dann kann ich die wahrscheinlich relativ mitnehmen oder selbst wenn ich die dann verliere, weil ich mein Kundensegment ändern will, dann kann ich damit halt auch leben. Was man dann halt, je größer man wird, desto mehr Legacy, das heißt, desto mehr Altlasten trägt man halt auch immer mit sich rum. und dann gibt es dann ganz spannende Sachen, mit denen wir dann auch auf einer täglichen Ebene quasi uns beschäftigen müssen. Zum Beispiel haben wir ein neues Feature eingeführt, ein neues Produkt, was eigentlich den Kunden, Jetzt wieder beim Thema Onboarding, was das sehr, sehr stark vereinfacht. Also eigentlich machen wir alles besser, einfacher, schneller für die Kunden. Jetzt aber das Problem, die Bestandskunden müssen damit eine Änderung durchführen. Da gab es eine Komponente, die war zum Beispiel hauptsächlich noch On-Premise ausgeliefert vorher. Das heißt, die wurde irgendwo gehostet und die haben wir jetzt in die Cloud gebracht, haben wir alles einfacher, günstiger, schneller gemacht. Aber jetzt hat man dann halt seine 20 Kunden und die muss man halt migrieren und migrieren heißt halt Aufwand, dann muss man dann plötzlich, dann baut man nicht ein neues Feature, sondern dann macht man sich plötzlich Gedanken, okay, wir müssen jetzt auch noch selber Consultants oder Partner sponsern, die da Tage investieren, um halt quasi von dem alten Setup die Kunden auf das neue Setup zu migrieren und nur dann können wir das alte Setup halt auch wirklich abschalten. Und hier muss man dann über Monate mit Partnern, mit Beratern zusammenarbeiten, um dann halt irgendwie alte Sachen abschalten zu können, auf die neue zu migrieren und dann halt wirklich den gesamten Value zu haben. Sowohl vom Aufwand, auch von der Komplexität, plötzlich hat man vielleicht, war das Feature ganz einfach zu bauen, aber der Aufwand liegt dann darin halt erstmal allen mitzunehmen, zu kommunizieren, abzustimmen, das Investment zu sichern, das Budget zu sichern, die irgendwie Timeline zu sichern, da muss man die Kunden mitnehmen, ne. Und dann hat man plötzlich die Komplexität und die Geschwindigkeit gar nicht in der Entwicklung verloren, sondern eigentlich im Rollout später. Und genau, mit den Sachen setzt man sich auseinander und wenn man natürlich je mehr Kunden man hat, Tausende, Hunderttausende oder Millionen, desto größer wird halt auch das Problem am Ende des Tages.

Joel Kaczmarek: Würdest du sagen, ich meine, wir reden die ganze Zeit über beide Welten, so im Vergleich, dass man im Startup-Bereich manchmal einfach auch schlichtweg unprofessioneller ist als im Corporate-Bereich?

Björn Wagner: Das hängt jetzt natürlich von Startup zu Startup ab, aber absolut. Es geht auch in ganz andere Richtungen rein. Als Startup hat man natürlich viel weniger Zertifizierung, viel weniger, sage ich mal, sicherheitsrelevante Themen, die man vielleicht auch umsetzt. Und hier ändert sich ehrlicherweise die Zeit auch, glaube ich. Am Anfang von vielen SaaS-Anwendungen, da war das noch gar nicht so stark auf dem Radar, da konnte man noch viel einfacher starten. Aber selbst wenn man heute als Startup in gewissen Industrien mit gewissen Daten oder kritischen Daten von Kunden handhabt, dann wird man dort schon vor schwierigere Hürden gestellt, die man plötzlich auch im Rahmen von Risikominimierung, Zertifizierung und so weiter schon vielleicht deutlich früher managen muss, als noch vorher. Und AI macht es ja auch nicht unbedingt einfacher. AI sorgt da auch nochmal für eine ganz andere Komplexität mit unter, wenn es halt darum geht, wenn die Leute die Kunden verstehen müssen, was passiert denn jetzt genau mit den Daten, von in welchem Land werden die prozessiert, bis hin zu welche Zertifizierungsstandard habt ihr denn? Ich glaube, die Hürden werden dort auch größer, was teilweise den Markt eintritt, zumindest in bestimmten Branchen, wie gesagt, für Startups halt auch schwieriger macht und für größere Firmen halt einfacher.

Joel Kaczmarek: Wie ist das denn juristisch, weil ich gerade so drüber nachdenke, als du eben meintest, so mit dem Startup wird man einfach gesagt, pass mal auf, können wir hier umziehen und ansonsten fliegt da halt raus der Kurve. Kann ja natürlich aber auch zu einem Wirtschaftsschaden zum Beispiel bei einem Kunden führen. oder du baust was Neues und dein Wettbewerber sagt halt so, warte mal ganz kurz, hast du von mir kopiert. Also gibt es juristisch, legalseitig Unterschiede zwischen beiden Sphären?

Björn Wagner: Absolut, ganz groß. Auch die Regeln sind deutlich schärfer. Wie gesagt, wenn ich halt hunderttausende Kunden bediene und für kritische Anwendungen ausliefere, dann haben die Kunden natürlich auch dort sehr viel strengere Verträge als mit so einem Startup. Und als Startup im Zweifel, wenn ich halt zehn Leute habe, da kann mich auch keiner auf Millionen verklagen, weil das Geld ist eh nicht da, dann ist die Firma vielleicht pleite. Aber wenn ich halt irgendwie ein paar hundert Millionen Milliarden Umsatz mache und dann auf ein paar hundert Millionen verklagt werde, dann sieht halt die Welt schon anders aus. Deshalb hat man irgendwie so auf der legalen Seite und was halt so vertragliche Anforderungen ist, ich kann nicht heute ein Feature bauen und das morgen abschalten. Das ist in der Regel so, wenn du das baust, musst du es drei Jahre mindestens drin lassen oder die Kunden lassen dich vorher raus. Das sind eher so Regeln, auf die man dann trifft und die natürlich auch, was so langfristige Kosten angehen und auch wieder Geschwindigkeit, Wartung und so weiter halt einen ziemlich großen Impact haben.

Joel Kaczmarek: Ich denke halt noch so, man hat ja auch irgendwie, also ich kenne es eher so aus dem Hardware-Bereich, dass sich ja Unternehmen auch gegenseitig verklagen wegen Patentverletzungen. Gibt es das eigentlich bei Software auch, wenn du jetzt an Product Engineering denkst? Also A, gibt es das und B, hast du da im Startup-Bereich schon drüber nachgedacht oder ist das eher so ein Corporate-Thema?

Björn Wagner: Ganz, ganz heißes Thema, gerade unter Entwicklern, weil im Softwarebereich gibt es ja viel Open Source, das ist auch viele Entwickler sind halt natürlich, weil A nutzen wir sehr viel Open Source Technologien sowieso und sind natürlich auch daran interessiert irgendwie zurückzugeben in der Community aktiv zu sein, das ist schon so eine intrinsische Motivation und Patente sind ja genau das böse Gegenteil davon. Auf der anderen Seite auch ab einer gewissen Größe, muss man sich halt schon anschauen, ja, Patente sind doch im Bereich Software wichtig. Und man kann halt zwei Strategien fahren. Zum einen kann man sagen, man möchte möglichst offensiv sein, man möchte ziemlich viele Patente haben und dann halt auch irgendwie aktiv, ich sag mal, verschiedene Konkurrenten angehen, um dann halt über, also die entweder auszubremsen oder sogar Geld durch irgendwie Lawsuit zu bekommen. Dann gibt es aber andere, die das eher defensiv machen, die auch Patente sammeln quasi und und das dann aber nutzen, dass sie quasi nicht durch die Konkurrenz verklagt werden können auf der anderen Seite zum Beispiel. Also man kann schon verschiedene Strategien haben, auf einer gewissen Größe kommt man glaube ich um das Patentthema grundsätzlich nicht mehr drum herum und verschiedene Firmen machen das ja sehr verschieden. Ich glaube Tesla, wenn ich es richtig im Kopf habe, ist ja zum Beispiel auch hier bekannt, die haben glaube ich alle ihre E-Auto-Patente auch öffentlich gemacht grundsätzlich. Also das zeigt, sie wollen damit kein Geld verdienen, aber sie können halt auch für gewisse Sachen nicht verklagt werden. Also man kann schon verschiedene Sachen machen. Es gibt natürlich auch, je nachdem, was meine Value Proposition als Startup ist, wenn ich halt was sehr Technisches habe oder was sehr schützenswert ist, dann beschäftige ich mich das vielleicht auch schon von Anfang an, je nachdem, wo halt mein Innovationsbereich ist, aber häufig, also ab einer gewissen Größe kommt man, glaube ich, um das Thema nicht mehr drum herum an der Stelle.

Joel Kaczmarek: Ja, schön. Ich glaube, da haben wir doch einen guten Ritt gehabt. Also Geschwindigkeit betrachtet, Prozesse betrachtet, Kommunikation und Risiko und Verantwortung. Und ich finde auch alles irgendwie ganz logisch eigentlich. Also man merkt natürlich, wenn die Reise länger wird und die Komplexität zunimmt, dass sich dann auch diese Dinge verändern. Ja, ich würde jetzt normalerweise fragen, was machst du lieber? Aber du hast ja schon mehrfach gesagt, dass es eigentlich beides so seinen Charme hat und vielleicht manchmal auch eine Frage der Phase oder der Präferenz ist, wo man sich auffällt.

Björn Wagner: Also was ich eigentlich mit am spannendsten finde, ist, wenn man mal durch so eine gewisse Journey durchgegangen ist. Also wenn man mal gesehen hat, okay, so funktioniert es im Kleinen und man ist dann mal das Wachstum auch mitgegangen, weil es ist ein sehr großer Unterschied, ob ich halt in eine große Organisation reinkomme und das sind schon die Prozesse, die Strukturen, die Arbeitsweise ist schon auf der Skalierung, sage ich mal, vorgesehen versus man fängt eigentlich sehr klein an und man muss ja nicht nur quasi die Organisation größer machen, sondern natürlich auch noch die Strukturen, die Prozesse, die Sachen etablieren. Ist auf jeden Fall aus persönlicher Sicht eine sehr spannende Lernerfahrung.

Joel Kaczmarek: Ich überlege gerade noch so, meinst du es macht irgendwie auch Sinn, es gibt ja im Medienbereich, in meiner Sphäre gibt es ja sowas wie ein Volontariat oder auch, ich weiß gar nicht, wie diese andere Ausbildungsform heißt, wo man aber im Prinzip verschiedene Stationen durchläuft. Macht es im Product- und Engineering-Bereich auch Sinn, dass man zum Beispiel sagt, jemand den man neu einstellt, Dass man Partnerschaften mit anderen Unternehmen macht, die ähnlich gelagert sind und tauscht dann Mitarbeiter mal irgendwie für ein Quartal oder für einen Monat oder für ein halbes Jahr aus und dass man mal so die unterschiedlichen Aspekte in genau diesen vier Bereichen sich eigentlich anschauen kann, wie das andere lösen?

Björn Wagner: Gute Frage. Also ich glaube Zwischenfirmen habe ich das noch nicht gesehen. Also natürlich machen viele Praktika, als Werkstudent kann man sich verschiedene Sachen anschauen. Was wir schon haben intern ist, dass man auch als, es gibt so verschiedene Studentenprogramme intern, wo man verschiedene Stationen durchläuft und sich verschiedene Abteilungen anschauen kann, aber dann halt schon innerhalb einer Firma. Aber was ich nur jedem Studenten oder jedem Bereich Software Engineering, Informatik, Produktmanagement empfehlen kann ist, einfach mal alles auszuprobieren im Studium. Wie gesagt, ich glaube Werkstudenten war selbst für mich super interessant, auf verschiedensten Größen mal reinzuschauen, zu gucken, wie arbeiten die Leute, wie arbeiten die Firmen. Und irgendwie, was interessiert mich am meisten? Um einfach mal zu verstehen, was einen wirklich am meisten motiviert. Ist es die Skalierung, um wirklich vielen Leuten viel Impact zu haben? Oder möchte ich mit einem möglichst kleinen Team auf einer kleinen Skalierung anfangen? Das sind, glaube ich, schon sehr unterschiedliche Sachen. Kann man auch probieren und kann man viel lernen.

Joel Kaczmarek: Gut, also egal ob groß oder klein, Product in Engineering bleibt fein. In diesem Sinne, vielen, vielen Dank, lieber Björn und bis zum nächsten Mal.

Björn Wagner: Danke dir, ciao.