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.

Vita

Johannes macht sich noch vor dem Abitur selbststĂ€ndig und arbeitet als Softwareentwickler und Berater. WĂ€hrend seines Studiums der Wirtschaftsinformatik an der WWU in MĂŒnster sammelt er Startup-Erfahrung und zieht wenig spĂ€ter nach Berlin, um eine Patentfinanzierungsplattform mit aufzubauen. 2016 wechselt er zu BCG Digital Ventures. Johannes ist Business Angel und leidenschaftlicher Snowboarder.

Empfehlungen

  • Buch: „Der Termin“, „The Phoenix Project“, „Switch“
  • Blog: Martin Fowler
  • YouTube: Bryan Cantrill

Social

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.

Die Kantine bei BCG DV.

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.

Portrait von Johannes in der Kantine.

Johannes und sein MAcBook.

Die Kantine ist ein beliebter Ort bei BCG DV.

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.

Die BörorÀume von BCGG Digitale Ventures.

Johannes Boyne an seinem Arbeitsplatz.

Ein Standing-Desk bei BCG DV.

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.

Auch bei BCG wird viel mit Klebchen gearbeitet.

Johannes in einem Meeting.

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.

Johannes und ein Kollege in einer Besprechung

Johannes beim Telefonieren.

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.

BierbÀnke und ein Elektroroller.

Der Innenhof bei BCGG DV.

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?

Außen-Portrait von Johannes Boyne, Engineering Lead bei BCG Digital Ventures.

Johannes arbbeitet hinund wieder mal in der Kantine.

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.

Das GebÀude von BCG DV in Berlin.