Stephan Schmidt, CTO bei Eventsofa

Stephan teilt mit uns seine Erfahrungen als CTO bei ImmobilienScout24 und eBay und erläutert, was heutzutage einen guten CTO auszeichnet. Außerdem erklärt er, warum er die PST-Methode für die Produktmanagement-Methode der Zukunft hält.

Anfang Juli treffe ich mich mit Stephan in seinem Lieblingscafé “19grams” in Berlin Mitte, direkt gegenüber des opulenten Neubaus des Bundesnachrichtendienstes. Obwohl Stephan aktuell für Eventsofa entwickelt, geht es bei dem Interview des  Ex-CTO von eBay und ImmoScout24, eher um das große Ganze, statt um sein aktuelles Entwicklerteam. In welche Richtung genau das Interview gehen wird, wissen wir noch nicht, als wir uns einen Kaffee bestellen. Eine Frage, die ich in fast jedem Interview mit Entwicklern stelle, ist die, wie man zum Programmieren kam. Stephans Antwort überrascht mich.

Hallo Stephan, wie hast du Programmieren gelernt?

Ich habe im Kaufhaus Programmieren gelernt. Damals, ich schätze 1982, waren Computer super teuer. Es gab nur wenige Computer und auch wenig Zubehör. Als Zehnjähriger war ich oft im Kaufhaus und da standen andere Kiddies und programmierten. Ich habe zugeschaut und mir etwas abgeguckt und einfach ausprobiert. Zum Beispiel haben wir Farben durchlaufen lassen oder Sound nach einer Warteschleife abgespielt. Die Verkäufer wussten natürlich nicht, wie man das ausschaltet.

Was war dein erster eigener Computer?

Ein Schneider CPC, den ich mir durch Ferienjobs zusammengespart hatte. Damit habe ich viel programmiert. Heute nutze ich einen iMac.

1. Über die Notwendigkeit ein Tech-Unternehmen zu sein

Zum Farben durchlaufen lassen reichts. Oder was machst du heute damit?

Aktuell bin ich Interims-CTO bei Eventsofa. Das ist die Firma meiner Frau. Wenn ich gerade nichts anderes zu tun habe, dann programmiere ich die Webseite.

Grundsätzlich mache ich das, was mir Spaß macht. Ich sehe mich als Helfer. Ich helfe unterschiedlichen Firmen, am liebsten Startups, mit ihren Technik-Herausforderungen. Oft sind das CEOs, die ihre Technik nicht verstehen. Da heißt es dann: Stephan, schau mal da drauf und sag mir, ob die das alles richtig machen. Oder meine Aufgabe ist es Leuten außerhalb von Tech das Programmieren beizubringen, damit sie Tech besser verstehen und bessere Entscheidungen treffen können. Der Ursprung davon war, dass ich bei brands4Friends den vielen CEOs immer wieder Tech erklären musste. Mit dem Slide-Deck, das ich zu diesem Zweck angefertigt hatte, konnte ich dann auch ein paar Vorträge auf Konferenzen halten. Daraus ist dann “Coding für Manager” entstanden, ein Workshop, meist für größere Firmen, welche ein bisschen mit dem Rücken zur Wand stehen, und die fast alles machen, um etwas technikaffiner zu werden.

Außerdem mache ich M&As wenn ein Investor eine Firma kauft und sie wollen, dass ich mir die Firma anschaue und mich zu deren Status äußere.

Warum ist es wichtig dem C-Level programmieren beizubringen? Mehr wie ein “Hello World” bekommen sie nach einem Tag doch sowieso nicht hin. Was hat sich geändert?

