Ein Sprung ins kalte Wasser – ständiges schwimmen um nicht unterzugehen, aber mit Land in Sicht.

Ich habe mich für dich als Gruppenleiter für das Embedded Firmware Team entschieden. Dieser Satz hat Anfang 2022 mein Berufsleben und meinen Ausblick in die Zukunft fundamental verändert. Bis dahin war ich Elektronik Entwickler, tief in der Hardware-Design und Low-Level Programmierung. Plötzlich ging es nicht mehr nur um Stützkondensatoren, Controllerauswahl, Leiterplattendesign, sondern um Menschen, Prozesse und Verantwortung.

Die erste große Umstellung, die ich erfahren musste, war der Weg vom „Ich löse das Problem selbst“ zum „Ich ermögliche anderen, Probleme zu lösen“. Doch bevor ich das konnte, musste ich erst einmal die mitgebrachten Probleme lösen, die ich aus meiner vorherigen Rolle mitgebracht habe. Da der Wechsel im selben Unternehmen stattfand, habe ich neben den neuen Aufgaben auch noch alle bisherigen auf meinem Tisch liegen. Das Team das ich leite bestand aus Softwareentwicklern, die alle im Rahmen von vorherigen Projekten an Embedded-Linux Systemen gearbeitet haben. Dorthin konnte ich die Elektronik Probleme des Projekts aus dem ich gerade kam nicht delegieren. Also doch selbst lösen und langfristig für eine Veränderung der Verantwortung sorgen. Leichter gesagt als getan. Das Projekt in dem ich vor dem Stellenwechsel gearbeitet habe ist nicht abgeschlossen. Es stehen noch so viele Arbeitspakete aus, die nicht nur ich noch liefern sollten. Auch sind die Ressourcen so dünn verteilt, dass mein Weggang zu einem massiven Verzug im Zeitplan geführt hat. Was nicht gerade geholfen hat die bereits begonnenen Themen zeitnah zu beenden und mit dem Projekt abzuschließen. Der Plan sah vor das Gerät bis Mitte 2022 in die Serienproduktion zu überführen. Was allerdings nicht funktionierte, da es für den bestimmten Einsatzbereich nicht genügen Rechenperformance hatte. Initial vorhergesagte Leistungsanforderungen an die CPU der Embedded Baugruppe, die zu Projektbeginn die Hardwareauswahl bestimmten, reichten mit der jetzt verfügbaren Software doch nicht aus. Trotzdem sah der Projektplan eine Fertigstellung bis Mitte des Jahres vor. Also wurde alle Tätigkeiten, die man zur Erreichung des Projektziels erfüllen musste nach Plan durchgeführt. Eine EMV und Funkzulassung mit der Hardware, die erwiesenermaßen nicht leistungsfähig genug ist. Eine Weiterführung des Wartungsvertrags für die extern bezogene Baugruppen, zwei Lieferanten für eine stabile Supply-Chain. Alles für die Tonne, denn das Produkt erfüllt nicht die Leistungsanforderungen.

Plan B musste schnell her. Parallel zur Abarbeitung des Meilensteinplans wurde die Hardware neu entworfen und von einer komplett extern bezogenen Baugruppe auf eine Inhouse gefertigte, wesentlich leistungsfähigere Lösung gewechselt. Dieser Wechsel von Bezugsteil auf Fertigungsteil hat in der Projektkostenrechung nicht annähernd den Kostenumfang bekommen, den er verdient hätte. Die Aufgaben, die mit der bestehenden Hardware durchgeführt wurden haben eine Großteil des Puffers im Budget aufgebraucht. So standen wir nun vor der Situation mit sehr geringen finanziellen Mitteln eine komplexe Baugruppe zu entwerfen und eine passende Software zu entwickeln. Die Anforderungen an die Software waren so vage, dass wir im Grunde genommen alles hätten bauen können, was wir wollten, so lange es eine gewisse Webseite mit genügend Performance anzeigen kann. Die Wünsche an Funktionen waren umfangreich, der Zeitplan kurz und das Budget so gut wie nicht vorhanden. Es gab kein dediziertes Projektteam sondern nur Fachkenner, die neben ihrer Hauptaufgabe noch zusätzlich dieses Projekt bedient haben. So neben bei halt. Total easy. Nicht hilfreich war es, dass das große Projekt, zu dem diese Produkt ein Zubehör war auch mit enormen Verzögerungen zu kämpfen hatte und es nicht schaffte auf den Markt zu kommen. Somit bestand kein Zeitdruck, denn wenn das Zubehör vor dem eigentlichen Produkt auf den Markt kann, kauft es ja trotzdem keiner.

