Engineers: „So machen wir das hier nicht“ ist keine Strategie

Dieser Artikel ist gemeinsam entstanden mitFelix Huschka – Danke für deine Gedanken und die nächtlichen Diskussionen :-)

„So machen wir das hier nicht."

Wer schon mit Engineers in einem regulierten Unternehmen gearbeitet hat, kennt diesen Satz. Ruhig, vernünftig, gesprächsbeendend.

Jahrelang war das keine Sturheit – es war Risikomanagement. Im Unternehmens-Engineering ist Irren teuer, manchmal illegal und gelegentlich schlagzeilenträchtig. Das System optimiert auf Vorhersagbarkeit: Nachweise, Nachvollziehbarkeit und eine starke Neigung zuFass es nicht an, wenn du nicht musst.

Diese Logik funktionierte, solange die Fleißarbeit – Anforderungen formulieren, Testfälle schreiben, Normen zusammenfassen, Compliance-Dokumentation erstellen – der Ort war, an dem Engineers ihr Gehalt verdienten.

KI nimmt dieser Logik die Grundlage. Sie interessiert sich nicht für eure Tradition, eure Gate Reviews oder dafür, wie lange das letzte Anforderungsdokument gedauert hat. Sie wird nicht um Erlaubnis fragen. Sie erledigt die Entwurfsarbeit schlicht schneller, als eure Organisation das Abstimmungsmeeting darüber terminieren kann, ob man sie erlauben soll.

In euren Lenkungskreis wird sie auch nicht kommen.

Eine Einordnung: Es geht hier um Engineering in großen Unternehmen – regulierte Umfelder, sicherheitsrelevante Produkte, lange Lieferketten, jene Art von Arbeit, bei der ein Fehler nicht nur ein Feature bricht, sondern Audits, Rückrufe oder eine Eskalation um drei Uhr nachts auslöst. Nicht das Drei-Personen-Start-up. Nicht die „Wir haben eine Landingpage ausgeliefert"-Variante von Engineering.

Warum Engineers sich gegen Veränderung wehren (und warum das nicht irrational ist)

Die meisten Engineers sind darauf trainiert, Korrektheit über Neuheit zu stellen. Das ist keine Charaktereigenart – es ist eine Reaktion auf Randbedingungen. Wenn späte Änderungen Nachtests, Rezertifizierung, Nachverhandlungen mit Lieferanten und Terminverzug bedeuten, bevorzugt die Organisation naturgemäß Vorgehen, die Unsicherheit früh reduzieren.

Das ist die Logik hinter Stage-Gate und planbasierter Governance. Bianchi, Marzi und Guerini (2020) fassen die zugrunde liegende Spannung sauber: Stage-Gate zielt darauf, Unsicherheit vorab zu reduzieren; Agilität ist darauf ausgelegt, sich länger in der Entwicklung an Unsicherheit anzupassen. [1] Zwei valide Antworten auf Risiko. Eine davon wird routinemäßig aufgefordert, sich wie die andere zu verhalten. Und dann wundern wir uns, dass niemand zufrieden ist.

Warum sich „agil" im Engineering oft wie ein schlechter Witz anfühlte

Viele Unternehmen haben keine Agilität ins Engineering eingeführt. Sie haben agiles Vokabular eingeführt.

Stand-ups in einer Stage-Gate-Welt. Backlogs, die weiterhin die Freigabe des Lenkungskreises brauchen. Sprints, die enden mit „großer Fortschritt – jetzt warten wir auf das nächste Gate". Führungskräfte nannten das agil. Engineers nannten es „mehr Meetings". Beide Beschreibungen waren richtig.

McKinsey ist dazu ungewöhnlich deutlich: In ihren Agile-für-Hardware-Einführungen bei mehr als 20 Unternehmen wurde Stage-Gate in jedem einzelnen Fall neben Agilität beibehalten, um Agilität mit langfristiger Governance „in Schach" zu halten. [2]

Das kann ein sinnvoller Kompromiss sein. Es erklärt aber auch, warum so viele Engineers mit dem Satz weggingen: „Agil funktioniert hier nicht." Was sie erlebt haben, war kein neues Liefersystem. Es war zusätzliche Zeremonie auf dem alten – dieselben Gates, plus ein tägliches Meeting um 9 Uhr.

Der Hybrid kann auch aktiv dysfunktional werden. Eine Fallstudie zur Entwicklung eingebetteter Systeme aus dem Jahr 2022 beschreibt einen agilen Lieferanten, der zu planbasierten Meilensteinen gedrängt wurde und zu dem griff, was die Autoren „keeping up appearances" nennen: Fortschritt gegen Meilensteine zu berichten, von denen das Team wusste, dass sie unrealistisch waren – was Machbarkeit und Qualität untergrub. [3] Wer je in einem Status-Review saß, in dem das grüne Ampelsignal merklich grüner war als der tatsächliche Stand, hat dieses Paper in Echtzeit erlebt.

