Systementwicklung für Flugzeuge über das Review hinaus: menschliche Chemie und die leise Kunst guter Entwicklung

Ich höre Führungskräften immer gern zu, wenn sie von Momenten erzählen, in denen sie durch schwierige erste Erfahrungen gelernt haben.

Nicht wegen der Dramatik, obwohl im Fall von Carol Erikson ein Satellitenprogramm durch spät entdeckte Testfehler beinahe scheiterte. Ich hörte zu, weil sie es so schlicht ausdrückte: „Wir hatten kein gründliches Design-Review durchgeführt.“ So einfach. So vermeidbar. So real.

Carol Eriksons vier Jahrzehnte in der Systementwicklung für Flugzeuge zeigen, dass gute Reviews Fehler früh erkennen – nicht allein die Tools.

Carol verbrachte fast vier Jahrzehnte bei Northrop Grumman. Lange genug, um sich an die Zeit zu erinnern, als Dokumente für Reviews persönlich übergeben und Designfreigaben per Kurier transportiert wurden. Lange genug, um zu erleben, wie sich die Luft- und Raumfahrt von Analogplatinen und Thermalvakuumkammern zu umfassenden digitalen Umgebungen entwickelte. Wenn sie über Systemintegrität spricht, bietet sie keine Theorie an. Sie erinnert sich an die Anspannung im Reinraum, wenn ein Sensor beim Test Risse bekommt, weil sechs Monate zuvor niemand ein Problem mit den Sicherheitsreserven erkannt hat.

Solche Momente trägt man mit sich. Sie prägen Instinkte, die man nicht immer in Worte fasst, die aber jede spätere technische Entscheidung leiten.

Früh simulieren, oft miteinander sprechen

Wenn Carol über Simulation sprach, tat sie das mit einer Dringlichkeit, die ich zuletzt in vielen Hardwarebereichen gehört habe. Die Tools sind heute besser. Man kann thermisches Verhalten vor dem Prototyp modellieren und Antennenverhalten simulieren, bevor eine Leiterplatte überhaupt layoutet wird. Sie betonte jedoch sofort, dass nicht die Tools für Geschwindigkeit sorgen, sondern die Kultur.

Ihre Teams nutzten Simulation, um Iterationen früher zu ermöglichen. Wer einen Test in Software ausführen und noch am Tag einer Idee die Auswirkungen einer Designänderung verstehen kann, spart sich Wochen des Ausprobierens. Das funktioniert aber nur, wenn Menschen es gewohnt sind, Ideen zu teilen, Fortschritte häufig zu prüfen und schwierige Fragen früh zu stellen.

Sie nannte Ansys als Toolset, das dies ermöglichte. Doch ihr Lob galt nicht der Software an sich, sondern dem Arbeitsrhythmus, den sie unterstützte: kurzen Rückkopplungsschleifen, klaren Zusammenhängen zwischen Ursache und Wirkung und einem Umfeld, in dem Denken und Umsetzen ineinandergreifen durften.

Annahmen machen EMI zum größten Problem

Für Luft- und Raumfahrtelektronik ist Simulation nicht nur ein Schritt im Ablauf. Sie bildet das Gerüst verantwortungsvoller Entwicklung.

Simulation zeigt, besonders in Verbindung mit elektromagnetischen Solvern, wie stark Signaltreue vom physischen Pfad abhängt. Ein Signal, das die Lage wechselt, muss seinen Rückstrom mitnehmen. Wechselt die benachbarte Referenzfläche von Masse zu Versorgung und bietet das Layout keinen durchgängigen Rückstrompfad, muss der Strom einen anderen Weg finden, meist über einen Entkopplungskondensator oder einen Verschiebungsstrompfad. Hochfrequente Rückströme verlaufen bevorzugt nahe dem Signalleiter. Jede Unterbrechung der Referenzfläche oder jeder abrupte Lagenwechsel stört diesen Strom und führt zu hochfrequentem Rauschen, Resonanzen oder abgestrahlten Emissionen. Das sind keine rein akademischen Phänomene, sondern Fehler, die eine Mission im Orbit beenden können.

Dieser Umweg vergrößert die Schleifenfläche. Größere Schleifen strahlen mehr Energie ab. Was wie ein ordentliches Layout aussieht, kann zu einer abstrahlenden Struktur werden und Emissionen erzeugen, die ohne Modellierung schwer vorherzusagen sind. Sie können empfindliche Analogschaltungen stören oder kritische Sensormessungen beeinträchtigen.

In der Luft- und Raumfahrt verschärfen sich diese Folgen, weil mehrere Systeme enge Gehäuse teilen und abgestrahlte Emissionen nicht nur die Einhaltung von Vorschriften betreffen, sondern auch die Missionsleistung. Entwickler müssen den Lagenaufbau als zentrales Werkzeug zur Steuerung von Stromfluss und Feldbegrenzung behandeln, nicht als nachträglichen Gedanken.