So dümpelte das Projekt von Monat zu Monat weiter, wurde mit minimalem Einsatz gerade gut genug gehalten um die vage formulierten Anforderungen grün zu testen. Es gab Kräfte im Unternehmen, die von dem Mehrwert des Zubehörs zum eigentlichen Produkt nicht überzeugt waren und die haben erwartungsgemäß auch nicht dazu beigetragen, dass der Projektablauf schneller lief, oder die hergestellte Qualität stieg. Alles in allem ein typisches Projekt, dass nach gravierenden Änderungen der Umwelt den ohnehin schon dünn aus-geplanten Plan stur verfolgte. Immerhin haben wir das schon mehrmals gemacht und es ist immer ein Produkt bei herausgenommen, dass unseren Kunden einen Mehrwert geleistet hat. Klassisch nach dem Wasserfall. Ist die Entwicklung fertig, folgt die Pflege. Aber ja keine neuen Funktionen. Hier trafen agile Denkweisen auf die bis dahin ausgeübten klassischen Projektplanungen. Mit dem Unterschied, dass man vergaß, dass Eigenentwicklung neben Zeit auch noch Ressourcen, also Geld benötigt. Als es absehbar war, dass wir den von uns auf die aktuell verfügbare Funktionalität angepassten Testplan erfolgreich abschließen können, wurde genau das gemacht „agil“ die Anforderungen so geschrieben, dass die Funktionalität validiert werden konnte. Somit ist das Produkt jetzt fertig und alle sind happy.

Ganz so einfach ist es natürlich nicht. Das Projekt hängt voll in der Schwebe. Die ersten Kunden haben bereits ihre Bestellung erhalten und arbeiten damit, allerdings gibt es keine Vision, wie wir in Zukunft mit diesem Zubehör weitere Mehrwerte schaffen können. Die gewünschte Funktionalität ist nur in einem minimalen Umfang umgesetzt, die es uns erlaubt die gewünschten Funktionen als umgesetzt zu bezeichnen, wohl wissend, dass alles was nicht explizit ausformuliert war nicht umgesetzt ist.

Doch was ist der Fehler, den ich gemacht habe? Ich habe keinen direkten Einfluss auf Projektentscheidungen und habe nur mit meinem Fachwissen geholfen das Projekt irgendwie über die Ziellinie zu schieben. Dabei haben wir sowohl die Ziellinie näher an das Produkt und das Produkt mit Stützrädern versorgt um das Ziel zu erreichen. Wenn ich ein Projekt sehen, das in einer vergleichbaren Situation steckt, dann werde ich nicht mehr versuchen das Ziel irgendwie zu erreichen, sondern versuchen darauf zu drängen das Ziel noch einmal, angepasst an die aktuelle Umwelt, zu hinterfragen und eventuell neu zu definieren. Denn wenn zum aktuellen Zeitpunkt nicht klar ist, was der Mehrwert für den Kunden ist, dann sollte an dieser Stelle angesetzt werden und nicht blinde Planerfüllung stattfinden.

