Shadow Engineering
When business units start building their own software — and IT just found out.
“We couldn't wait for IT, so we built it ourselves.”
“Our marketing analyst learned to use n8n over a weekend.”
“We found out about it when it broke and nobody could fix it.”
What it looks like
Business units are building applications, workflows, and integrations using no-code tools, AI coding assistants, and platforms like n8n, Make, Cursor, and Retool. Marketing built a customer data pipeline. Operations built automated reporting. These aren't spreadsheet macros — they're real software processing real data, sometimes PII, that's become business-critical without technology knowing it exists.
Why it happens
Shadow Engineering isn't rebellion. It's desperation. Business units have legitimate needs that technology can't fulfill at the speed required. AI tools and no-code platforms have made building software accessible. The combination of urgent need and accessible tools creates a predictable outcome.
The question isn't whether shadow engineering will happen. It already is.
What it causes
Ungoverned data pipelines processing PII. Business-critical workflows with no documentation, version control, or backup. Single points of failure. Security exposures the security team doesn't know exist. Compliance violations undiscovered until audit.
But it also represents genuine innovation. Business users who build their own tools understand their problems better than any requirements document.
How TRUST addresses it
Phase 4's AI Practices assessment probes for unofficial tool usage. Phase 2 business unit interviews surface shadow engineering organically. The roadmap includes governance that enables rather than blocks: define guardrails and create a path for promoting good shadow engineering into supported capability.