Heute sind alle Unternehmen Tech-Firmen. Früher war IT und Tech ein Cost-Center und spielte eine ganz andere Rolle. Wenn man sich die Entwicklung der IT anschaut, dann wissen wir seit circa 15 bis 20 Jahren, wie Programmieren im Anwendungsbereich funktioniert. Davor wussten wir das eigentlich nicht. Als ich an der Uni war, gab es viele Prozesse, wie den Rational Unified Process, mit sehr vielen Dokumenten und Prozessschritten. Am Ende hat das aber nicht funktioniert, weil man zwar irgendwann etwas lieferte — aber das wollte halt keiner. Dann kam das Extreme Programming auf und dann kam auch schon Agile und hat alles transformiert. Mit dem Internet hat sich diese Entwicklung beschleunigt.

Die agile Entwicklung gab es schon vor dem Internet?

Ich glaube das hat sich parallel entwickelt. Mitte der 90er kam das Internet im großen Stil, wobei das erst mal aus IRC Chats bestand und auch erst mal nur an den Unis. Internet und Agile hat letztlich dazu geführt, dass man anfing ergebnisorientierter zu programmieren. Seit dem geht es auch schneller. Heute versucht man Software zu bauen, die funktioniert. Und das bedeutet nicht, dass die keine Bugs mehr hat. Sondern sie wird genutzt, und der Kunde findet sie toll.

Die Transformation durch Agile und dem Internet hat dazu geführt, dass letztlich alle Unternehmen Tech-Firmen sind.

Es hat eine kopernikanische Wende stattgefunden. Die Erde dreht sich um die Sonne und nicht andersherum. Business dreht sich heute um Tech und Product und nicht Tech um Business wie früher. Und die Unternehmen, bei denen das immer noch so ist, sind nicht schnell genug und verlieren den Anschluss.

Welche Firmen sind das zum Beispiel?

Nokia zum Beispiel. Nokia war zwar eine Hardware-Firma, aber eben kein Softwareunternehmen. Apple ist zum Beispiel ein Softwareunternehmen. Die Hardware ist bei Apple ein Hygiene- und Branch-Faktor. Der springende Punkt ist: Ein super designtes Nokia-Fon hätte keiner gekauft, da es keine Apps dafür gegeben hätte. Es hätte dafür keine Software, und die dafür nötige Infrastruktur gegeben. Und das ist eine Tech-Schwäche.

Ein anderes Beispiel ist Nikon. Eine exzellente Firma, die bislang mit exzellenten Hardware-Engineers tolle Kameras gebaut hat. Aber die Software ist super schlecht. Sie haben zum Beispiel keinen Autofokus mit Gesichtserkennung, die Ratings im Appstore sind mies. Nikon geht meiner Meinung nach gerade den Nokia-Weg. Gerüchten zufolge ist Quelle unter anderem Pleite gegangen, weil sie ein altes Mainframe-System hatten, was sie nicht auf den aktuellen Stand bekommen haben, um zum Beispiel eine Sendungsverfolgung zu ermöglich.

Im Gegensatz zur Otto Gruppe, die gerade ganz gut abliefert.

Ja, sie versuchen sich als Tech-Konzern zu definieren, machen vieles richtig, haben Tech-Töchter und sind im Kern tech-getrieben. Die Frage ist natürlich, ob sie langfristig eine Chance gegen Amazon haben. Grundsätzlich haben sie aber die besten Chancen, da sie den Wandel vom Business-Unternehmen zum Tech-Unternehmen bewältigt haben.

2. Die Rolle des CTOs und die Beziehung zwischen Tech und Product

Welche Rolle spielt die Art der Technologie? Muss heute alles React und NodeJS sein?

Es ist total wurscht welche Software man verwendet. Es gibt eine Bandbreite von Technologien, die man problemlos einsetzen kann. Fortran zu verwenden wäre jetzt eher keine gute Idee. Und C ist für eine Webseite im Internet auch nicht klug. Aber ob das jetzt PHP, Ruby oder NodeJS ist, spielt keine Rolle. Auch bei den Datenbanken spielt das erst einmal keine Rolle. Denn im Prinzip machen 90 Prozent der Firmen in Berlin ein Frontend für eine Datenbank. Das muss man auch mal sehen: Das ist ja kein Rocket Science. Was mich zu dem Problem führt, dass ich sehr häufig angesprochen werde, ob ich nicht schon wieder der CTO für eine Firma sein will, die ein Frontend für eine Datenbank baut.

