Und jetzt: Wert schöpfen

Matthias Kramer

Mark Jäger und Nicolas Kittner haben eine spannende Diskussion angefangen – wir wollen lösen.

Nicolas sagt, “Das Problem mit den meisten Consultants ist: Sie sind ausschließlich Consultants. Sie bewegen sich auf einer Metaebene, alles ist Makro, nichts Mikro.” Er fordert, dass die Berater die Mikro-Ebene auch tun müssen, “sie müssen wissen, wie man aus einer E-Commerce Strategie einen Shop macht, wie man aus einer Idee einen Prototypen baut, wie man aus Trends ein Produkt entwickelt.”

Marks völlig richtiges Gegenargument ist, dass man keinen Kolben wechseln können muss, um zu erkennen, dass Verbrennungsmotoren ihrem Ende entgegen gehen:

“Strategen müssen aus einer E-Commerce-Idee keinen Shop bauen können. Sie müssen aber eine sehr gute Einschätzung haben, welche Idee die höchste Wahrscheinlichkeit hat, am Markt Erfolg zu haben.”

Wir möchten lösen: 42!

Na ja eigentlich 51. Das ist nämlich die aktuelle Anzahl unserer Teammitglieder. (Kurzer Werbeblock: Wir suchen dringend Designer und Hardwareentwickler)

Was wir (also wir 51, aber auch Nicolas und Mark) doch wollen, ist Wert zu schöpfen. Sonst würden wir den Job doch nicht machen. Und das kann man nur mit Strategie UND Execution. Warum also trennen? Die Diskussion, was wichtiger ist, Consultants (Konzept) oder Macher (Execution) ist da nicht hilfreich und langweilt, weil sie so alt ist, wie das Business. Eine Idee ist immer nur ein Potenzial, bis sie realisiert wurde. Und bleibt ein Potenzial, bis sie erfolgreich vermarktet wurde. So einfach, so richtig.

Das Problem liegt doch gerade in der Komplexität der Ventures, die man startet. Diese erfordert ein hohes Maß an Expertise aus unterschiedlichen Bereichen. Und auch wenn wir uns alle für die richtigen Brains halten, wird man es alleine nicht schaffen, die Komplexität zu beherrschen. Wir brauchen also ein Team mit unterschiedlichen Fähigkeiten. Und da müssen die Strategen verstehen, wie man etwas implementiert und die Implementierer das Konzept richtig verstanden haben. Man muss gemeinsam vor der Wand stehen, Hypothesen entwickeln und Methoden finden diese zu überprüfen. Man muss gemeinsam bauen, gemeinsam verkaufen, gemeinsam lernen.

Mit jedem neuen Produkt oder Geschäftsmodell tun wir das immer wieder. Und mit jedem neuen Produkt und jeder neuen Technologie lernt man mehr — und spezialisiert seine Erfahrungen. Durch enge Kommunikation an den Schnittstellen lernt man auch, was sich “auf der anderen Seite” tut. Und gerade diese geteilten Erfahrungen und das gemeinsame Lernen erhöht die Erfolgswahrscheinlichkeit.

Der kleinere Teil des Teams (nämlich genau 9) besteht aus “Consultants” (wir mögen den Begriff nicht so sehr, weil wir keine Berater sind, die nur “beratend” tätig sind, aber das ist eine andere Geschichte). Jeder davon hat einen anderen Background, eine andere Expertise, eine andere Herangehensweise. Aber jeder übernimmt die unterschiedlichen Aufgaben, die in Projekten anfallen. Auch Martin Böhme (den auch Konzerneinkäufer eindeutig als Senior identifizieren — nicht nur wegen seines Xing-Profil-Bilds) testet Applications, schrubbt Designs und lötet auch mal die Platine zusammen.

Wenn er eine Strategie macht, dann holt er sich die Entwickler mit in den Raum, die das Produkt bauen werden. Und wenn das Martina Terlević ist (die als Teamjüngste hier mal gerade als Junior her halten muss, damit auch der Konzerneinkauf das einordnen kann), dann führt er trotzdem eine Diskussion auf Augenhöhe.

Wenn nämlich Martina die Strategie und Martin die Architektur versteht, sind die Voraussetzungen für ein erfolgreiches Produkt gegeben.

Und noch ein interessanter Fakt für die Diskussion: Komplexität ist eine Eigenschaft der Innovation. Das ist nicht nur Bullshitbingo, sondern echt relevant für die Diskussion: es gibt nämlich viele Unsicherheiten und Risiken, mit denen sich das Produkt und Geschäftsmodell kontinuierlich ändert.

Scrum versucht das mit agilem Vorgehen und kontinuierlicher Repriorisierung abzufangen- trennt dabei aber strikt nach Rollen. Bei dieser Dynamik wird auch ein Scrum-Team entweder ineffizient, verrückt oder beides. Wenn also ein Risiko oder ein Pivoting Point eintritt, ist es wichtig, dass die Fachlichkeit versteht, was das technisch bedeutet und die Entwickler vorgesorgt haben, um nicht ein Refactoring über den ganzen Code machen zu müssen.

Long story short: Gratulation für die Diskussion, aber die Trennung der Rollen, bzw. Plädoyer für “Alleskönner” sind nicht hilfreich. Wir verwenden viel Zeit und Energie darauf, geeignete Team Setups zu finden, gemeinsames Verständnis aufzubauen und dann zusammen loszurennen. Und das Ding zu machen.

by Jenni Schwanenberg, Innovation Evangelist und Matthias Kramer, Head of Digital Innovation beim Company Builder mantro.