Simulationsgestützte Entwicklung deckt Probleme auf, bevor Hardware existiert. Gerade bei EMI treffen Entwickler oft folgenschwere Fehlannahmen: „Gut genug“ ist häufig eben nicht ausreichend. Selbst kleine Änderungen des Lagenaufbaus verursachen Impedanzfehlanpassungen und Schlitzantenneneffekte. Besonders bei hochdichten Platinen wird elektromagnetische Simulation damit zu einem Werkzeug der Risikominderung auf Führungsebene.

Hardware für die Luft- und Raumfahrt bewegt sich an der Grenze zum Versagen. Je besser Simulation Physik und Systemintegration abbildet, desto mehr wird sie zu einem zentralen Entwicklungsergebnis und nicht nur zu einem Freigabeschritt.

Die Chemie eines guten Teams

In unserem Gespräch kamen Carol und ich immer wieder auf ein Wort zurück, das in technischen Umfeldern zu wenig Anerkennung erhält: Chemie.

Nicht die Chemie des Periodensystems, sondern die zwischen Menschen. Die leisen Signale zwischen Disziplinen. Die Momente, in denen sich eine Thermikingenieurin und ein Systemintegrator endlich zusammensetzen, eine Unstimmigkeit entdecken und beheben, bevor sie die Fertigung erreicht. Carol sprach oft von solchen Momenten. Sie beschrieb Reviews als Orte unerwarteter Gespräche, an denen die richtigen Menschen die richtigen Probleme zum richtigen Zeitpunkt erkennen, statt als bloße Freigabehürden.

Dieser zwischenmenschliche Rhythmus entsteht nicht aus Prozessdiagrammen. Er entsteht aus einer Kultur der Klarheit, des regelmäßigen Kontakts und eines gemeinsamen Verständnisses guter Arbeit. Wenn sie tägliche oder wöchentliche Stand-ups beschrieb oder die Praxis, jederzeit alle zum Ansprechen von Fragen einzuladen, dann nicht aus Glauben an ein flaches Organigramm. Sie hatte erlebt, was geschieht, wenn Menschen sich sicher genug fühlen, einen Zweifel zu äußern, bevor daraus ein Fehler wird.

Führung in technischer Sprache

Carols Führungsstil bestand nicht darin, aus einer Tabellenkalkulation heraus zu steuern. Sie war tief in die Details eingebunden und, noch wichtiger, übersetzte zwischen ihnen. Sie verstand genug von Systemen, Software und Beschaffung, um funktionsübergreifend glaubwürdig zu sprechen. Diese Fähigkeit zur Vermittlung trennt oft Projekte, die sich mühsam vorwärtsbewegen, von Programmen, die Fahrt aufnehmen.

Sie begeistert sich für digitale Transformation, doch ihr Blick darauf ist in Menschen verankert. Es geht nicht um glänzende Tools oder darum, alle auf eine neue Plattform zu drängen. Es geht darum, einem Team zu zeigen, wie seine Beiträge in den größeren Zusammenhang passen. Beschaffung, Test, Design und Fertigung sind bewegliche Teile mit unterschiedlichen Anreizen, Zwängen und Sprachen. Sie wusste, dass sie sich nicht von selbst aufeinander abstimmen. Es braucht Führungskräfte, die Menschen immer wieder auf ein gemeinsames Zentrum ausrichten.

In dieser Art von Führung liegt eine tiefe Zufriedenheit. Man baut das Produkt nicht mehr direkt. Man schafft das Umfeld, in dem gute Entwicklung überhaupt stattfinden kann.

Die Zufriedenheit fundierter technischer Führung

Technische Arbeit gut zu führen bereitet eine besondere Freude. Man erlebt nicht nur den Reiz, ein Problem zu lösen, sondern auch die stille Zufriedenheit, anderen zu helfen, es besser zu lösen, als man es allein gekonnt hätte. Carol strahlt diese Art von Führung aus. Sie treibt Produkte nicht aus der Ferne voran. Sie formt Teams, die mit Zuversicht, Sorgfalt und gemeinsamem Verständnis arbeiten.

So zu führen braucht Geduld. Und Liebe zur Sache. Man muss die Tools mögen, aber auch die Abwägungen. Das Produkt, aber auch das merkwürdige zwischenmenschliche Zusammenspiel aus Reviews, Stand-ups, E-Mails und nächtlichen Fehlerrunden. Man muss Klarheit lieben. Denn im Nebel aus Terminen, Versionen und Beschaffungsdebatten ist es die Klarheit, die die Arbeit schützt.

Carol sagte nie, sie wolle die klügste Person im Raum sein. Stattdessen sprach sie davon, Räume zu schaffen, in denen kluge Menschen sich entfalten können.

Entwicklung ist Vermittlung

Carols Laufbahn ist nicht nur deshalb interessant, weil sie Produkte funktionsfähig hielt. Sie sorgte gleichzeitig dafür, dass die Organisation funktionierte.

Denn die Realität ist: Kein Entwickler arbeitet allein. Jede Disziplin wird von der nächsten ein wenig missverstanden. Software denkt in Zeitabläufen, Mechanik in Volumina, Thermik in Gradienten, Systementwicklung in Strukturen. Wenn niemand die Übersetzungs- und Vermittlungsarbeit leistet, hält das System nicht zusammen.