90 Prozent der Firmen in Berlin brauchen ein Frontend für eine Datenbank.

Wichtig ist, dass Technologie Business unterstützt. Nur durch Tech kann Business seine Ziele erreichen. Das ist wichtig, weil die CEOs oft wenig Ahnung von Tech haben. Zumindest in Deutschland. In Amerika ist das ein bisschen anders. In Deutschland haben wir viele Business-Gründer, die wenig Erfahrung mit Tech haben. Die stellen dann einen CTO ein und der ist of nicht ausreichend Executive, sondern Nerd. Dadurch gerät der CEO in die Opferrolle, weil er nicht steuern kann, wovon er keine Ahnung hat. Dann passiert es, dass Technologien gewechselt werden, weil wir eine Lebenslauf-driven-Industry haben. Wenn wir von PHP auf Ruby on Rails umsteigen, dann kann ich ein weiteres Keyword meinem Lebenslauf hinzufügen. Da geht es oft mehr um Selbstverwirklichung, als um den Nutzen. Das kostet viel, bringt dem Business aber gar nichts.

Wann lohnt es sich die Technologie zu tauschen?

Es gibt echte Argumente, Technologie zu tauschen. Ich habe in der Vergangenheit immer wieder Technologien getauscht. Wenn einem eine neue Technik einen wirklichen Business-Vorsprung verschafft oder man mit einer Technologie an eine Skalierungsmauer fährt, lohnt es sich, die Technologie zu tauschen. Dabei habe ich früher immer alles selber entschieden, weil ich dachte, ich bin der Beste, habe die meisten Erfahrungen und kenne mich aus. Oft kennt man aber als CTO nicht alle Details und Rahmenbedingungen der Anwendung. Dann trifft man leicht die falschen Technik-Entscheidungen. Seitdem pushe ich Entscheidungen zu den Entwicklern weiter.

Was zeichnet einen guten CTO aus?

Ein guter CTO verantwortet Tech-Entscheidungen, aber trifft sie nicht. So ein Software-Stack ist oft unglaublich kompliziert, hat hunderttausende Lines of Code. Als CTO hat man ein vereinfachtes Bild der Realität. Trifft man Entscheidungen aus dieser Perspektive, bildet es bestimmte Probleme einfach nicht ab. Deswegen ist es sinnvoller wenn ein Senior-Entwickler oder ein Counsellor der Senior-Entwickler die Entscheidungen trifft. Als Mitglied des Managements hat der CTO die Aufgabe, zwischen Business und Tech zu vermitteln und mit einem Bein in jedem Bereich zu stehen. Als Manager hat man die Aufgabe, die Leute zu unterstützen, die die echte Arbeit leisten. Das ist ein Netz, das man zu pflegen hat. Der Teamleiter unterstützt die Programmierer, die Abteilungsleiter unterstützen die Teamleiter und der CTO unterstützt die Abteilungsleiter und versucht sie zusätzlich mit dem zu alignen, was Business will.

Das heißt, wenn die Abteilung Lust hat ein weiteres Keyword ihrem Lebenslauf hinzuzufügen, dann setzen sie das durch. Oder sie sind halt weg.

Das ist ein wichtiger Aspekt. Darum fassen CEOs und CTOs Tech oft mit Samthandschuhen an. Denn der Entwickler kann natürlich Forderungen stellen, manchmal auch nur unterschwellig.

Wie sieht die optimale Beziehung zwischen Tech und Business aus?

