Johannes Boyne, Engineering Lead bei BCG Digital Ventures

Johannes zeigt uns die phasenweise Produktentwicklung beim Digital Venture-Arm von BCG und erklärt, warum schneller Teamaufbau und People Management wichtig ist. Als Venture-CTO stellt er das Team auf und definiert die Roadmap eines Ventures.

Hallo Johannes, du bist Engineering Lead bei BCG DV, erkläre uns kurz, was deine Aufgaben sind.

Meine Aufgabe als Engineering Lead ist es, die technische und produktgetriebene Vision eines Ventures von Anfang an auf die Straße zu bringen. Dazu gehören die Auswahl des technischen Teams, die Definition einer Roadmap und diese so weit zu shapen, dass sie machbar ist. Bei uns heißt es: Wir arbeiten im Team und das Team baut das Ganze. Meine Rolle dreht sich daher auch viel darum, das Team zu enablen und ihm möglichst viel Freiraum zu geben.

Das macht den Eindruck, als würdest du die Aufgaben eines CTOs übernehmen.

Wir sagen oft auch Venture CTO dazu. Wobei ein Team so groß sein kann, dass es neben dem Venture CTO noch weitere Leads gibt. Den Begriff Interim CTO finde ich eigentlich noch besser, weil er beschreibt, dass wir nur sechs bis zwölf Monate auf einem Venture sind und wir uns am Ende Stück für Stück daraus zurückziehen.

Welche Erfahrungen bringst du in deine Rolle als Venture CTO ein?

Ich war Teil von zwei Gründungen, bei denen ich der CTO beziehungsweise der Director Engineering war. Bei Archkomm haben wir zum Beispiel die Indoor-Navigation „Virtual Twins“ gebaut. Die andere Firma war eine Finanzierungsplattform für Patente, die kleine Unternehmen, Privatpersonen und besonders deutsche Hochschulen entwickelt und angemeldet haben. Hochschulen sind nicht so gut darin, diese zu vermarkten. Mit Machine Learning haben wir die Patente analysiert und über Crowdfunding sowie Private Equity wollten wir sie für Investitionen öffnen.

Das sind zwei sehr unterschiedliche Projekte. Wie unterschiedlich sind die Ventures bei BCG Digital Ventures?

Das ist hier genauso. Hier in Berlin kennt man Coup, eine eScooter-Sharing-Lösung, die wir mit Bosch zusammen entwickelt haben. Dann haben wir die Gebrauchtwagenplattform Heycar gemacht. Mit Kollegen aus Amerika haben wir XinKaishi gemacht, ein Gerät, um die Herzschläge des Kindes während der Schwangerschaft zu analysieren. Des Weiteren haben wir viele Ventures im Bereich Industrial Goods aufgebaut. Zum Beispiel war mein letztes Venture ein Agri Tech Venture, das Satellitendaten nutzte, um clevere Düngeempfehlungen zu geben. Der Landwirt benötigt weniger Dünger und erwirtschaftet mehr.

Welche Rolle spielt für dich der Corporate Partner im Job?

Der Corporate Partner, dessen Venture wir aufbauen, ist Teil des Dreigestirns aus BCG DV, ihm selbst und dem Venture. Wir entwickeln die Idee zusammen mit dem Corporate Partner, darum kann er natürlich auch mitsprechen. Wobei ich als Venture CTO lange das Recht habe, „Nein“ zu sagen. Zum Beispiel, wenn wir das Venture an ihr SAP anbinden sollen. Wir sind nicht die verlängerte Werkbank der Konzern-IT. Zudem muss ein Venture einige Freiheiten haben, um schnell zu sein.

An welcher Stelle wird der Venture CTO mit ins Boot geholt?

Sobald der Innovation-Prozess losgeht, kommen einer unserer Engineers und ich als Venture CTO mit dazu. Die Teile der Definition, wohin das Venture gehen soll, möchte ich mit shapen. Das Ganze ist natürlich ein multidisziplinäres Team.

Wie ist das Team zusammengesetzt und wie entwickelt es sich?

