Die gesamte Serie lesen
Dieser Artikel ist Teil einer ausführlichen Anleitung dazu, wie wir mit Quilters physikgestützter Layout-Automatisierung einen Computer auf Basis des NXP i.MX 8M Mini nachgebaut haben.
Carol Erikson verbrachte fast vier Jahrzehnte in einem der komplexesten Engineering-Unternehmen der Welt: Northrop Grumman. Sie leitete Entwicklungsteams für Satellitensysteme mit beschränktem Zugang, verantwortete Initiativen zur digitalen Transformation in der Raumfahrt und half, Programme von so großer Bedeutung wie die nächste Generation der US-amerikanischen ICBM-Plattform zu steuern. Fragt man sie jedoch, woran ein Programm wirklich gelingt oder scheitert, spricht sie nicht zuerst über Budgets, Spezifikationen oder Zeitpläne.
Sie spricht über Menschen. Und Systeme. Und die Kommunikation dazwischen.
„Was mir vor allem in den Sinn kommt“, sagte sie mir, „ist Systemdenken – und Kommunikation. Die Fähigkeit, Brücken zwischen Disziplinen zu schlagen und wirklich zu verstehen, wie die Teile zusammenpassen. Das lässt sich nicht einfach vermitteln. Aber es ist unverzichtbar.“
Unser Gespräch reichte von frühen Fehlschlägen und Simulationswerkzeugen bis zur Frage, was es bedeutet, ein Team so zu entwerfen wie eine Nutzlast. Im Kern stand jedoch eine einfache Erkenntnis: Beim Entwickeln von Hardware geht es nie nur um die Hardware.
Von Flugsoftware an die Spitze der digitalen Transformation
Carol begann direkt nach dem Studium bei Northrop Grumman und stieg in die Entwicklung von Flugsoftware für Satellitensysteme ein. Sie hatte ein fundiertes technisches Wissen und erkannte früh, wie eng Software und Hardware unter Weltraumbedingungen miteinander verflochten sind.
„Man musste Lageregelung, Temperaturregelung, Kommunikationssysteme verstehen – das gesamte System. Das zwang mich, wie eine Systemingenieurin zu denken, selbst wenn ich nur Code schrieb.“
Diese Denkweise führte sie in den Missionsbetrieb, dann ins Systems Engineering und schließlich in die Programmleitung und in Führungspositionen auf Unternehmensebene. Mit jedem Schritt weitete sich ihr Blick. Doch sie kehrte immer wieder zu denselben Herausforderungen zurück: Wie koordiniert man technische Disziplinen? Wie vermeidet man Überraschungen in späten Phasen? Und wie hält man Teams auf einem gemeinsamen Kurs, wenn viel auf dem Spiel steht und die Systeme sehr umfangreich sind?
Ihre Antwort lief zunehmend auf Struktur und Kommunikation hinaus.
„Als VP of Engineering war es einer meiner wichtigsten Schwerpunkte, Silos aufzubrechen. Und als ich zur digitalen Transformation wechselte, ging es darum, Kommunikation nicht nur zwischen Teams, sondern zwischen Funktionen zu ermöglichen: Entwicklung, Beschaffung, Fertigung, Programmmanagement. Zwischen allen.“
Wenn Reviews zu spät kommen
Carol strahlt Ruhe aus, doch ihre Geschichten haben Gewicht. Besonders eindrücklich war eine aus einem großen nationalen Wettersatellitenprogramm, in dem sie als Nutzlastmanagerin tätig war. Sie musste die Entwicklung mehrerer Sensoren koordinieren – jeder von einem anderen Auftragnehmer, alle unter engem Zeitdruck.
Und dann schlugen die Tests fehl.
„Wir hatten Sensoren von fünf verschiedenen, etablierten Luft- und Raumfahrtunternehmen. Einer nach dem anderen fiel bei elektrischen, thermischen oder Vibrationsprüfungen durch. Wir testeten nach dem Prinzip ‚Test like you fly‘ und simulierten Start- und Weltraumbedingungen. Und diese Geräte hielten einfach nicht stand.“
Die Ursache lag nicht in der Fertigung. Sie lag im Prozess.
„Wir hatten die Sensorentwürfe von unserem Kunden übernommen. Dort waren keine ordentlichen Designreviews durchgeführt worden, weil man angenommen hatte, die Sensoren seien bereits im All geflogen und damit ‚flugerprobt‘. Und wir haben das nie nachträglich überprüft. So fanden wir spät in der Testphase Probleme, die wir schon im Design hätten erkennen müssen.“
Die Lösung? Den Reviewprozess stärken und sicherstellen, dass jede Fachfunktion beteiligt war.
„Jedes wichtige Review – vorläufiger Entwurf, kritischer Entwurf, Testbereitschaft – musste interdisziplinär sein. Der Elektroingenieur musste dem Thermikspezialisten zuhören. Die Leitung der Nutzlastintegration musste mit den Software- und Energieversorgungsteams sprechen. In diesen Reviews finden die Gespräche statt. Dort beginnt die eigentliche Integrationsarbeit.“
Agilität mit kleinem a
Carol schätzt Agile – allerdings mit Einschränkungen.
„Bei Northrop sprachen wir vom ‚großen A‘ und ‚kleinen a‘. Das ‚große A‘ bedeutete, jede Agile-Regel genau nach Lehrbuch zu befolgen. In der Hardwareentwicklung kann das jedoch zulasten der Anforderungsdefinition und gründlicher Tests gehen. Das ‚kleine a‘ bedeutete, die Prinzipien – Iteration, schnelles Feedback, Reaktionsfähigkeit – zu übernehmen und klug anzuwenden.“
Sie ist nicht dogmatisch. Sie ist pragmatisch.
„Agile Praktiken müssen zum Produkt, zum Team und zur Branche passen. Ich habe erlebt, dass Agile hervorragend funktioniert, wenn eine starke Führungskraft sowohl Agile als auch klassisches Systems Engineering versteht. Und ich habe erlebt, dass es scheitert, wenn es nur noch darum geht, Kästchen abzuhaken.“
Ein entscheidendes Hilfsmittel, auf das sie immer wieder verweist, ist Simulation.
„Wenn man die Leistung früh simulieren kann, kann man früh iterieren. So entsteht Geschwindigkeit. Man muss nicht warten, bis ein Prototyp auf dem Prüfstand auseinandergerüttelt wird. Man modelliert, testet und passt an, solange alles noch in der Software stattfindet.“
Ihre Teams nutzten unter anderem die Simulationssuite von Ansys mit umfangreichen Bibliotheken für HF-, thermische und systemweite Analysen. Doch selbst mit den besten Werkzeugen hing der Erfolg von Struktur und Kultur ab.
„Man kann ein Problem nicht einfach mit einem Werkzeug bewerfen. Man braucht geschulte Ingenieure, einen Rhythmus für Iterationen und Kommunikation in alle Richtungen.“
Wie Systemdenken in der Praxis aussieht
Carol verklärt Systemdenken nicht. Sie sagt klar, dass es schwer zu vermitteln und noch schwerer in die Praxis umzusetzen ist. Dennoch hält sie es für unverzichtbar.
„Viele Ingenieure verlassen die Hochschule mit einer starken Grundlage in ihrem Fachgebiet. Aber fachübergreifend kommunizieren? Zielkonflikte auf Systemebene bearbeiten? Dafür braucht es Erfahrung.“
Für sie bedeutet Systemdenken, über das eigene Fachgebiet hinauszusehen und zu verstehen, wie sich Designentscheidungen auf das gesamte Programm auswirken.
„Ein Leiterplattenlayout zu optimieren ist das eine. Zu erkennen, wie dieses Layout Wärmeabfuhr, Verkabelung, Integration und Zugang für Tests beeinflusst, ist etwas anderes. Auf dieser Ebene müssen mehr Ingenieure denken.“
Sie befürwortet mehr fachübergreifende Möglichkeiten im Studium, sieht aber auch heute noch eine Lücke.
„Noch immer ist das zu oft die Ausnahme. Wenn Studierende nicht an einem speziellen Robotikprogramm oder einem fachübergreifenden Abschlussprojekt teilnehmen, begegnen sie der Gesamtsystemsicht möglicherweise nie.“
Sie hält es außerdem für wichtig, Ingenieure zu unterstützen, während sie in diese Denkweise hineinwachsen.
„In meine Teams kamen außerordentlich fähige Ingenieure ohne Systemerfahrung. Aber gibt man ihnen Einblicke, Mentoring und die richtige Struktur, entwickeln sie sich schnell.“
Die Rolle der Kultur für den Engineering-Erfolg
Einige der nachdenklichsten Passagen unseres Gesprächs drehten sich um Teamdynamik. Wie misst man den Erfolg eines Teams? Wie baut man ein erfolgreiches Team auf?
„Es gibt nicht immer gute Kennzahlen“, sagte Carol. „Wir nutzten Mitarbeiterbefragungen, um einen Eindruck von der Wirksamkeit zu gewinnen. Aber ehrlich gesagt beruht vieles auf Beobachtung. Man muss nah genug am Team sein, um zu spüren, wann die Kommunikation fließt und wann nicht.“
Sie betonte regelmäßige Kontaktpunkte. Keine Überwachung, sondern einen Rhythmus.
„Je nach Komplexität der Aufgabe hatten wir tägliche oder wöchentliche Stand-ups. Gleichzeitig lebten wir eine Kultur der offenen Tür. Wenn etwas aufkam, setzten wir uns kurz zusammen – virtuell oder persönlich. Jeder wusste, dass er jederzeit darum bitten konnte.“
Sie wies auch darauf hin, dass Erfolg oft in einer subtilen Abstimmung sichtbar wird: Menschen vervollständigen in Besprechungen die Gedanken der anderen. Ingenieure lösen ohne Aufforderung funktionsübergreifend Probleme. Entwicklungs- und Testteams arbeiten mit einem gemeinsamen Verständnis.
„Das kann man nicht erzwingen. Aber man kann es ermöglichen.“
Gedanken über Wandel – und Kontinuität
Carols Karriere umfasst mehrere Technologiegenerationen. Sie erinnert sich daran, wie ihr Vater als Ingenieur am Apollo-Programm arbeitete, von Hand zeichnete und mit dem Rechenschieber rechnete.
„Es ist erstaunlich, was sie mit so wenigen Hilfsmitteln erreicht haben. Heute können wir mit Simulation, KI und integrierten Werkzeugketten so viel mehr leisten. Aber ich glaube, der Kern hat sich nicht verändert.“
Dieser Kern ist für sie durchdachtes Engineering. Sorgfältiges Design. Teamarbeit, die funktioniert. Verantwortungsbewusstsein für die Mission.
Heute beginnt sie eine neue Rolle und gründet ihre eigene Engineering-Beratung. Schon beim Verfassen der Broschüre begegnete ihr erneut die Bedeutung verständlicher Vermittlung.
„Ich schickte sie einem Freund aus dem Branding-Bereich. Er sagte, es klinge spannend, aber er verstehe nichts davon. Das erinnerte mich daran: Technische Kommunikation braucht immer Kontext. Man muss Menschen dort abholen, wo sie stehen, selbst wenn die Arbeit komplex ist.“
Erkenntnisse aus einer Karriere in der Praxis
Während ich Carol von ihrer Arbeit erzählen hörte, kehrte ich immer wieder zu einem Gedanken zurück: Sie hat sowohl Hardware als auch Kultur gestaltet. Sie hat Produkte entwickelt, aber ebenso die Umgebungen geschaffen, in denen großartige Produkte entstehen können.
Einige Erkenntnisse:
- Designreviews sind wichtig: Nicht wegen formaler Vorgaben, sondern wegen der Gespräche. In Reviews stimmen sich funktionsübergreifende Teams ab und erkennen kleine Probleme, bevor sie groß werden.
- Simulation vervielfacht die Möglichkeiten: Früh in Modellierungswerkzeuge und Fachwissen zu investieren, schafft Zeit, Klarheit und Vertrauen. Es macht aus Vermutungen konkretes Handeln.
- Agile ist eine Haltung, kein Regelbuch: Erfolgreiche Teams iterieren, passen sich an und kommunizieren. Ob das Agile heißt, ist weniger wichtig als die Frage, ob es funktioniert.
- Systemdenken ist eine Fähigkeit und eine Kultur: Mit der richtigen Struktur und den richtigen Einblicken entwickeln Ingenieure sie weiter. Führungskräfte können dieses Wachstum beschleunigen.
- Kommunikation macht Erfolg im Hintergrund möglich: Vom Nutzlastdesign bis zur digitalen Transformation gelingen jene Projekte, in denen Menschen über Grenzen hinweg miteinander sprechen – und zuhören.
Carol Erikson hat Teams durch einige der anspruchsvollsten technischen Herausforderungen unserer Zeit geführt. Doch nicht nur ihr Lebenslauf beeindruckt, sondern ihre Klarheit. Ihre Geduld. Ihre Weigerung, technischen Erfolg von menschlichem Erfolg zu trennen.
Das ist der Kern von Hardware Rich Development. Und genau diese Art von Führung braucht dieses Fachgebiet häufiger.