Das hier oben beschriebene Beispiel hat keinen direkten Bezug zur Software-Teamleitung, oder? Stimmt. Aber es zeigt sich, dass Projektmanagement ein fundamentaler Bestandteil der Entwicklung ist. Software will agil entwickeln, also mit variablem Scope, kurzen Iterationsschleifen und früher Lieferung an den Kunden. Doch was ist der Kunde? Der, der nachher das Produkt aus dem Regal nimmt? Auch. Auf dem Weg trifft das Produkt aber auf viele Kunden. Das betrifft vor allem Software für Hardware basierte Produkte. Embedded Systeme sind fundamental komplexer als reine Software Produkte. Hier sind die Kunden, in der Literatur auch als Stakeholer bezeichnet, auch die Kollegen der anderen Fachbereiche Elektronik und Mechanik. Denn dort funktioniert Agilität etwas anders als bei Software. Der Klick auf „Kompilieren“ bei einer Leiterplatte kostet gerne vier- bis fünfstellig und dauert mehrere Wochen. Bei Kunststoff Spritzguss kann man an beide Werte noch eine Größenordnung dranhängen. Aber das sollte uns nicht davon abhalten hier auch Agilität zu denken. Dazu werden ich in späteren Beiträgen näher eingehen. In diesem Beitrag belassen wir es einfach mit der Erkenntnis, dass Kommunikation mit anderen Fachbereichen (oder auch Schnittstellenpartnern im gleichen Bereich) nicht nur ein „Soft Skill“ ist. Es ist der Schlüssel zum Erfolg. Entscheidungen trotz mangelnder Informationslage werden vereinfacht, wenn die Informationslage aktiv verbessert wird. Das ist einer der Grundsätze der Agilität. Transparenz in Fortschritt, Probleme und Meilensteinerreichung schaffen. Dabei geht es nicht darum einen Schuldigen am Projektverzug zu finden, sondern Transparenz zu schaffen um frühzeitig auf Probleme reagieren zu können.

Neben den Tätigkeiten im oben beschriebenen Projekt habe ich auch noch mein eigenes Team aufbauen dürfen. Gegründet wurde das Team während einer organisationalen Umstrukturierung. Der Organisationsaufbau hatte die letzten Jahre die einzelnen Geschäftsbereiche des Unternehmens mit einer eigenen Entwicklungsabteilung und eigenem Budget aufgesetzt. Durch globale Umstrukturierung in den Geschäftsbereichen wurden alle in der Niederlassung in der der ich arbeite ansässigen Entwicklungsabteilungen in eine neue Organisation transformiert. Dabei wurden Technologien in Chaptern organisiert, hier sind die einzelnen Personen mit Technologiebezug aufgehoben. So auch meine neue Gruppe mit Firmware und Embedded-Linux Bezug. Diese Chapter versorgen dann die unterschiedlichen Projekte mit Technologiewissen für die Implementierung der dort notwendigen Funktionalität. In der Theorie klingt das ganz logisch. Alle Softwareentwickler in eine Gruppe und dann Personenweise in die Projekte verteilt, um mögliche Freiräume so gut wie möglich abdecken zu können.

Um eine einheitliche Gestaltung der von den Chaptern erstellten Funktionalität über die Projekte zu erreichen wurden Technologie Arbeitsgruppen gebildet. Doch so schön das alles ist, sobald Projekte mit potenziellem Verzug drohen, werden alle vorausschauenden Tätigkeiten eingestellt, wenn sie nicht von einer bestimmten Person weiter getrieben werden.

„Du musst auch mal abgeben“ das war der Rat, den ich versucht habe zu befolgen. So habe ich die Aufgabe die Technologie Arbeitsgruppe für das einheitliche Embedded-Linux abgegeben. Ich wollte in dem Bereich nicht als der Manager erscheinen, der alles besser weiß und jetzt wird gemacht wie ich sage. Mir ist durchaus bewusst, dass ich fachlich teilweise weit hinter den Mitgliedern meines Teams zurückstehe. Ich bin Elektronik-Ingenieur und haben nur 15 Jahre Berufserfahrung . Das ist das nicht anders zu erwarten, wenn nur fähige und erfahrene Softwareentwickler in meinem Team sind. Aber ein Projekt ohne Budget und ohne direktes Produkt als Ergebnis zu leiten ist etwas neues, sowohl für mich als auch für die Softwareentwickler in meinem Team. Also musste ich nach einigen Monaten die schwere Entscheidung treffen, das ich das nicht delegieren kann sondern musste die Verantwortung für diese Projekt wieder zu mir nehmen. Das ist jetzt ungefähr ein Jahr her. In der Übergangsphase hatte ich dann drei Hüte auf. Das nie enden wollende Projekt für das Produkt Zubehör, die disziplinarische Leitung der Gruppe von Softwareentwicklern und die Leitung des Projekts zur Vereinheitlichung des Embedded Linux in unseren Produkten. In dieser Zeit lief nebenbei auch noch das berufsbegleitende Studium. Ich würde es nicht unbedingt empfehlen, aber ich habe in der Zeit neben den ganzen technischen, theoretischen und praktischen Erfahrungen auch viel über mich selbst und über meine Stressresistenz erfahren.