Carol machte das zu ihrer Aufgabe. Durch Sorgfalt, Reviews und Struktur statt durch inspirierende Reden. Sie stellte sicher, dass der Kommunikationstechniker hörte, was die Thermikleitung beunruhigte. Sie fragte, warum niemand aus der Beschaffung den Beschaffungszeitplan geprüft hatte, bevor ein Prototypentermin zugesagt wurde.

Sie abstrahierte das nicht zu Schlagworten über Unternehmenskultur. Sie behandelte es wie ein technisches Problem: Fehlermöglichkeiten erkennen und ihnen mit Prozessen, Tools und Rückmeldung begegnen.

Vielleicht ist genau das Führung in der Entwicklung: Klarheit unter Randbedingungen, jenseits von Geschichten und Charisma.

Was ein System wirklich bedeutet

Viele Menschen hören „System“ und denken an formale Diagramme, Abhängigkeitsbäume oder vielleicht ein SysML-Diagramm. Wenn Carol das Wort verwendete, meinte sie etwas viel Konkreteres.

Ein System ist die E-Mail-Kette, aus der eine Stücklistenänderung wird. Es ist das undokumentierte Wissen einer Testtechnikerin über einen Steckverbinder, der zu thermischer Drift neigt. Es ist das fünfminütige Gespräch, das eine sechswöchige Verzögerung verhindert. Ein System ist die Summe technischer Teile und menschlicher Gewohnheiten. Dazu gehören Prüfstände und Flurgespräche, Jira-Tickets und ungeschriebene Regeln darüber, wer was prüft.

Im Entwickleralltag ist ein System alles, was prägt, wie Arbeit erledigt wird: der Kontext, in dem man sich bewegt, die Übergaben, die man organisiert, und die Lücken, die man stillschweigend schließt, ohne darum gebeten zu werden.

Wenn Carol von besseren Systemen sprach, meinte sie all das: Rückkopplungsschleifen enger machen, Rollen klären, Überraschungen reduzieren und gemeinsames Verständnis stärken. Sie vereinfachte nicht die Arbeit. Sie stärkte die Verbindungen, die Komplexität zusammenhalten.

Wer gut entwickeln will, muss das System verstehen, in dem er arbeitet. Wer gut führen will, muss dieses Verständnis für andere erweitern.

Die Entwicklerin hinter der Geschichte

Carols Vater arbeitete an der Mondlandefähre. Sie wuchs mit Geschichten über Rechenschieber und Zeichentische auf. Heute arbeitet sie mit Toolchains, die Simulationsumgebungen, integrierte Testinfrastruktur und Echtzeit-Review-Plattformen umfassen. Doch wenn sie über das Wesentliche nachdenkt, geht es immer um Menschen. Um Gespräche. Um Entwickler verschiedener Disziplinen, die früh und klar genug miteinander sprechen, um später böse Überraschungen zu vermeiden.

Ihre liebsten Erinnerungen stammen nicht aus technischer Perfektion, sondern aus schwierigen Momenten, die gemeinsam bewältigt wurden. Teams, die sich von Fehlschlägen erholten, indem sie präsent waren, Wissen teilten und die Mission im Blick behielten. Das ist gute technische Führung: durch die schwierigen Phasen führen.

Inzwischen hat sie eine Beratung gegründet und bringt ihren Ansatz in Unternehmen ein, die Ambition und Umsetzung besser aufeinander abstimmen müssen. Als sie einem Freund aus dem Branding einen Broschürenentwurf zeigte, sagte er, das klinge spannend, aber er verstehe kein Wort davon. Sie lachte. „Dann muss ich wohl noch etwas umschreiben.“

Auch heute arbeitet sie noch an der Kunst des Vermittelns. Daran erkennt man, dass sie weiterhin Ingenieurin ist.

Abschließende Gedanken

Carol vermittelte mir in einem kurzen Gespräch viel. Nicht durch große Schlussfolgerungen, sondern durch die Art, wie sie die Arbeit beschrieb: ruhig, klar, zielgerichtet. Eine Art der Entwicklung, die so tief geht, dass sie leise sein kann.

Das ist mir geblieben:

• Entwicklung lebt in den Verbindungen, nicht nur in den Bauteilen.
• Gute Reviews schaffen mehr Wert als gute Tools.
• Kommunikation ist keine bloße Sozialkompetenz. Sie ist ein strukturelles Element.
• Führung schafft im besten Fall Umfelder, in denen hervorragende Arbeit selbstverständlich ist.

Und vielleicht am wichtigsten: Systeme existieren nicht ohne Menschen. Wer möchte, dass die Maschine funktioniert, sollte verstehen, wie die beteiligten Menschen denken, sprechen und zusammenarbeiten.

Carol versteht das. Und es zeigt sich in allem, was sie aufbaut.

Wenn Sie ein Programm gestalten und dessen Grundlagen stärken möchten, ist Carol eine gute Ansprechpartnerin. Und wenn Sie solche Geschichten über die Kultur und das Handwerk großartiger Entwicklung interessieren, folgen Sie weiter Hardware Rich Development. Es kommt noch mehr.