Ich bin ein großer Fan davon, Tech und Product an eine Person zu hängen, als Chief Technology Product Officer. Das ist nicht für alle das Richtige, aber es ist oft das Richtige. Denn die Frage ist, wen der CEO am Tisch haben will. Wenn Product und Tech getrennt sind, dann ist das ein Dreierverhältnis, bei dem der CEO nicht wirklich weiß, was er mit Tech besprechen soll. Wenn es nicht gerade Rocket Science ist, wie selbstfahrende Autos, sondern eher ein Frontend für eine Datenbank, dann hätte ich als CEO lieber jemanden, mit dem ich über Product reden kann. Das bedeutet aber auch im Umkehrschluss, dass der CPO ein tieferes Verständnis von Tech haben muss, und nicht eine reine Product-Person sein kann. Oder eben umgekehrt.

Ein guter CTO steht mit einem Fuß in Business und einem in Tech.

Die Trennung ist also nicht zwischen Product und Tech, sondern zwischen CEO und Product. Das ist viel effizienter. Dann weiß der CEO auch wie er das managen kann.

Wie realistisch ist es, so eine Person zu bekommen?

Wie realistisch ist es einen guten CTO zu bekommen? Das ist eh schwierig, wenn es jemand sein soll, der ein bisschen Erfahrung hat und nicht in einem Startup ein Programmierer war und dann beschlossen hat der CTO zu sein. Ein Grund, warum es schwierig ist einen guten CTO zu bekommen, ist, weil er nicht richtig gemanagt wird.

Zum Einen wissen die meisten nicht, was Senior eigentlich bedeutet. Wenn ich zu meinen Beratungs-Kunden gehe und sie frage, was Senior ist, dann bekomme ich selten eine gute Antwort, warum der jetzt Teamleiter geworden ist. Mir war immer wichtig, dass Teamleiter oder Senior Developer etwas vom Business verstehen. Er muss Business verstehen und sich mit Business unterhalten können. Zumindest auf einem bestimmten Track. Wenn du Business verstehst, dann kannst du Senior Developer werden, dann Teamleiter und vielleicht sogar CTO. In einem Unternehmen, bei dem es viel Interaktion zwischen Tech und Business gibt, ist es leichter einen guten CTO inhouse zu rekrutieren.

3. Über den optimalen Prozess und PST als Management-Methode

Wie sieht in so einem Umfeld für dich der optimale Entwicklungsprozess aus?

Das hängt immer davon ab, um welche Art von Unternehmen es geht und an welchem Punkt sich das Unternehmen, beziehungsweise die Produktentwicklung, befindet. Die wenigsten Unternehmen sind selbstreflektiv und nutzen den Baukasten und ihre Rolle so, wie es nötig wäre, sondern so, wie sie es schon mal woanders gesehen haben.

Wichtig ist es einen Prozess zu haben, bei dem Leute früh miteinander reden und zum Beispiel mit Paper-Prototyping anfangen. Der Fokus hat sich da heute ja auch Richtung UX-Design verlagert. Simon Wardley hat für mich ein sehr interessantes Produktmanagementmodell ins Spiel gebracht, das in Zukunft eine Rolle spielen wird. Es heißt Pioneer, Settler, Town Planner. Kurz: PST. Die Idee ist, dass es drei wichtige Produktphasen gibt. Die Pioneers sagen: Hier am See ist es toll, hier baue ich mein Haus. Es gibt Fische und Wasser und die Berge sehen hübsch aus. Nach den Pioneers kommen die Settlers. Sie sehen, da ist schon etwas und lassen sich darum nieder. Das Dorf wächst. Ab einer bestimmten Größe kommen die Town Planner. Die schauen, dass die Straßen schön gerade sind und jedes Haus Wasser und Strom hat. Den Pioneers sind das dann schon zu viele Leute und fangen an zu gehen.

Wie muss man sich das konkret in einem Unternehmen vorstellen?

Bei Startups passiert relativ häufig, dass sie mit Pioneers anfangen, viele Settler einstellen aber dann den Fehler machen, zu früh Town Planner einzustellen. Dann gehen die Pioneers und die Innovation ist weg und man weiß nicht, wie es weitergehen soll.