Und dann ist da noch die Toolchain

Engineering hat nicht nur eine Risikokultur. Es hat eine Werkzeuglandschaft, die sich auf einer anderen Zeitskala verändert als nahezu jede andere Funktion im Unternehmen.

Die PLM-Migration, die 2019 begann, läuft noch. Der ALM-Rollout, zu dem sich das Unternehmen 2017 verpflichtet hat, wird in Werk 7 immer noch eingeführt. Die CAD-Umgebung ist eine Hauptversion hinter dem aktuellen Stand, weil der Validierungszyklus der CAM-Toolchain 18 Monate dauert und niemand Lust hat, ihn zu starten. Anforderungen leben in DOORS, dann in DOORS Next, dann irgendwann in etwas anderem – nach dem nächsten Lenkungskreis.

Das ist kein langsames Engineering. Es ist die Physik großer Unternehmens-Toolchains: Jede Änderung kaskadiert durch CAD, Simulation, Fertigungsplanung, Lieferanten, Qualität, regulatorische Dokumentation und zwei Jahrzehnte Altdaten, die migriert werden müssen, ohne Nachvollziehbarkeit zu verlieren. Mehrjährige Programme mit achtstelligen Budgets sind normal. Ein bis zwei Jahre Verzug sind normal. Stilles Descoping ist ebenfalls normal.

Wer ein Jahrzehnt in diesem Umfeld verbracht hat, hat mehrere „Das wird unsere Arbeitsweise transformieren"-Programme dabei beobachtet, wie sie neue Logos auf alten Bildschirmen lieferten. Skepsis gegenüber dem nächsten großen Ding ist kein Charakterfehler. Es ist Mustererkennung.

Die Falle ist die Annahme, KI werde demselben Muster folgen.

Wird sie nicht. KI wartet nicht auf die PLM-Migration. Sie braucht keinen Lenkungskreis, der ein neues führendes Werkzeug freigibt. Sie läuft neben dem, was ohnehin existiert – entwirft Anforderungen, während Engineers sie noch in DOORS tippen; erzeugt Testvektoren, während das Testmanagement-Werkzeug exakt dort bleibt, wo es war; fasst 400-seitige Normen zusammen, während der Einkauf entscheidet, ob 2027 das nächste System lizenziert wird. Die Veränderung kommt nicht als Transformationsprogramm mit Projektnamen und SteerCo. Sie kommt als Kollegin oder Kollege, leise, mit einem Chatbot-Tab in der Ecke des zweiten Monitors.

Das heißt: Die üblichen organisatorischen Abwehrmechanismen – langsamer Einkauf, mehrjährige Rollouts, Governance-Gates, die Anziehungskraft der bestehenden Toolchain – greifen nicht. Bis das Transformationsprogramm zugeschnitten ist, hat sich der Arbeitsmix darunter längst verschoben.

KI ist bereits im Engineering – und sie frisst die Fleißarbeit

Das ist keine Debatte über die ferne Zukunft. In der Automobil-F&E berichtet McKinsey, dass70 % der befragten Führungskräfte sagen, ihre Unternehmen integrieren generative KI bereits in die F&E. [4]

Wichtiger als die Adoptionsschlagzeile ist,wo der Wert entsteht. Nicht bei „kreativen Geniestreichen". Sondern bei der Arbeit, die Engineers historisch durchackern mussten:

• Test und Homologation: 20–30 % Verbesserungspotenzial durch Automatisierung von Reporting, Dokumentation und szenariobasierter Simulation. [4]

• Testvektoren: Ein deutscher Tier-1-Zulieferer berichtete von einemProduktivitätsgewinn von 70 % – inklusive menschlicher Prüfzeit – durch generative KI zur Erzeugung von Testvektoren wie vollständiger Branch Coverage und MCDC. [4]

• Anforderungen und Compliance: Ein Copilot für Anforderungsdokumente brachte bei einem deutschen OEM rund 20 % Effizienzgewinn. Ein Compliance-Copilot verkürzte die Vorbereitungszeit, indem er Normen aus ISO-artigen Dokumenten extrahierte. [4]

Deshalb geht „KI versteht meine Domäne nicht" am Kern vorbei. KI muss das Engineering-Urteil nicht ersetzen, um das Spiel zu verändern. Sie muss nur den ersten Entwurf billig machen.

Sobald Entwerfen billig ist, verschiebt sich die knappe Fähigkeit auf das, worin Engineers ohnehin gut sein sollten: Validierung, Abwägungen und verantwortete Entscheidungen.

Das eigentliche Risiko: Engineers überschätzen ihre KI-Immunität

