Before You Hire an AI Executive, Stop Treating AI as Magic
An AI title does not create business value. Define the production mandate before hiring the executive.
The AI Workshop Will Not Ship
8 min read
The Clever Colleague Still Needs Tests
18.08.2026, By Stephan Schwab
The AI workshop will not ship. The maturity model will not integrate with your CRM. The transformation deck will not handle exceptions, log decisions, pass an audit, recover from bad input, or explain why the agent just sent the wrong answer to a customer. That is the part of the AI conversation senior management hears too late. The easy story is everywhere: clever colleagues, instant productivity, empowered business teams, a new operating model, maybe a few inspiring panels about the future of work. Then the real bill lands in the CTO's world. Which workflow changes? Which data is touched? Who owns the errors? Where are the tests? Who can deploy a fix? AI adoption is not primarily a change-management program. It is software work wearing business clothing. Change management can help people accept a new way of working, but it cannot replace architecture, integration, deployment discipline, observability, security, privacy, and maintenance. The useful role is not the AI prophet with a keynote. It is someone close enough to the business to understand the workflow and technical enough to make it survive contact with production. Call that a Forward Deployed Engineer, embedded senior, delivery partner, or simply the adult in the room. The label matters less than the scars. Which of those questions is still unanswered in your AI rollout?
The phrase that started the irritation was the “IQ500 colleague.”
It is brilliant executive bait: short, impressive, slightly mystical. It makes AI sound like a stellar hire who quietly joins the team and lifts everyone through cognitive horsepower.
The slogan surfaced in discussions around corporate AI maturity models. Level 0: access to models. Level 1: capacity gains from optimized workflows. Level 2: team agents. Higher levels: business model shifts. That is a serious framework.
Then the metaphor took over: what would we redesign if an impossibly smart colleague joined the team?
As a prompt to stop treating AI like a glorified search box, it is harmless. Taken literally, it is nonsense. Models do not become colleagues because a slide gives them a number. They carry no responsibility, understand no business context, and own no consequences. They agree too easily, hallucinate plausibly, and sound confident while being wrong.
The danger is not ambition. The danger is that the metaphor lets people sound strategic while avoiding operational reality.
The Conversation Is Too Comfortable
The easier the AI conversation sounds in the executive room, the more likely the hard part has been postponed.
The issue is not a shortage of smart voices. It is the filter.
The people invited to explain AI to senior management are rarely the ones who have to run the result. They are change managers, HR strategists, innovation moderators, and keynote consultants who discovered the market rewards fast confidence.
Some bring structure. Some help leadership move past fear. But danger begins when adoption framing becomes the entire strategy: mindset, literacy, enablement, culture.
These are not fake topics. They are incomplete topics.
AI adoption becomes real only when it alters a workflow. And a workflow is not a slide. It is the messy place where business intent hits software reality: identity, permissions, data quality, legacy systems, exceptions, audit trails, and undocumented compromises.
That is where inspiration ends and software work begins.
AI Adoption Is Software Work
If an AI initiative touches data, decisions, workflow, integrations, or customers, it has entered the CTO's world.
The executive fiction is that AI transformation is mostly about people learning new habits.
Learning matters. But the moment AI touches an operational process, software questions demand answers:
- What data may the model see?
- Which decisions may it influence, and which trigger automated action?
- Who reviews the output?
- What is logged, reproducible, and rollback-ready?
- Which failure is an annoyance, and which is an incident?
- Who maintains the prompt, integration, or agent once the pilot team leaves?
That is the baseline of seriousness.
AI will not run your company by itself. It amplifies the system you attach it to. Paired with clear workflows and disciplined deployment, it delivers leverage. Paired with organizational confusion, it produces faster confusion in polished prose.
Change management helps people move. Software discipline decides whether the destination works.
The Forward Deployed Engineer Is a Useful Clue
The useful part of the Forward Deployed Engineer model is proximity: close to the workflow, close to the code, close to the consequences.
Palantir made the Forward Deployed Software Engineer famous. Enterprise AI is now reviving the pattern because the value is never in the platform alone. Value emerges when skilled practitioners embed near the problem and adapt software to real operations.
Strip away the mystique and keep the core: a technical practitioner operating inside the business problem with the authority to turn fuzzy intent into working software.
The role sits in the productive middle:
- close enough to users to understand actual workflows
- technical enough to build and guide real implementation
- senior enough to reject a demo that cannot survive production
- disciplined enough to leave behind tests, deployment paths, and ownership
Leadership does not need another visionary describing AI potential, nor isolated developers receiving sanitized requirements weeks too late. It needs someone standing in the workflow asking what software must exist for the change to hold.
The Demo Is Not the System
The first demo measures imagination. Production measures discipline.
AI demos are seductive because the visible surface arrives in days. A chatbot answers questions over docs, an agent drafts customer replies, or a dashboard updates live. The room applauds, consultants say “scale,” and the deck marks a quick win.
Then reality charges by the hour.
Internal documents contradict each other. Permissions are too broad. The model cites obsolete policy. The agent takes unreplayable actions. Error handling in third-party APIs falls over. Security asks about access, legal asks about data retention, and operations asks who gets paged at 2 AM.
This is what the workshop never ships.
Vibe coding is not software development because software is the surrounding discipline that keeps output working across time, scale, and failure. Demos got cheap. Robust systems did not.
What Actual Development Adds
TDD, CI/CD, trunk-based development, and executable specifications are not developer hobbies. They are how AI work becomes governable.
The core practices of software development return with a smirk. The techniques once dismissed as developer preferences are precisely what makes AI safe to deploy.
- TDD defines expected behavior explicitly before a model modifies it.
- CI uncovers breakage while the change is small enough to diagnose.
- CD turns releases into routine mechanics rather than quarterly prayers.
- Trunk-based development eliminates long-lived fantasy branches where integration risk hides.
- Executable specifications give business rules verifiable teeth.
- Observability tells the CTO how the workflow behaves under real traffic.
AI generates more code, workflows, and plausible explanations than legacy release cycles can absorb. Without discipline, you get output inflation: bigger repos, bloated process maps, and compounded risk. With discipline, you get genuine leverage.
Predictable software delivery was never about process worship. It was about fast feedback loops. AI raises the penalty for lacking them.
Governance Without Delivery Is Paperwork
Governance that cannot see delivery turns into policy theater. Delivery without governance turns into unmanaged risk.
Compliance is non-negotiable. GDPR, the AI Act, data sovereignty, and auditability are real constraints. Anyone urging enterprise teams to “move fast and ignore rules” is selling imported recklessness.
Yet governance has its own failure mode: substituting policy for delivery.
Committees draft principles, risk matrices, and operating models while real work migrates to unmonitored scripts, SaaS automations, and ad-hoc prompts. That is paperwork watching shadow IT unfold.
Effective governance requires delivery visibility. It demands knowing which systems exist, where data flows, who owns the components, and how incidents are resolved.
The CTO must anchor this dialogue—not to block progress, but to make commitment operationally honest.
Questions the CTO Should Bring
The CTO does not need to win the AI rhetoric contest. The CTO needs questions hype cannot answer without becoming real.
When excitement sweeps the executive room, the CTO does not need to perform skepticism. The stronger move is asking operational questions consistently:
- Show me the exact workflow.
- Which data is touched, and who owns the output?
- Where are the automated tests?
- What is the rollback path when the model fails?
- How do we measure whether output improved?
- Who deploys fixes, and what gets logged?
- Who maintains this system after the pilot team disbands?
These questions cut through abstraction. Change managers can still contribute, vendors must discuss operational mechanics, and leadership sees that the CTO is defining what progress must survive.
That is not anti-AI. It is anti-theater.
With the CTO, Not Around Them
AI adoption should strengthen the CTO's authority, not create a parallel technology agenda through the side door.
The riskiest AI initiatives start innocently: a department pilot, a turnkey vendor pitch, a workflow built around IT because “engineering is backlogged.”
That creates software liability without technical ownership. By the time IT is consulted, the tool has active users, political momentum, and unmanaged risks that the CTO is suddenly expected to sanitize.
AI work belongs with the CTO the instant it touches systems, data, or customer workflows.
A useful external partner reinforces that responsibility rather than bypassing it. They embed near the business problem and the development team to turn executive intent into reliable software.
Whether you call it a Forward Deployed model, embedded delivery partnership, or senior software judgment near the work, the conclusion stands: the workshop will not ship, the deck will not integrate, and the clever colleague will not write the postmortem.
Someone still has to build the system, own the consequences, and know where software breaks.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
The Table That Tells You Everything
Don Ricardo Sánchez invites Stefan and Sophie for dinner at his family's estate. The food is extraordinary, the conversation is careful, and Sophie...
Process Theater and the Grind
Preston Hale arrives just in time to do what he does best: call fear professionalism and bless documents that cannot actually guide the work. By Th...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- The AI Workshop Will Not Ship (18.08.2026)
- The System Only One Person Understands (13.08.2026)
- Before You Hire an AI Executive, Stop Treating AI as Magic (08.08.2026)
- Nobody With Delivery Scars Is in the Room (05.08.2026)
- Software Flow Is Not Process Theater (01.08.2026)