Inkubatoren von großen Firmen machen oft den Fehler, dass die Firmen voller Town Planner sind und man dann ein paar Pioneers dazu steckt. Die können nicht miteinander sprechen und das funktioniert einfach nicht.

Ein Beispiel für eine erfolgreiche Umsetzung könnte das Entdeckungsfeature bei AirBnB sein, ohne dass ich bei der Entwicklung dabei gewesen bin. Dieses Feature wurde eventuell bei einem Design-Thinking-Workshop entwickelt, als die Frage gestellt wurde, wie man Kunden von AirBnB dazu bringen kann, mehr zu buchen. Die Pioneers haben das erste MVP erarbeitet und die Settler kommen in der Scale-Phase ins Spiel, hängen das Marketing dran, Programmieren neue Features, designen es schicker. In der Phase geht es dann auch darum mit dem Marketing herauszufinden, wie man das erfolgreich machen kann. Dann geht es in die Town-Planner-Phase, bei der sich das Marketing etwas verändert und die letzten Prozentpunkte mit A/B-Testing herausgekitzelt werden.

Und das funktioniert?

Ich weiß es nicht. Es gibt leider zu wenige, die es ausprobieren. Aber ich bin ein Fan von diesem Modell. Markus Andrezak, ein befreundeter Produktmanagement-Berater, glaubt, dass die Leute nicht zwischen den Typen wechseln. Es gibt halt diese drei Typen. Und wenn ich als Unternehmen die Leute in den falschen Kontext stecke, dann werden sie kündigen.

Das heißt, in jeder Phase brauche ich ein anderes Team?

Und in jeder Phase gebe ich denen die Tools, die sie brauchen. Ich werde in der Wachstumsphase kein A/B-Testing machen, um die Conversion zu steigern. Das ist eher ein Town-Planner-Ding. Wenn ich ein Verständnis davon habe, welches Produkt in welcher Phase ist, fällt es mir auch leichter Tech- und Product-Entscheidungen zu fällen.

4. Über den persönlichen Werdegang und Altersdiskriminierung

Welche Stationen waren nach dem Kaufhaus-Programmierkurs für dich in deinem Werdegang wichtig?

Mir war nicht immer klar, ob mir ein Informatik-Studium wirklich Spaß machen würde. Letztendlich habe ich ein Studium begonnen und nach dem Vordiplom abgebrochen und angefangen zu arbeiten. Ich wechselte immer wieder die Stellen. Spannend war eine Web-Firma, bei der ich ein virtuelles Labor programmierte. Über das Web konnte man Chemikalien, sogenannte Oligonukleotide, synthetisieren. Das war Mitte der 90er und hieß “Virtual Laboratory”.

Meine damalige Freundin hat mich dann gedrängt das Studium abzuschließen. Ich habe nebenbei gearbeitet und als ich die Diplomprüfungen gemacht habe, habe ich ein Startup gegründet. Es war ein Wissensmanagement-Startup, für das wir sogar eine erste Finanzierungsrunde bekommen haben. Leider waren wir damit ein paar Jahre zu früh. In diesen zwei Jahren habe ich aber viel gelernt. Dann war ich bei Fraunhofer und habe Firmen mit Scrum, Agile Produktmanagement und Software-Qualität geholfen.

Wie ging es dann weiter?

Ungefähr 2005 kam ich dann zu ImmobilienScout und da habe ich im Grunde gelernt, wie man im großen Stil Tech macht. Ich muss sagen, ich ärgere mich bis heute, dass ich damals nicht auch mal in Operations reingeschaut habe. Ich kann jedem nur raten über den Tellerrand der Entwicklung zu sehen.

