Der Erfolg von Fynn und die Rolle von No-Code Tools
00:00:05
Speaker
Herzlich willkommen zu einer neuen Folge vom Visual Makers Podcast. Nach einer kurzen Sommerpause von vier Wochen sind wir wieder zurück und ich freue mich, heute einen ganz besonderen Gast in der Folge zu haben. Das Münchner Scallop Finn gilt als das Paradebeispiel für die erfolgreiche Eskalierung mit No-Code. Die Verwendung von No-Code-Tools wie Make, Airtable, Webflow und Co. haben es Finn ermöglicht, innerhalb von so kurzer Zeit ein selten gesehenes Wachstum hinzulegen.
00:00:34
Speaker
Jetzt haben sie einen Artikel veröffentlicht mit dem Titel No Code Isn't Scalable. In dieser Folge spreche ich mit Andreas Wixler, CTO und Co-Founder von Fynn, über die Rolle, die No Code beim Erfolg von Fynn gespielt hat, wie man es hinkriegt, No Code erfolgreich in die Unternehmens-DNA zu implementieren.
00:00:53
Speaker
und warum sie beschlossen haben, in ihrem Hauptprodukt jetzt auf Code zu wechseln und warum das eigentlich kein Widerspruch ist, sondern vielmehr eine Evolution ihres Toolstacks ist.
Andreas Wixlers Weg und technologische Innovationen bei Fynn
00:01:05
Speaker
Darüber spreche ich mit Andreas. Ich freue mich sehr auf die Folge und ich wünsche euch viel Spaß beim Hören. Herzlich willkommen, Andi. Schön, dass du da bist. Ja, vielen Dank für die Einladung, liebe. Es ist sehr nice, dass ich hier dabei sein darf.
00:01:19
Speaker
Ja, ich freue mich. Ich freue mich sehr. Wir hatten ja schon mal vor ein paar Podcastfolgen, ich glaube, Nummer 45. Wir hatten jetzt eine Monatpause drin an unserem Podcast in einer kleinen Sommerpause. Und ich glaube, in Folge 45 haben wir auch schon mit Jens gesprochen. Jens ist Product Manager bei euch. Da haben wir auch schon tiefer über Finn gesprochen. Das werden wir jetzt gleich auch noch tun. Aber bevor wir, bevor wir näher uns mit Finn beschäftigen, lasst uns doch erst mal kurz kurz zu dir kommen.
00:01:49
Speaker
Wie ist so dein Werdegang? Wie bist du denn eigentlich zu Fynn gekommen? Ja, genau. Also ich bin Andi38, schon ein paar Tage älter damals, als wir Fynn gegründet haben. Seit Oktober 2019 bin ich bei Fynn als CTO für alles Technische verantwortlich und habe auch das große Glück, auch einer der Co-Founder zu sein. Bei Fynn vorher habe ich Klassisch-E-Commerce gemacht.
00:02:14
Speaker
Ecomass ist etwas, wo ich mich massiv wohlfühle. Wir sind eigentlich ein zusammengestöpseltes Team. Es ist jetzt tatsächlich nicht, dass wir uns die besten Buddies waren, sondern wir kannten zum Teil gar nicht. Nur über zwei, drei Ecken. Und so ist dann Finn entstanden. Das heißt, ich wurde ganz, ganz klassisch per LinkedIn angeschrieben. Und genau, so ist Finn entstanden und so bin ich dann bei Finn gelandet.
00:02:39
Speaker
war vorher fünf Jahre lang beim anderen deutschen Münchner E-Commerceler oder europaweit tätig. Hab Möbel verkauft, hätte ich fast gesagt, nee, alles für Home and Living. Und genau, wiederum vorher noch selber gegründet gehabt und wiederum vorher auch im R&D Bereich bei IBM tätig. Also vieles gesehen und vieles mitgemacht von klassischer Forschung bis zur
00:03:05
Speaker
Muckelei, also so nenne ich gerne Softwareentwicklung. Genau alles, was dazu gehört und selber Softwareentwickler gewesen für die Karten. Ja.
No-Code als Mittel zur Wertschöpfung bei Fynn
00:03:13
Speaker
Muckelei, das finde ich auch ein sehr schönes Wort für Softwareentwicklung. Ich finde es ganz spannend, dass du ja einen sehr technischen Background hast. Du hast ja auch Computer Science und Physik studiert und wie du jetzt gerade schon gesagt hast, eben bei wirklich namenhaften Unternehmen als Entwickler gearbeitet und als Teamlead für die Entwickler und so.
00:03:36
Speaker
Wie kam es denn zu No-Code? Weil Finn ist ja quasi das paradische Beispiel für die Skalierung eines Start-ups mit No-Code. Wie bist du denn zu No-Code gekommen? Eigentlich tatsächlich ausschließlich über Finn. Also vorher war das Thema No-Code war kein Thema für mich, absolut gar nicht. Dazu muss man aber auch ein bisschen so Historie wissen.
00:04:02
Speaker
Dadurch, dass ich selber Entwickler war und Soft-Entwicklungsteams geleitet habe, über 80 Leute, iOS, Android und Web Development, gab es da so eine Regel, die sich für mich so manifestiert hat. Und avoid engineering for the sake of engineering. Also auf Deutsch, Engineering nur zu machen, um Engineering zu machen, das reicht nicht. Und wenn man dann ganz, ganz defensiv hineingeht und sich selber gegenüber nicht bullschüttelt,
00:04:31
Speaker
dann bleibt nicht mehr viel übrig, dass man sagt, okay, wie schaffe ich das, company-weit, dieses wirklich Mindset zu integrieren? Wir machen etwas, um einen Wert zu schaffen. Und da kommt dann No-Code so ein bisschen, so einen kleinen Nuancen rein. Und dann, wenn man dann noch tiefer reingeht, dann kommt so eine zweite Statement von mir immer wieder rein. Und das ist, ja, we buy commodities, we build assets.
00:05:01
Speaker
Wie kannst du etwas, was löst ein Problem mit Geld, wenn du es mit Geld lösen kannst? Also in diesem Fall Comority. Aber fokussiere dich darauf, um wirklich Wert zu schaffen. Wenn man das alles kombiniert, dann ist No-Code ein Ansatz. Tatsächlich ein Ansatz. Da gibt es natürlich verschiedene andere, die ich nicht kenne. So tief habe ich mich noch nicht auseinandergesetzt. Aber No-Code war dann ein massives Thema, aber um deine Frage zu beantworten.
00:05:25
Speaker
Ich habe mich damit vorher nicht auseinandergesetzt. Und ich habe all die Schweinereien gemacht, verstehe mich nicht falsch, als Softwareentwickler. Das heißt, ich habe selber meine eigenen Frames entwickelt. Zwei Wochen später habe ich gedacht, was habe ich da eigentlich entwickelt? Und das war die geilste Zeit ever. Ich war glücklich, wie Bolle. Aber das Ding hat keinen Wert generiert. Das war einfach nur Spaß um, ja, ich sage mal, Eigenglückmaximierung, nämlich das. Aber das hat keinen Wert geschaffen. Das hat einfach Spaß gemacht.
00:05:51
Speaker
Ja, auch spannend. Also du meinst auch Tech als Zweck und nicht als Selbstzweck, sondern quasi als Mittel oder als Mittel zum Zweck, nicht als Zweck, sondern Tech als Mittel zum Zweck. Genau. Und das ist immer wieder die Kunst. Also wir können da wirklich, wir können, wenn du magst, zwei Stunden drüber reden. Wie kriegt man das hin? Also da gibt es ja verschiedene Treiber mittlerweile auch im
00:06:15
Speaker
viel Gerede um Efficiency of Engineers, Automatisierung, wie kriegen wir das ganze Thema Digitalisierung hin und so weiter. Das sind so Themen, die für mich zusammengegangen sind. Aber jetzt mal zurückgesprungen im Oktober 2019, da habe ich Perfume angefangen. Da guckt man sich einmal kurz das Business Modell an und merkt, es sind eigentlich zwei Pillars auf Deutsch. Wie heißt das auf Englisch? Zwei Säulen, genau. Eine Säule ist E-Commerce.
00:06:44
Speaker
Das habe ich jetzt zehn Jahre plus gemacht. Okay, take, done, erledigt. No surprises. Ich sage nicht, dass es einfach ist. Es ist bockenschwer, das auf den Kern zu destillieren. Aber nichts Unbekanntes. Und dann kommst du die zweite Säule an und das ist K-Fulfilment. Wie kriegst du diese, als Physiker, wie kriegst du diese 2000 Kilogramm von A nach B? Das ist sehr viel kinetische Energie, die du da bewegen musst.
00:07:13
Speaker
Und nur damit die Zahl mal gefallen ist, um eine CAS-Description anzubieten, End-to-End mit allen Sachen, die dazugehören, brauchen wir 112 Partner. So, jetzt ist die Quizfrage natürlich, wie kriegst du, wie siehst du, Helikopter-View, komplett Helikopter-View, bevor man überhaupt eine Zeile Quellcode geschrieben hat oder überhaupt die Organisation aufgesetzt hat, wie kriegt man diese, ich sag jetzt mal, diesen Service so Asset-Light oder nicht Asset-Light, Asset-Light Operations, würde ich sagen.
00:07:44
Speaker
Wie kriegt man diese erste Light Operations hin? Das heißt, am Ende reden wir von Massive Partner Integration, auf Englisch gesagt, on scale. Also am Ende, wie kriegst du diese 100 verschiedene Partner orchestriert? Und nach drei Jahren Fynn, im Oktober ist es bald so weit. Ich kann dir sagen, wir haben jeden einzelnen Partner ausgetauscht.
00:08:10
Speaker
OEMs, Banks, Insurance Provider, dann Infleeting, Car Delivery, Gutachten, also Appraisals, Car Registration. Jeden einzelnen Provider, selbst unseren 24-7 Hotline Provider, haben wir auch austauschen müssen, weil die zum Teil entweder mit uns nicht skalieren können oder der Service erfüllt nicht unseren Anspruch. Man überlegt mal, wenn du das alles orchestrieren musst und alles machen musst,
00:08:40
Speaker
ohne jetzt genau den Bereich KVL-firma zu kennen, dann ist NoCode schon eine sehr, sehr attraktive Alternative zur, ich sage jetzt mal, eine ganze große Organisation, Engineering-Organisation von Scratch anzubauen. Und all die ganzen Challenges, die man als Startup hat, hat Scale, Hyperscale, man muss noch prüfen, dass das Business überhaupt funktioniert, all das kommt noch on top.
00:09:09
Speaker
Und dann bleibt, ist No-Code ein Ansatz, ja.
Evolution des Technologie-Stacks von Fynn
00:09:12
Speaker
Ja. Auch vor allem vermute ich wegen, also einmal, ihr seid ja unglaublich schnell. Also wenn man sieht, wo ihr jetzt seid und dann, wo du gerade gesagt hast, bald ist es drei Jahre mit Fynn. Ich kurz schlucken musste und dachte krass, stimmt, es sind erst drei Jahre und wie weit ihr damit schon gekommen seid. Und wahrscheinlich ist Schnelligkeit einmal ein Ansatz von No-Code und Agilität, dass ihr auch dadurch, dass ihr No-Code benutzt habt von Anfang an. Ich glaube, ihr habt mit
00:09:37
Speaker
Google Sheets, Webflow und Zepia damals tatsächlich, glaube ich, angefangen, oder? Genau. Und dann immer weiter evolutioniert und weitere Partner mit dazu genommen, die ihr dann angebunden habt durch Zepia und habt quasi dadurch immer euer Tech Stack oder evolutioniert. Immer mit den Anforderungen, richtig?
00:09:58
Speaker
Ja, absolut, absolut. Aber das klingt jetzt so, ich sag mal so zurückblickend, klingt das so, alles total organisch, logisch gewachsen. Ja, das wäre natürlich die PR-Version wäre es natürlich absolut. Aber du darfst nicht vergessen, also ab Tag eins war uns klar, also mir insbesondere, dass wir müssen alles automatisieren. Nur so kriegen wir Hyperscale hin. Wir wussten ganz genau, wir bauen hier ein Business.
00:10:24
Speaker
was nicht irgendwie übermorgen wieder weg ist. Das heißt, wie kriegen wir Automatisierung hin? Das ganze Thema No-Code, so haben wir gar nicht gedacht. Das ging ausschließlich um Automatisierung. Nur darum. Das heißt, wie kriegt man wirklich Traction hin und baut einen Dienst und bringt Autos zum Kunden hin mit allen Services, die dazugehören und gleichzeitig
00:10:48
Speaker
Zum Parallel dazu, wie heirat man die Ingeniers. Also die ersten 5 bis 6 Monate habe ich nichts anderes gemacht. Wie jeden Tag 6 bis 8 Interviews pro Tag. Klatsche, klatsche, klatsche. Interview, Interview, Interview. Da habe ich keine Zeit, mich um Implementierung zu kümmern. Das hat zweieinhalb Monate gedauert, bis der erste Ingenieur ge-onboardet war. Und guess what? Er hat an der Webseite gearbeitet. Das heißt, mit Next.js die Webseiten-Server, das aufzubauen.
00:11:17
Speaker
Das heißt, die ganze operative Komplexität, da gab's für Monate kein, kein Ingenieur. Und die Autos mussten raus. Ja, ja, verstehe. Und ihr habt aber, also, wenn wir nochmal einmal ganz zum Anfang zurückspringen, wo ihr wirklich mit dem, mit dem absoluten MVP mit, mit Google Sheets Webflow und selb ja gearbeitet habt. Und von, warst du da schon dabei oder kamst du dann, dann dazu? Genau. Ja.
00:11:46
Speaker
Und wie, wenn wir jetzt von dem Tech Stack ausgehen, was war deine Rolle da genau? Dann hast du angefangen Leute zu heuern. Wie hast du denen das erklärt von, okay, wir wollen Hyperautomation machen und wir werden erstmal so viel wie möglich mit No-Code arbeiten? Oder wie hast du denen das vermittelt? Der Satz war ziemlich einfach. We believe in automation und fertig.
00:12:12
Speaker
Das heißt und dann unser Ansatz und dann ganz klar unseren Ansatz erzählt. Lustige Geschichte, der Jens hat tatsächlich die erste Webseite geboten mit Medflow, mit Zapier und dann Google spreadsheet behind the scenes und Webflow ist zumindest für mich nach meiner Definition Low-Code und nicht Low-Code. Du musst schon eine gewisse Coding-Intelligenz mitnehmen und da mit was zu tun.
00:12:35
Speaker
Wir sind da von einem Tool zum nächsten gegangen. Wir haben dann gemerkt, okay, Google Spreadsheet kommt an die Limits, weil immer mehr Entities dazugekommen sind. Das heißt, das ganze Business Model, es war jetzt nicht nur Auto und Subscription als Entity, sondern Tickets, Deliveries. Dann sind dann Topics dazugekommen wie Appraisals, das heißt Rückgaben. Plötzlich gab es Schäden am Auto und dann das ganze Entity Relationship Model ist immer größer geworden. Okay, Spreadsheet.
00:13:03
Speaker
ist ein Limiting Faktor. Das heißt, wir haben die Special erst mal komplett geknechtet. Wir holen immer das Maximum aus dem Tool raus, bis das gar nicht mehr kann. Okay, einmal kurz geguckt. Was gibt es für Alternativen mit API Zugang? Rtable. Okay, ab zur Rtable, einmal Import. Dann sind wir bei Rtable. Und dann weiter. Rtable komplett ausgenutzt mit allen Limits, die wir da haben. Das Ding blutet komplett. Das ist auch der Sinn der Sache. Das ist immer wieder der Ansatz.
00:13:31
Speaker
Du nimmst ein Tool, holst das Maximum aus dem Tool raus, und unten dicken mehr, und dann die nächste Evolution. Und so haben wir uns dann weitergebracht. Das heißt, im No-Code-Bereich, Zapier, da war uns fehlten If-Conditions, ganz ehrlich. Und bei Zapier, die If-Conditions, zum Beispiel damals, war total graus. Inline If-Conditions. Okay, No-Code with If-Conditions, dann sind wir bei damals in Tigromat gelandet, ja, mit einem schönen Router. Hey, cool.
00:14:01
Speaker
Weil wir nichts anderes wollten, wie die Umsatzsteuer rausnehmen für B2B-Kunden und B2C-Kunden müssen die Umsatzsteuer anzeigen. Das war der Use-Gaste. Da war keine Magie. Und so sind wir in dieses Universum dann eingetaucht und haben dann erst gemerkt, was diese Macht an No-Code gibt, insbesondere auch aus organisatorischer Sicht. Wie kriegt man dann
00:14:25
Speaker
diese Mächtigkeit, die man damit als Wert schaffen kann, auch in die Company rein. Das ist ja dann die nächste Challenge, genau. Ja, darüber wollen wir auch gleich nochmal tiefer reden. Vielleicht noch einmal zu dem Ansatz, wo ihr sagt, ihr habt euer Tag Stack immer wieder evolutioniert und immer wieder von Tool zu Tool.
00:14:49
Speaker
Und jetzt habt ihr letztens tatsächlich einen Artikel veröffentlicht mit dem mit dem Titel No Code Isn't Scalable, der, wenn man ihn liest tatsächlich, trotz der Headline, für mich auch eher wie eine Lobeshymne dann doch auf No Code klingt, als andersherum. Welche Rolle spielt No Code nach wie vor bei Finn, auch wenn ihr jetzt auf No Code, auf Code oder auf Custom Code geht und
00:15:17
Speaker
Was waren die größten Herausforderungen, die ihr hattet? Also sehr, sehr, sehr gute Frage. Also absolut. Du hast absolut recht. Der Artikel wurde von der Stärkung vor uns liebevoll isch genannt, formuliert. Und das ist ein Lobosünde auf
Kombination von No-Code und maßgeschneiderter Software bei Fynn
00:15:32
Speaker
ein No-Code. Absolut. Und vielleicht wollten wir ein bisschen so die Trolls füttern. Man sollte uns das nicht böse werden, aber die Leute tendieren, Headline zu lesen, ihre Meinung zu bilden. Wir haben sehr viel Bass generiert. Das war sehr, sehr gut.
00:15:46
Speaker
Und das ist sehr, sehr gut. Aber in a nutshell, was wir jetzt machen, ist wir nennen das No-Code und Hard-Code oder Custom-Code oder Pro-Code nennen das, wie du möchtest. Am Ende bringen wir die beiden Universen noch mehr zusammen. Das ist die nächste Evolutionsstufe. No-Code spielt nicht nur weiterhin eine starke Rolle. Also bei uns ist es nicht No-Code, es ist Automatisierung. Aber wir bringen jetzt Kontext rein. Stell dir das so vor, wenn du vorher
00:16:17
Speaker
Ich sage jetzt mal ein Production-Update. Das heißt, du bekommst ein Auto und jetzt sagt dir beispielsweise ein Tesla oder ein BMW, okay, das Auto wurde jetzt produziert. Bei uns bekommt man auch schließlich Neuware. Das heißt, wir müssen das Produktionsdatum jetzt updaten in der Datenbank. So. Das kann man sagen, okay, wir updaten diesen Datensatz in der Datenbank fertig.
00:16:38
Speaker
Das heißt, was wir jetzt machen ist, wir stellen das Modul bei uns Make, wir haben eine eigene Make Instance, als Modul Cores zur Verfügung. Und dann kann man da drauf, please update me, also watch Szenario, wenn das das Production Kit geupdatet wurde. Wie auch immer das passiert. Das heißt, was wir machen ist, wir bringen Kontext und erheben die Entitäten. Wir arbeiten nicht mehr auf Datenbank Einträgen, sondern zu sagen, wir arbeiten nur noch auf Objekten. Klassische Softwareentwicklung, Objekt-Orientierung.
00:17:07
Speaker
Aber wir bringen Objekte, so wie sie hier gehören, in No-Code rein. Das heißt, jeder kann, jeder Einzelne der ganzen Company kann noch auf diesen Objekt arbeiten, aber die Abstraktionsschicht wird komplett weg. Das ist die nächste Evolutionsstufe, die wir da sehen. Und das wird uns nochmal massiv nach vorne boosten. Das heißt, wir bringen diese Welten nicht nur zusammen, sondern durch diese Zusammenführung schaffen wir ein komplett neues Level. Das heißt, auf dieser Abstraktionsebene können wir viel mehr Werte generieren und viel mehr Werte schaffen.
00:17:38
Speaker
Und das ist am Ende der Hauptgrund, wieso wir das machen. Das heißt, unsere Kernprozesse gehen jetzt immer tiefer in den Pro Code oder Hard Code Bereich, weil wir jetzt nach drei Jahren, fast drei Jahren, erst jetzt ganz genau verstehen, wie jeder einzelne Element dieses Businesses funktioniert. Also und die ersten zwei Jahre, zweieinhalb Jahre, weil die ganze Zeit Rambatt sammeln, Vollattacke, Autos an den Mann bringen und dann verstehen.
00:18:07
Speaker
wie das ganze Biester funktioniert und dafür ist dann Automatisierung oder speziell No-Code einfach ein toller Weg. Ja, glaube ich total und ich finde es auch total interessant,
00:18:20
Speaker
Diese Denkweise, die viele Startups ja haben, ist ja, okay, wir müssen ein tolles Tech-Produkt entwickeln, wo Tech auch wirklich als Selbstzweck dann auch wieder funktioniert und die dann aber Dinge ausprobieren, wo sie unglaublich lange für brauchen und unglaublich unflexibel auch sind in der Anpassung, bevor sie überhaupt irgendeine Idee validiert haben oder ein Konzept oder vielleicht ist die Idee validiert, aber eben wie es dann funktioniert noch nicht.
00:18:47
Speaker
eben mit No-Code eben extrem schnell und agil machen zu können, weil ihr eben auch so schnell Dinge austauschen könnt. Absolut. Aber wie schon gesagt, also das macht absolut Sinn, das genauso zu machen. Wenn du mal ein Software als Service anbietet oder ein SDK anbietet, dann muss man das machen. Du kannst keine CLI oder SDK anbieten und sagen, ich mach das mit No-Code. Wird gehen. Also ich hab jetzt schon drei Ideen, wie man's machen kann. Aber darum geht's nicht gehen. Das heißt,
00:19:13
Speaker
Es kommt immer aufs Business Modell an und das muss man sich immer wieder angucken. Was mache ich hier eigentlich? Also ist es jetzt ein Commodity, die ich anbiete, ist es etwas, wo ich High Uncertainty, Hyperskill, super aggressiver mag. Das heißt, ich muss da richtig schnell und stark radieren. Da muss man, also da muss man seine Ansatz ganz genau wählen. Wenn der Markt bekannt ist und alles relativ klar ist und
00:19:42
Speaker
Dann gibt es verschiedene Ansätze und das ist ein Tool. Das muss jedem bewusst sein. Es ist nicht No-Code wird uns alle ersetzen, nein. Aber Automatisierung ist ein essentieller Teil, um Effizienz zu treiben. Ja, definitiv. Um mal zum Thema zu kommen, wie implementiert man Automation und so ein No-Code-Mindset eigentlich in der Company? Ich glaube, wenn man, also das kennen wir ja zum Beispiel auch als kleineres Start-up,
00:20:11
Speaker
Wenn man anfängt, mit No-Codes zu bauen, in einem relativ kleinen Team, ist das noch die eine Sache, alle mit an Bord zu kriegen und begeistert davon zu bekommen, was No-Code und Automation machen kann, und alle verstehen relativ schnell, was der Benefit ist. In einer größeren Company, und ihr seid inzwischen über 250 Mitarbeiter? 358 habe ich extra nachgeguckt. Also ungefähr 300 in Deutschland, der Rest ist in den USA, genau. Ja, Wahnsinn.
00:20:41
Speaker
Wie kriegt man das hin, so ein Mindset von No Code in die DNA vom Unternehmen zu implementieren? Ich glaube, da müssen wir, also exzellente Frage. Das ist die Frage, die wir uns bei Fynn gar nicht stellen. Wir hatten den Luxus. Wir sind auf Greenfield gestartet. Wir hatten das Mindset komplett sofort in die DNA reingebacken, wenn man das möchte. Das gehen wir auch nicht mehr raus.
00:21:08
Speaker
Aber immer wieder mit einem ähnlichen Mantra. Wir nennen das do it, do it automated. Das ist wirklich, dass man sagt, okay, mach jetzt einmal manuell, mach das zweites Mal manuell, wenn es exakt das gleiche ist, dann automatisierst du das. Und zwar dafür muss man sich Zeit nehmen. Das heißt, wie stellen wir das sicher, dieses Mindset, das einmal aufzubauen und dann solide über die kritische Masse zu steuern, ist glaube ich einfacher.
00:21:37
Speaker
Das heißt, wie stellen wir das sicher, dass jeder Neustart, wir haben unheimlich viele Neustart, 20 pro Monat mindestens. Manchmal auch mit Monaten über 40. Das heißt, es sind besondere Interns, die dann kommen und sechs Monate später dann wieder gehen und dann weiter im Studium weitermachen. Das heißt, wir haben ganz klassisches, ganz klares Onboarding. Mit Video zum Thema Automation, zum Thema, welche Tools wir verwenden, zum Thema Make.
00:22:05
Speaker
Ja, Teebel jetzt mittlerweile wird es ein bisschen weniger und all die anderen Tools wieder zu haben. Und dann gibt es einmal pro Monat auch ein Q&A Session mit dem CDO. Das heißt, mit jedem einzelnen können die Leute ihre Fragen stellen, challenging Fragen stellen, gerne auch ein bisschen mehr zu finden erfahren, um das wirklich dieses Mindset weiter zu treiben. Man muss dasselbe investieren.
00:22:30
Speaker
So, jetzt ist es einfach. Das war jetzt Greenfield. Lass uns drüber reden. Nicht jeder Unternehmer hat den Luxus von Anfang an zu fahren. Wie kriegt man das in eine Company rein, die bereits existiert? Ich glaube, da muss man ein bisschen anders gehen. Verstehe ich bitte nicht falsch. Also einfach zu sagen, lass uns No-Cut machen, weil es ist trendy. Ich glaube, das wird schwer. Wenn ich jetzt drüber nachdenke, ich bin CXO von einer Company. Das heißt, man muss über verschiedene andere Themen ran.
00:22:59
Speaker
Beispielsweise Efficiency of Engineers, aktuell richtig heißes Thema. Oder Automate Everything Mindset, dieses ganze Thema, wie kriegen wir Digitalisierung in unsere Firma rein? Und dieses Mindset zu schaffen, das funktioniert nun, wenn man wirklich wirklich wirklich wirklich selektiv ansetzt.
00:23:23
Speaker
Also wirklich selektiv, auch gerne zum Beispiel als CTO und sagt, okay, ich setze mich jetzt hin, nehme jetzt ein paar 29 Euro, 20 Euro für ein NoCo-Tool, setze mich hin und versuche mich selber dafür zu begeistern, das zu verstehen. Es ist zu einfach und zu günstig, als dass man das nicht ausprobieren kann. Und erst wenn man diesen mentalen Schritt selber macht, dann kann man das auch selber aushauen.
00:23:52
Speaker
So würde ich es machen. Und erst dann, wenn man selber dieses Feuer hat, kann man dieses Feuer in anderen dann entfachen. Einfach nur verlangen, bitte brennt, funktioniert nicht. Also man muss schon selber das Feuer entfachen und dann über ganz andere Ansätze, über Tooling wird das eher schwer, sondern vielleicht Effizienzmetriken oder Optimierungsmetriken dran gehen. Jetzt als CTO. Ich will, dass meine Ingenieure sich auf das fokussieren, was wichtig ist.
00:24:22
Speaker
Und dann sollen die nicht immer den gleichen erneuen Job machen. Was machen Ingenieure? Hand aus Herz und weiter gelogen. Ingenieure machen irgendwelche PDF-Exports von irgendwelchen Daten, die bekannt sind, irgendwelche Table Views erstellen und irgendwelche Card-Operationen. Meistens. Dann hast du im Wesentlichen 60 Prozent der Zeit auf ein regularer Ingenieur. Das heißt, wie kriege ich diese erneuen Taschen, also wirklich diese Taschen an diesen Commodity von einem Ingenieur weg?
00:24:51
Speaker
Wirklich komplett weg. Nicht schneller machen den Ingenieuren, sondern komplett weg. Die dürfen gar nicht beim Ingenieur auffallen, weil Ingenieuring ist teuer im Vergleich zu anderen. Das heißt, NoGood ist eine Möglichkeit, um Ingenieurs effizienter zu machen, in dem Moment, dass man sagt, die machen das einfach gar nicht, sondern andere Leute machen das und die blühen da zum Teil da drinnen auf. Das heißt, man könnte dann
00:25:15
Speaker
Einfach anfangen, 29 Euro Kreditkarte selber schon mal loslegen. Zwei, drei Leute ausstatten. Probier das mal. Guck mal, wie das funktioniert. Und dann, wenn man merkt, da gibt es eine gewisse Traction. Dann kann man das entsprechend mit neuen zusätzlichen Rollen unterstützen. Wir haben bei Fynn zum Beispiel den Business Automation Manager. Dann nennen wir BAM in jedem Departement eine dedizierte Person, die nur Automations macht und auch für alle Automationsfragen
00:25:43
Speaker
in den Departments zur Verfügung stehen. Und jeder hat Zugriff auf unsere Make Instance. Jeder, der bei Fynn anfängt, automatisch wird das provisioned und hast Zugriff auf. Das ist Google Workspace, Zugriff, RTB, Zugriff und dann entsprechend auch Make-Zugriff. Ja. Und sind die, sind diese sogenannten BAMs, sind das, haben die einen Entwickler-Background oder sind die in den Fachabteilungen und kriegen zusätzlich die Automation-Ausbildung?
00:26:10
Speaker
Das sind meistens keine Engineering-Leute, keine Engineering Foundation, sind sehr, sehr smarte Leute mit dem Ingenieurs-Hintergrund oder Wirtschaftsinformatik oder ähnliches. Also die Leute, die wirklich an der Automatisierung interessiert sind, sind sehr, sehr smarte Leute und die können dann, also die haben keine klassische Software Engineering ausgebildet, aber die denken gerne in Lösungen und nicht in Probleme. Das ist so, ich sag jetzt mal das Recruitment Targeting Ziel.
00:26:38
Speaker
Ja, ja schön, das glaube ich. Ich finde, was du eben gesagt hast, da sind nochmal einige Aspekte drin, gerade wenn
00:26:49
Speaker
wenn ein CTO jetzt überlegt in einer Company, die noch keinen No-Code oder keine Automation benutzt, einmal das Tool selbst auszuprobieren und dadurch aber auch ein Mindset zu entwickeln, weil das finde ich auch ganz wichtig, wenn man No-Code in eine Company mitbringt, dass es ja nicht nur darum geht, das Tool zu lernen und technisch zu lernen, quasi was sind die Funktionen und was kann das, sondern auch ein Mindset zu entwickeln von wo sind überhaupt Automatisierungspotenziale, was kann ich überhaupt automatisieren,
00:27:18
Speaker
Und wie kann ich das in den einzelnen Fachabteilungen implementieren, dieses Wissen, weil die ja die Prozesse viel besser kennen als ein Engineering-Team oder eine IT-Abteilung oder so was. Absolut, absolut. Ich könnte jetzt hyper aggressiv argumentieren und sagen, okay, das ist jetzt ein Return und Invest.
00:27:41
Speaker
Sagen wir mal, man ist CTO, man hat richtig Bock drauf. Man sagt, okay, die 20 Euro für einen Make-Account. Ich nehme jetzt Make als Beispiel, weil wir Make verwenden. Die Preise der anderen kenne ich nicht. Ich gehe da rein, trage das ein, kann mal ein bisschen was automatisieren. Sagen wir mal, ich will meine Inbound-E-Mails mit einem Open AI analysieren. Dann soll dann automatisch antworten, ob die net antworten oder weniger net, je nachdem, wie die AI entscheidet, um dann irgendwas zu automatisieren. So kann ich anfangen. Nach ein, zwei Tagen habe ich
00:28:11
Speaker
Rumspielen habe ich ein Gefühl dafür. Und jetzt lassen wir ein Gefühl dafür. Und wenn man dann merkt, okay, ich meine das ernst, dann kann man ja immer noch dieses, so ein Projekt auslesen. Ganz klassisch. Im C-Level denkst du im Projekt. Okay, kann. Integration Project, Migration Project oder ähnliches. Das ist ein wirklich ganz einfaches Beispiel. Sagen wir mal, das kostet nicht 20 Euro pro Monat pro User. Das ist jetzt kein fremder Betrag. Sagen wir mal, du hast eine Company mit 100 Leuten. Das heißt, du
00:28:40
Speaker
Das kostet dich 2.000 Euro pro Monat. Ich mach das jetzt live. Also wenn ich mich verrechnet habe. Das heißt, es kostet dich 2.000 Euro pro Monat, die ganze Company damit auszustatten. Das ist das Risiko. Pro Monat. Das heißt pro Jahr 24.000. So. 100 Leute kosten dich im Jahr, im Schnitt sagen wir mal 50.000 Euro. Es wird eher mehr sein. 5 Millionen Euro. Das heißt, du investierst 24.000 im Vergleich zu 5 Millionen. Das ist jetzt ein ganz kleiner Betrag von
Der ROI und die Effizienz von No-Code
00:29:10
Speaker
von den Kosten. Und der potenzielle Uplift ist, sagen wir mal, die Leute werden um ein Prozent effizienter. Also den Business geht, da muss ich jetzt nicht hoch mathematische Komplex-Integrale lösen, um zu verstehen, dass das Ding sich nach einem halben Jahr rentiert. Ganz einfach. Und was ich dann machen würde, ich würde es genauso aufsetzen, okay, das Risiko sind 24.000 Euro und nach einem Jahr und dann sage ich, use this tool or don't use it, it's up to you. Macht damit, was ihr wollt. Und nach einem Jahr würde ich das komplette
00:29:40
Speaker
Projekt killen. Und dann gucken wir, wer rumholt. Wenn dann mehr als zehn Leute scheinen, nein, nein, nein, aber ich verwende es doch, dann war es doch ein Success. Hat dich 24.000 Euro gekostet. Also das ist jetzt wirklich ein populistischer Case. Aber so würde ich es tatsächlich machen. Und wenn dann keiner schreit, das ist mir aber wichtig, dann war es ein unwichtiges Tool. Und das würde ich genauso mit ihren anderen tun. Ja. Das ist ein radikaler Ansatz, würde ich sagen.
00:30:07
Speaker
Ja, das ist schon ein radikaler Ansatz, aber ich verstehe es nicht halb, wo du damit hin willst, weil ich glaube schon, dass es noch mal noch mal was braucht, um diese Begeisterung anzustoßen, weil ein Tool in den Raum zu schmeißen und also das funktioniert ja bei einigen Menschen sehr gut, einfach ein Tool in den Raum zu schmeißen und hier guck mal. Aber bei vielen ist es ja dann doch auch ein also Macht der Gewohnheit, einfach die Tools zu nutzen oder so so zu machen, wie man es halt schon immer gemacht hat. Und natürlich braucht es Zeit, Automatisierung aufzusetzen.
00:30:35
Speaker
Und vielleicht auch erst mal die eine Automatisierung aufzusetzen, dauert vielleicht auch mehr Zeit, als ich jetzt brauchen würde, um das Ding zweimal manuell zu machen, den Prozess. Oder ob ich jetzt von einer Excel-Tabelle ins nächste kopiere und mir Gedanken zu machen, von wie automatisiere ich diesen Prozess überhaupt, dass der auch sinnvoll ist. Weil, sagen wir mal ehrlich, ein schlechter Prozess, der digitalisiert ist oder der automatisiert ist, bleibt halt immer noch ein schlechter automatisierter Prozess.
00:31:02
Speaker
Absolut. Also ich verstehe deine Denke, aber am Ende, wie du schon gesagt hast, ja, es wird immer Argumente geben, etwas nicht zu machen. Da bin ich sehr romantisch unterwegs. Entweder du überzeugst jetzt alle oder du sagst, dann sind wir alle fully committed und alle schreien Juhu und dann machen die alles oder wir machen es ein bisschen realistischer. Da gibt es ein paar, die sagen, okay, ich habe jetzt ein bisschen viel Bedenken, aber ich glaube, die Öl-Adopter, die muss man packen.
00:31:29
Speaker
Es gibt jetzt eine andere Regel, die mich auch, ja, ich mag die sehr, die ist wieder sehr, sehr romantisch populistisch. Also be the creator of the automation that replace you. Also ich glaube felsenfest daran, dass in der Zukunft, das ist vielleicht jetzt schon in 10, 20 Jahren, dass sehr viele Sachen einen Menschen ersetzen werden können. Ob wir das machen, ist ein anderes Thema.
00:31:55
Speaker
Aber wenn du die Person bist, die dir Automatisierung schreibt, die dich selber ersetzt, hey, cool, passt. Das heißt, wenn man die Frage, deine Frage, wie kriegt man das in der Kampagne rein, auch beantworten kann, und wenn man kein Zieler ist, sondern ein Individual Contributor, hey, nimm die 20 Euro pro Monat pro User, hol sie eine Plattform, gehst da drauf und machst das erst mal. Und wenn die Leute merken, dass du eigentlich schön einen wegchillst und deine Arbeit immer noch wertschaffst,
00:32:25
Speaker
Ich glaube, Neid wird die dann entsprechend antreiben oder die Neugier. Was macht diese Person da eigentlich? Jetzt mal wieder sehr, sehr romantisch. Ja, ja, total bin ich total bei dir. Also du siehst, mein Ansatz ist ein bisschen ein bisschen anders. Ja, also wie schon gesagt, es kann funktionieren. Man kann auch warten, bis das Management das merkt. Ihr müsst entscheiden, was Realität ist. Genau, genau.
00:32:54
Speaker
Und wenn man einmal die Potenziale verstanden hat, ich glaube, dann noch die Begeisterung quasi in die Company reinzutragen. Das ist dann eine Frage von Storytelling und Kommunikation. Sehr gerne, aber dafür gibt es ja euch dann, oder? Genau, dafür gibt es uns, genau. Jetzt haben wir aber die eine Seite mit wie bekomme ich das in eine Company rein und alle davon begeistert. Jetzt nehmen wir mal an, ich habe jetzt alle davon begeistert und jeder ist, jeder meiner Mitarbeiter hat Bock auf Automation.
00:33:24
Speaker
Wie stelle ich denn jetzt sicher, dass nicht absolutes Chaos passiert, wenn jeder Zugriff hat? Ja, also das ist eine sehr, sehr, sehr, sehr gute Frage. Wie stellt man sich ein absolutes Chaos? Also am Ende ist es. Ich kann dir sagen, wie wir das machen. Genau, das ist eigentlich meine Frage. Ich kann dir nicht sagen, wie man es generell macht. Soweit bin ich noch nicht gekommen.
00:33:53
Speaker
Also wir lassen einen gewissen Level an Chaos zu, um Innovationen zu ermöglichen. Gleichzeitig mit einer sehr starken Confidence, dass wir aus dem Engineering sehr starke, über die Karten, Bulletproof Prozesse und Ansätze haben, um Chaos zu managen. Ich sag dir erst mal ein Beispiel.
00:34:21
Speaker
Wir haben sehr klassische Monitoring-Konzepte, Monitoring-Tools, Alerting-Tools, um zum Beispiel zu identifizieren. In Software-Engineering, du hast einen Application-Logging-Tool wie Sentry oder Muralic oder wie die alle heißen. Das heißt, du kannst diese immer noch in dein Tool indizieren, by the way, das ist genau das, was wir gerade machen, um zu verstehen, um das komplette Transparenz zu schaffen, welche Prozesse sollten nicht fehlen, also sollten nicht kaputtgehen.
00:34:49
Speaker
Das heißt, erst mal Monitoring, erst mal sehen, was passiert da gerade. Und danach können wir ein Alerting drauf aufbauen. Das ist der eine Satz. Hey, dieses Szenario sollte laufen, läuft aber nicht. Das heißt, wir haben sehr klasse, in der Softwareentwicklung nennen wir das DevOps. Jetzt überlegen wir DevOps und Automation. Das ist genau das Thema, was ich gerade bei Fint treibe. Dafür eine dedizierte Person. Wir bauen ein dediziertes Team auf und dann zusammen mit dem Team
00:35:17
Speaker
dann die nächsten Interaktionen in dem Touring zu schaffen. Da gibt es in dem Markt dadurch, dass das ganze Thema Automation zu Know-Code sehr frisch ist, noch keine Industriestandards. Wird es geben, wenn ich felsenfest überzuche. Also wir lassen Chaos ein bisschen zu, um zu verstehen, wie kriegen wir Monitoring an Leute an Top of that. Bis dahin Convention. Also in Engineering gibt es
00:35:44
Speaker
Lintas und zu überprüfen, ob der Code gewissen Standards folgt. Wir haben bei Fynn ein Integromat Rulebook. Diese Regeln muss erfüllt, damit das Szenario vernünftig unter dem, ich sage jetzt mal, Fynn Monitoring Guidance steht. Das heißt, wir haben gewisse Severity Level. Du fühlst einfach so ein P1 oder P2 in dein Szenarionamen ein.
00:36:07
Speaker
Das Szenario Name sollte auch immer DRI haben, eine e-Mail-Adresse. Und dann verwenden wir Make, um die anderen Make-Szenarien zu monitorieren. Das heißt, wenn dein Szenario fällt und es sollte nicht fehlen, dann wirst du genotified. Wenn du nicht acknowledged, dann wird das in dein Team delegiert, in dein Departement und so weiter und so fort. Das heißt, wir haben well-known standards. Die Frage ist, wann enables du diese Conventions? Und wie kannst du ab einer gewissen Größe ganz gut umsetzen?
00:36:37
Speaker
No-Code selber dafür verwenden, um das Monitoring und das Erläutigen zu treiben. Also mein Plan ist, also da, wo wir jetzt sehr viel Potenzial sehen, ist Inter-Szenario Monitoring. Das heißt, was passiert, wenn wir 17 Szenarios voneinander abhängig sind und jetzt schon sieben fehlt. Dann müssen wir das wissen. Und da gibt es technische Möglichkeiten. Das ist klassisch Service Discovery. In der Softwareentwicklung ist das ein klassisches Service Discovery.
00:37:06
Speaker
hast du genauso. Es gibt Lösungen dafür, wir müssen die jetzt nur auf diese neue Umgebung anpassen. Ja. Ja, spannend. Okay, und wenn ihr, du hast eben gesagt, jeder Mitarbeiter bei euch, egal aus welcher Abteilung, bekommt ein kleines Onboarding zu den ganzen No-Code-Tools, die ihr verwendet, vor allem zu Make und Airtable und Retool dann wahrscheinlich, lernen die auch in dem Zuge dann auch die ganzen Conventions oder ist
00:37:36
Speaker
Genau. Die bekommen einen Link zu Confluent. Link zu Confluent, das ist die Convention. Und wenn du dir folgst, dann hast du sehr viele Vorteile, weil dann gibt es ein Team, das kümmert sich darum, wenn es Probleme gibt und die hilft dir dabei. Und wenn du der Convention nicht folgst, dann brauchst du auch nicht nach Hilfeschreien. Also das kommt. Also im Nicht-Engineering-Umfeld gibt es ja auch, ich sage jetzt mal, sagen wir mal, mir fällt kein besseres Beispiel ein.
00:38:02
Speaker
ein Shared Drive, wo du Dateien ablässt in der großen Corporate. Wenn du der Naming Convention auf der Shared Drive nicht folgst, wirst du auch keine Datei finden, wenn du da plötzlich magst, in meines Heck mitzumachen. Also Folge dieser Naming Convention, die hat einen gewissen Vorteil. Vielleicht gibt es dann oder ein Spreadsheet, wo man verschiedene Sheets hat. Und wenn du eine aus der Reihe hast, dann gibt es halt vor der Gruppe
00:38:27
Speaker
immer einen auf den Finger. Er sagt, hey, you're not following the naming convention, so we can't support you. Also wenn du dann Schmarrn machst, dann ist es dein Schmarrn. Aber bitte ruf uns nicht an, wenn es nicht funktioniert. Ich glaube, das ist so der Prozess, den ich treiben würde. Und dann, wenn das größer wird, so bei uns, zum Beispiel sind bei 2.000, 3.000 Szenarios, ich muss jetzt einmal nachgucken, dann muss man ein dediziertes Team dafür haben. Aber hey, let's get there.
00:38:53
Speaker
Baby steps. Erst mal dahin kommen und dann kann man das Problem lösen. Man braucht nicht irgendwie Probleme lösen, die man noch gar nicht hat. Ja. Heißt das im Umkehrschluss aber auch, dass ihr eine extrem enge Teamkultur habt, was es angeht? Okay, wir bauen Automations und das lösen wir zusammen und wir stecken im selben Boot. Also welchen Einfluss hat No Code auf eure Unternehmenskultur?
Die Kultur der funktionsübergreifenden Teams bei Fynn
00:39:17
Speaker
Jetzt hast du den wichtigsten Punkt eigentlich genannt, den habe ich jetzt die ganze Zeit verschwiegen. Und zwar,
00:39:24
Speaker
Ich habe ihn nicht verschwiegen, aber man muss zu Finn wissen, die Organisationsstruktur ist eine andere. Wir nennen das Mission Based Cross Functional Teams. Wir haben Cross Funktionale Teams. Das heißt, wir haben Business, Product und Tech, die formen immer ein Team. Das heißt, das ist klassisch gedacht, wir haben das Why we are doing that?
00:39:49
Speaker
Das Wort Product Management und das How formen ein Team, sitzt sogar von der Location zusammen oder bei uns meistens remote, im gleichen Team, die gleichen Ziele. Das heißt, wir haben sogar die gleichen OKRs. Dadurch stellen wir sicher, dass ein Volles bei Ihnen zu der Lösung da ist. Das heißt, wir haben kein klassisches Engineering Department, wo dieser Feature Request rübergeschmissen werden und dann werden irgendwelche Features zurückgeschmissen. Nein, das haben wir nicht. Und das trägt zu dieser
00:40:19
Speaker
zu dieser zu dieser Einheit bei. Das heißt, das knowledge sharing passiert immer durch die ganze Kampagne. Ja, das ist das ist der Trick. Also wenn man möchte. No code ist, das ist auch das Wichtige. Bei no code ist die core audience immer Business. Es sind selten Ingenieures. Wenn Ingenieure no code verwenden will, dann wie bei Gast verwende das und
00:40:47
Speaker
Die Antwort ist, die werden es auch verwenden. Die verwenden es auch sehr, sehr oft. So schnell mal CI Pipeline triggern, da brauchst du kein Scheduler, sondern kannst ja Make verwenden und fertig. Aber gleichzeitig 200 Prozent sind es die Businessleiter. Ich habe es zu oft gesehen, da sitzt ein Ingenieur und macht einen Export eines Product Feeds, damit die Produkte bei Google Merchant Center auftauchen. Und muss irgendwie Spalten zufügen.
00:41:16
Speaker
Ganz ehrlich, da blutet mir das Engineering-Herz, da zerreißt es mich. Dafür brauchst du keinen Engineer, der dann drüber eine Stunde merkt, wie soll er das machen und zu recht merkt. Das ist eine CSV-Datei. Da ist jetzt keine Innovationshöhe drin.
00:41:38
Speaker
Ja, das ist auch die Antwort auf die Frage, die mir oft gestellt wird von Entwicklerseite tatsächlich. Es wird immer mit einem Lachen, aber auch manchmal mit auch zu viel Ernst dahinter, werde ich gefragt, also nimmst du mir jetzt meinen Job weg mit No-Code quasi und wo die Antwort dann immer drauf ist, aber mit No-Code, also No-Code ermöglicht euch halt an den wirklich coolen und kreativen und wirklich wichtigen Aufgaben zu arbeiten.
00:42:06
Speaker
eine ganze Busy Work halt auszuhebeln. Absolut, absolut. Das ist das erste Argument und für einen Entwickler wäre meine Antwort und dafür war ich zu lange Entwickler. Wenn dein Job durch ein No Good Szenario, ein paar No Good Szenario ergänzt werden und ersetzt werden kann, dann solltest du dir die Frage, die Wichtigkeit der Frage, dann musstest du erst mal verstehen, was machst du da eigentlich? Und hey, wir sind so privilegiert als Software Entwickler.
00:42:34
Speaker
Es gibt so viel zu viele Jobs und viel zu wenig Software. Dann gehst du irgendwo hin und richtig geilen Wertstoffen kannst. Ist doch viel, viel cool. Macht doch viel, viel mehr Bock als irgendwelche Rumgemuckele an irgendwelchen Product Feeds. Ja.
00:42:49
Speaker
Ja, total. Und ich finde auch, es befähigt oder hebelt so die Kommunikation auch in Teams. Wo du, wie du sagst, einmal alle das gleiche Ziel haben und das Ziel ist eben Business. Und alle, die die gleiche Idee davon haben, was denn Erfolg bedeutet.
00:43:07
Speaker
Und dadurch, dass aber auch dann nicht-technische Leute Technik oder Tech besser verstehen durch No-Code, durch visuelle Programmierung, weil halt Konzepte dadurch ja schon übermittelt werden, dass man daraus auch miteinander einfach ein viel besseres Verständnis für die Sache bekommt, an der man eigentlich arbeitet. Und das eben den ganzen Unternehmensgeist nochmal hebelt.
00:43:29
Speaker
Ja, also das ist jetzt. Ich kann dem Argument folgen. Ich kann aber die Ingenieurs verstehen. Überleg mal, wir haben jetzt. Also ich kann die wirklich verstehen. Ich bin einfach. Da gibt der Ingenieur, der kleine Ingenieur in mir auf. Überleg mal, du hast zehn Jahre lang. Hast du irgendwelche Begriffe erfunden, damit die Leute, die anderen dich nicht verstehen? Du bist in deiner kleinen Bubble und da ist die Welt in Ordnung. Ingenieuring for the sake of Ingenieuring. Du musst dich wenig erklären. Alles ist alles ist wirklich, wirklich läuft.
00:43:58
Speaker
Du hast ein ganz gutes Gehalt, die Welt ist in Ordnung. Jetzt kommt eine Pappbase her und der heißt Andy und erzählt dir was von No Code und dann würde es bei mir auch klingen, Moment, Moment, Moment. Stability, all sowas. Und dann, die sind ja nicht blöd, die Genius. Ich verstehe sofort, was die Macht dahintersteht. Das heißt plötzlich wird alles, was du machst, sehr transparenter.
00:44:23
Speaker
Transparenz ist per se bei vielen Leuten immer negativ belastet, bei mir sehr positiv belastet. Und deswegen verstehe ich die Argumente. Das heißt, der nächste Schritt ist, nicht diese Angst zu nehmen, sondern ganz valide zu sagen, hey, it's a tool, verwende das. Aber das Ziel ist es nicht, dich zu replacen, sondern den ganzen Schmarrn, den du hast. Und da muss der Ingenieur mal in sich gehen oder die Ingenieure
00:44:48
Speaker
Und sagen, was für einen Spaß mache ich da eigentlich? Überlegt man, das kommt alles weg. Du bekommst immer noch den Gehalt. Und wenn nicht bei dieser Kampagne, dann bei einer anderen. Das ist für die Karten sichergestellt. Da guckt ihr jede Statistik an. Und gleichzeitig kannst du dich endlich mal darauf fokussieren, den Hottenshit zu machen. Ja. Aber die Angst verstehe ich. Ja, auf jeden Fall. Begegnet dir das manchmal im Recruiting, dass du Entwickler, also gerade Entwickler im Recruiting überzeugen musst?
00:45:18
Speaker
Nö. Also, wenn es so weit kommt, dass ich einen Entwickler davon überzeugen muss, dann ist das nicht die richtige Person für Finn. Also, wir haben wieder einen sehr starken Luxus. Wir haben nur im Engineering Department über 1100 Applications pro Woche.
00:45:45
Speaker
Das heißt, wir machen sehr starkes Cherry-Picking. Das heißt, wenn die Person das nicht versteht, was es heißt, das ist unsere DNA, dann ist diese DNA, die wir alle teilen, diese Person teilt diese DNA nicht. Aber ich glaube, das ist sehr viel Self-Reflection und dann Empathie. Wenn die Leute empathisch sind, dann können sie sich immer in die Situation und die Position des anderen hineinversetzen. Und ja, ich kann verstehen, wenn man diesen Luxus dann nicht hat, dass man ein bisschen anders agieren muss.
00:46:15
Speaker
Aber hey, das Problem löse ich, wenn ich das Problem habe. Auf jeden Fall. Noch mal vielleicht einmal zurück auch nochmal zum Business Case und zum Business Case Fin vielleicht auch.
Investorenfokus auf Ergebnisse statt Tools
00:46:27
Speaker
Was haben denn eure Investoren damals eigentlich gesagt, dass ihr mit No-Code entwickelt? War das ein Thema? Nö. Also, die meisten Investoren sind nicht so operativ tief dran. Ja. Also, ich bin ganz ehrlich zu dir, das Thema ist noch nie aufgekommen.
00:46:45
Speaker
Also man erwartet, dass es funktioniert und wir haben sehr, sehr starke Investoren, da bin ich sehr, sehr dankbar dafür. Und also man muss sich mal vorstellen, dass ich glaube nicht, dass bei irgendeinem Startup, was nicht jetzt sehr Deep Tech macht, dass die Investoren dann sagen, was für ein Programmiersprache man verwendet. Das passiert. Also ich kenne keinen Fall. Wenn es den Fall gibt, dann würde mich das interessieren, aber nie. Also wir müssen die Autos an den Mann bringen, so effizient wie möglich. Und da gibt es andere Effizienz, GPIs.
00:47:15
Speaker
zum Beispiel Transactions per FTE. Das ist eine KPI, die wir uns ganz genau angucken. Wie viele Subscriptions machen wir pro Fulltime-Employee? Das gucken wir zum Beispiel sehr, sehr auf Company-Level sehr detailliert dann. Ja, verstehe. Spannend, okay, weil wir werden auch immer gefragt von Startups, wie das denn so ist, wenn sie jetzt mit No-Code entwickeln und ob das denn valide für die Startups auch ist und für die Investoren vor allem. Genau, spannend.
00:47:46
Speaker
Also ich denke jetzt mal sehr laut und ich habe mich auf die Frage tatsächlich absolut nicht vorbereitet. Am Ende geht es ja in den Investoren, wie viel Wert schaffst du? Wie viel Asset? Also man kann auch durch Kapitalisierungseffekte, kann man sagen, wie viel Wert hat man generiert, damit Ingenie kein reines Kostzentrum ist, sondern auch Profit-Zentrum. Ich habe fast gesagt, Ingenie kann nie Profit-Zentrum. Aber Asset generieren, also zum Company-Wertbeitrag.
00:48:13
Speaker
rein Monitoring, Tracking in dem Sinne über Jira-Tickets. Also unsere BAMs, unsere Business Automation Manager sind auch in dem Scrum Team. Das heißt, sie bekommen Tickets zu. Wenn es ein Task ist und kein Bug-Fixing, dann generiert das Asset, dann kannst du das mit gewissen Mätriken auch sauber als Kapitalisierungsprojekt umsetzen. Und dann wird es für Investoren interessant. Also ich habe jetzt wirklich sehr laut gedacht. Also an alle Start-ups out there,
00:48:40
Speaker
Tasks und Apex, die keine Bug-Tickets sind. Und deswegen machen wir ja das ganze Ticket-Tracking. Das ist nicht dafür da, um Engineers zu ärgern, weil die ihren Estimations-Scheiße sind. Die Estimations von Engineers sind immer schlecht. Das ist normal. Das ist the beauty of engineering. Sondern, dass man das sauber trägt über Velocity Points oder über Time und damit man das als Kapitalisierungsprojekte, also den Wert der Firma erhöht. Ganz einfach. Ja, ja, macht total Sinn. Ja, definitiv.
00:49:10
Speaker
Wo siehst du denn No-Code in den nächsten zehn bis zwanzig, wann oder immer Jahren? Zehn Jahre. Vor zehn Jahren war ich 28. Was hab ich da gemacht? Ich bin gerade aus der Uni geplumpst. Fiese Frage. Aber gute Frage, finde ich gut. Ich mag fiese Fragen.
00:49:33
Speaker
Ich kann es dir nicht sagen. Ich kann dir sagen, wo ich die Automatisierung sehe, was für mich jetzt aktuell ist, ein Tool, um Automatisierung nach vorne zu treiben. Wir werden well-known engineering Prinzipien sehen. Monitoring, alerting, dann business alerting, end-to-end-tests, profiling, debugging. All sowas werden wir im Bereich No-Code sehen. Ich wünsche dir das von Herzen.
00:50:03
Speaker
Wir werden No-Code als eine Möglichkeit sehen, um schnell und solide als zusätzlichen Tool für ein Business, um etwas umzusetzen. Gern auch ein Start-up oder well-known company. Das werden wir sehen. Es wird jetzt nicht Engineering ersetzen, auf gar keinen Fall. Glaub ich nicht. Wird das nicht. Dafür haben wir zu viele Aufgaben vor uns.
00:50:30
Speaker
Also lass mich deine Frage so ein bisschen episch beantworten. Wir haben viel zu viele Aufgaben als Gesellschaft. Da müssen wir uns auf was besseres konzentrieren, als irgendwelche Commodities zu basteln. Immer wieder den gleichen Schmarrn. Da gibt es Blueprints. Ob das Low Code oder was auch immer Code ist. Who fucking cares? Einfach, dass ich auf die Sachen konzentrieren, die wirklich Werte schaffen.
00:50:59
Speaker
Und das ist das Schwierige. Und da kann man auch ingenious und non-ingenious hinbekommen, dass sie drüber nachdenken, was wirklich Wertes schafft. Und dafür muss man die Zeit zum Atmen haben. Man kann erst selbst reflektieren, wenn man nicht die ganze Zeit muckelt. Sondern überlegt, was mache ich hier eigentlich? Und davon haben viele Menschen an sich, einfach Gedanken mit sich selber. Und dann wird die Antwort sein, okay, it's no good, it's the fastest way to go.
00:51:22
Speaker
Und dann erwischst du dich selber dabei, plötzlich irgendwelche Bubbles bei Make durch die Gegend zu schubsen. Aber es löst das Problem. Und ich hoffe, die Leute gehen dann mit einem Schmunzen nach zehn Jahren und sagen, okay, ich habe meine Automatisierung, die 98 Prozent meiner Arbeit erledigen. Ich bekomme 100 Prozent des Jobs, des Gehalts. Ich geniere den Wert und dieser Wert wird im Gehalt zurückerstattet. Und wer das dann macht, ob es eine Automatisierung ist, ein No-Code oder Hardcode,
00:51:52
Speaker
sollte irrelevant sein. Ja. Das fände ich eigentlich ein total schönes Schlusswort für unseren Podcast, für die Folge.
Ziele von Fynn in den USA und Europa
00:52:03
Speaker
Ich möchte aber trotzdem noch mal kurz fragen, wo geht es denn jetzt hin mit Fynn? Ihr seid gerade in oder seid gerade auch dabei, in die USA zu expandieren. Was sind die nächsten Steps? It's more of the same.
00:52:22
Speaker
Also nichts an 20, 30, eine Million Carsubscriptions. Dafür müssen ein bisschen Blech bewegt werden. Das machen wir. Also wir haben zwei, drei Sachen probiert. Wir haben auch schon mal versucht, die Versuche, wir haben es gemacht. Wir haben Autos Boots auf der Webseite verkauft. Das erdet nur Complexity. Ja, da ist ein Uplift da, aber nicht genug für uns zumindest, nicht genug. Immer das gleiche. Carsubscriptions, Carsubscriptions, Carsubscriptions. 23 wird's.
00:52:50
Speaker
Europa werden, da werden nur ein paar europäische Länder dazuschalten, wir wissen selber noch nicht welche. Aber hey, da machen wir einmal kurz einen Business Case durchrechnen, dann werden uns die Zahlen schon sagen. Fokus auf USA, ein bisschen mehr, ein paar mehr Staaten in den USA, da ist einiges an der Komplexität drin. Und dann more of the same, mehr UEMs. Was wir werden ist nichts anderes wie dein One Stop. Du gehst dahin, da findest du Subcar Subscriptions von allen UEMs.
00:53:18
Speaker
Such dir das schönste Angebot aus, was für dich am besten passt für deine aktuelle Lebensphase. Und dann, hey, voila, bitte kauf keine Autos. Das ist ökonomischer Wahnsinn. Bitte tut es nicht. Es sei denn, es ist eben so ein tolles Auto, was nur gekauft werden kann. Dann okay, aber ja, das macht gar keinen Sinn. Genau. More of the same. Das ist die Antwort. Ja, sehr gut.
00:53:44
Speaker
finde ich eine sehr, sehr gute Antwort. Ich könnte tatsächlich, ich habe noch 17.000 Fragen tatsächlich, die ich dir gerne noch stellen würde, aber das machen wir vielleicht in einer Follow-up-Podcast-Folge. Andi, es hat mir sehr, sehr großen Spaß gemacht, dass du da warst. Wer mehr zu finden wissen möchte, den Artikel und alle Links, alle wichtigen Links verlinken wir euch unten in den Show Notes.
00:54:12
Speaker
Und Anni, vielen, vielen Dank für das Gespräch. Es war mir ein großes Fest. Es waren super spannende Insights mit dabei. Und ich habe mich sehr, sehr gefreut. Vielen Dank. Sehr, sehr gerne. Vielen Dank für die Einladung. Wir können, lasst uns gerne einen Follow-up machen. Ja, vielen Dank dafür. Also ich kann, wie schon gesagt, über No-Code und Automatisieren ewig reden. Das heißt auch an die Leute da draußen, wenn ihr Fragen habt oder irgendetwas absolut gar keinen Sinn macht. Schreibt mir eine Nachricht immer gerne und dann
00:54:41
Speaker
lasse ich mich gerne auf die Diskussion ein. Am besten positiv, das macht immer am meisten Spaß. Und dann Survival of the fittest. Ja, Survival of the fittest und denen, denen die am offensten durchs Leben gehen. Ich finde, das macht nämlich... Vielleicht habe ich eine Automatisierung und beantworte die, wenn ich's ja gar nicht will. Vielleicht. Absolut, vielen Dank. Hat mir echt Spaß gemacht. Vielen, vielen Dank.