Der übliche Bewältigungsmechanismus ist simpel. Eine falsche KI-Ausgabe sehen. Das Ganze für „nicht engineering-tauglich" erklären. Leicht selbstzufrieden weitergehen.

Emotional befriedigend. Strategisch schwach.

KI muss nicht perfekt sein, um die Ökonomie der Fleißarbeit zu übernehmen. Sie muss schnell, günstig und mit Validierung nutzbar sein. Im Unternehmensumfeld deckt das bereits einen überraschenden Anteil des Kalenders ab: Anforderungen entwerfen, Testideen vorschlagen, Normen zusammenfassen, Dokumentationsgerüste erzeugen. [4]

Also ja – Engineers bleiben verantwortlich. Aber der Arbeitsmix verändert sich. Wenn eure berufliche Hebelwirkung lautet „Ich kann mich durch den Papierkram und den ersten Entwurf durchbeißen", dann kommt KI für genau diese Komfortzone. Die Engineers, die am sichersten sind, unersetzlich zu sein, sind typischerweise jene, deren erste Entwürfe bereits von einer Kollegin mit Chatbot und einer Tasse Kaffee erzeugt werden.

Was Engineers jetzt tun können (ohne daraus eine Religion zu machen)

Kein „Umarmt die Zukunft". Ein praktischer Überlebensleitfaden. Vier Bewegungen, die im Unternehmens-Engineering tatsächlich etwas verändern:

1. Beginnt mit abgegrenzter, prüfbarer Arbeit. Nutzt KI dort, wo Ergebnisse überprüfbar sind – erste Entwürfe von Anforderungen (mit Nachvollziehbarkeit), Vorschläge für Testvektoren, Dokumentationsgerüste, Zusammenfassungen von Normen, Änderungsauswirkungsanalysen. Und dann prüft. Die Verantwortung wandert nicht; die Geschwindigkeit bis „bereit zur Prüfung" schon.

2. Baut Validierungsdisziplin auf, keine Prompt-Bibliothek. Prompten ist nicht die Engineering-Fähigkeit. Validieren ist es. Review-Checklisten, Akzeptanzkriterien, Testumgebungen, Nachweisketten. KI entwirft. Engineers zeichnen ab. Die Unterschrift bedeutet weiterhin etwas – sie bedeutet sogar mehr, weil das Volumen auf dem Schreibtisch gerade gestiegen ist.

3. Hört auf, auf die Toolchain zu warten. Das nächste PLM-Release kommt nicht in diesem Quartal. Die integrierte, KI-native Engineering-Suite ist eine Folie, kein Produkt. Nutzt KI neben den Werkzeugen, die es heute gibt, mit klaren Regeln, wie Ergebnisse in das führende System zurückfließen. KI-Adoption als Beschaffungsproblem zu behandeln, ist der schnellste Weg, drei Jahre zu spät zu sein.

4. Repariert den Zugang zu Kontext. KI ohne Kontext erzeugt Volumen, nicht Qualität. Wenn Wissen in Postfächern, PDFs und Erfahrungsgedächtnis feststeckt, wird die KI-Ausgabe mittelmäßig sein – und Engineers werden recht haben, sie abzutun. Investiert in geregelten Zugang zu Anforderungen, Normen, Entscheidungen, Architekturen und Verifikationsnachweisen. Das ist unglamouröse Arbeit, die fast niemand finanzieren will. Finanziert sie trotzdem.

5. Wer Engineers führt: gebt Werkzeuge und Leitplanken, keine Slogans. Freigegebene Werkzeuge. Klare Nutzungsregeln. Trainings mit Fokus auf Validierung, nicht auf Prompt-Handwerk. Erlaubnis zu verändern, wie die Arbeitgetan wird – nicht nur, wie sieberichtet wird. Wiederholt nicht den Fehler der Pseudo-Agilität, Zeremonien hinzuzufügen, ohne Randbedingungen zu entfernen. Engineers riechen Theater. Sie sind beruflich darauf trainiert.

Abschließender Gedanke

Die traditionelle Engineering-Kultur ist nicht falsch. Sie ist optimiert für eine Welt, in der Fleißarbeit Zeit kostete, Zeit Hebelwirkung war und die Toolchain darunter sich in Gletschertempo bewegte. KI nimmt die ersten beiden weg – und umgeht die dritte.

Die Wahl lautet nicht „KI gegen Engineers". Die Wahl ist, ob Engineers in der Wertschöpfungskette nach oben rücken. Behandelt KI als Junior-Engineer, der schnell tippt und Validierung braucht, und ihr werdet wertvoller – Urteilsvermögen, Systemdenken und verantwortete Entscheidungen sind genau das, was der neue Arbeitsmix verlangt.

Ihr könnt weiterhin sagen: „So machen wir das hier nicht."

Verwechselt es nur nicht mit einer Strategie.