Wir versuchen, für jedes Venture ein Founder Team hinzustellen. Das sind dann der General Manager als Vertreter des Business, der Venture CTO, Design (UX, UI sowie Strategic Design) und ein CPO, also ein Produktmanager. Das Team wird im Laufe eines Life Cycle immer größer. In der Incubation-Phase erreicht es seine maximale Größe. Da haben wir zwischen fünf und 15 Entwickler auf so einem Venture. Dann kommen noch mal zwei bis drei gute Designer dazu, Growth Architects und ebenso viele Business-Leute. Das ist dann allerdings auch schon ein großes Team.

Was ist die Incubation-Phase und wie viele Phasen hat bei euch ein Venture?

Wir bauen unsere Ventures in der Regel in drei Phasen: Innovation, Inkubation, Kommerzialisierung. In der Innovation wird, wie der Name sagt, die Idee gefunden und schon zu großen Teilen ausdefiniert. Wir nutzen hier besonders Design Thinking und ethnographischen Research. Die Inkubation ist dann der bekannte Ansatz, schnell ein MVP auf den Markt zu bringen, sprich ein Minimal Viable Product. Jedoch stoppen wir da natürlich nicht, sondern entwickeln iterativ weiter. Anschließend kommt es zur Kommerzialisierung; in dieser Phase skalieren wir das Venture und ersetzen uns mit Top-Talenten. Wir rekrutieren diese selber und legen viel Wert auf eine gute Übergabe.

Du hast PM eher beiläufig erwähnt. Aber welche Rolle spielt Product in euren Teams?

Das ist je nach Team unterschiedlich. Aber ein erster Abgrenzungspunkt zu Tech ist die Frage, wie viel Projektmanagement der Produktmanager machen möchte. Meistens ist es bei DV so, dass die Produktmanager viel lieber Produktmanagement machen, da wir oft recht komplexe Produkte haben und weniger im Projektmanagement arbeiten wollen. Das ist mir dann immer ganz recht. Denn dann kann ich Entscheidungen, die das Produkt nach rechts oder links bringen, in die Hände der Produktmanager legen. Das kann man dann noch mal challengen. So liegt am Ende die Entscheidung, ob man sich zum Beispiel mit der E-Mail-Adresse oder über Facebook einloggen können soll, beim PM.

Wer entscheidet, welchen Sprint-Rhythmus die Teams haben und welche Methoden angewendet werden?

Da möchte ich auf jeden Fall ein Wörtchen mitreden. Das ist ein Leadership Effort, bei dem der General Manager des Ventures die letzte Entscheidung treffen könnte, was er aber eher selten tut, da Venture CPO und CTO letztendlich die Verantwortung dafür tragen, dass ein Produkt delivert wird. Wir arbeiten zum Beispiel eher selten von Anfang an mit Scrum, sondern starten mit Kanban.

Wie sieht es mit Business Intelligence aus?

Das ist von Anfang an ein Bestandteil der Entwicklung, denn nur was man messen kann, kann man auch managen. Ganz nach Peter Drucker:

You can only manage what you can measure.

Vielleicht kannst du an einem Beispiel mal erklären, wie man sich die Produktentwicklung bei euch vorstellen muss.

In der Regel arbeiten wir mit 80 Prozent „Battle-Proven Technology“. Das sind bei uns die Frameworks Java Spring, häufig auf Kotlin inzwischen, und Ruby on Rails. Damit bauen wir meist die Basis, was recht schnell geht. Allerdings bauen wir immer alles von Scratch auf, da „one solution fits all“ bei unseren Corporate-Partnern nicht funktioniert. Für die letzten 20 Prozent, die am Ende den meisten Mehrwert bieten, nehmen wir Technologien, die zum Anwendungsfall gut passen. Zum Beispiel Python für die Machine-Learning-Teile, die inzwischen beinahe zum Standard-Repertoire gehören. Aber auch Node.js für Serverless-Themen oder Golang, wenn es Richtung Netzwerk und Hardware geht. Im Prinzip sind wir Technologie-agnostisch.

Wir arbeiten mit einer Satellitenarchitektur, wie wir das nennen. Anfangs gibt es oft eine Art Kern, einen Monolithen, von dem wir dann mehr und mehr Teile, die Satelliten, abspalten. Da kommen dann Microservices ins Spiel, die über API Calls miteinander sprechen. Wir setzen das meist auf AWS oder Google Cloud auf. Für die Container-Orchestrierung nutzen wir Kubernetes und Terraform, um die Infrastruktur zu codifizieren.