In der Zeit hat es geholfen in der Kommunikation auf volle Transparenz zu setzen. Ich weiß, dass ich in den letzten Jahren eine große Bandbreite an technischem Fachwissen aufbauen konnte, aber ich weiß auch, dass ich nicht alles weiß. Daher der klare Versuch im Team mit den Fachkennern das Vertrauen aufzubauen gemeinsam die beste Lösung zu finden. Auch wenn das nicht unbedingt die bequemste Lösung ist.

Abschließend möchte ich noch über ein Erfolg bei den ganzen Schwierigkeiten in den vorherigen Absätzen berichten. Diese Jahr haben wir genau ein Jahr lang mit agilen Methoden im Embedded-Linux Projekt gearbeitet. Wie die Transformation von „ja, agil hab ich schon mal gehört“ zu einem funktionierenden Ablauf im Team stattgefunden hat und welche Hürden auf dem Weg zu nehmen waren, ist dann Inhalt des nächsten Beitrags.

Ich habe während der Zeit meiner Ausbildung zum Elektronik-Ingenieur und der Zeit in der ich als solcher gearbeitet habe viele Beiträge hier verfasst. Seit November 2013 183 um genau zu sein. Als Elektronik-Ingenieur war ich lange Zeit tief in der Welt der Elektronischen Komponenten und Hardware von Embedded-Systemen verwurzelt. In dieser Zeit habe ich zusammen mit Chris einen Podcast gestartet, der es auf über 40 Episoden geschafft hat. Der Podcast ist bei Spotify und iTunes gelistet. Ich habe in der Zeit von Corona auch angefangen bei Twitch.tv zu streamen. Da gab es regelmäßig Content zu Elektronik, Embedded Software und alles rund um den Themenkomplex. Alles mit der Prämisse, bis es funktioniert und nicht weiter.

Anfang 2022 hat sich für mich eine neue Möglichkeit eröffnet und ich habe mich auf eine Gruppenleiterstelle beworben. Im April 2022 wurde das dann auch Realität: Ich bin jetzt nicht nur für die Erledigung meiner zugewiesenen Aufgaben zuständig, sondern auch noch für das Management von echten Menschen! Das ist etwas, dass ich während meiner Ausbildung nie für mich selbst gesehen habe. Manager sind die, die einem als Entwickler das Leben schwer machen, die Budgets klein halten und überall nur Kosten einsparen wollen. Und jetzt bin ich selbst in der Rolle mit der Intention es besser zu machen. Da war ich also nun mit meinem eigenen Team. Neu gegründet aus Personen, die während organisationaler Umstrukturierung in den Topf Embedded Linux und Firmware geworfen wurden. So ging sie los die Reise vom Elektronik Entwickler zum Software Engineering Manager.

Das erste Jahr war gefüllt mit „Altlasten“, also Projekten an denen ich noch Elektronik entwickelt habe, deren Laufzeit länger gingen als geplant (ein Symptom, das die ganze agile Transformation beheben sollte). Ich habe mit den ganzen neuen Ideen, meiner Vision für das Team und den organisationalen Struktur ein turbulentes Jahr erlebt, das geprägt war von Überstunden und teilweise starken Kontextwechseln. EMV-Probleme mit der Netzwerkeinheit eines Produkts, die ich noch als Elektronikentwickler designend habe, Zulassungsprobleme eines WiFi Funkmoduls im Frequenzbereich von WiFi6 und die nächste Besprechung, in der es die notwendigen Personalressourcen für die strategische Ausrichtung unseres Embedded Linux Projekts zu verteidigen galt. In all diesem Trubel wollte das Team auch einen gewissen Zusammenhalt entwickeln, also habe ich mich, neben den rein technischen Problemen auch noch zwischenmenschlichen Konflikten gewidmet. Das kalte Wasser in das ich geworfen wurde war sehr kalt. In dieser Zeit hat es geholfen, dass ich nicht alleine mit all diesen Themen stand. Ich hatte Mentoren in Form meines eigenen Vorgesetzten, anderen Gruppenleitern und einem Coach, mit der ich all die nicht technischen Probleme und Situationen durchsprechen und mit einem Blick „von Außen“ eingeordnet bekam.

