"Am Ende musst du sicherstellen, dass du Technologie hast, die dein Business maximal unterstützt. Das heißt nicht nur Server, Programmiersprache und Applikationen, sondern auch Prozesse, Hiring und Organisationen."

"Engineering for the sake of Engineering – ich halte das für die größte Gefahr. Wir Engineers leben das, auf Teil 17 runterzugehen, geile technische Lösungen zu bauen, und dann sterben wir in Schönheit."

"In dem Moment, wo jemand sagt, ich will ein Scalable Business, ist meine erste Frage: Wo ist das Org-Chart? Infrastruktur ist easy. Die Kunst ist herauszufinden, was braucht man wirklich, um maximalen Benefit für die Firma zu schaffen."

"Ich habe immer wieder gesehen, dass Gründer mit einem Drei-Personen-Team anfangen und dann 50 Microservices bauen. Dann erstickst du jegliche Innovation, weil du nur noch damit beschäftigt bist, deine Services zu maintainen."

"Der klassische Fehler: 'Hey, wir haben nicht viel Geld, lass uns Juniors und Praktikanten reinholen.' Drei Jahre später guckst du in die Firma und weißt genau, wer das gebaut hat. Dann fängst du an, noch drei Jahre aufzuräumen."

"Am Anfang hole ich mir gerne Leute, die ein bisschen wild unterwegs sind – Cowboy-Style, Delivery, Delivery, Delivery. Aber die müssen auch wissen, was sie tun."

"Wenn die Pipeline kaputt ist, wie schnell wird das gefixt? Der Klassiker: Vor dem Mittagessen geht die Pipeline kaputt, alle gehen erstmal zum Mittagessen. Bei mir ist das komplett Meltdown."

"In einem Portfolio-Unternehmen dauerte das Deployment eine Stunde. Der Entwickler drückte den Knopf, ging zum Mittagessen, kam wieder und schaute: durchgelaufen oder kaputt. Bei 40 Leuten im Team kannst du maximal zehnmal pro Tag deployen – das reicht nicht."

"Du nimmst einen komplexen Prozess und machst das erstmal manuell mit einem Auto. Dann mit 10 Autos. Dann kommt 10X, 100X, 1000X. Ich stelle mir das vor wie einen Tunnel bohren: Erstmal ein kleines Löchlein mit einem Laser, nicht sofort mit dem Diamantenbohrer, der Millionen Euro pro Tag kostet."

"Die meisten Projekte schaffen es niemals, die Skalierung zu erreichen, weil es gar nicht notwendig ist. Wir denken immer, wir müssen diese Durchsätze erreichen. Am Ende realisierst du: brauchst du gar nicht."

"Würde ich mir eine Kuh kaufen, um selber meinen eigenen Käse herzustellen? Die Value Chain ist ein bisschen lang. Am Ende: Headless CMS – wie viele gibt es auf dem Markt? 100. Wie viele sind mir bekannt? 5. Why not?"

"Core ist das, wofür mich meine Kunden bezahlen. Kontext ist alles drumherum. Bezahlen mich meine Kunden dafür, dass ich das beste CMS habe? Wahrscheinlich nicht. Das kaufe ich ein. Wo habe ich die wirkliche Wertschöpfung? Das baue ich selber."

"Schulden sind Probleme, die du nicht abbezahlst. Wenn du Schulden aufnehmen kannst mit 3% Interest Rates und hast 20% Marge – do it. Und dann sorg dafür, dass du die schnell abbezahlst."

“Mein Credo war immer: Ich muss meinen Junior-Entwickler nachts um drei anrufen können und fragen: Was ist unsere Mission, Vision und wie zahlt das, was du gerade tust, darauf ein? Wenn die Leute das können, hast du es richtig gemacht."

"Das wird gebetsmühlenartig wiederholt. Das kannst du nicht überkommunizieren. Vor allem auch in den Leadership-Teams – alle zwei Wochen und dann in den One-on-Ones: Wie haben wir jetzt darauf eingezahlt?"

"Am Anfang hast du diese Cowboy-Style-Leute. Dann kommen die Prozesse, Leute die mehr Struktur brauchen – die sind essential für deinen Ramp-up. Diese Transition-Phase, da wird einmal die Suppe gedreht. Da muss man höllisch fokussiert sein als C-Level."

"Bei 15, 50 (Mitarbeitenden) und weiteren Schwellen sind es immer Knackpunkte. Wenn du in diese Größen kommst, musst du die nächste Iteration deines Organisationsmodells gehen."