Wie sieht es mit Testing aus?

Tests und Deployment sind bei uns ein nicht verhandelbares Thema. Wir haben von Tag 1 an Continuous Integration. Mir ist es dabei nicht wichtig, ob der Entwickler den Test vorher oder nachher schreibt, aber am Ende muss er da sein. Am Ende hilft dies einem, die „Debug-Time“, sprich die Suche nach Fehlern, gering zu halten.

Wie sieht ein Product Team innerhalb eines Ventures aus?

Generell muss ich erst mal erklären, dass wir in sechs Kohorten organisiert sind. Die Venture Architects sind die Business-Leute. Die Growth Architects sind für den Marketing-Growth zuständig. Es gibt die Produktmanager, das ist klar, und die Strategic Designer. Bei denen geht es zum Beispiel um User Research und Ethnographie. Dann haben wir natürlich auch Experience Design und die Engineers.

Unsere Produkt-Teams im Venture sind Feature Teams, bestehend aus Produktmanager, Experience Designer und Engineers. Sie bilden ein crossfunktionales Team und arbeiten fast schon ein bisschen autark an den einzelnen Features.

Was das Thema Growth, Marketing und vor allem Go-to-Market angeht, arbeiten wir in Domains. Da geht auch mal Engineering mit rein, um herauszufinden, was notwendig ist, um das Tracking aufzubauen, oder welche Datenpunkte wichtig sind.

Was ist das Erste, was du in einem Venture tust?

Teambuilding ist anfangs eine der wichtigsten Komponenten. Dafür haben wir Methodenbausteine für uns geschaffen, mit denen wir Vision, Mission und Purpose schnell ins Team bekommen. Mit Team-Events und -Trainings geht es darum, den Prozess des Kennenlernens zu beschleunigen.

Teambuilding ist anfangs eine der wichtigsten Komponenten.

Wir wissen, ein Team muss bestimmte Phasen durchlaufen. Forming, Storming, Norming. Da führt kein Weg daran vorbei.

Die Team-Events macht ihr, noch bevor ihr die erste Zeile Code schreibt?

Ja, und dann auch immer wieder. So was hilft nicht nur am Anfang. Alle drei bis vier Wochen muss das Team etwas gemeinsam unternehmen.

Organisierst du das oder habt ihr dafür jemanden im Team?

Die Rolle dafür heißt Venture Team Assistant und die ist genau dafür zuständig. In der Regel geht das vom Venture Leadership aus, also dem GM, dem Venture CTO oder den PMs. Das ist wichtig, weil wir das Team insbesondere vor intensiven Phasen zusammenschweißen wollen. Dann holt man sich den Venture Team Assistant dazu und bespricht zum Beispiel die Idee einer Bootsfahrt. Am Ende ist jedoch das tägliche Vorleben von Zusammenhalt und Einheit im Team das Wichtigste, mit einer Bootsfahrt auf der Spree alleine ist dies nicht getan － missen möchte ich diese trotzdem nicht.

Das Team steht, wie geht es weiter im Venture?

Wir entwickeln weiter, das Venture kommt nie zu einem Stillstand bei uns. Meine Rolle verändert sich dabei im Laufe des Venture. Erst bin ich sehr produktfokussiert und das Team läuft quasi wie ein gut geölter Motor von selbst ohne Hands-on Management. Und dann beginnt die Recruiting-Phase. Über vier, fünf Monate ein oder zwei Tage die Woche bin ich mit dem Recruiting beschäftigt.

Wie geht ihr dabei vor?

Wir hiren stückchenweise die Leute rein und ziehen unsere wieder raus. Diese Phase nennen wir Commercialisation-Phase und die findet in den letzten Monaten statt. Da erfolgt die Übergabe an die Nachfolger, die dann nach einigen Wochen hoffentlich so weit eingearbeitet sind, dass sie übernehmen können.

Wenn man dir so zuhört, dann klingt das wenig technisch und viel nach Team-Arbeit. Woran liegt das?