Ich hatte im Laufe des Jahres immer mehr Kontakt zu anderen nicht Engineering Managern. Die haben teilweise eine ganz andere Sprache gesprochen, als das in der Entwicklung zwischen den Ingenieuren üblich war. Ich habe zu diesem Zeitpunk gemerkt, dass es hier ein Übersetzer benötigt, der sowohl mit den Ingenieuren die technischen Details besprechen, als auch mit den Betriebswirten, dem Marketing und allen anderen nicht technischen Rollen im Unternehmen sprechen kann. Also habe ich mich dazu entschieden ein Fremdsprachen Studium parallel zu meinem gefüllten Arbeitstag zu verfolgen. Ich habe MBA General Management an der Hochschule Fresenius studiert.

Die einzige Möglichkeit hierfür Platz zu schaffen war es für die Zeit des Studiums andere Hobbys zu pausieren. Daher gab es seit Januar 2023 auch keine Podcasts oder Twitch streams mehr. Ich habe in der Zeit stattdessen die Felder der Agilen Führung von Unternehmen, Finanzorganisation, Marketing Management, Internationales Management, Generative KI, Datenanalyse für unternehmerische Entscheidungen, wirtschaftswissenschaftliche Modellierung, Organisationsmanagement, strategisches Management, Personalmanagement, Digitalisierung und Volkswirtschaftliche Managemententscheidungen ergründet.

Alle diese Disziplinen habe ich mit dem Blick des Elektronik-Ingenieurs begonnen und, so hoffe ich zumindest, mit einem erweiterten Horizont beendet. Warum möchte ich also wieder mit dem Bloggen beginnen? Ich habe im Studium viel Text produziert. Das hat mir geholfen Konzepte wirklich zu verstehen. Dabei war ein großer Faktor das wirklichen ausformulieren meiner Gedanken und nicht nur das stichpunktartige auflisten von Schlagworten, oder kurzen Sätzen. Ich möchte einerseits für mich das ganze weiterführen, also Konzepte ausformulieren, damit ich sie für mich selbst besser greifbar mache, andererseits aber auch anderen die Möglichkeit geben mit mir gemeinsam zu lernen und zu wachsen.

Ich bin der festen Überzeugung, dass wenn wir immer in der Komfortzone bleiben in der wir alles gut genug können, wir einen ganz großen Teil dessen verpassen, was wir leisten könnten. Daher werden hier in der nächsten Zeit in unregelmäßigen Abständen Beiträge erscheinen, in denen ich praktische Einblicke für Ingenieure, die in Führungsrollen wechseln geben möchte. Außerdem habe ich mich im Laufe des Studium mit agilen Methoden, nicht nur für die Softwareentwicklung, beschäftigt und möchte auch hierzu meine Gedanken ausformulieren.

Mein Ziel: Ich bringe mir selbst Klarheit in Bereiche in denen ich bisher hauptsächlich unbewusst agiert habe und gebe euch die Möglichkeit mit mir dazu in den Dialog zu gehen.

Was euch erwartet: Persönliche Geschichten aus meiner Transformation vom Elektronik Entwickler zum Engineering Manager; Lessons Learned aus der agilen Praxis wenn es sich nicht nur um Softwareprodukte handelt; Technische und organisatorische Tipps für stabile Prozesse, die für mich funktioniert haben.

Warum das für dich wichtig ist: Vielleicht befindest du dich nicht in meiner Situation, arbeitest aber mit Personen die es sind; Oder du hast ein ganz anderes Umfeld, das überhaupt nichts mit Entwicklung zu tun hat. Es ist erstaunlich welche Parallelen es zwischen vermeintlich unabhängigen Umfeldern gibt.