Fabian Wesner von ROQ Technology

Hallo und herzlich willkommen in der Programmierbar. Der Fabi, der zugeschaltet ist, und ich, Dennis. Wir freuen uns wieder, ein CTO Special aufnehmen zu dürfen und das machen wir heute mit Fabian Wiesner. Fabian, schön, dass du bei uns bist. Ja, vielen Dank, dass ihr mich eingeladen habt. Ich freue mich. Du bist aktuell Gründer, also hast ein Unternehmen oder bist dabei, ein Unternehmen mit komplett aufzubauen, hast aber viele Jahre lang in verschiedenen CTO Rollen gearbeitet. Wird deswegen glaube ich, spannend, dass ich heute an deinem Lebenslauf ein bisschen lang zu hangeln. Und bevor wir dann gleich einsteigen und gucken, wo hat alles für dich angefangen mit der Technologie, vielleicht erst mal ganz kurz zu dem, was du gerade machst. In welchem Setting bist du unterwegs? Wie sieht dein Arbeitsleben aktuell aus? Ja, sehr sehr gerne. Also ich bin jetzt seit zwei Jahren wieder als Gründer unterwegs. Die Firma habe ich zusammen mit meinem Freund Tim Niemeyer gegründet. Also die Firma nennt sich ROK Technology. R O Q Punkt Tech ist unsere Domain. Und die Idee ist folgende. Wir haben beobachtet, wenn Leute eine Webapplikation bauen, zum Beispiel eine Software, also Service Applikation oder ein Kundenportal, dann müssen sie zum einen die eigenen Features bauen, die eigene Secret Source, aber sie müssen auch immer wiederkehrende Funktionalitäten, immer wieder von vorne gebaut. Man baut immer wieder ein Login, eine Nutzerregistrierung, ein Double Up In, ein Chat, gleich Benachrichtigungen und so weiter. Es gibt also einen Satz von immer wiederkehrenden Features, Funktionalitäten. Und die werden überraschend häufig immer wieder von vorne neu programmiert. Und Tim und ich, wir kommen aus dem Ecommerce Umfeld und da ist das nicht der Fall. Das ist so, wenn man einen Shop haben möchte, dann nimmt man ein Shopsystem. Man würde nicht anfangen und Warenkorb, Checkout immer wieder vom Sketch zu bauen. Man nimmt was Fertiges und baut drauf auf. Und im Bereich Körper Applikationen ist das halt leider häufig nicht der Fall. Und da haben wir gedacht, das müssen wir irgendwie ändern. Das muss besser gehen. Man muss mal einen Satz von fertigen Funktionalitäten bereitstellen, die man dann sozusagen einfach in seine bestehende Applikation integrieren kann und dann einfach sich nur noch auf die eigenen Spezialitäten fokussieren kann. Und das, genau das ist ROK. Was wir anbieten sind Funktionsbausteine, technisch sind das React Komponenten und eine GraphQL API, mit der man zum Beispiel ganz einfach ein Login, eine Nutzerregistrierung, Notifications und so weiter in die eigene Applikation integrieren kann. Das ist die Grundidee. Wir haben vor zwei Jahren gestartet und wir haben uns viel Zeit genommen, den Markt zu analysieren und das ganze System zu bauen. Es ist ein großes System, kann man sich vorstellen. Wir haben gerade Anfang der letzten Woche eine neue Webseite veröffentlicht. Kann man sich gerne mal ansehen. Ich würde mich über Feedback freuen, über Interessenten natürlich. Und als Gründer sagen, wie soll ich sagen, drücke ich mir die Daumen und drücke uns die Daumen natürlich, dass es klappt. Wenn man was Neues baut, man hofft natürlich immer, dass es gut ankommt im Markt. Und das soll es auch schon gewesen sein zu meiner Gründerseite. Ansonsten würde ich jetzt gerne als CTO weitersprechen. Ich bin sowohl Gründer als auch CTO. Bin Softwareentwickler seit über 20 Jahren und lasse uns jetzt gerne ein bisschen technischer sprechen. Cool. Ja, cool. Sehr gut. Und mit Sicherheit kommen wir auch da gleich nochmal ein bisschen hin. Definitiv. Also bei Rogue kommen direkt auch einige Fragen bei. Mir auf jeden. Fall auf. Ja, cool. Genau. Aber lass uns mal ganz vorne anfangen. Du hast gerade gesagt seit 20 Jahren bist du irgendwie in diesem Feld unterwegs. Wir starten gerne auch da mit der Frage so, was war dein erster Kontakt zu Technologie? Also wie bist du dazu gekommen? War es in der Schule? War es privat? Was war das allererste Mal, dass du das für dich entdeckt hast? Das erste Mal war tatsächlich Schule. Ich glaube, das allererste Mal war ich zwölf. Das ist schon lange, lange her. Das war die QBasic im 3.86er. Ja, das war der erste Kontakt. Aber das war nicht vor 20 Jahren, das war schon vor 30. Und dann als Schule und so weiter. Da hat man dann auch irgendwas gelernt. Ich weiß gar nicht mehr, was man da gelernt hat. Und dann ganz klassisch Informatik studiert und dann gingen halt die ersten Jobs los. Ich habe die erste Programmiersprache, die ich so richtig gelernt habe, war Java. Dann habe ich aber verstanden, das macht mir viel Spaß, das ist toll, tolle Sprache, leider sehr umständlich, damit irgendwas zu machen, und dann bin ich ganz schnell auf PHP gewechselt. Das war schon 1999. Php 3 damals, da gab es doch keine Klasseninterface, da hat man einfach so den PP Code in den HTML Code geschrieben und das hat funktioniert. Und ich habe das auch nicht lokal zum Laufen gemacht, ich habe das einfach auf so einem billigen Strato Web Space lief das da und da habe ich auch direkt per FTP hingucken Wie lange lief das da? Ich hatte auch kein Environment. Ich hatte genau ein Environment und das war das Live Environment und da habe ich halt drauf gearbeitet. Direkt mit meinem File Editor. Direkt mit dem File Editor, da war auch nichts mit einer IDI, mit der man da gearbeitet hat. Da haben die Leute manchmal eine Fehlermeldung gesehen, aber das war dann so. Und das war dann sozusagen in deinem ersten Job, also wenn du gesagt hast, das erste Programmiersprache war Java, war das dann während dem Studium und danach der Switch zu PHP, war das dann während des Studiums, nebenbei das programmiert hast oder wo war das gerade zeitlich deine PHP direkt auf Production, Entwicklung, Umgebung? Das war tatsächlich noch vorher. Also angefangen mit Webseiten habe ich 1998, das war noch in der Schule, einfach HTML, erst mit so Tools wie Dreamweaver und da gab es noch ein Microsoft Tool, ich vergesse, wie das heißt. Frontpage. Genau, da gab es Frontpage Express for free und es gab noch die kostenlose Version. Ich hatte natürlich nur die free Version. Und damit konnte man so Webseiten hinmalen und dann kam ein irgendwelcher grottiger HTML Code dabei raus. Das ging ganz gut. Dann habe ich danach ein Praktikum gemacht bei einer Internetagentur. 1999 war das. Und da habe ich das erste Mal PHP kennengelernt...... Und habe dann angefangen, in mein HTML...... Php rein zu pflanzen und das lief dann auch ganz gut. Und dann eine PHP Pause während des Studiums...... Und dann wieder zurück zu PHP. Und dann habe ich...... Das war 2006/2007...... Habe ich meine erste Firmengründung versucht...... Bin damit auch gescheitert...... Und das war auch mit PHP gebaut. Was war das Inhalt, was wolltest du da machen? Das war noch an der Uni, das war so ein Existence Seed Programm...... So ein gefördertes...... Da ging es darum...... Ich hatte entdeckt, dass es...... Affiliate Marketing gibt...... Also man kann einen Link auf Seite einbinden...... Leute klicken drauf, kriegen Geld...... Wenn jemand was kauft...... Und ich habe gedacht, das wäre doch cooler, wenn man einfach direkt so eine Art Shop einbinden könnte. Man kann direkt die Produkte aussuchen, die da angezeigt werden und dann können die auch direkt gekauft werden. Also eine Shopeinbindung auf beliebige Webseiten. Damals gab es aber gar keine Blogs, man hatte einfach so Webseiten. Und da dachte ich mir, wenn ich jetzt eine Webseite zum Thema Fotografie habe, kann ich direkt dort auch Fotokameras verkaufen und kriege dann praktisch Geld, statt einfach nur einen Link zu setzen auf saton.de oder so. Aber das hat natürlich...... Vorhin nicht funktioniert. Ich habe das technologisch gebaut. Ich hatte viel Spaß, das damals mit Codeigniter zu bauen, PHP. Aber als es dann darum ging, Händler zu sourcen, die dann Produkte reinstellen, da ist dann gescheitert, weil das konnte ich dann nicht mehr so gut. Ja, wie es dann so ist, ich hatte ein Jahr Förderung von der Uni, das war dann irgendwann vorbei. Ich habe mit ein paar Business Angels gesprochen damals. Ich hatte gar kein Netzwerk. Ich kannte niemanden. Ich wusste nichts, wie man Geld raised. Ich kannte die ganzen Begriffe gar nicht. Ich habe dann irgendwie die GmbH gegründet. Das war so ein bisschen holprig alles. Und damals auch zusammen mit meiner Frau gemacht, das alles so ein bisschen irgendwie sich halt so durchgewurschtelt und dann das Ganze gescheitert. Aber viel gelernt. Und von der Idee her ja auch, also Idee hat es ja eigentlich nicht gemangelt. So die Klang gibt es ja so an sich jetzt auch noch. Ich meine Instagram macht es ja auch direkt mit First Party kaufen und so weiter. Also so von der Idee her ja eigentlich gut. Genau, es ist halt nur keine Idee für einen Entwickler. Es ist eine Idee für jemand der in der Lage ist, Händler zu sourcen. Und dann sich irgendwie, die dann irgendwie online die Produkte anzuzeigen. Aber wenn man nur die Technik kann, dann hat man praktisch nur den kleineren Teil des Problems gelöst. Und wie hast du damals schon den, also den Drive irgendwie das auszuprobieren? Ich finde irgendwie, also heute hört man das ja, oder ist es auf meine Wahrnehmung vielleicht nur, hört man häufiger mal, es gibt irgendwie Unterstützung und man kann irgendwelche Programme mitmachen und kriegt auch finanzielle Unterstützung. Das hört sich jetzt für mich relativ früh an, dass da an der Deutschen Hochschule irgendwie Projekte waren, wo finanzielle Unterstützung waren, irgendwas zu gründen. War das dann einfach, weil du irgendwie mitbekommen hast, das ist das und da kannst du deine Technologie ausleben oder hattest du auch schon irgendwie schon auch den Drang, ein Produkt selbst an den Markt zu bringen, was irgendwie erfolgreich ist, selbst wenn du dir selbst sagst, das oder nicht unbedingt die Fähigkeiten hat, die Sales Sachen dann abzubilden? Also ich war schon immer jemand, der sowohl IT mag, also Software entwickeln, programmieren, das hat mir immer viel Spaß gemacht, aber ich hatte auch immer den Drang, selbst was zu gründen und zu bauen. Ich war so in der Zeit der ersten New Economy, also 2000 war ich noch zu jung und hatte auch vor allem gar keine Ahnung, gerade frisch aus der Schule, keine Ahnung, wie man das machte und habe es ein bisschen verpasst. Und dann hatte ich praktisch danach den Drang, das nochmal neu zu machen, wusste aber gar nicht, wie es geht, also überhaupt nicht. Und dann gab es aber an der Uni dieses Förderprogramm, so ein Existprogramm, das gibt es immer noch. Das heißt jetzt ein bisschen anders, aber man kann im Prinzip, man kriegt dann von der Uni so Räume und ein bisschen Geld und ein bisschen auch Unterstützung fürs Private und so weiter. Und das habe ich beantragt, das ging relativ einfach, das konnte man, das hat jeder bekommen. Man musste so eine kleine Businessplan vorlegen und dann wurde es einfach bewilligt und fertig. Und das hat mir die Möglichkeit gegeben, das mal zu machen. Nur leider ist die Wahrscheinlichkeit, dass daraus was wird, halt gering, wenn man als Gründer thematisch nicht aufgestellt ist und auch sonst noch nicht richtig ready war. Das war einfach Also mega, mega lehrreiche Zeit, auf jeden Fall. Und ich habe es dann auch fortgesetzt. Also die Idee habe ich dann verworfen. Es hat nicht geklappt. Ich habe dann zwei Jahre Freelancer gemacht danach, was sozusagen wichtig war, auf das Persönliche weiterzukommen, musste ein bisschen Geld verdienen. Ich hatte zu dem Zeitpunkt schon Familie und Kind. Und dann kam ich in Kontakt mit Rocket Internet. Die haben mich angeschrieben als potenziellen CTO für eins der Startups. Und das war ziemlich cool für mich, weil das ein Karriereweg war. Als Freelancer habe ich Software programmiert für verschiedene Firmen, zum Beispiel für Bayer Sharing. Und das war auch nett und so, das war auch schön, Geld zu verdienen, aber man hat halt keine Karriere. Man ist irgendwie da, man hat einen Stundensatz und man kann den Stundensatz optimieren und das war's. Das hat mich unzufrieden gemacht. Ich wollte ja weiterkommen, als Gründer oder wenigstens als CTO arbeiten. Und bei Rock Internet gab es diese Perspektive. Die haben gesagt, komm zu uns. Die hatten mich damals interviewt. Vielleicht für die Rolle CTO von Zalando. Also kann sein, dass die mich dafür angeguckt haben, wobei ich war überhaupt nicht ready dafür, das wäre komplett gescheitert. Das haben die mich auch sofort herausqualifiziert, hab mich aber behalten in dieser Rolle als CTO Kandidat. Und die Idee war, ich habe das Rüstzeug, aber mir fehlt noch xyz. Ich hatte zum Beispiel keine Ahnung von DevOps. Haben die mich ein Jahr lang an Bord genommen als Senior Lead Entwickler bei Rocket damals und haben mir verschiedene Stationen durchlaufen lassen. Und nach einem Jahr wurde ich dann auch CTO. Das hat auch funktioniert. Das war wirklich toll für mich zu sagen, die Karriere chance CTO plus auch wieder ranzurücken als Gründer. Ich hatte ja gar kein Netzwerk. Ich bin ursprünglich aus der DDR. Ich habe gar kein familiäres Netzwerk, was irgendwie mit Unternehmern zu tun hat. Ich hatte auch keine Freunde, also überhaupt keinen Zugang zu den ganzen Leuten. Ich kannte das alles nur so ein bisschen von den Blogs vielleicht. Also da finde ich es interessant, vielleicht können wir kurz an dem Punkt, wo du sagst, okay, dann bist du dieses ein Jahr durchlaufen und wurdest dann CTO. Vielleicht können wir da gleich wieder anknüpfen, aber gerade dieser Sprung von Universität, ein Jahr lang eigene Gründung, dann direkt Freelance und als Freelance Entwickler unterwegs, obwohl da gefühlt, also den Step fand ich nochmal sehr interessant, dass du direkt Freelancer wurdest und dann, wie kam es denn dazu, dass Rocket Internet dich dann angeschrieben hat? Also was war dein, auf was sind sie, wie sind sie darauf aufmerksam geworden? Weil ich meine, es wird ja jetzt nicht jeder aus der kalten Hüfte angeschrieben, der gerade freelancemäßig unterwegs ist und mal ein Uniprojekt, also gut, Uniprojekt ist jetzt ein bisschen schmaler ausgesprochen, aber wie kam das, dass du angeschrieben wurdest? Weil das natürlich auch, wenn du auch sagst, du hast ja kein Netzwerk so, war das einfach nur glückliche Fügung oder weißt du, wie es dazu kam, dass du dann angeschrieben wurdest von Rocket? Also ich weiß jetzt nicht, wie es dazu kam, dass ich jetzt angeschrieben wurde, dass direkt ich angeschrieben wurde, aber ich weiß ja, wie Rocket funktioniert hat, wenn er einfach bei Rocket gewesen wäre. Die haben einfach alle angeschrieben. Ich war einfach in dem Suchmuster drin, auf Zing, damals war es möglich, die haben mich halt angeschrieben und ich bin halt durch das Interview durchgekommen. Ich bin ein guter Softwareentwickler, bin dann halt durch das Interview gekommen, hab die Fragen, das war auch ein schnelles Interview, ich glaube drei, vier Stunden oder so, das ging zack, zack, zack. Und dann wussten die halt, guter Entwickler, viel Potenzial, aber noch kein CTO. Das war so das Ergebnis. Ah, okay. Das heißt, damals war es einfach so in der Zeit, dass einfach super viele angeschrieben wurden und einfach dann ausgesiebt wurde im Gespräch. Du hast eher auch Fakten mit Entwicklererfahrung, welche Programmiersprachen. Und wenn ich dann wahrscheinlich in dem Zuge auch, wenn du gemeint hast für Zalando war es, war dann dein Ecommerce Background da dann aber auch einer der wichtigen, also war das irgendwie in deinem Profil mit drin, dass du probiert hast, ein eCommerce Produkt aufzubauen? Ich glaube, das war egal. Einen richtigen Ecommerce Background hatte ich gar nicht in dem Zeitpunkt. Das war ja alles selbst experimentiert. Ich bin dann gestartet, das war Ende 2009. Ich bin dann am ersten Tag zu Rocker gegangen, hab meinen Laptop geholt, bin dann zu Zalando rüber gewechselt und saß dann da bei Zalando und hab die Aufgabe bekommen, baue mal den Checkout neu. Und das war im Oktober und wir sollten noch vor Weihnachten launchen. Ich habe dann einen sehr erfahrenen Entwickler an meine Seite bekommen, der hat mich dann wirklich eingearbeitet, den Daniel Nowak, und dann haben wir das halt zusammen gemacht. Also das war damals noch der Magento Multi Page Checkout bei Zalando. Der hatte halt diverse Probleme. Also zum einen war es UX Problem, aber auch logische Fehler. Es gab so einen schönen Fehler beim Payment. Das Payment war so integriert, dass erst gecaptured wurde, bevor die Bestellung gespeichert wurde. Und dann hatte Magento aber so einen Bug, wenn zu viele Bestellungen letztlich reinkommen, wurde dieselbe Order ID mehrfach vergeben und dann ist es beim zweiten Mal gecrashed, weil irgendwie die ID Berechnung falsch war. Es war so ein Datenbank Cluster und dadurch ist praktisch das zustande gekommen. Es wurde mehrfach dieselbe ID vergeben und der zweite halt das Pech gehabt. Das heißt, das Problem war dann, wurde das Payment aber praktisch geholt, das Geld wurde geholt, die Order wurde aber nie gekostet. Und solches Fehler hatten wir halt im alten Checkout. Und meine Aufgabe war das halt komplett auszutauschen. Das haben wir auch gemacht und dann haben wir vor Weihnachten noch den Checkout bei Zalando damals ausgetauscht, gelauncht und ich hatte dann mein Weihnachtsfest und Silvester Da habe ich dann damit verbracht, mir die Exceptions anzugucken. Es ist immer. Schön, vor Weihnachten zu prüfen, macht immer Spaß. Es hat funktioniert, hat funktioniert, genau. Danach ging es gleich weiter. Danach haben wir gelauncht, Zalando Launch, das ist so ein Vent Privé Klon, weiß nicht, ob das jemand kennt. Von Zalando, da bin ich mit eingestiegen, hab das mitgelauncht, hab das mit betrieben, eine Zeit lang. Und hab danach noch ein weiteres Projekt gemacht bei Zalando. Und dann, nach einem Jahr Zalando, wurde ich dann CTO. Aber ich wurde nicht CTO von einem der Startups, sondern CTO von Rocket Internet Direct. Und das war reiner Zufall, das war einfach so. Rocket zu der Zeit war leer. Also Rocket wuchs sozusagen 2007/2008 sehr groß an, haben verschiedene Sachen ausgegründet. Und dann gab es so zwei Flaggschiffgründungen. Das eine war Zalando, das andere war Groupon. Und die Leute sind praktisch scharenweise in diese beiden großen Gründungen abgewandert. Und Rocket selbst und auch die Aufmerksamkeit praktisch der Geschäftsführung war ganz woanders. Florian Heidemann war dann halt Geschäftsführer von Rocket und von Zalando, war aber praktisch bei Zalando. Und dadurch war Rocket selbst ziemlich leer. Und nach meinem einen sozusagen Trainingsjahr, ging es wieder los. Und die brauchten halt einen neuen CTO. Und das war dann ich, weil ich war halt noch da als einziger wahrscheinlich. Also glaube ich so. Ich war einfach der einzige CTO, der da halt praktisch anwesend war. Wurde ich halt CTO von Rocket und hatte die Aufgabe, einen neuen Online Shop wie Zalando zu launchen. In Japan. Da war schon ein Team vor Ort. Da wurden schon Produkte gesourcet, Räume gemietet, Leute geheiert. Und meine Aufgabe war, baue diesen Shop auf. Ich hatte genau vier Wochen Zeit und es gab einen Sonderbonus von 5000 Euro damals, wenn ich das schaffe. Und das habe ich natürlich geschafft. Weil wenn die Aufgabe nur lautet, mache einen Shop und sonst nichts als Anforderung gibt, dann schafft man das halt auch. Dann nimmt man halt praktisch Magento, packt die Produkte da rein. Mit dem Checkout habt ihr gute. Erfahrungen von Magento. Ja, wir haben den dann so gelassen, weil es war einfach Magento genommen, wie es war. Wir hatten dann auch jemanden im Büro in Berlin zu sitzen, jemand der japanisch spricht, der uns geholfen hat, das wir keinen Unsinn hinschreiben. Und das hat dann funktioniert. Nach vier Wochen haben wir den Shop gelauncht. Lokondo heißt der, den gibt es immer noch. Der ist dann leider ein halbes Jahr später bei dem Erdbeben Fukushima Katastrophe ist der leider so ein bisschen zu Bruch gegangen, aber den gibt es grundsätzlich immer noch. Und danach haben wir alle vier Wochen einen weiteren Shop gelaunched. Dann gab es vier Wochen später "Da Vinci" in Brasilien. Den gibt es immer noch, der ist immer noch sehr, sehr groß. Und dann noch ein paar Wochen später nach Lamoda in Russland. Zum Verständnis mit CTO bei Rocket Internet, das heißt, das sind dann sozusagen kleine, also was ist das, wieso ist dieses, dieser Webshop jetzt bei, oder der Ecommerce Shop, direkt bei Rocket Internet und keine eigene Ausgründung eines Startups, also legen die bei Rocket Internet los und werden dann irgendwann an ein weiteres Team übergeben oder wie lange lebt dann sowas direkt bei Rocket Internet und wird dann eine eigene Ausgründung oder sowas? Richtig, genau. Ich muss ein bisschen erklären, wie das eigentlich funktioniert mit Rocket, gute Frage. Also damals war es so. Heutzutage ist es nicht mehr so. Also heutzutage ist Rocket von heute halt mit dem Rocket von damals nichts mehr zu tun. Damals war Rocket Internet einfach eine Fabrik für Firmen. Also man hat sich eine Idee überlegt oder irgendwo abgeguckt oder die Idee kam halt irgendwo her. Es gab ein eigenes Ideengründungsteam und so weiter. Also die Idee kam her und die wurde einfach executed. Das heißt, man hat mit den eigenen IT Ressourcen, eigenen Marketing Ressourcen, eigenen Business Development Ressourcen diese Idee einfach umgesetzt. Man hat sich Gründe gekauft. Man hat Rocket gesucht, ehemalige WHO Absolventen oder wo man die auch immer hergenommen hat und die wurden dann darauf angesetzt. Und Rocket hat dann praktisch die technische Umsetzung durchgezogen und mein Job war es im Prinzip, die jeweiligen Shops zu launchen. Die Technologie auszusuchen, zu launchen und dann aber auch jeweils ein Team zu rekrutieren in dem Land und dann an dieses Team zu übergeben und zwar schnellstmöglich. Die Aufgabe von Rocket Internet war es, neue Startups herzustellen, sich aber danach nicht mehr ewig darum zu kümmern. Man war ja keine Agentur, man hatte gar kein Interesse daran, Stunden zu verdienen oder so weiter. Man wollte einfach die Shops hinstellen und weitermachen, möglichst viele Shops. Also möglichst viele Gründer enabeln, ihre eigene Ecommerce Firma weiterzuentwickeln. Okay, und wie lange warst du dann CTO bei Rocket Intent direkt und wie viele von diesen weiteren Shops gab es dann noch? Ich glaube wir sind bei Shop 3 gelandet. Es gab dann noch diverse weiter. Es gibt ziemlich viele noch davon. Wir haben dann auch, technisch spannend ist der Aspekt des Shop Systems. Und zwar, wir haben mit Magento gelauncht und hatten damals aber gesagt, wir lassen Magento so wie es ist und verändern es nicht. Weil bei Zalando wurde damals Magento verändert und die veränderte Version konnte man nicht mehr updaten. Das war problematisch. Und darum habe ich bei Rocket gesagt, wir nehmen Magento, setzen aber unseren eigenen Code in eine eigene Applikation. Und die nannte sich Bob. Bob stand damals für Bigfoot und Back. Und Bigfoot war der Überbegriff für das ganze Projekt. Bigfoot. Also Bigfoot. Weil das ja kam ja von Zalando Schuhe und so weiter. Das war so ein bisschen die Erleitung. Und das war Zen Framework damals, PRP. Und da haben wir unseren eigenen Code reingebaut. Und dann irgendwann haben wir gesagt, okay, jetzt brauchen wir eigentlich kein Magento mehr, weil Magento zu haben nur fürs Frontend, macht ja gar keinen Sinn. Also haben wir eine zweite Applikation gebaut, die nur das Frontend geändert hat, also Shopfrontend. Die haben wir dann Alice genannt. Und damit hatten wir ein Shopsystem namens Alice und Bob. Das gibt es immer noch. Also man findet tatsächlich immer noch...... Immer noch auf einigen Webseiten, wenn man dann Bob. Den Namen eingibt, findet man es immer noch. Es gibt immer noch Fragmente. Es wurde auch genutzt z.B. Für HelloFresh oder auch Westing in Brasilien hat das genutzt und es gab dann mehrere Dutzend solcher Shops. Um zu deiner Frage zurückzukommen, ich bin ein Jahr bei Rocket geblieben, also ein weiteres Jahr und damals gab es ja diese Ausgründung Project A Rocket Internet. Da hat die Geschäftsführung von Rocket Internet gesagt, sie wollen das gleiche Modell machen, aber auf eigene Rechnung. Und die haben dann einen Teil des Teams mit rübergenommen. Wenn man dann noch ein bisschen nachgoogelt, das findet man auch im Netz. Und da bin ich mitgegangen zu dem anderen Inkubator Project A und habe im Prinzip dort das Gleiche gemacht. Und mein Problem war, dass ich ja mein Shop System verloren hatte. Also ich mochte dieses Alice in Bob System. Ich fand das gut. Ich habe damit viel gemacht. Wir hatten auch sehr, sehr viele Entwickler dran. Wir hatten insgesamt über 1000 Entwickler an dem System, also weltweit über die verschiedenen Startups verteilt. Und ich habe mich daran gewöhnt. Ich fand das wirklich toll. Und bei Project A durften sie ja nicht mitnehmen. Und da haben wir ein neues Shop System gebaut. Das nennt sich Eve & Zed. Da sieht man schon von der Namensgebung sehr kreativ. Also bei Rocket haben wir die ersten Buchstaben genommen, Alice und Bob. Bob war Zed Framework und Alice war, habe ich vergessen, hätte ich gesagt, was das war für ein Framework. Können wir die Show Notes packen, falls du die später drinnen hinstellst. Ja, das findet man auch raus. Und Eve & Zedd. Zedd war das war halt damals Zed, das Zend Framework und Eve ist damals das Yiframework, das war ein spezielles PHP Framework, besonders schnell. Und damit haben wir dann weitere Onlineshops gebaut. Da gab es einen, der nennt sich zum Beispiel Tirendo, wahrscheinlich kann man sich nicht mehr erinnern, aber Tirendo war ein Onlineshop für Reifen und da gab es Onlinewerbung mit Sebastian Vette. Da gab es Fernsehwerbung mit Sebastian Vette. Vielleicht hat man den Spot mal gesehen. Ja, da hat man glaube ich, sogar was von der Zeit. Das war mein zweites Shopsystem. Also ich. Hatte gute Leute an meiner Seite, auf jeden Fall. Ich glaube, ich bin ein guter Softwareentwickler. Ich kann guten Code schreiben. Ich weiß auch, wie das funktioniert mit Solid, Klingcode und so weiter, Softwarestruktur. Aber offen gesagt, ich war zu dem Zeitpunkt noch nicht besonders breit aufgestellt. Ich kannte eigentlich nur eine Primärsprache tief, nämlich PHP. Dort kannte ich ein Handvoll Frameworks. Die habe mich gefragt, wie triffst du Technologieentscheidungen, wenn du so. Jung in diese CTO Rolle reingewachsen bist? Die erste klingt wahrscheinlich relativ nah mit Zalando, Erfahrung mit Magento, dann nehmen wir das so. Aber wie hast du dich in der Rolle gefühlt, als CTO dort zu sein und dann bei diesen ganzen Unternehmen den Grundstein der Technologieentscheidung zu treffen? Hattest du gefühlt schon genug Knowhow, um das Ganze machen zu können? Wie hast du über die Zeit hinweg diese Technologieanschaltung getroffen, wenn es immer wieder neue Produkte waren, was ihr. In Technologie einsetzt? Und wie hat sich das dann im Laufe der. Zeit geändert? Und wie hast du dann, ich meine als CTO wird man seine Erfahrungen nicht mehr so stark von Hands on Entwicklung wahrscheinlich bekommen. Wie hat sich dieser Erfahrungsschatz verändert? Sind diese Diskussionen heute anders über die, welche Programmiersprache wird eingesetzt? Welches Framework wird genutzt? Ich habe 2020, also Corona Zeit, eine Pause gemacht. Ein halbes Jahr und habe in der Zeit meine Technologie Ich habe meinen Technologie Sprachortschatz einmal erweitert und habe über mehrere Monate hinweg jeden Tag Online Tutorials gemacht und habe mir angeguckt, was gibt es noch so. Ich hatte vorher, ich war sehr tief im PHP, ich habe ja nach Project A einen Sprite, also da kann ich ja noch ein bisschen was dazu erzählen. Ja, kommen wir gleich zu. Aber ich habe sehr, sehr viele Jahre nur PHP gemacht und weiß auch, wie die Sprache funktioniert. Also ich kann auch genau vorhersagen, wie sich das verhält auf dem Server, wenn es Traffic gibt, Unterlassbedingungen und so weiter, was Sicherheitsprobleme sind. Also PHP, sozusagen bin ich Experte, aber man kommt da nicht mehr raus. Wenn man einmal tief drin ist, dann nutzt man das natürlich immer wieder neu. Man geht ja nicht hin und baut was Neues mit irgendeinem Tool, was man gar nicht kennt. Das ist viel zu riskant. Darum habe ich mir gesagt, okay, du brauchst mal eine Pause. War ja auch sonst, war Corona, die Kinder waren zu Hause, war auch einfach auch wirklich nett. Und da habe ich dann jeden Tag mehrere Stunden Tutorials gemacht. Ich habe mir alle gängigen Promi Sprachen angesehen. Ich habe mir Ruby angesehen, Rails angesehen, Python angesehen, ein bisschen mit Java gespielt, JavaScript, Node.js und bin dann zum Schluss gekommen, dass die einzige Sprache, die wirklich Sinn macht, für mich zu lernen, ist JavaScript. Weil Python ist nicht besser als PHP, ist eher schlechter. Außer man macht Machine Learning, wollte ich nicht. Kein Interesse. So was wie Perl macht überhaupt keinen Sinn. Ruby und Rails machen es auch nicht besser als PHP, ist das Gleiche eigentlich. Also Syntax ist ein bisschen anders und vielleicht ein bisschen mehr Syntactic Sugar. Aber es kann nichts Grundlegendes an, also es läuft auf dem Server, es ist nicht schneller, es gibt eigentlich nur ein richtiges Framework. Das fand ich jetzt nicht besonders interessant. Aber JavaScript, fand ich spannend. Da hab ich mich nicht angetraut. Das hab ich in den 20 Jahren vorher sozusagen nie so richtig gelernt. Das war immer ein Mist sozusagen. Am Anfang musste man ja JavaScript pro Browser neu schreiben. Das war ja total ein Murks. Und dann kamen so Frameworks raus, Script, JQuery usw. Das war auch alles irgendwie... Ich fand das immer doof. Und jetzt hab ich mich gezwungen, das mal systematisch zu lernen. Und ich habe insgesamt über zwei Monate gebraucht, um die Stack zu lernen. Also die Sprache selbst hat eine Woche gedauert, das war kein Problem. Aber dann diese ganzen Frameworks, also da geht es schon los mit dem Frontend. Was machst du? Machst du React, machst du Vue, machst du Angular? Ich habe mich für React entschieden, weil da gibt es auch React Native, gibt es auch auf dem Mobile, kannst du auf dem Mobile und Clients halt die gleiche Sprache haben. Das fand ich schon mega spannend. Der Hauptvorteil von JavaScript ist halt, du hast es sozusagen serverseitig im Browser und auf der Mobile App kannst du die selbe Sprache verwenden. Das ist so der Killer. Das ist der Hauptvorteil. Da kann keine andere Sprache mithalten. Das ist so der Grund, das zu nehmen. Aber dann diese ganze Technologie, die es da gibt, also diese Sprachen, ich habe, also React, React alleine reicht ja nicht. Da musst du noch Next.js machen. Dann brauchst du noch State Management. Was zum Geier ist denn State Management? Das hatte ich vorher nicht. Php. Da hast du das serverseitig HTML generiert und fertig. Da musst du Redux nehmen. Das Ökosystem ist auf jeden Fall sehr groß. Formulare. Formig, Validierung, JAP usw. React Native, das mal alles sich angeguckt. Und dann serverseitig, ne? Node.js, ok, klar. Express. Express ist so ein bisschen wenig. Das ist so ein bisschen dünn. Das ist nur so ein Router. Das reicht nicht. Da brauchst du ein richtiges Framework. So was wie Symfony oder Laravel. Oder Rails oder Django. Aber das gibt's halt nicht für Node.js. Dann gibt's halt NestJS, weil das ist irgendwie auch das vielversprechend. Das sieht aus wie richtiger Code. Das sieht ja nicht so aus, wie Javascript sonst so aussieht, sondern es sieht halt richtig aus mit Klassen und Interfaces und Methoden. Und das fand ich schön. Und dann, welches ORM nimmst du? Nimmst du TypeORM, nimmst du Prisma, nimmst du SQLite? Und das hat mehrere Monate gedauert. Und jetzt, um auf deine Frage zurückzukommen. Man sagt ja immer, ein guter Softwareentwickler sollte alle möglichen Sprachen beherrschen. Und ich glaube, dass der Aufwand, so eine Sprache zu wechseln, also die Sprache selbst ist kein Problem, man sollte sich auf jeden Fall mehrere Sprachen angucken, aber so ein komplettes Ökosystem zu können auf Senior Level Niveau, das dauert einfach. Und wenn man nicht das Glück hat, dass man einen Job hat, der das irgendwie erzwingt nach dem Motto, ihr müsst jetzt alle Java lernen, weil wir machen jetzt ab morgen Java, das ist cool, wenn das kommt, dann wird man bezahlt fürs Lernen. Aber wenn man die Gelegenheit nicht hat, dann rutscht man immer tiefer in eine Sprache und kommt da nicht raus. Und bei manchen Leuten ist ja sogar das Framework sticky. Die sind dann irgendwie Experte für Magento oder Experte für Typo 3 oder für irgendwas. Das ist ja noch blöder. Wenn das dann irgendwann nicht mehr drin ist, dann hast du keinen Job mehr. Und ich habe das erzwungen, indem ich selbst gesagt habe, jetzt mal Schluss mit PHP, jetzt mache ich mal was Neues und habe mir diese JavaScript Welt angeguckt. Und seitdem bin ich auch viel breiter aufgestellt. Also jetzt fallen mir andere Dinge auch viel leichter, weil der Wechsel von PHP auf JavaScript hat mir auch sehr, sehr viel zusätzliches Wissen eingebracht, das ich vorher nicht hatte. Einfach weil das Sprachmodell anders ist, weil die Ausführungsart anders ist. Und es fällt mir auch leichter, jetzt noch über ganz andere Sprachen nachzudenken. Und wenn ich jetzt über Architektur nachdenke oder Softwareentwicklung, habe ich nochmal einen ganz anderen Blick, als ich den noch hatte vor vier, fünf Jahren. Das ist nicht so einfach. Das lässt sich nicht so einfach reproduzieren. Man braucht diese Zeit dafür. Ja, aber. Jetzt sind wir, bin wir sozusagen vorgesprungen zu 2020, wo du das dann gemacht hast. Jetzt, wir haben aufgehört bei Project A, wo du ja dann auch weitere Shops gelauncht hast, da ja dann der PHP Welt und das auch gerade noch angesprochen, hast dann irgendwann Spriker auch gegründet, was ja alles noch davor passiert ist. Das heißt, in dieser Zeit, wenn wir jetzt nochmal auf das Technologische schauen, da war dann einfach, sag ich mal, welche Sprache und vielleicht auch welches Framework so irgendwo genutzt werden, das war dann einfach Gesetz, so was die Technologieentscheidungen angeht. Das war einfach PHP, das war es in all diesen Stationen so vorher. Was es ja durchaus. Schön einfach. Macht insofern. Also ich meine, ich glaube auch, warum sollte man das nicht alles mit PHP umsetzen können. Umsetzbar ist das alles. Und ja, irgendwie auch eine gewisse Freiheit zu sagen, über die Entscheidungen muss man sich gar nicht groß unterhalten. Aber war es denn Thema in der Zeit? Man würde ja sagen, es war bei Rocket Internet damals, als Alison Bob entwickelt wurde, tausend Entwickler, die daran entwickeln. War das denn nie ein großes Thema, weil es so vorgegeben war und es hat für alle gepasst? Also ich als PHP CTO, Hands On CTO, ich will mein System immer auch beherrschen und wenn es in einer Sprache gebaut ist, die ich nicht kenne, dann kann ich das nicht. Dann das Team war natürlich ein PHP Team, das heißt die Auswahlmöglichkeiten waren eh limitiert. Und dann ist es halt so, in der Ecommerce Welt, wenn du jetzt willkürlich 100 Entwickler mit Ecommerce Knowhow weltweit zusammenstellst, ist die Wahrscheinlichkeit, dass 90 davon PHP Entwickler sind, sehr sehr hoch. Das liegt daran, dass die Open Source Ecommerce Systeme in PHP sind. Der Markt sieht ein bisschen anders aus. Da gibt es ja auch Systeme wie Hybris in Java, aber das ist halt nicht Open Source. Also die meisten Entwickler weltweit, die Ecommerce Erfahrung haben, sind PHP Entwickler. Das liegt vor allen Dingen am Magento. Okay. Das heißt, der Vorrat an Leuten, die man sozusagen rekrutieren kann, weltweit, der ist in dem Bereich am größten bei PHP Entwicklern. Wenn du jetzt sagst, du baust ein Shop System mit Ruby, da wirst du ein Riesenproblem haben. Dann kannst du zwar gute Ruby Entwickler finden, aber die haben dann keine Ahnung von Ecommerce. Und das Ecommerce Wissen, das ist meistens größer und aufwendiger zu lernen als das PHP Wissen. Also es ist viel wichtiger, Leute mit Ecommerce Erfahrung zu hirnen, als Senior Level Entwickler, wenn die dann das Framework nicht kennen, wenn die dann immer gearbeitet haben mit mit Symphonie statt mit Zen Framework, die müssen sich dann umstellen. Das ist nicht so schlimm. Das dauert dann zwei Wochen und das kann man dann lernen. Aber das Ecommerce Wissen, wie genau ist es mit dem Katalog, wie genau funktionieren Warenkaufregeln, was ist eigentlich zwischen einem Gutschein und einem Kaufgutschein, mit der Umsatzsteuer, das alles zu wissen, das lernt man nicht mal eben so nebenbei. Das steht auch nirgendwo. Eine Sache, die ich nochmal ein bisschen genauer eingehen möchte. Das war ja zumindest so von außen, der das selbst nicht erlebt hat, würde ich es als wilde Zeit irgendwie ein bisschen zumindest beschreiben, was Rocket damals gemacht hat. Also ein Startup oder eine Firma nach dem anderen rauszuhauen. Und du hast ja auch dann gerade bei Projekt A viele Firmen irgendwie begleitet oder gestartet und dafür Leute auch eingestellt. Wie sehr habt ihr da immer auch euer Bild von einem funktionierenden Unternehmen angepasst? War das einmal eine Blaupause, dass man gesagt hat, okay, das sind die Skills und damit gehen wir jetzt einfach los, weil ich stelle mir irgendwie so wahnsinnig viele Herausforderungen vor. Eben hatten wir irgendwie Japan als einen Standort. Alleine da ist irgendwie kulturell wieder tausend Sachen, die man eventuell beachten muss. Wenn es darum geht, da einen Startup hin zu exportieren oder eine Idee hin zu exportieren. Also in diesem Konstrukt, und da warst du ja auch dafür verantwortlich, Leute einzustellen, die dann diese Sachen übernommen haben und irgendwie mitgebracht haben. Wie habt ihr das irgendwie oder wie hast du das für dich weiterentwickelt? Wie viel Kontakt hattest du denn immer noch zu dem, was dann irgendwo entstanden ist? Hast du mitbekommen, wie gut es war? Vielleicht kannst du da nochmal ein bisschen Einblicke geben. Also bei Rocket hatte ich sehr wenig Kontakt. Ich bin auch selbst nie hingefahren. Ich hatte Projekte in Japan und in Brasilien und Russland. Ich konnte gar nicht von wo ich hinfahren, das wäre unmöglich. Und da haben wir einfach jemanden geheilt, der unsere Anforderungen erfüllt hat und der war es dann. Da war nicht viel mehr mit kultureller Auswahl oder irgendwie, das musste einfach funktionieren. Also technische Fragen beantwortet und grundsätzliche Fragen, wie "Wie wirst du ein Team führen, wie machst du agile Prozesse und dann war das jetzt CTO und fertig. Bei Project A war das anders. Bei Project A hatten wir viel mehr Zeit mit den Startups. Da war ich selbst teilweise der Interim CTO von den Startups und da habe ich auch extrem darauf geachtet, dass der CTO, den dann der Startup danach übernommen hat, dass der gepasst hat. Und das ist gar nicht so einfach. Wenn man so eine Firma aufbaut, ich habe ja nur die technischen Teile mit aufgebaut von den Firmen, dann hat man natürlich eine gewisse Führungsphilosophie, wie die Leute arbeiten, man soll sie frei denken, werden sie eingeführt, ist es wichtig, hochwertigen Code zu schreiben, ist es wichtig, Tests zu schreiben und so weiter. Und da habe ich bestimmte Vorstellungen, die ich natürlich als interim CTO dann auch durchsetze. Wenn aber der Nachfolger dann ganz andere Meinungen hat, dann wird er alles abreißen. Dann tritt ja alles sozusagen einmal weg und im schlimmsten Fall will er alles neu bauen. Das gibt es ja auch, dieses Gefühl, dieses Not Invented Here Syndrome. Das heißt, es war extrem wichtig, da jemanden zu finden, der diese Führungsphilosophie fortgeführt hat, und bei Project A habe ich das, und das ging auch ein paar Mal schief. Ich habe auch ein paar Mal Leute geheiratet als in die CTO Position, die danach sozusagen gesagt haben, so tschüss, das war's, ich mache jetzt meine eigene Sachen, und das war dann nie gut für das Startup, weil wenn, also auch wenn das, was die da neu gemacht haben, gut war, trotzdem dieser Moment des Veränderns, der war halt immer unpassend. Das ist ja gerade in der Startphase der Startups und da will man ja kein CTO haben, der sagt, wir müssen alles neu bauen. Auch wenn das Bestehen vielleicht nicht so gut ist, wird trotzdem erstmal fortgeführt, bis man vielleicht Broad Market Fit hat oder bis man vielleicht eine Finanzierungsrunde hat, aber einfach, einfach das ändern, wegen des ändern ist halt nicht gut. Und bei Project A habe ich dann selbst so ein CTO Trainee Programm eingeführt. Das heißt, ich habe dann Leuten angeboten, guck mal, wenn du CTO werden möchtest in einem Startup, dann machst du vorher ein Jahr lang dieses Programm mit. Dann wirst du halt als Tech Lead in verschiedene Startups gesetzt. Du musst dir da beweisen. Du siehst dann, wie es funktioniert und lernst auch von mir und wirst dann praktisch so ein bisschen eingenordnet. Und dann nach dem einem Jahr, die Leute, die dann praktisch da rausgekommen sind und die auch Empfehlungen mitbekommen haben von den Gründern. Die wurden dann CTO von einem der Startups, aber haben das dann so fortgeführt, wie ich das gemacht hätte. Jedenfalls für die ersten Monate. Dann irgendwann weiß ich es nicht mehr, aber am Anfang. Und das hat sehr, sehr gut funktioniert. Damit hat man die Firmen sehr schön in eine Richtung geschubst. Und das hat in den meisten Fällen funktioniert. Sowohl die Firmen als auch die Leute haben sich in der Regel gut funktioniert. Also an der IT ist da nicht gescheitert. Also wenn es gescheitert ist, dann nicht in der IT. Die anderen Aspekte der. Firma habe ich ja nicht kontrolliert. Also wie jetzt die Gründer ausgesucht wurden oder ob das Geschäftsmodell funktioniert, das war außerhalb meiner Reichweite. Ja cool. Dann würde mich auf jeden Fall jetzt ein bisschen der Schritt interessieren von, wir hatten es vorhin angesprochen, du warst jetzt CTO bei Project A und warst da eine ganze Weile lang, ich glaube bis 2015 und hast dann...... Spiker gegründet, so der Schritt würde mich...... Eigentlich interessieren, so wie...... Wie kam es von...... Interim CTO Position zu der...... Eigenen Firma und...... Nehmen wir uns gerne mal mit, was genau Spiker...... Eigentlich ist. Ja. Also...... Kurz mal, was ist eigentlich...... Projekt A, ich weiß nicht, ob das jeder kennt hier. Also Projekt A ist auch...... War damals ein Company Builder, also auch eine Firma, die selbst wieder andere Firmen gebaut hat, also Startups, Ideen evaluiert hat, Gründer gefunden hat, die vielleicht schon Ideen hatten, die noch keine Idee hatten, das zusammengebracht, mit Kapital ausgestattet. Projekt A hatte selbst auch Manpower, also für 100 Leute damals, IT, Marketing, BI und so weiter und hat praktisch dann die Startups mit Gründern, Geld, anfänglichen Ressourcen ausgestattet und hat sie dann praktisch auf die Reise geschickt. Und ich habe mich damals hauptsächlich um die Ecommerce Firmen gekümmert als CTO von Project A. Und dabei ist dieses Shopsystem namens EFONZ entstanden. Und es gab damals auch einige Kooperationsversuche und größeren Unternehmen mit Konzernen. Und die haben gesagt, guck mal, ihr habt ja dieses Shop System und das scheint ja gut zu sein. Das ist ja irgendwie ein gutes Asset. Das sagt die auch immer. Wenn jetzt die Startups Geld raisern, dann nennen die auch immer das Shop System als Asset. Das hat praktisch die Bewertung der Firmen auch so ein bisschen mit... Das wurde immer herausgestellt. Ich weiß nicht, ob das jetzt bewertet wurde, aber es war immer so, wir haben ein eigenes Shop System, ein wichtiges Asset. Und darauf haben große Firmen reagiert und haben gesagt, können wir das nicht auch irgendwie haben? Können wir das auch nutzen für unsere eigene...... Die Kommerzstrategie. Und das hat nicht geklappt, weil Project A ist ja keine Agentur, die können ja keine Software verkaufen, die können auch keine Entwickler verkaufen. Es gab aber kein Szenario, es gab auch keinen Deal Szenario. Wie will denn ein VC mit einem Großkonzern zusammenkommen? Das klappt ja von hinten nicht. Aber es gab irgendwie Demand für dieses System. Das war auch überraschend. Also für mich war das überraschend, weil es gab ja schon so viele Shopsysteme. Also ein Intershop, ein Magento, ein WooCommerce, ein Hybris, Demandware. Also es ist ja nicht so, dass es an Shop wäre damals auch. Es ist ja nicht so, dass es an Shopsystemen gemangelt hat in der Welt. Aber irgendwie gab es da noch Bedarf. Und dann ist es so, die Idee für Spiker, die kam nicht von mir, die kam von ganz anderen Leuten. Die kam von Alexander Graf und Nils Sebach. Zwei externe Gründe. Selbst auch Geschäftsleute, machen Consultingfirma, in der sich E.Tribes in Hamburg. Und die haben sich mit Project A zusammengesetzt, mit dem Florian Heinemann, Geschäftsführer, und haben diese Idee für Spriker gemeinsam entwickelt. Dass man da ein Shopsystem macht, damals noch mit ein bisschen Frameworkgedanken, also ein Shopsystem, was besonders flexibel ist, was man besonders gut anpassen kann an beliebige andere Geschäftsmodelle. Und das wurde mir dann so ein bisschen vorgesetzt. So, guck mal hier, wir werden jetzt ein Shopsystem ausgründen. Wie findest du das? Und ich dachte mir, ja cool, aber vielleicht sollte ich da mitgehen. Und dann hatte ich einfach die, ich hatte die Wahl. Entweder suche ich dann einen CTO, der das macht, den ich dann einarbeiten muss, oder ich nehme die Option, selbst zu gründen. Und ich hatte ja erzählt, ich hatte ja schon selbst, ich hatte ja vorher schon mal selbst gegründet, nicht erfolgreich. Und hier war im Prinzip einfach so, ich konnte mich jetzt gemacht im Nest setzen. Also da war eine Firma, die war gefundet, mit der Geschäftsidee, mit Gründern und ich durfte einfach so an Bord kommen als CoFounder der CTO. Und die Chance, die nimmst du natürlich, also das ist ja klar. Und dann habe ich das gemacht. Dann wurde ich CoFounder. Ich bin nicht wirklich Gründer von Spyker. Ich bin ein bisschen später an Bord gekommen, aber ich bin sozusagen CTO. Aber es war das Shop Framework von Project A, die Grundlage, es wurde nicht was Neues entwickelt oder so, den Source Code habt ihr mitgenommen? Jein. Wir haben die Storyline mitgenommen. Wenn du neuen Softwarebinder baust, ist immer das Problem, dass du keine Referenzen hast. Wir konnten immer schon die bestehenden Project A Projekte nennen als Referenzen. Das war am Anfang wichtig, weil keiner will ja Kunde Nummer 1 sein. Den Source Code von Project A, der war halt für den Anwendungsfall schnell Status bauen gedacht. Und Spiker ist ja Enterprise Software. Der Code hat die Anforderungen gar nicht erfüllt. Also das war kein Clean Code, da war kein Zolle Prinzipien drin, das war nicht dokumentiert, nicht ausreichend Tests und so weiter. Das heißt, da gab es dann schon nochmal eine Bauphase, eine längere Bauphase, bis das System überhaupt erstmal auf Enterprise Readiness kam. Das heißt, wenn man jetzt den Code von damals heute vergleichen würde, ich bin mir nicht sicher, ob da was übrig ist. Die Namen sind noch da, also man sieht im Source Code, der Code von Spiker, der ist ja öffentlich, der ist auf GitHub, da sieht man diese alten Namen Ivo und Z drin. Also jeder, der mit diesem System arbeitet, der kennt auch diese Begriffe Ivo und Z, die haben sich hartnäckig gehalten. Die gehören gar nicht zur Spiker in der Namenswelt, aber die sind halt drin im Code. Und wenn man die umbenennen würde, würde man einen wahnsinnigen Specie Break machen. Die sind einfach noch drin. Aber die Architektur und die ganzen Coding Guidelines ist alles anders. Also da ist, glaube ich, nicht mehr viel übrig. Aber es ist sozusagen ein Nachfolger System. Wir haben nicht den Code weggeschmissen und neu gemacht. Das haben wir nicht. Sondern es hat sich dahin entwickelt. Aber es. Ist im Prinzip. Fast eine neue Entwicklung. Aber es ist dann mal ein drittes Jobsystem. Also sozusagen zwei Iterationen vorher schon. Da waren viele, viele Learnings verbaut. Ja, und technologisch haben wir ein paar Sachen geändert. Also das so ein bisschen nach und nach von den Frameworks gelöst. Also das EVE System, es war dann nicht mehr EVE Framework. Das war dann Silex. Silex ist so ein Micro Framework von Symfony, das wurde irgendwann gearchivet und das sozusagen wurde irgendwann geinsourced in Spiker. Und so ein paar andere Themen auch, zum Beispiel das ORM, das war Propel ORM. Das gibt es ja auch gar nicht mehr. Und das hat dann Spiker irgendwann übernommen und weiter maintaint. Also die verwendeten Frameworks, die fädeten langsam irgendwann aus. Und dann musste Spiker das nach und nach alles übernehmen. Aber halt nicht mehr als Open Source weitergeführt, sondern dann... Doch, doch, das ist Open Source. Okay, ihr habt den. Open Source weitergeführt. Das ist ein bisschen das Problem, wenn man eine Scores Software baut, die man vertreibt, du musst dich ja irgendwann entscheiden, was du da einbaust. Und so ein Open Source Software, der Lifecycle von Open Source Software, der ist ja nicht unendlich, der ist irgendwann vorbei, weil der Maintainer keinen Bock mehr hat oder etwas anderes macht oder einfach sagt, das ist jetzt nicht mehr...... Nicht mehr relevant und dann hast du das Problem, du hast es verbaut und was machst du jetzt? Wenn du jetzt wechselst, wenn du jetzt sagst, du gehst jetzt von Propel auf Doctrine zum Beispiel, dann müssen ja alle deine Kunden mitziehen. Die haben ja den Code in ihr eigenes Projekt übernommen. Die haben ja selbst drauf aufgebaut und das kannst du nicht. Das kannst du nicht bringen. Dann würdest du in all deinen Kundenprojekten einen wahnsinns Migrationsaufwand erzeugen. Und das geht einfach nicht. Also musst du halt dann diese Open Source Software selbst weiterentwickeln. Und wie ist dann eure Entscheidungsfindung dafür eine Open Source Software einzubinden oder eben auch nicht so. Also das ist ja dann durchaus eine sehr große Entscheidung zu sagen, nehmen wir uns diese Abhängigkeit rein, entwickeln wir es selbst. Hoffen wir einfach darauf, dass es möglichst lang Open Source weitergemacht wird und dass wir es nicht insourcen müssen. Wie ist da der Entscheidungsprozess? Also wie der jetzt bei Sprite Girls, weiß ich nicht. Das war ja da. Also das war ja 2015, 2016. Das ist schon ein bisschen her. Wie der jetzt aussieht, weiß ich natürlich nicht. Aber ich. Meine, ihr habt wahrscheinlich jetzt bei Rock das Gleiche. Die gleiche Frage stellen. Das Problem hat glaube ich, jeder. Also der irgendwie Software baut, die man dann verkaufen möchte. Wenn man Software für sich selbst baut, ist das egal. Dann nimmst du ja heute React und morgen nimmst du Vue.js und dann ist es fertig. Aber wenn du eine Software baust, die du weiterverkaufen willst, wo Leute den Sourcecode in die Hand kriegen, hast du immer das Problem. Jetzt bei Rock ist das so, wir nennen das Feature as a Service nennen, Also wir betreiben die Plattform, das heißt der Kunde kriegt die APIs und ein paar Open Source Komponenten von uns. Aber der Hauptkern der Applikation, die betreiben wir auf unseren Servern. Das heißt, wir haben dort die Möglichkeit, das beliebig zu wechseln. Und bei Spiker ist es so, Spiker ist on premise, das heißt der Kunde hatte damals den Source Code komplett bekommen, das gesamte System und konnte es dann lokal im eigenen Repository hosten, speichern und verändern. Und dadurch sind diese Dependencies nach draußen gegangen und das erzeugt dann diese Probleme mit den Open Source Tools. Wie war Spriker so aufgestellt? Wie groß war die Mannschaft, das Dev Teams, das Dev Team...... Das ihr da hattet und wie viele Leute habt ihr an dem Shop System entwickelt? Wir waren. Ursprünglich 20 Entwickler ungefähr. Und damals auch so von wahrscheinlich agilen Softwaremethoden und sowas, alles aus Project A und auch Rocket Intel, irgendwie so die Arbeitsweisen, die ihr entwickelt habt, schon damals in Scrum Teams irgendwie unterwegs gewesen? Oder wie wart ihr aufgestellt mit den 20 Entwicklern? Nee, nee, das war eher, also ich bin kein Scrum Freund. Das war eher erkannbar, sozusagen. Jedes Feature für sich, also ganz klassisch jedes Feature, eigener Branch, eigenes Epic wurde dann, wenn das Feature fertig war, wurde es getestet, dann in Main gemerged. Und Sprite hat eine sehr interessante Architektur. Kann ich kurz mal erklären, wenn euch das interessiert? Ja, gerne. Und zwar ist es so, wenn man Software baut und die rausgibt, dass andere Leute die selbst sagen, bei sich speichern, dann ist ja immer die Herausforderung, die wollen es ja erweitern. Und sobald Leute erweitern, also Klassen überschreiben oder Plugins einsetzen, hat man das Problem, beim nächsten Update erzeugst du relativ einfach einen BC Break, also eine Änderung, die dann lokale Anpassungen notwendig machen. Und das will man nicht, weil die Kunden haben in der Regel, haben die überhaupt keine Lust, Zeit zu investieren, um irgendwelche Updates einzuspielen. Die wollen, dass das einfach so funktioniert. Und das Problem hat alle Software praktisch. Also jedes Framework, jedes Shopsystem, jedes CMS hat dieses Problem. Und das Problem lässt sich auch nicht einfach so lösen. Das ist einfach da. Das ergibt sich so. Wenn du Code rübergibst und diesen Code veränderst, du kannst Abstraktionen machen, du kannst mit Interfaces arbeiten, du kannst mit Plugins arbeiten usw. Aber das ist endlich. Und darum haben wir gesagt bei Spiker, okay, wir können das Problem zwar mitigieren durch Abstraktionsschichten und Zolle Prinzipien, aber wir können es nicht ganz fundamental lösen. Aber wir können es ein bisschen abschwächen. Und zwar haben wir Spiker, ein modulares System, das besteht inzwischen aus über 1000 Modulen, die sieht man auch auf Gitter, wenn man die Source Code öffnet, die mit Composer zusammengezogen werden. Und jedes Modul hat eine eigene Versionsnummer, also Semantic Versioning mit den drei Zahlen, Major, Minor, Patch Release. Und dadurch hatte man die Möglichkeit zu sagen, man macht nur auf bestimmten Teilen des Systems einen Major Release. Das heißt, es gibt neue Versionen nur vom CMS. Und wer diese neue Version haben möchte, der muss dann auch den Updateaufwand, den Migrationsaufwand für diesen Teil machen. Wer aber sagt, er möchte das gar nicht haben oder hat diesen Teil lokal angepasst im Projekt, der behält das einfach, das alte. Kann aber trotzdem einen neuen Katalog haben oder ein neues Gutschein System. Aber irgendwie wird es ja Abhängigkeiten darin geben, dass man nicht jede Version mit jeder mixen kann, oder? Das ist richtig. Es gibt einen Abhängigkeitsbaum, den haben wir auch gezeichnet. Der erfüllt auch die, da gibt es so wieder Prinzipien, der ist asyklisch und so weiter. Aber grundsätzlich geht das schon, also es geht zumindest auf so Optim geht das. Also du kannst sagen, du kannst den Katalog, der ist relativ unabhängig vom CMS und klar, zum Beispiel der Warenkorb und die Gutschein Engine, die sind nicht unabhängig. Also da gibt es Dependencies. Aber auch wieder nur in eine Richtung. Also der Warenkorb, der ist unabhängig vom Gutscheinensystem, das Gutscheinensystem ist natürlich abhängig vom Warenkorb. Also kannst du praktisch in eine Richtung kannst du unabhängig voneinander updaten. Also es geht schon, es ist ein bisschen theoretisch schon klar, aber wenn man das Problem hat, dass man ein System Gehackt hat oder überschrieben hat, dann ist das immer noch besser, als wenn man gar keine Updates machen könnte. Das war sozusagen mein Lerneffekt aus der Magento Zeit. Bei Magento war es so, wenn man Magento einmal überschrieben hat und einmal ein paar grundsätzliche Sachen geändert hat, dann konnte man keinen Update mehr einspielen. Das ging einfach nicht mehr. Das gesamte System war gesperrt. Und wenn du einmal verpasst hast ein Update, dann kommt das nächste und das übernächste und dann hängst du ein Jahr zurück und dann, ach, dann war es das. Dann bist du abgehängt. Und das wollte ich verhindern. Und das sozusagen verhindert durch Abstraktionsschichten und diese Modellisierung. Modellisierung war nicht trivial, sondern das ist ganz schön aufwendig, das zu maintainen. Aber ich glaube, das hat sich gelohnt. Und ein anderer cooler Effekt ist halt, dass du sozusagen gerade so ein Shop System wird halt sehr, sehr groß irgendwann und nicht jeder braucht alle Funktionalitäten. Und du kannst einfach Module weglassen. Also du gehst hin in deine ComposerJSON und sagst einfach, die und die Module will ich gar nicht haben. Das geht jetzt nicht bei den Basismodulen. Also du kannst nicht einfach den Warenkorb weglassen oder den Checkout. Das wird nicht gehen. Aber du kannst zum Beispiel sagen, ich habe hier in meinem Projekt habe ich jetzt keine Verpackungseinheiten. Ich verkaufe meine Produkte immer nur stückweise. Ich habe keine Maßeinheiten. Ich verkaufe nicht 100 Gramm Leberwurst. Das habe ich einfach nicht. Also lasse ich die entsprechenden Package und Measurement Module einfach weg und das System funktioniert trotzdem noch. Ich muss mir den Code gar nicht irgendwie laden. Ich brauche das nicht. Also ich verstehe das Konzept, ich stelle es mir trotzdem wahnsinnig schwierig vor, weil du gerade bei diesen Beispielen wieder, wo du sagst, ich brauche irgendwie bestimmte Mengenangaben nicht, aber an allen möglichen Stellen wird ja tendenziell darauf zugegriffen. Sei es im Weinkorb, sei es auf Produktseiten, sei es wo auch immer, in Datenbanken. Du kannst zwar Sachen weglassen, aber trotzdem gibt es potenziell sehr, sehr viele Stellen, wo es. Dann gebraucht. Werden könnte. Du hast recht. Das ist eine Architekturfrage. Also wenn du direkte Zugriffe hast, also eine Methode reift dir direkt auf die Methode einer anderen Klasse zu, dann ist das hart gekoppelt, dann kannst du da nichts mehr weglassen. Da wird es eine Exception geben, wenn die andere Klasse fehlt. Dann kannst du gar nicht erst koppelieren. Was du halt machen kannst, du kannst ein Plugin System bauen und idealerweise haust du Logiken immer durch ein Array von Plugins. Das ist eine Warenkorbkalkulation, ist nicht einfach irgendwo hart ausprogrammiert, sondern das ist ein Array von Plugins, wo das erste Plugin berechnet dann zum Beispiel nur die Summe der Produkte. Das zweite Plugin berechnet dann nur die Umsatzsteuer. Das dritte Plugin macht dann nur die Gutscheine. Das dritte Plugin macht dann praktisch nur die Kaufgutscheine und so weiter. Dann hast du praktisch deine 20, 30 Plugins hintereinander weg. Und du kannst auch einfach welche durchlassen, weil jedes Plugin... Rausnehmen und weglassen, weil jedes Plugin selbst nur ein Stück des Systems berechnet. Und so kannst du ein System bauen, wo du durch Veränderung dieser Konfiguration der Arrays das System flexibel machst. Bei Logik geht das relativ einfach über solche Plugin Systeme. Aufwendig wird es in der UI, wenn du sagst, du hast da im Warnkorb eine Anzeige einer Maßanheit, 100 Gramm. Das heißt, du hast ein Unit, Gramm, das könnte auch Kilogramm oder Tonnen oder Zentimeter oder was auch immer. Du hast eine Zahl, könnte auch Komma sein, 5,3 Meter Kabel. Das hast du aber nur, wenn du dieses Feature grundsätzlich drin hast. Und das heißt, da musst du praktisch in der UI, musst du auch modular denken. Das heißt, da hast du auch praktisch, da geht es nur sehr begrenzt fairerweise. Das haben wir probiert mit Trick Komponenten. Also Trick ist das Template System, das bestimmte Komponenten nur hast, wenn das Feature da ist. Wobei da reichst du die Limits relativ schnell. Also das wird dann irgendwann auch auch Coder Welch im HTML. Aber sehr gut gelöst bekommen haben wir es auf der Datenbank Ebene. Da hast du ja auch Relationen nur in bestimmten Fällen. Und bei Striker ist es so, dass Datenbanks Das Schema liegt nicht einfach irgendwo als Datei vor, das liegt in Form von ganz, ganz vielen kleinen XML Dokumenten vor, die praktisch dann einmal von einem XML Merger zusammengezogen werden zu einem großen XML Dokument. Das heißt, du kannst einfach stückweise XML weglassen und dann fehlen einfach Datenbank der Wellenrelation. Die gibt es dann einfach nicht. Und der Code darf dann aber nicht darauf zugreifen. Der muss praktisch wissen, das könnte sein oder das könnte nicht sein. Es gibt eine Produktoption, also eine Option sowas wie ein Geschenkpapier auf dem Produkt, die gibt es nur, wenn das Product Option Modul installiert ist, sonst nicht. Wie kam diese. Grundsätzliche Architekturentscheidung? War es das bei Project A, ihr auch schon bei dem Shop System, das so implementiert hat? Oder war das eine neue Entscheidung bei. Projekt A haben wir das System gebaut für die großen Enterprises gemacht habt? Das war das erste Startup. Und dann haben wir es für das zweite Startup kopiert und haben es dann weitergebaut. Und dann für das dritte haben wir es dann wieder kopiert. Es gab praktisch kein Core. Es. Gab ja auch kein Core Team. Das heißt, jedes Startup hat für sich dieses Framework eigentlich dann weiterentwickelt. Genau. Es gab keine Synergieeffekte, man konnte nicht vernünftig teilen. Das war gar nicht vorgesehen. Und bei Spiker mussten wir das halt machen. Das heißt, man brauchte eine ganz, ganz fundamentale Architektur, das zu lösen. Aber diese Architektur, also was ich halt gemacht habe, ich muss halt ein bisschen lernen. Das ist ein Packaging Prinzipien, das muss man einmal lernen, das sind so 11 Prinzipien. Und dann halt sich die ganzen Tools angucken. Wie funktioniert Composer? Wie funktionieren Packages? Wie kann man es machen, dass man in der Core Entwicklung in einem großen Modul Repository arbeitet, wo alle Module drin sind. Die Kunden, die sich die Module aber auf einzelnen Git Repositories bekommen, dass sie praktisch nicht ein großes haben, sondern viele kleine. Da hat man so einen Git Subtree Split. Also man nimmt praktisch das Hauptrepository und kann das dann praktisch runtersplitten auf die ganzen Subrepositories. Diese ganzen Techniken, die musste ich auch erstmal alle lernen. Und dann auch so den Teil Semantic Versioning. Jeder Entwickler weiß so ein bisschen, was Semantic Versioning ist, aber die meisten Leute können nicht genau erklären, was ein unterschiedlicher Miner und Patch Release ist. Und das wird ja auch in der Regel falsch gemacht. Also auch Major Frameworks machen dann Miner Releases mit einem BC Break, was ja komplett illegal ist, also im illegalen Sinne der Definition ist. Und das richtig anzuwenden und auch überhaupt erstmal zu definieren, was bedeutet eigentlich ein BC Break? Ist das eine Änderung in der Signatur? Also wenn ich jetzt neuen mandatory Parametern zusetze im Interface, dann ist es halt logischerweise ein BC Break. Aber wenn das Interface gleich bleibt, ich aber hinten irgendwo in der Geschäftslücke irgendwas ändere, was vorher nicht so war, dann ist es auch ein BC Break. Dieses Lernen hast du dann praktisch zusammen mit dem Team gemacht. Das heißt, ihr habt euch dann hingestellt und habt mehrere Iterationen auch gehabt oder gegen das relativ Straightforward, dass ihr eine Idee hattet und habt das dann sehe ich das ja in der Signatur gar nicht. Die API. Sieht genauso aus, aber hinten irgendwo, Zeiler 8, 17, in der und der Klasse ist was anders. Und zack, ist ein BC Break. Und schon habe ich Major Release am Hacken, was ja doof ist, was ich ja nicht will. Das hat ziemlich lange gedauert, das alles zu lernen. Wir kannten die Problemstellungen relativ gut, weil wir hatten viel Ecommerce Erfahrung, auch viel Pain schon gehabt mit Updates und so weiter. Wir kannten die Technologien, die wir einsetzen, relativ gut. Wir kannten aber die Theorie, wie man das löst, nicht so gut. Die mussten wir erst mal lernen. Und da haben wir sozusagen dann haben wir eine Zeit lang einfach so, zum Beispiel haben wir Brown Bag Lunches gemacht. Das heißt, wir haben uns Bücher genommen, zum Beispiel hier "Clean Code" von Angel Bob. Und dann hat jeder Entwickler 20 Seiten bekommen, die er dann praktisch einmal lesen musste und dem Team vorstellen musste. Dann haben wir praktisch gemeinsam diese Sachen gelernt. Design Patterns vorgestellt. Und die ganzen Light2Prinzipien, wirklich mal jeden einzelnen Buchstaben aus Solle durchgekaut. Gemeinsam. Da war wirklich viel, viel, viel Education Zeit notwendig, damit wir das alles verändert haben. Die Entwickler, die Sprike ursprünglich gebaut haben, die Core Entwickler, die arbeiten übrigens alle noch für Sprike. Also das ist ein wahnsinnig toller Job. Toller Job, also für ihre Leute sind wirklich sticky, was die Architektur angeht. Die kannst du nachts wecken, die können dir sagen, was Dependency Inversion Prinzip ist und wie man es anwendet und warum und worauf man achten muss. Also diese Tiefe an Wissen, die normalerweise die meisten Leute einfach nicht haben und auch gar nicht brauchen, die mussten wir aufbauen und das war einfach notwendig. Das finde ich aber interessant, weil gefühlt von dem kulturellen Aspekt, so wie ich jetzt Project A und Rocket wahrnehmen würde, mit in sehr kurzer Zeit schnell etwas hinstellen und jetzt geht ihr zu Sprite und sagt, okay, ihr müsst das erst mal lernen. Da frage ich mich erstens, wie lange hat das gedauert und zweitens so, Kulturiell ist dafür am Anfang die Zeit? Da habe ich gedacht, wenn man aus so einer Kultur kommt, legt man vielleicht erstmal schnell los und wie viel Zeit ist dafür da, Brown Bag Lunches zu machen, erstmal die Solid Prinzipien nochmal zusammen zu lernen und so. Also wie viel Zeit hat euch das gebraucht und war das so ein kultureller Change, wie ich mir vorstelle oder war das auch schon in der DNA vorher drin, als es bei Project A und Rocket war? Okay, gab es irgendwelche Vorgaben, wie wir arbeiten, das war uns überlassen. Ob wir das mittags gemeinsam gelernt haben oder was auch immer, das war egal. Es gab sozusagen kein Micromanagement oder irgendwas. Es gab eine Aufgabenstellung und die lautete, macht mal ganz schnell viele Startups oder macht mal in Ruhe einen richtig. Und die Aufgabenstellung hat man dann genommen und hat die halt bestmöglich gelöst. Die Idee war immer, viel zu reden, also viel Brainstorming, viele Refinement Meetings, sich vor das Whiteboard stellen, einfach gemeinsam zu sagen, das ist jetzt die Ausforderung und wir lösen wir die jetzt einfach. Also die grundsätzlichen Prinzipien einfach nicht einfach loslegen und irgendwas bauen, sondern erstmal drüber nachdenken, die Schwarmintelligenz des Teams nutzen und dann findet man schon Lösungen. Und es gab natürlich eine ziemlich hohe Fehlerquote, muss man auch sagen. Also sicherlich 30% der Entscheidungen sind einfach falsch gewesen. Muss man halt revidieren, muss man erkennen, muss man auf den Tisch bringen, darf man sich nicht doof vorkommen, wenn man auch dann mit Leuten zu sagen, also die Bereitschaft Fehler einzugestehen oder auch anderen Leuten Fehler vorzuwerfen. Also Fehler eingestehen ist einfacher als anderen Leuten Fehler vorzuwerfen. Man muss beides können, weil es im Endeffekt egal ist. Fehler wurde gemacht. Jetzt sind wir schlauer als vorher und er muss es revidiert werden. Und auf gar keinen Fall darf irgendwas stehen bleiben, nur weil man irgendwie Ruhe am Team haben will. Das darf nicht passieren. Dafür haben wir keine Zeit. Das habe ich bei vielen Firmen so gesehen, wo unterschiedliche Konflikte geblieben sind. Man hat irgendwelchen Mist gemacht. Jeder wusste, dass es Mist ist, aber man weiß, wenn man das jetzt auf den Tisch bringt, dann ist XY irgendwie beleidigt und das will man nicht. Und sowas darf es nicht geben. Es muss immer diese Egoless Culture bleiben und dann wird jedes Problem für sich oder jede Problemstellung für sich im Team angegangen und gelöst. Also egal, ob man schnell gehen muss oder langsam, das ist egal. Das ist eigentlich gar nicht so. Rolle. Das ist mir persönlich auch wirklich völlig egal. Ich mache sowohl viele Projekte in kurzer Zeit als auch ein Projekt in langer Zeit. Das ist auch gut. Cool. Ja, die Zeit vergeht schnell mit dir. Ich würde einmal vielleicht unsere Fragerunde kurz einschmeißen, bevor wir dann vielleicht nochmal über dein aktuelles Rock Technology ein bisschen mehr sprechen. Kurz da nochmal einsteigen, wie das Setting da im Moment ist und auf was du da Wert gelegt hast beim Aufbau des Teams. Zu diesen wunderbaren Hintergrundklängen kommen ein paar Fragen, die du einfach so schnell raus beantworten kannst. In der ersten Kategorie geht es um entweder oder Fragen, was du lieber oder besser findest. Und wir fangen an mit Hunde oder Katzen? Hund, ganz klar Hund. Wir haben auch einen Schafspudel zu Hause, einen. Schönen schwarzen. Sehr gut. Tee oder Kaffee? Kaffee. Auto oder Fahrrad? Elektroauto. Java oder JavaScript? Javascript. Das hätte ich jetzt auch nach deiner Erläuterung hätte ich die Frage für dich beantworten können. Mac oder Windows? Mac. Ios oder Android? Android. Büro oder Remote? Gute Frage. Sehr, sehr viel Remote. In letzter Zeit. Jetzt wieder mehr Büro. Ich habe auch Lust auf Büroleben wieder. Es ist einfach so. Frontend oder Backend? Backend. Funktional oder objektorientiert? Objektorientiert. Native oder Web? Web. Und Teamwork oder Individualist? Teamwork. Deine erste Programmiersprache? Haben wir glaube ich, schon geklärt. Das war? Die allererste war Cool Basic. Dein erster Computer? Das war ein 386er SX25. Was ist deine Lieblingsprogrammiersprache heute? Ja, das ist eine gute Frage. Ich bin immer noch ein bisschen PHP Fan, muss ich zugeben. Ich mag aber auch Node.js, also JavaScript. Also tatsächlich, was man mit mir jetzt entscheiden müsste. Ich würde mal sagen Node.js, JavaScript. Schade, ich hätte PHP besser gefunden. Da findet man nicht mehr so viele in die PHP als ihre Lieblingssprache. Ich bin großer PHP Fan. Nicht tot, die Sprache auf gar keinen Fall. Dein liebstes Frontend Framework? Ja, React. Fehlerweise kann ich auch nur React. Dein liebstes. Open Source Projekt? Ich bin großer Next.js Fan tatsächlich. Ich mag auch Prisma ORM sehr, sehr gut, sehr gerne. Das sind sehr schöne Tools. Auf jeden Fall. Finde ich sehr schön gemacht. Bitte hier unterschreiben. Und als. Letztes noch, was ist deine, hast du eine Lieblings App? Ich habe. Meine Lieblings Webseite, aber das ist keine, das ist keine, also ChatGPT und Mitschüler, ich glaube die Antwort ist relativ lame gerade. Das sind definitiv die beiden Projekte, die ich gerade am meisten nutze, so privat. Cool. Da muss ich direkt nachfragen. Also erstmal vielen Dank für die Beantwortung und die Fragerunde. Chatgpt, wofür nutzt du das im Alltag aktuell? Also privat natürlich, aus Spaß. Aber ich nutze das tatsächlich für die Arbeit, fast jeden Tag. Ich bin auch einer von denen, die 42 Euro zahlen würden. 42 ist eine großartige Zahl, mit der Anekdote. Ich nutze das sehr viel für Inspiration. Gib mir fünf Bullet Points. Erklär mir mal, wie ich eine Email Kampagne aufsetze. Ich nutze das auch ein bisschen für die Programmierung. Also nicht, dass ich da einen Code erzeuge, den ich dann rüber kopiere. Das noch nicht. Aber ich experimentiere damit rum. Ich glaube, das wird kommen. Ich habe einen Artikel geschrieben letzte Woche. In fünf. Jahren, bis es noch Entwickler gibt. Genau, genau. Habe ich jetzt eine Frage vorgegriffen? Nee, erzähl darüber gerne. Ich habe das mit Begeisterung gelesen. Da habe. Ich behauptet, dass die AI bald auch programmieren wird, weil sie kann es ja jetzt faktisch schon. Sie kann jetzt schon Snippets schreiben und auch beliebiger Programmiersprache. Und warum soll sie nicht in der Lage sein, komplette Applikationen zu schreiben in ein paar Jahren? Und dann brauchst du eigentlich keinen mehr bezahlen dafür, dass der Code schreibt. Da haben wir auch immer noch Leute, die Anforderungen schreiben und sich ein bisschen Konzepte ausdecken, aber du brauchst keinen mehr, der sozusagen da irgendwie neues Formulat tippt oder ein Controller oder Resolver oder eine REST API. Das fällt meines Erachtens weg. Und auf diesem Post gab es sehr, sehr, sehr viele Reaktionen und es hat viele Leute getriggert. Nein, das kann nicht sein, das wird so nicht sein. Wer bist du, dass du sowas sagen kannst?" Also ich habe alle Kommentare beantwortet. Aber es ist interessant. Also Leute finden sich wirklich bedroht in ihrer, ich weiß nicht, Existenz, weiß ich nicht, aber so ein bisschen in ihrem eigenen Wert. Man hat viel in sich selbst investiert, man hat das gelernt, man kann programmieren, man ist so viel wertvoll geworden, man findet leicht einen Job. Und das soll jetzt irgendwann vorbei sein in ein paar Jahren, das glaubt man nicht, das will man einfach nicht. Und das ist ja auch dazu auch geschrieben, es wird ja noch bestimmt einige Legacy Systeme geben, wo vielleicht Chachik Bichner nicht sofort das alles ersetzen kann, aber interessant, weil du ja dann gesagt hast, weil der Punkt hat mich interessiert. Ich habe nicht jeden Kommentar gelesen, aber du hast geschrieben, dass ja zumindestens dann, weil ich mich gefragt habe, wie passt dann Rock Technology da jetzt rein mit euren API Services, die ihr anbietet, um, sag ich mal, wiederverwendbare Komponenten, die viele Leute entwickeln müssen, aber gar nicht zur Core Logik gehören. Da hätte ich in erster Linie gesagt, gut, aber wenn Chat GPT, die Logiken kann doch dann erst recht Chat GPT machen oder nicht? Die, die sozusagen jeder Boilerplate eigentlich schreiben muss und von euch sehr gut entwickelt werden. Die Frage ist ja berechtigt. Die muss sich eigentlich jeder stellen, der Software vertreibt. Also jeder, der Code schreibt, der dann verkauft wird oder als Open Source vertrieben wird, hat ja im Prinzip diese Challenge. Braucht das überhaupt noch jemand? Und ich habe darauf zwei Antworten. Das eine, ich glaube, wenn eine AI einen Code generiert, wäre es eigentlich doof, wenn sie allen Code generiert, sondern sie würde vermutlich versuchen, Funktionen über APIs einzubinden, weil du willst ja jetzt nicht, dass die ganzen, also angenommen, du brauchst ein gutes Chatsystem. Du brauchst jetzt aber nicht den Source Code für das ganze Chat System. Du musst es ja auch spezifisieren. Du musst ja der AI sagen, was du alles können solltest. Du willst ja trotzdem, hast ja Aufwand, das zu beschreiben. Und das wird ja auch sehr, sehr viel Source Code dann, wenn du jetzt praktisch alle Details generierst, die du jetzt generierst. Stell dir vor, du willst einen Shop und das Ding generiert dir den gesamten Shop System Code. Das glaube ich nicht. Ich glaube, auch eine AI wird bestehende Dinge einbinden über API oder Open Source Libraries, die dann irgendwie geladen werden über APM oder so. Das heißt, ich glaube, auch da wird es künftig Nutzen für geben. Punkt eins. Punkt zwei ist, ich habe eigentlich drei Punkte. Punkt zwei ist, AI wird alles Mögliche ändern. Es ist ja nicht mehr gesagt, dass es überhaupt noch Applikationen geben wird. Vielleicht macht man alles mit einem persönlichen Assistent. Vielleicht braucht man gar keine Apps mehr. Wer weiß das schon. Und da hilft es nur als Gründer einfach die Augen offen zu behalten und zu gucken, was da kommt und dann das für sich selbst zu nutzen. Also kann sein, dass man in drei Jahren ein ganz anderes Business macht. Also auch das eigene Geschäft ist ja nicht statisch. Was wir heute machen, auch noch in drei Jahren so ist. Also auch man muss sich einfach mitentwickeln. Man darf auf gar keinen Fall das jetzt verpassen. Also ich glaube, jeder muss jetzt darauf achten, was da kommt und da irgendwie ausprobieren und mitmachen. Man muss kein Experte werden für eine. Man muss keine neuronalen Netzwerke programmieren. Ich glaube, das ist vorbei. Man muss jetzt sich selbst mit den Möglichkeiten von Themen wie Chats GPT mit Journey und so weiter beschäftigen. Man muss es ausprobieren. Wer das jetzt nicht macht, der wird abgehängt. Ich glaube, man muss sich selbst die Erfahrung geben, dass man selbst darüber nachdenken kann und selbst überlegen kann, was man damit jetzt anstellt in seinem Umfeld und ob das auch ein Risiko wird für den eigenen Job. Und Punkt 3 ist, als Gründer, Gründer ist ja immer auch ein bisschen, also du guckst natürlich voraus in Zukunft, was da kommt, aber im Endeffekt baust du ein Business auf für einen Markt, der heute existiert. Weil es macht ja keinen Sinn, ein Business zu bauen für einen Markt, der vielleicht in drei, vier Jahren kommt. Es ist ja nicht, man baut was riesengroßes oder so und hat irgendwie 500 Millionen Funding, das ist was anderes, aber wenn man sagt, man will irgendwie in den nächsten Monaten Geld verdienen, dann muss das ja jetzt funktionieren. Und zu sagen, ich mache das jetzt nicht, weil ja vielleicht in der Zukunft XYZ passiert, das wäre dumm. Da könnte man auch gleich aufhören, weil man könnte ja auch, wer weiß, was morgen in der Welt so passiert, das ist. Also ich glaube, irgendwie Angst zu haben oder so oder irgendwas unterlassen, das macht gar keinen Sinn. Ja, aber es ist auf jeden Fall auch, was du gesagt hast, dass du sagst, die AI wird ja wahrscheinlich trotzdem wahrscheinlich irgendwie APIs nutzen, damit nicht jeder den Source Code sozusagen selbst. Ich meine, das ist auch die Frage, gerade auch das Hosting und sowas werde ich mich wahrscheinlich mittelfristig dann trotzdem noch selbst irgendwie kümmern müssen. Wie kommt der Code jetzt wirklich in Production so oder macht das die Manatee? Natürlich macht das die AI. Also die AI ist ja... Also das ZGPT ist ja aktuell Das ist ja nicht verbunden mit irgendwas, das kann ja nichts ausführen, aber das wird ausführen können. Und das pusht den Code dann einfach auf Wurzel oder auf... Wo auch immer hin, das ist egal. Also natürlich wird das kommen. Aber man darf nicht einfach den Kurzlaufen bringen, das ist dann einfach da. Da machst du dir keinen Kopf mehr. Es ist halt die Frage, wenn aber dann zum Beispiel viele schon mal ausspezifiziert haben, wie ein Chat zu funktionieren hat, warum sollte sich dann die AIB, wenn sie sagt, ich hätte gerne ein Chat, also mein System soll einen Chat haben, warum sollte es dann in dem Zuge die API sein, wenn es vorher schon hundertfach spezifiziert wurde, sie eigentlich weiß, was im Chat funktioniert und was dann ähnliche Funktionalitäten hat wie das Produkt, was ihr dann anbietet, dann kann sie doch auch den Code einfach auch noch irgendwo mit hin pushen und das Chat System einfach selbst hosten, wenn die Spezifikation von Chat sich wahrscheinlich gar nicht so groß unterscheiden wird. Ja, das kann, also das könnte sein. Andererseits entsteht dadurch auch viel Sourcecode, die dann die AI wieder selbst verwalten muss. Du kannst ja diesen generierten Sourcecode nicht anfassen, sondern der wird ja von der AI verwaltet, das heißt, der sollte idealerweise möglichst klein sein. Ja, die AI hat ihren eigenen API Service. Die weiß, alle wollen Chat, ich hoste einen Chat Service, den meinen Chat Service, den wir alle nutzen. Aber also, wir werden sehen. Ich glaube, das ist ganz wichtig. Also die Annahmen, die wir heute treffen, die gelten schon für heute und man kann sie ein bisschen in Zukunft schauen, aber ich glaube, man kann nichts heute bauen, was für eine ungefähre Zukunft gilt. Das ist nicht möglich. Aber ja, ich glaube, das gilt für jeden Job. Man muss schauen, was kommt da auf uns zu und wie stört man sich auf. Auf jeden Fall. Ich glaube, mit der These gehen wir auch komplett mit. Ich glaube, es passt ganz gut, dass wir, Dennis und ich, morgen geht es bei uns in der Firma los, wir haben drei Tage lang Game Jam, wo wir Spiele entwickeln und mit der Prämisse, wir müssen irgendwie AI einbinden. Also was kann AI für uns tun und was können wir mit den Tools jetzt bauen, was vielleicht vorher noch gar nicht ging oder Prozesse vereinfacht, Ideen möglich macht, die jetzt schon möglich sind, die vorher für uns nicht möglich waren mit einem kleinen Team. Deswegen, also da gehe ich komplett auf jeden Fall mit. Es wird sich verändern. Wie, wird auf jeden Fall spannend. Auf jeden Fall, dein Beitrag, den du da bei LinkedIn, also Ich habe ihn bei LinkedIn gelesen, da ist auch da, wo er auch veranstaltet hat, den verlinken wir auch nochmal. Fand ich sehr interessant. Sehr interessante Anstöße. Wollen wir nochmal die letzten Minuten so ein bisschen nehmen, um, wir kommen immer sehr spät dazu, und auf Rock Technology nochmal einzugehen. Wie, du hast vorhin den kurzen Ausflug ins Jahr 2020 gemacht, wo du dein halbjähriges Studium eingeschlagen hast und dich dann mit vielen Programmiersprachen beschäftigt hast, unter anderem JavaScript und Node. Und wie kam es denn dazu, von dieser Pause, die du hattest, hin zu der Neugründung von Rock Technology? Ich habe in dieser Pause ein bisschen überlegt, was mache ich als Nächstes? Ich war damals bei Spiker raus, ich war nach Spiker nochmals als Filianz unterwegs, bei der Metro AG eine Zeit lang und habe danach gesagt, jetzt wird sich hier was gründen, es muss was Neues kommen. Aber ich hatte keine Geschäftsidee. Ich bin dann eine Zeit lang zurückgegangen zu Rocket Internet und habe mich da einfach mit reingesetzt ins Büro und habe dann gemeinsam mit dem Team von Flash, das ist der Inkubator, wie ich siehe, von Rocket Internet, und habe dann gemeinsam einfach Geschäftsideen iteriert, durchprobiert und alles Mögliche, sowas wie Nachrichten, eine gemeinsame Inbox für Handwerker haben wir uns überlegt, das ist eine Geschäftsidee oder diverse andere Geschäftsideen. Und als Softwareentwickler habe ich mir überlegt, wie würdest du das jetzt bauen und dann habe ich sozusagen geguckt, na gut, dann nimmst du dir was Fertiges und sowas wie ein Shopsystem, nur halt für Sars, ein Sars System. Da muss doch irgendwas Fertiges geben. Und da gab es nichts. Also da gab es die NoCode Plattform, so etwas wie Bubble.io, wo man sich so zusammen klickern kann. Aber das fand ich nicht spannend als Entwickler. Ich will ja schon selbst den Source Code haben. Ich will das schon selbst frei bestimmen können. Ich will mich nicht einengen lassen von so einem System. Und danach, wenn man die No Code Systeme ausschließt, dann ist ja nicht mehr viel. Also die meisten Software Service Projekte werden vom Scratch gebaut. Da geht einer hin und sucht sich eine Programmiersprache aus und ein Framework und ein Frontend Framework, und ein Backend Framework, und ein Datenbanksystem und dann wird das halt alles gebaut. Dann baut jemand ein Loginformular und eine Order Confirmation Email und eine Anbindung an Centroid und ein Notification System und so weiter. Das wird alles vom Scratch gebaut. Das passiert immer noch sehr häufig. Und da habe ich überlegt, na gut, wenn Leute so viel Zeit verschwenden, immer dieselben Grundfunktualitäten, dann müsste man das doch mal irgendwie produktifizieren. Und da hat gesagt, okay, offensichtlich ist mein Geschäftsidee nicht, dass ich jetzt selbst Software as a Service baue, sondern ich baue ein Grundlagensystem für Software as a Service. Und das war dann die Geschäftsidee. Und das, wie sagt mein Mitgründer, Tim Niemeyer ist dann auch sofort draufgesprungen und hat gesagt, die Idee ist super, die machen wir gemeinsam, gucken wir uns den Markt an und dann haben wir gemeinsam sehr, sehr lange Interviews geführt, mit Leuten gesprochen. Macht das Sinn? Wie könnte sowas technisch aussehen? Wie könnte man sowas vertreiben? Welche Value Proposition könnte man da mit abbringen und das...... Und das Ganze mündete dann in einer relativ großen Finanzierungsrunde, Seedrunde. Das war so zu Corona Hochzeiten, als noch viel Geld im Markt war, haben wir dann eine relativ große Runde gemacht...... Und...... Ja und so lief das Ganze an. Das hat sich alles so ein bisschen ergeben...... Also es war nicht so, dass das irgendwie...... Das hat sich alles ergeben, also es ist kein...... Ist jetzt gar keine spannende Gründerstory...... Das hat sich alles so irgendwie so...... Gefügt. Okay, cool. Wie viele Leute, also welche Größe...... Hat das, dieses System, das er jetzt gebaut hat...... Wie viele Leute haben das erstellt? Aufweder 20. Also ich finde so Teamgröße 20 ist so ideale IT Größe. Wenn es mehr Leute werden, wird es unübersichtlich. Und mit viel weniger hat das System, das ihr gebaut habt, erstellt? Das ist die ideale Größe, also inklusive Product Owner usw. Und wir haben uns Zeit gelassen, das zu bauen. Wir haben das initial gebaut, wie ein Shop System, also als Kickstarter konzipiert, also so ein System, was man praktisch alles Mögliche kann. Das sollte man dann klonen und dann darauf sein eigenes Projekt bauen. Und diese Idee, die ja leider nicht funktioniert, die haben wir auch wieder verworfen im Markt, weil die Leute hatten das cool. Hey, da ist so ein Software Service Boilerplate, darauf kann ich aufbauen. Aber das ist ja opinionated, das ist dann schon mit React und Next.js und Node.js und Postgres kommt das. Und viele Entwickler wollten sich das nicht vorschreiben lassen, was sie einsetzen. Die haben gesagt, sie finden das super, wollen aber gerne Backend Ruby nehmen. Oder sie wollen lieber Vue.js, das React nehmen. Und das heißt, die Idee, wie so ein Shop System zu arbeiten, also so ein SaaS System, so ein Vorlagensystem, das haben wir dann wieder verworfen. Und haben gesagt, na gut, darum machen wir jetzt UI Komponenten. Also wir haben dann praktisch unsere ganzen Logiken in React Komponenten verpackt. Die sehen hübsch aus, die kann man mit CSS customisieren, und sind aber auch voll funktionsfüchtig. Also unser Notification System zeigt Notifications an in real time. Hat eine socket connection und zeigt dann Notifications an. Der Chat funktioniert auch wirklich als Chat. Login funktioniert als Login und so weiter. Also lauter wieder UI Komponenten in React mit unserer API verbunden. Und damit sind wir praktisch jetzt agnostisch, was das Zielsystem angeht. Man kann es in jede beliebige Web Applikation integrieren, egal was da für Programmiersprachen auf. Wir sind aktuell auch auf React gebunden. Das ist meine nächste Challenge. Wie kann man das jetzt praktisch auch für Leute verfügbar machen, die Vue.js nehmen oder Angular oder Svelte oder Quick oder was auch immer. Da gibt es zum Glück ein Framework. Das nennt sich Minosis, glaube ich. Damit kann man in einer React ähnlichen Sprache die Komponenten schreiben und die dann praktisch umkompilieren in die verschiedenen UI Libraries. Das ist ziemlich cool. Das ist so der nächste Challenge, den man lösen muss. Also wie baut man so eine Komponentensammlung so, dass die jeder verwenden kann, ohne dass man sagen muss, du musst jetzt React verwenden. Und ja, das machen wir. Und das kommt gut an. Also das zieht. Die Leute finden es cool. Es gibt einen direkten Mehrwert. Und ja, das. Und das heißt aber, ich nutze einerseits die Komponenten, die dann sozusagen alle Logik schon mit drin haben, um mit eurem Backend zu sprechen. Aber wenn ich es jetzt richtig verstehe, ihr habt Authentication und User Management ja auch drin und du hast ja mein GraphQL Das heißt, wenn ich auf diese Daten zugreifen will, am Ende habe ich auch die API, die ich entweder über mein Backend angehen kann oder auch im Client, falls ich das möchte oder so. Aber so die Interaktion dann mit den Daten ist dann wirklich immer über die API, also auf diese Postgres Instanz, die ist alles bei euch gehorsam. Ich habe niemals keinen direkten Datenbankzugriff mehr, sondern das ist immer API getrieben. Ihr stellt euch dann einen Service dahin, mit dem ich interagiere. Richtig, richtig. Die Beobachtung ist halt, dass du, wenn du eine Software Service Applikation brauchst oder ein Portal, dann verbrauchst du halt ein Drittel bis die Hälfte Zeit für diese grundsätzlichen Features, die dir gar keine Mehrwert bringen, weil die hat ja jeder. Die brauchst du, damit es professionell aussieht, aber die helfen dir noch nicht weiter. Du brauchst dein eigenes Geschäftsmodell. Du musst dein eigenes, praktisch das, was dich ausmacht, deine Flot Management Lösung oder dein, keine Ahnung, dein Delivery Service, was du halt dann, deine eigene Geschäftslogik, die musst du programmieren und nicht irgendwie Zeit verschwenden mit einem Passwort vergessen Funktionalität, weil das kannst du dir einfach so integrieren. Das gibt es schon fertig. Und bei uns gibt es und unser Value Add ist, dass es alle Features aus einer Hand kommen. Also all diese Grunddingen, Features. Und du dich darauf fokussieren kannst, du kannst eine sehr leichtgewichtige Applikation bauen. Wir geben auch einen Kickstarter raus für neue Applikationen. Und du musst dich halt nicht mit diesen Grundlagensachen rumschlagen. Das ist so der Grundpitch. Und wir gehen immer weiter. Wir bauen jetzt auch Access Management, dass wir praktisch sagen, du kannst in deiner eigenen Applikation Multitenancy realisieren, du kannst die Zugriffe, die Permissions setzen, die Rollen setzen und so weiter. Und das sind so Funktionalitäten, die du halt sonst selbst programmieren musst. Und dir das System auch unsicher machen, wenn du das nicht professionell einkaufst. Das Team mit dem du das aufgebaut hast, weil du hast ja gesagt, du hast dich jetzt sozusagen weitergebildet in der Zeit, in 2020 und hast dann technologisch umgeschwenkt und jetzt hast du eine 20 köpfige Mannschaft dort. Also waren das auch Leute, die du kanntest von vorher aus der PHP Zeit, die dann mit dir den Switch gemacht haben? Hast du explizit Leute eingestellt, die das Knowhow dann hatten in den Technologien oder wie hast du dein Technologieteam gestafft? Ja, also Leute, mit denen ich vorher gearbeitet habe, die kann ich ja nicht angehen, weil die arbeiten ja bei Firmen, wo ich vorher war. Und das verbietet sich sozusagen. Plus, die sind auch sehr happy. Also die Leute, die bei Spriker arbeiten, die sind sehr, sehr happy. Die wollen da nicht weg. Und das wäre auch nicht akzeptabel, dass ich da irgendwelche Leute anspreche. Insofern muss ich das Team neu aufbauen. Und dadurch, dass die Programmiersprache eh anders war, machte das auch Sinn. Wir haben die Firma während Corona gegründet. Wir hatten gar kein Büro am Anfang. Wir haben jetzt ein neues Büro seit letzter Woche, aber vorher war das eine Remote Firma. Und entsprechend haben wir auch die Entwickler komplett remote gestuft. Wir hatten ursprünglich gar keinen Entwickler in Deutschland. Das Team sitzt immer noch weit verstreut. Wir haben jetzt inzwischen einen VP Engineering, der kommt aus Bangalore. Den haben wir inzwischen hier bei uns mit der Blue Card. Unser Lead Architect, der kommt aus der Nähe von Kiew. Den haben wir rübergeholt, bevor der Krieg begonnen hat. Das war uns dann doch ein bisschen unsicher. Aber ansonsten sind die Leute immer noch weit verstreut. Das Team sitzt immer noch weit verstreut. Dazu eine kleine Anekdote. Wir hatten einigen Leuten das Angebot gemacht, rüber zu kommen. Kommt auch nach Deutschland. Hier gibt es eine Bluecard, hier ist es schön. Und das wollten die nicht. Früher wollten das immer alle. Also so vor fünf bis zehn Jahren war das normal. Wenn du jemanden geheilt hast, irgendwie in Pakistan, dann war das klar, dass der eigentlich zu uns kommen will. Und das wollen die gar nicht mehr, die Leute. Weil das Einkommen hat sich jetzt gerade während Corona so ein bisschen ausgeglichen. Also die Entwickler in Indonesien, Indien, Pakistan, auch in Afrika, die verdienen jetzt auch nicht mehr viel weniger als hier. Die sind immer noch günstiger für uns, weil du keine Nebenkosten hast, aber es ist nicht mehr irgendwie, dass du jemanden kriegst für 500 Dollar im Monat, der einen guten Code schreibt. Das kannst du vergessen. Die Leute sind auch teuer und die haben häufig mehr Netto als in Deutschland, weil keine Zahlbeziehungsbeiträge und so weiter. Das heißt, die leben dann dort sehr, sehr gut und die wollen ja nicht nach Deutschland kommen. Das ist gar nicht mehr attraktiv. Also auch das ist eine interessante Beobachtung. Die Leute wollen gerne da bleiben, wo sie sind. Und das funktioniert auch ausgesprochen gut. Also es ist eigentlich egal, wo Leute sind, es gibt gar keine Unterschiede mehr. Also in der Qualität sowieso nicht. Leute sind genauso gut wie deutsche Entwickler oder europäische Entwickler. Es gibt keinen Unterschied mehr. Die Kultur hat sich auch angeglichen. Und das Einzige, was ein bisschen stört, das sind vielleicht Zeitzonen, aber das ist nicht unser Problem. Das ist eher das Problem von den Leuten. Man muss ein bisschen darauf achten, wenn man ein Team aufbaut, sollte man nur in eine Richtung heiern. Also wir haben uns für Osten entschieden. Also alle östlich von uns. Und wir haben darauf verzichtet, Leute westlich von uns zu heiern. Also keine in Südamerika zum Beispiel. Weil dann die Zeitunterschiede zu groß werden. Aber wenn wir sagen, jemand ist, weiß ich nicht, 8 Stunden Zeitunterschied oder 6 Stunden Zeitunterschied, dann muss derjenige halt einfach spät anfangen zu arbeiten und arbeitet ein bisschen länger und das geht dann auch gut. Damit man so ein bisschen Überlappung hat. Also Überlappung muss jetzt nicht den ganzen Tag sein, aber so ein bisschen sollte man schon haben, sonst sieht man die ja gar nicht. Und darauf haben wir geachtet und das funktioniert sehr gut. Also ich vermisse praktisch diese Rückkehr zu allen Entwicklern in einem Raum und Meetings und so, das vermisse ich überhaupt nicht. Das macht viel, viel mehr Sinn so, wenn jeder dort in seiner Wohlfühlatmosphäre arbeitet. Keiner muss mehr irgendwie jeden Tag rumfahren. Und die Anzahl Entwickler, die man rekrutieren kann, ist auch viel, viel größer jetzt. Also es ist Faktor 1000 größerer Markt, als wenn man sagt, Leute müssen in Berlin sitzen. Plus es gibt in Berlin gar keine Wohnung mehr. Also auch wenn man jemand hätte, der herkommen will, der findet ja nichts mehr. Also es klappt einfach. Ich glaube, das wird nie wieder kommen. Warum habt ihr jetzt ein Büro? Wir haben jetzt ein Büro. Das ist ein kleines Büro, das ist sozusagen für die Führung der Firma, wir sind jetzt praktisch aus der Bauphase raus, kommen jetzt in die Go to Market Phase und da muss man halt viel miteinander sprechen. Und das ist einfach, glaube ich, nicht mehr die Zeit, wo es darum geht, Sachen abzuarbeiten. Jetzt setze ich mich also in den Laptop und tagge mal was runter, acht schon. Jetzt ist die Zeit, wo es darum geht, kreativ zu sein, vielleicht mal einen Spaziergang zu machen. Vielleicht mal doch am Whiteboard arbeiten. Einfach um zu überlegen, was machen wir als nächstes? Welchen Kanal probieren wir aus? Welche Märsche probieren wir aus? Und das geht tatsächlich doch am besten, wenn man im selben Raum sitzt. Aber wir sind immer noch eine Remote Company, also ich komme jetzt nicht jeden Tag ins Büro, so ist das nicht. Aber trotzdem schlimm. Wenn man gar kein Headquarter hat, ist das schon doch ein bisschen, weiß ich nicht, also eine Firma braucht schon so ein bisschen Platz. Aber wir hätten keine Räumlichkeiten, um alle unsere Mitarbeiter unterzukriegen, das wäre nicht möglich. Und es gibt auch kein Szenario, dass alle letztendlich kommen. Das geht gar nicht. Fabi, hast du noch was? Ja, also ich könnte wahrscheinlich noch ewig weiterfragen, aber wenn ich mal ein bisschen auf die Zeit blicke, ich fand das eigentlich jetzt gerade einen schönen Abschluss dafür. An Fragen würde es nicht noch mangeln, aber eher an der Zeit, die wir dafür noch aufwenden. Das ist richtig. So geht es mir auch. Von daher eher vielleicht noch an dich, Fabian, die Frage, gibt es noch etwas, was du gerne losgeworden wärst in diesem Gespräch, wo wir nicht zugekommen sind? Ich glaube, wir haben alle Themen soweit abgehandelt. Wir haben auch über AI gesprochen, das hat mich gefreut. Mein Hobbythema gerade, ich bin mega gespannt. Ich bin zufrieden. Ich glaube, wir haben alle Checks dran. Hat Spaß gemacht, mit euch zu reden. Vielen Dank, dass du die Zeit gefunden hast. Und an unsere Hörer*innen, wie immer die Bitte, schreibt uns gerne Feedback zu dieser und anderen Folgen entweder an Podcast@programmierbar oder über unsere Webseite, wo auch immer ihr mögt. Da freuen wir uns immer riesig drüber. Sonst habt eine gute Zeit und. Bis. Bald. Macht es gut. Ciao. Ciao.