Das liegt daran, dass man die Technologie schon irgendwie in den Griff bekommt. Daran wird es nicht scheitern. Produktentwicklung ist ein totales People-Thema. Und das ist das Spannende. Dazu kommt hier noch das Dreigestirn hinzu. Es macht mir großen Spaß, dem Vorstand eines Corporate zu erklären, warum Blockchain hier nicht der richtige Weg ist, und Argumente und Beweise dafür zu finden, dass ein bestimmter Markt und Technologien die richtigen sind, um zu investieren.

Technologie bekommt man schon irgendwie in den Griff. Produktentwicklung ist ein totales People-Thema.

Jetzt hast du schon ein paar Teams aufgebaut und auch wieder abgegeben. Welchen Tipp hast du für Engineering Leads, die schnell ein Team aufbauen müssen?

Man muss den Teamaufbau planen. Viel davon geht vom Bauchgefühl aus: Ich glaube, die funktioniert so, der funktioniert so, der funktioniert anders. Dieses Hypothesengetriebene ist sehr natürlich. Aber man muss das strukturieren. Wenn ich ein neues Team aufbaue, erstelle ich ein großes Dokument mit allen Namen und schreibe mir zu den Leuten alles auf. Woher kommt er, welchen Erfahrungsschatz bringt sie ins Team, was möchte er selber lernen? Wir sprechen mit jedem Teammitglied darüber, was es in diesem Venture persönlich erreichen möchte. Das sind wichtige Faktoren, besonders, wenn man nicht so viel Zeit hat.

Es gibt viele Techniken, die man verwenden kann. Lob ist zum Beispiel so ein Thema. Wie möchte jemand Lob bekommen? Da gibt es unterschiedliche Arten. Ebenso beim Thema Kritik. Möchte die Person es lieber direkt und über Face to Face oder kommt sie mit öffentlicher Kritik klar?

Wie wichtig ist für dich noch das Entwickeln selbst und hast du noch die Möglichkeit, selbst Hand anzulegen?

Das Interessante ist bei allen Ventures, die nicht von Anfang an 15 oder 20 Mann groß sind, dass man die Teams ja Stück für Stück zusammenbaut. Da ist man am Anfang auch immer mit Coden dabei, vielleicht nicht auf dem kritischen Pfad, aber man steuert etwas bei. Für mich ist das eine gute Gelegenheit, als Vorbild zu führen. Ich glaube, man verliert irgendwann mal die Akzeptanz beim Team, denn man muss ja auch die Entscheidungen für das Team treffen. Später lese ich mir auch immer noch jeden Pull Request durch, weil ich wissen möchte, wohin es sich entwickelt, und ich komplett mitreden können möchte. Außerdem bin ich kein Fan des Seagull-Managements.

Wo, denkst du, geht die Reise technologisch in Zukunft hin?

Machine Learning ist ein Riesenthema, da sieht man eine extreme Weiterentwicklung und bald werden bestimmte ML-Themen „commodity“ sein, sprich so normal wie Video-Inhalte. Der nächste große Sprung wird allerdings nicht von DV kommen. Wir bringen diesen letzten Sprung, den es gab, aber in echte Produkte ein. Zum Beispiel Computer Vision funktioniert in der Zwischenzeit so gut, dass man das in den jetzigen Entwicklungsprozess einbringen kann.

Welche Lese-Tipps hast du für angehende Engineering Leads und alle, die sich in dem Bereich weiterbilden möchten?

Alles von Harvard Business Review zum Thema People Development ist gut. Diese Bücher sind sehr konzentriert und lassen sich darum gut durcharbeiten.

Aus dem Bereich Projektmanagement finde ich das Buch von Tom DeMarco, „Der Termin“, im Englischen „The Deadline“, sehr gut. Es ist zwar ein Roman, aber vollgepackt mit viel Wissen aus Projekt- und vor allem IT-Management. „The Phoenix Project“ ist auch für Leute aus dem Bereich. Mehr zum Thema People Management findet man in „Switch“ von Chip und Dan Heath. Das Thema ist: „How to change things if change is hard.“

An Blogs kann man auf Martin Fowler zum Thema Software Engineering verweisen. Bryan Cantrill, den CTO von Joyent, also der Firma, die Node.js gemacht hat, kann man sehr gut auf YouTube sehen. Er ist der witzigste CTO, den ich je gesehen habe.

Lieber Johannes, vielen Dank für das Interview.

Dieses Interview wurde am 24. August im Berliner Office von BCG Digital Ventures geführt.