Heinevetter: Wie stellst Du Dir die künftige Zusammenarbeit zwischen IT und Business vor? Um Dir eine erste Orientierung für Deine Antwort zu geben, kannst Du aus vier Szenarien auswählen: 1. Business und IT verschmelzen komplett. Sie arbeiten in gemischten End-to-End-Produktteams zusammen. Infrastrukturservices kommen entweder von einem externen Partner oder aus der Cloud. 2. Hier zerfällt die IT in zwei Teile; der businessnahe Bereich verschmilzt mit dem Business wie in Szenario 1, der Infrastrukturbereich wird als Plattform- oder Foundational-IT organisiert. Das 3. Szenario läuft unter dem Schlagwort Produkt-IT und ähnelt dem Zweiten. Nur sind es keine dezidierten Teams, sondern virtuelle Teams aus Business und IT, die End-to-End zusammenarbeiten. Das 4. Szenario ist nahe an der heutigen Struktur. Auf der einen Seite gibt es gemischte virtuelle Teams, auf der anderen Seite gibt es aber auch klassische Plan-Build-Run-Teams in der IT. Also, für welches Szenario kannst du dich am ehesten erwärmen?
Dröschel: Bei uns sehe ich eher einen Mix aus den Szenarien 1 bis 3. Ich glaube zum Beispiel, dass die Infrastrukturteams in die Produktteams integriert werden. Sie nehmen weiterhin ihre Infrastrukturaufgaben wahr, können aber teilweise auch am Produkt mitarbeiten. So leben wir das gerade. Dass Business und Produkt komplett miteinander verschmelzen, halte ich nicht für ausgemacht. Ein Businessverantwortlicher erledigt neben der Produktentwicklung noch viele andere Dinge, bei denen er losgelöst von der Produktentwicklung arbeitet. Da würde es keinen Sinn ergeben, diese beiden Rollen in einem festen Team zu verschmelzen. Allerdings bin ich sicher, dass wir die Crossfunktionalität stärker fördern und intensivieren müssen. Natürlich hängt das von der Ausrichtung des jeweiligen Unternehmens ab. Je technischer, desto näher sollten Business und Produkt zusammenarbeiten. Schließlich verkauft das Business technische Produkte und will gerade in der Entwicklungsphase das Feedback des Kunden einbringen können. Deshalb ist das Thema Agilität hier auch so wichtig. Es gibt diesen linearen Entwicklungsprozess nicht mehr, in dem am Anfang die Anforderungsaufnahme steht und am Ende das Produkt. Es geht um vernetztes Arbeiten mit etlichen und möglichst frühen Feedbackschleifen zwischen Produzent und Kunde.
"Es geht um vernetztes Arbeiten mit möglichst frühen Feedbackschleifen zwischen Produzent und Kunde"
Also würdest Du auch virtuelle Teams befürworten?
Ja. Ich meine, dass Flexibilität heute eine der wichtigsten Anforderungen ist. Und mit virtuellen Teams, deren Set-up ich zur Not auch grundlegend verändern kann, kann ich am schnellsten auf Veränderung reagieren. Diese Flexibilität brauche ich heute. Beispiel aus unserem Sales: Die Verkäufer bilden natürlich eigene Sales-Teams, gleichzeitig arbeitet aber praktisch jeder Verkäufer auch in einem oder mehreren Produktentwicklungsteams mit, weil er das Kundenfeedback möglichst früh wieder in den Entwicklungsprozess einspeisen will.
Spielen Citizen Developer und Low-Code-Plattformen in euren Organisationsüberlegungen eine Rolle? Macht Low Code das Business unabhängiger?
Richtung Kunde ist das bei uns ein ganz wichtiges Thema. Normalerweise möchte ein Softwareanbieter seinen Kunden möglichst von sich abhängig halten. Anforderungen sollte der Kunde direkt an den Anbieter stellen, der kann dann entwickeln und wird vom Kunden für zusätzliche Funktionalität bezahlt. Aber so funktioniert das heute nicht mehr. Zumindest wir möchten unseren Kunden autarker machen, sodass er in gewissem Maß eigenständig auf die Anforderungen seiner Kunden reagieren kann. Und dabei hilft uns Low Code jetzt schon. Beispielsweise im Bereich Konfigurierbarkeit. Hier versetzen wir unsere Kunden in die Lage, selbst bestimmte Logistikprozesse anzupassen. Wie schon gesagt, Veränderbarkeit ist die größte Anforderung. Im klassischen Modell kostet Veränderung den Softwareanbieter Zeit und Aufwand, und da unsere IT ohnehin immer am Limit fährt, ist es schlauer, den Kunden direkt einzubinden, ihm einfachere Wege der Veränderung aufzuzeigen und so beide Seiten zu entlasten.
Überfordert man den Kunden damit nicht?
Die IT-Affinität hat sich in den vergangenen Jahren positiv entwickelt. Es kennen sich inzwischen viel mehr Leute ein bisschen mit IT aus als noch vor drei Jahren. Und die Organisationsthemen, über die wir hier gerade sprechen, gehen auch an anderen Unternehmen nicht spurlos vorüber.
In unseren Diskussionen mit IT-Verantwortlichen wird das Thema Low Code in Zusammenhang mit Schatten-IT gebracht und damit teilweise auch als Risiko für die IT gesehen. Was meinst Du, hindert Low Code eher oder ist es förderlich, weil es auch die IT-Kompetenz in den Fachbereichen stärkt?
Mir fehlt ein bisschen die Fantasie, das als Risiko zu begreifen. Alles wird digital, und es wird immer genug Aufgaben für die IT geben, wo sie der Fachabteilung zuarbeiten kann. Wenn die Fachabteilung sich selbst befähigen und selbst Dinge lösen kann, führt das für mich zu einer Beschleunigung der Entwicklung für das ganze Unternehmen. Das sollten sich eigentlich alle wünschen, denn dann kann ein Unternehmen mehr verkaufbare Werte produzieren. Dass die IT irgendwann einmal nutzlos ist, sehe ich nicht, sondern sie wird andere Dinge übernehmen, die die Fachabteilung nicht kann.
Wir haben schon kurz über Produktteams gesprochen. Ich würde das gern vertiefen. Welche Erfolgsfaktoren siehst Du für die Aufstellung von Produkt-Teams – in Bezug auf Kompetenzausstattung, Skills, Rollen, Größe? Aber auch in Bezug auf die Frage intern oder extern sowie ob sie stabil gehalten werden sollen oder ob sie in ihrer Zusammensetzung flexibel aufgestellt werden sollen?
Meiner Erfahrung nach sollte man Kern-Produktteams im Unternehmen aufbauen und nur punktuell mit externen Kräften erweitern. Schließlich geht es hier um Dinge, die das Unternehmen verkaufen möchte, um den eigenen Geschäftskern. Andere Prozesse außerhalb des Geschäftskerns können auch mit externen Kräften besetzt werden.
"Heute müssen wir die Möglichkeit für Fachkarrieren schaffen"
Arbeitest Du mit Scrum-Teams?
Da kommen wir her, passen das Prinzip Scrum jedoch auf unsere Bedürfnisse an. Zurzeit arbeiten wir nach dem Domänen-Prinzip und schneiden uns in thematisch orientierte Teams, die auch mal 20 Leute umfassen können. Je nach Anforderung können diese sich zum Beispiel für Sprints weiter in kleinere Teams aufteilen. Jedes Team hat mindestens zwei Product Owner und wird durch zusätzliche Expertisen verstärkt: UX-/UI-Designer, Frontend-Experten, mobile Entwickler, Spezialisten für Backend und so weiter. Je nach Kundenanforderungen und Prioritäten splitten sich diese Teams für zwei bis vier Wochen auf und arbeiten an den gewünschten Produkten.
Gibt es auch eine übergreifende Team-Bildung über die beiden großen Teams hinweg?
Wir haben die beiden Teams thematisch in die Domänen getrennt, um einen Fokus zu schaffen. Natürlich gibt es Schnittmengen zwischen den großen Teams. Bei Spotify heißen die Gilden, bei uns Fachteams. Leute mit ähnlichen Skills – zum Beispiel Frontend-Entwickler – treffen sich wöchentlich und stimmen sich ab. Sie versuchen, eine gemeinsame Basis zu schaffen. Das Gleiche gilt für Product Owner, Architekten usw. Außerdem halten wir es für sehr wichtig, dass sich die verschiedenen Skill-Gruppen übergreifend austauschen können – also die Cloud-Engineers mit den Backend-Entwicklern oder Architekten und Product Owner und ähnliche.
Wie löst ihr die Themen „People Lead“ und „Product Lead“? Trennt ihr die fachliche (product) und die disziplinarische (people) Führung?
Darauf haben wir noch keine perfekte Antwort. Der Product Lead liegt zurzeit bei den Product Ownern und bei den Architekten. Der People Lead liegt bei mir. Ich bin für die disziplinarische Führung aller Mitarbeiter verantwortlich. Das heißt aber nicht, dass ich über alle Themen vom Urlaub über Gehalt bis Kompetenzentwicklung allein entscheide. Da hole ich mir selbstverständlich Input von anderen, teilweise auch von den fachlichen Leads.
Verändert sich auch die Art, wie geführt wird?
Ja, wir denken zum Beispiel über People Coaches nach, die sich eher um die Entwicklung der Leute kümmern. Wichtig ist das Mindset der Personen. Das müssen Coaches sein mit viel Empathie, die sich in die Leute hineinversetzen können, damit sie verstehen, was gebraucht wird. Diese Leader müssen nicht die besseren Fachleute sein, aber sie müssen den Rahmen stecken, damit sich Leute gerade in der IT weiterentwickeln können. Viele wollen nämlich keine Titel mehr, aber sie wollen die Möglichkeit mitzugestalten, Verantwortung zu übernehmen, und sich weiterentwickeln. Da hat sich fundamental etwas verändert. Früher war es immer so: Ich bin gut in meinem Job, bringe eine super Leistung und deshalb werde ich bald selbst Chef. Eine andere Möglichkeit, Karriere zu machen, gab es nicht. Heute müssen wir die Möglichkeit für Fachkarrieren schaffen, sonst laufen wir Gefahr, dass gute Fachleute schlechte Leader werden.
Ihr seid ein sehr junges Unternehmen. Deshalb könnt ihr einfacher neue Wege gehen. Aber wie lautet Dein Rat an traditionelle IT-Organisationen, die genau vor dieser Herausforderung stehen. Die können ja nicht abwarten, bis die gestandenen Manager in Ruhestand gehen, die sich stark über Hierarchien definieren und darüber, wie viele Leute sie führen.
Auch die traditionellen Unternehmen müssen sich umstellen. Sie müssen ihren Managern zunächst einmal Selbstreflexion abverlangen. Was für Führungskräfte sind sie? Sind sie stark fachlich orientiert, haben sie eine Produktvision oder sind sie eher Management orientiert, können sie gut mit Leuten umgehen, können sie gut organisieren, beherrschen sie ihren Führungskräfte-Instrumentenkoffer? Entsprechend ihren Stärken und Schwächen müssen sie sich Unterstützung holen, fachlich oder disziplinarisch. Wenn sie das selbst nicht können, übernimmt es das Unternehmen. Sie werden stärker eingebettet in ein Führungsteam, sind keine Solitäre mehr. Ich denke, auch die Geführten fühlen sich dann wohler. Sie haben es nicht mehr mit einem Chef oder Chefin mit Schwächen im einen und Stärken im anderen Bereich zu tun, sondern sie werden von einem Team geführt, das alle Aspekte abdeckt.
Gehen wir mal weg von den Leuten und kommen wir zum Thema Daten. Welche Auswirkungen hat das Thema Data Driven auf die Unternehmen? Wird sich zum Thema Daten vielleicht sogar eine eigene Organisation bilden, wie wir das beim Thema IT erlebt haben? Wird es einen Chief Data Officer geben, also das Thema Daten zentral gehandhabt, oder wird das Thema dezentral bearbeitet und Bestandteil jeder einzelnen Organisationseinheit?
Ich schätze, dass beides der Fall sein wird. Auf der einen Seite beim Sammeln und Aufbereiten sowie bei Basisauswertungen werden Unternehmen wahrscheinlich eher zentral vorgehen, weil das effektiver ist. Auf der anderen Seite kann ich mir bei den tiefergehenden Analysen vorstellen, dass die sowohl dezentral in den Teams vorgenommen werden als auch zentral. Aber es wird eine zentrale Stelle im Unternehmen geben, die das Thema Daten insgesamt vorantreibt. Sie wird die Anforderungen der Teams in Bezug auf Datenerhebung und Auswertungen aufnehmen, die innerhalb der Teams nicht geleistet werden können. Über allem steht allerdings die Frage, was ich als Unternehmen eigentlich mit den Daten machen will. Davon hängen natürlich die organisatorischen Fragen ab und welche Rollen, wo gebraucht werden.
Wie habt ihr das realisiert?
Wir haben Team-übergreifend einen Analytics-Bereich geschaffen: Data Engineers und Data Scientists kümmern sich um die Erhebung und die Analyse der gesammelten Daten. Parallel ist es auch gut möglich, dass die Rollen für eine gewisse Zeit in den Teams mitarbeiten, um spezielle Funktionen mithilfe ihres Blickwinkels zu optimieren. Mit diesem zweigleisigen Approach hoffen wir, das Datenthema bei uns noch stärker verankern zu können und uns auch fit zu machen für KI und Machine Learning.
Ich möchte noch ein weiteres großes Thema ansprechen: Transformation. Ihr müsst euch als junges Unternehmen überlegen, wie eure nächste Evolutionsstufe aussieht und wie ihr dahin kommt. Was sind die Erfolgsfaktoren für eine solche Transformation?
Ich glaube, es gibt nicht die eine Transformation, nach der ein Unternehmen wieder in eine stabile Phase eintaucht. Ich glaube, dass Transformation zumindest über eine gewisse Zeit hinweg ein permanenter Prozess ist, in dem Miteinander, Transparenz und Kommunikation ganz wesentliche Punkte sind. Dazu gehört auch, vieles auszuprobieren und mit intensiven Feedbackschleifen aus der Mitarbeiterschaft fortzuentwickeln oder zu verwerfen. Es muss nicht jeder alles mitentscheiden, aber jeder muss die Gelegenheit haben, sein Feedback zu allen Entwicklungen geben können.
Habt ihr damit schon Erfahrungen gemacht?
Wir probieren das gerade mit einer Taskforce aus. Dabei haben wir die Rollen festgelegt, die bei der Diskussion über die Weiterentwicklung des Unternehmens dabei sein sollten, dann aber innerhalb dieser Rollen Freiwillige gesucht, die mitmachen wollen. In dieser Taskforce lassen wir uns auch extern beraten. Dort sprechen wir über verschiedenste Szenarien und entwickeln gemeinsame Modelle. Die stellen wir dann auch den Kolleginnen und Kollegen in den Teams vor und holen ihre Feedbacks ab, die wir zusätzlich berücksichtigen. Auf diese Weise hoffen wir, jeden zu involvieren, der involviert werden will, ohne eine Basisdemokratie zu schaffen. Aber so ist jeder abgeholt. Ob das klappt, weiß ich noch nicht, weil wir erst gerade damit beginnen.
Letzte Frage. Was sind die drei wichtigsten Herausforderungen, denen Du dich kurz und mittelfristig stellen musst?
Die erste ist der Fachkräftemangel – gerade in der IT. Die zweite große Challenge ist, in der Technologiebewertung auf dem Laufenden zu bleiben. Welche neuen Technologien sind wichtig und welche sind gut für mein Unternehmen. Die dritte große Herausforderung ist die Entwicklungsgeschwindigkeit. Wie kann ich sicherstellen, dass ich neuen Kundenbedürfnissen möglichst schnell entsprechen kann.