Die nächste wichtige Station war brands4Friends, wo es meine Aufgabe war die Plattform, die sehr stark gewachsen war, zu stabilisieren. Da wurde ich diverse Male nachts aus dem Bett geklingelt, gerne auch mal während des Urlaubs, und habe zusammen mit Entwicklern und Operations die Webseite repariert. Das war super stressig, denn das technische Problem, die Server auf einen Ansturm vorzubereiten, war nicht trivial. Dennoch war es unglaublich befriedigend, wenn man es mit einem super Team doch schafft.

Dann wurden wir von Ebay gekauft. Dort habe ich gelernt wie ein börsennotierter Konzern mit Umsatzerwartungen, Budgeting und solchen Themen, funktioniert. Bei Ebay lernte ich weniger Tech, sondern eher Executive Management und viel Business. Letztendlich war ich da aber am Ende der Fahnenstange angekommen, und ich hätte nur noch weiter ins obere Management gekonnt. Das wollte ich aber nicht und bin dann in die Beratung gewechselt. Und heute mache ich nur noch Sachen, die mir Spaß machen.

Bereust du diesen Schritt? Immerhin wirst du heute eher gefragt, ob du CTO eines Frontends für eine Datenbank sein willst.

Nein, was ich aktuell mache ist eigentlich viel besser! Ich sehe in viel mehr Unternehmen rein, sehe unterschiedliche Tech-Stacks, und was mich am meisten interessiert: die unterschiedliche Interaktion zwischen Business und Tech. Ich habe pro Jahr viel mehr Kunden als vorher und erfahre sehr viel mehr als in der gesamten Zeit zuvor. Das ist spannend.

Wo siehst du Dich in Zukunft?

Das Thema Coding for Manager ist mir sehr wichtig und da möchte ich meine Arbeit in den nächsten Jahren intensivieren. Ich kann damit einfach mehr bewegen statt als CTO zu schauen, ob ein A/B-Test richtig implementiert wurde.

Welche Themen werden für die Gesellschaft in der Zukunft wichtig sein?

Für mich persönlich ist es Coding for Manager, auch deswegen, weil wir in unserer Industrie das Thema Altersdiskriminierung haben, über die eigentlich keiner spricht. Ich werde nicht mehr irgendwo programmieren können mit meinen 45. Eigentlich sieht man nirgends Entwickler über 40, wenn man mal von ein paar Konzernen absieht. Bei vielen Softwarefirmen ist die Altersstruktur schwierig.

Künstliche Intelligenz wird wie ein Waldbrand durch die Gesellschaft fegen.

Für die Gesellschaft stellt sich in Zukunft die Frage, wie wir damit umgehen werden, dass künstliche Intelligenz vielen Menschen die Arbeitsplätze wegnehmen wird. Callcenter, Rechtsanwälte, Taxifahrer, LKW-Fahrer. Das ist eine moralische Frage, mit der ich mich schon damals im Labor beschäftigt habe. Wir haben zwar niemanden entlassen, aber auch niemanden eingestellt, weil ich automatische Software geschrieben habe. Das ist ein wichtiger Grund, warum Programmierer so viel Geld bekommen, weil man durch Software die Arbeit Vieler ersetzen kann. Künstliche Intelligenz wird wie ein Waldbrand durch die Gesellschaft fegen. Für Unternehmen, die bis dahin kein Tech-Unternehmen sind, wird es das Aus bedeuten.

Das Interview können wir doch nicht so negativ beenden!

Ich glaube ja, dass wir uns wieder irgendwie transformieren werden. Das haben wir immer. Ich bin ein großer Freund des bedingungslosen Grundeinkommens. Vielleicht wird Arbeit, wie wir sie heute kennen, nicht mehr unbedingt im Mittelpunkt der Gesellschaft stehen. Vielleicht müssen wir da auch proaktiver drüber nachdenken, statt immer nur reaktiv zu sein. Das würde ich mir wünschen.

Lieber Stephan, das klingt optimistischer. Vielen Dank für das Interview.

Dieses Interview wurde am 3. Juli  in Berlin geführt.