Engineers: "We don't do things that way" isn't a strategy

This article was co-created with Felix Huschka - Thank you for your thoughts & late night discussions :-)

"We don't do things that way."

If you have worked with engineers in a regulated enterprise, you have heard this sentence. Calm, reasonable, conversation-ending.

For years, it was not stubbornness — it was risk management. In enterprise engineering, being wrong is expensive, sometimes illegal, and occasionally newsworthy. The system optimises for predictability: evidence, traceability, and a strong bias toward don't touch it unless you must.

That logic worked when the legwork — drafting requirements, writing test cases, summarising standards, producing compliance documentation — was where engineers earned their salary.

AI removes that logic. It does not care about your tradition, your gate reviews, or how long it took to write the last requirements document. It will not ask for permission. It will simply do the draft work faster than your organisation can schedule the alignment meeting about whether to allow it.

It will not join your steering committee either.

A note on scope: this is about engineering in large enterprises — regulated environments, safety-relevant products, long supplier chains, the kind of work where a defect doesn't just break a feature, it triggers audits, recalls, or a 3am escalation. Not the three-person startup. Not the "we shipped a landing page" version of engineering.

Why engineers resist change (and why it isn't irrational)

Most engineers are trained to value correctness over novelty. That is not a personality quirk — it's a response to constraints. When late changes mean re-testing, recertification, supplier renegotiation, and schedule slips, the organisation naturally prefers approaches that reduce uncertainty early.

That is the logic behind Stage-Gate and plan-driven governance. Bianchi, Marzi and Guerini (2020) frame the underlying tension cleanly: Stage-Gate aims to reduce uncertainty up front; agile is designed to keep adapting to uncertainty longer into development. [1] Two valid responses to risk. One is routinely asked to behave like the other. Then we wonder why nobody is happy.

Why "agile" often felt like a bad joke in engineering

A lot of companies did not introduce agility into engineering. They introduced agile vocabulary.

Stand-ups inside a Stage-Gate world. Backlogs that still need steering committee approval. Sprints that end with "great progress — now wait for the next gate." Leaders called this agile. Engineers called it "more meetings." Both descriptions were correct.

McKinsey is unusually direct about this: across their agile-for-hardware implementations at more than 20 companies, Stage-Gate was retained alongside agile in every single case, keeping agile "in check" with long-term governance. [2]

That can be a sensible compromise. It also explains why so many engineers walked away saying, "Agile doesn't work here." What they experienced was not a new delivery system. It was additional ceremony layered on top of the old one — the same gates, plus a daily 9am.

The hybrid can also become actively dysfunctional. A 2022 case study of embedded systems development describes an agile supplier being pushed toward plan-driven milestones and resorting to what the authors call "keeping up appearances" — reporting progress against milestones the team knew were unrealistic, which undermined feasibility and quality. [3] Anyone who has sat in a status review where the green RAG was noticeably greener than the actual status has watched this paper play out in real time.

And then there is the toolchain

Engineering does not just have a risk culture. It has a tool environment that changes on a different timescale to almost every other function in the company.

The PLM migration that started in 2019 is still running. The ALM rollout the company committed to in 2017 is still being onboarded at plant 7. The CAD environment is one major version behind current because the validation cycle on the CAM toolchain takes 18 months and nobody has the appetite to start it. Requirements live in DOORS, then they live in DOORS Next, then they will live in something else, eventually, after the next steering committee.

This is not engineering being slow. It is the physics of large enterprise toolchains: every change cascades through CAD, simulation, manufacturing engineering, suppliers, quality, regulatory documentation, and two decades of legacy data that has to migrate without losing traceability. Multi-year programmes with eight-figure budgets are normal. Slipping by a year or two is normal. Quietly being descoped is also normal.

If you have spent a decade in this environment, you have watched several "this will transform how we work" programmes deliver new logos on old screens. Skepticism about the next big thing is not a personality flaw. It is pattern recognition.

The trap is assuming AI will follow the same pattern.

It will not. AI does not wait for the PLM migration. It does not need a steering committee to approve a new authoritative tool. It runs alongside whatever already exists — drafting requirements while engineers still type them into DOORS, generating test vectors while the test management tool stays exactly where it was, summarising 400-page standards while procurement decides whether to license the next system in 2027. The change does not arrive as a transformation programme with a project name and a SteerCo. It arrives as a colleague, quietly, with a chatbot tab open in the corner of the second monitor.

Which means the usual organisational defences — slow procurement, multi-year rollouts, governance gates, the gravitational pull of the existing toolchain — do not apply. By the time the transformation programme is scoped, the work mix has already shifted underneath it.

AI is already in engineering — and it is eating the legwork

This is not a far-future debate. In automotive R&D, McKinsey reports that 70% of surveyed executives say their companies are already integrating gen AI into R&D. [4]

More important than the adoption headline is where the value is showing up. Not in "creative genius" tasks. In the work engineers have historically had to grind through:

• Testing and homologation: 20–30% improvement potential through automating reporting, documentation, and scenario-based simulation. [4]

• Test vectors: A German tier-one supplier reported a 70% productivity gain — including human review time — using gen AI to generate test vectors such as full branch coverage and MCDC. [4]

• Requirements and compliance: A requirements-document copilot delivered roughly 20% efficiency gains at a German OEM. A compliance copilot cut prep time by extracting norms from ISO-style documents. [4]

This is why "AI does not understand my domain" misses the point. AI does not need to replace engineering judgment to change the game. It only needs to make the first draft cheap.

Once drafting is cheap, the scarce skill shifts to what engineers should be good at anyway: validation, trade-offs, and accountable decisions.

The real risk: engineers overestimating their AI immunity

The standard coping mechanism is simple. See one wrong AI output. Declare the whole thing "not engineering-grade." Move on, slightly smug.

Emotionally satisfying. Strategically weak.

AI does not need to be perfect to take over the legwork economy. It needs to be fast, cheap, and usable with validation. In enterprise settings that already covers a surprising share of the calendar: drafting requirements, proposing test ideas, summarising standards, producing documentation scaffolding. [4]

So yes — engineers remain accountable. But the work mix changes. If your professional leverage is "I can grind through the paperwork and the first draft," AI is coming for that comfort zone. The engineers most confident that they are irreplaceable are typically the ones whose first drafts are already being produced by a colleague with a chatbot and a cup of coffee.

What engineers can do now (without turning this into a religion)

Not "embrace the future." A practical survival guide. Four moves that actually shift the dial in enterprise engineering:

1. Start with bounded, checkable work. Use AI where outputs are verifiable — first drafts of requirements (with traceability), test vector proposals, documentation scaffolding, summaries of standards, change impact analysis. Then verify. Accountability does not move; the speed of getting to "ready to verify" does.

2. Build validation discipline, not a prompt library. Prompting is not the engineering skill. Validation is. Review checklists, acceptance criteria, test harnesses, evidence trails. AI drafts. Engineers sign off. The signature still means something — in fact, it means more, because the volume crossing the desk just went up.

3. Stop waiting for the toolchain to catch up. The next PLM release is not coming this quarter. The integrated AI-native engineering suite is a slide, not a product. Use AI alongside the tools that exist today, with clear rules for how outputs flow back into the authoritative system. Treating AI adoption as a tool-procurement problem is the fastest way to be three years late.

4. Fix access to context. AI without context creates volume, not quality. If knowledge is trapped in inboxes, PDFs, and tribal memory, the AI output will be mediocre and engineers will be right to dismiss it. Invest in governed access to requirements, standards, decisions, architectures, and verification evidence. This is unglamorous work that almost no one wants to fund. Fund it anyway.

5. If you lead engineers: give tools and guardrails, not slogans. Approved tools. Clear usage rules. Training focused on validation, not prompt-craft. Permission to change how the work is done, not just how it is reported. Do not repeat the fake-agile mistake of adding ceremonies without removing constraints. Engineers can smell theatre. They are professionally trained to.

Closing thought

Traditional engineering culture is not wrong. It is optimised for a world where legwork took time, time was leverage, and the toolchain underneath everything moved at glacial speed. AI removes the first two, and routes around the third.

The choice is not "AI vs engineers." The choice is whether engineers move up the value chain. Treat AI as a junior engineer who types fast and needs validation, and you become more valuable — judgment, systems thinking, and accountable decisions are exactly what the new work mix demands.

You can still say, "We don't do things that way."

Just don't confuse it with a strategy.