AI Transformation

My Thoughts on AI Transformation

Sebastian Stöhr

Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

Follow

• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  2w ·

  Every AI idea on the roadmap is a bet: scarce capacity committed now against a return nobody can prove yet.

  What makes a bet honest is deciding up front what would settle it.

  Most roadmaps skip that step. Ideas get sorted into neat groups, then every group is measured by time saved, because that is the number everyone already knows how to argue about.

  Time saved flatters productivity work, undersells anything that builds a foundation, and says nothing at all about an experiment whose whole purpose was to answer a question.

  Five kinds of bet cover most of what a company will consider. Each settles differently.

  • Learning bet: an open question is now closed, in enough detail that someone can act on it. A working prototype and no changed decision is a failed learning bet.
  • Productivity bet: sustained voluntary use after the novelty wears off. Not seats provisioned.
  • Workflow bet: movement against a known before-state. Cycle time, handoffs, rework, exceptions.
  • Capability bet: the second and third use. One consumer means you built a component of that consumer’s workflow.
  • Strategic bet: a core process or a competitive position has actually moved.

  Five standards, five owners, five different ways to fail.

  Before starting your next AI initiative, clarify: What are you betting on?

  #EnterpriseAI#AIStrategy#AITransformation

  
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  2w ·

  Most AI workflows go to production running on a single model – usually the most capable frontier model chosen during prototyping.

  That choice makes the initial demo work. In production, it means every simple classification, formatting, or extraction step inherits the peak cost, latency, and rate limits of the hardest reasoning step.

  A workflow is not a single task. It is a sequence of steps with different requirements for accuracy, speed, and cost.

  Instead of assigning one model to the entire process, map capability to the step:

  • Deterministic code for fixed logic: use standard rules or regex for schema validation, calculations, and exact lookups without calling a model
  • Small models for structure and routing: use fast, low-cost models for intent classification, data extraction, or format parsing
  • Mid-tier models for routine generation: use balanced models for standard drafting, summarization, or structured transformations
  • Frontier models for high-stakes logic: reserve the most capable models for complex reasoning, ambiguous edge cases, or final synthesis
  • Fallback paths: route low-confidence outputs to a stronger model or human review automatically

  The trade-off is operational complexity. Managing multiple models requires clearer routing logic, version tracking, and testing across tiers.

  A single model default is simpler to deploy, but you pay for that simplicity on every single execution.

  What is one step in your pipeline where swapping an LLM for code or a smaller model gave you the biggest win?

  #EnterpriseAI
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  3w ·

  Most enterprise AI reporting still answers one question: how many people used the tool.

  That number is easy to collect and easy to put on a dashboard. It says very little about whether the work got better, faster, or safer.

  Access is not adoption. Prompt volume is not productivity. High usage can mean employees are getting value, or it can mean they are spending 45 minutes fighting with an assistant to finish one task.

  Tool telemetry hides what leaders actually need to see. Three metrics tied to the work itself tell a clearer story:

  • First-pass acceptance rate: how much generated output passes human review without a major rewrite
  • End-to-end cycle time: whether total elapsed time from request to final deliverable dropped, or if effort just shifted from drafting to editing
  • Exception rate: how often work drops out of the assisted path back into manual handling

  Measuring this does not require a complex analytics platform. You anchor the measurement to a specific workflow step and add a simple check at the human review gate.

  Take customer proposal drafting as an example. Instead of counting how many prompts team members send to an assistant, track how many generated sections pass review without a major rewrite, and measure total time to finish the proposal.

  If prompt volume goes up while cycle time and rework stay flat, you have not accelerated the process. You have only added a step.

  If tool usage doubled in your organization tomorrow, would you know whether the underlying work actually improved?

  #EnterpriseAI
• I post on AI transformation and engineering leadership a few times a week. If this is your kind of thing, let's connect over there.

  Connect on LinkedIn
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  3w ·

  A use case can be technically feasible and still be a bad operational decision.

  Feasibility is easy to demonstrate. Operating cost shows up later: someone needs to define what good output looks like, review failures, update prompts and context, maintain permissions, notice quality drift, and own the escalation path.

  Review and maintenance effort is not the same for every workflow. Ticket triage is cheap to check, and cheap to correct when it is wrong.

  Documentation for a legacy system is the case I keep coming back to. The generated text reads well. Confirming it is correct means reading and understanding the code, which was the expensive part to begin with. The work did not disappear. It moved from writing to checking, and checking now needs someone senior.

  Same model, same accuracy, opposite economics.

  So before funding a use case, check one thing: can someone verify the output without going back to the source?

  If yes, review stays cheap and the value survives contact with operations.

  If no, you have not removed work. You have just changed its shape.

  #EnterpriseAI#AIStrategy#AITransformation

  Is this workflow worth operating?

  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  AI transformation often has energy at the top and curiosity at the edges.

  Executives want productivity, faster cycle times, better knowledge access, and a credible AI strategy. Employees experiment because the tools are easy to try.

  And still, adoption stalls. Not because nobody sees value. Because the middle of the organization has not changed.

  Team leads, product owners, engineering managers, department heads, and process owners inherit the practical questions:

  • Which tasks should the team use AI for?
  • What data is allowed?
  • What output requires review?
  • How do we know quality improved, not just speed?
  • Who owns the workflow after the enthusiast moves on?

  This layer turns ambition into daily practice: queues, rituals, reviews, handoffs, exceptions, and deadlines.

  If it is unsupported, AI stays informal. Managers let experimentation happen, but avoid making it part of the official process. From a distance, that can look like adoption. Up close, it is drift.

  There is also an incentive problem.

  AI asks teams to change how they work while still delivering the work they already committed to. If managers are measured only on short-term delivery, they will not spend time turning useful AI habits into shared workflows.

  Central AI teams should not try to own every use case.

  Their better role is to give the middle layer safe defaults, review patterns, reusable templates, escalation paths, and a place to share what works.

  Using a tool is just the beginning; real adoption happens when business processes actually improve.

  #EnterpriseAI

  Why AI adoption stalls in the middle

  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  An AI agent can generate a UI.

  That does not mean it understands your design system.

  A design system is not just a catalog of buttons, colors, and layouts.

  It contains decisions:

  • what should be reused
  • what may change
  • which pattern fits a given job
  • which constraints must remain stable

  Without that context, the agent approaches every request as a new design exercise. It explores the file, guesses the structure, and rebuilds patterns that already exist.

  For my LinkedIn visuals, I built a Figma component library and gave the agent a skill that explains the available formats and how to use them through Figma MCP.

  The visual is only the small example. The same pattern works for website sections, product UIs, prototypes, dashboards, and other repeatable design work.

  Reusable components matter. An instruction layer makes them usable by an agent.

  How do you make your design-system decisions available to AI tools?

  #DesignSystems#AIAgents

  
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  AI can make weak judgment look productive.

  The output is fluent. The structure is clean. The tone is confident.

  And still, it may be unsupported, incomplete, outdated, or wrong for the decision in front of you.

  That is why prompt training is useful, but it is not the same as AI capability.

  The baseline skills are review and verification.

  Before using an AI output in real work, ask:

  • What supports this answer?
  • What might be missing?
  • Where could it be plausible but wrong?
  • Is it good enough for the decision we are about to make?

  A better prompt can reduce rework. Verification is what stops fluent output from becoming unreviewed work.

  Where does AI create the most hidden review effort in your team today?

  #EnterpriseAI

  AI capability starts with verification

  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  If you have a hammer, everything starts to look like a nail.

  AI creates the same risk.

  Before using AI, the first question should be: “Is this actually an AI problem?”

  Many topics are more reliable, cheaper, and easier to operate without AI in the target application.

  That does not mean AI has no role. You might use AI once to generate an application, a script, analyze a workflow, or speed up implementation.

  But the final solution may still be a simple application, a “boring” script, a workflow system, or a classic automation. AI does not make everything better! It adds complexity, indeterminism - and often additional costs. So it should better be worth it.

  Many automation problems are better solved with workflow tools like n8n, rules, integrations, or queues. AI can still be useful in narrow places as a single step in a process: classification, extraction, summarization, or routing.

  A simple 5-point check before using AI:

  1. Is the input ambiguous or unstructured?
  2. Does the task require language, judgment, or pattern recognition?
  3. Would rules or workflow automation be too brittle?
  4. Can we evaluate the output reliably?
  5. Does the target application actually need AI, or only the implementation process?

  AI enthusiasm is justified. But good engineering still starts with the same principle: Use the right tool for the job.

  #AI#EnterpriseAI

  Is this actually an AI problem?

  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  The first internal AI assistant often looks like a knowledge management breakthrough.

  People can ask questions instead of digging through policies, tickets, project files, SharePoint folders, and old Confluence pages.

  Then the uncomfortable part starts.

  • The assistant quotes an outdated policy.
  • It mixes an old process with a new one.
  • It finds three versions of the same template.
  • It summarizes a decision, but misses the constraint that made the decision valid.

  The easy reaction is to blame the AI setup.

  Sometimes that is fair.

  But often the system is showing something more basic: the real state of the organization’s knowledge.

  AI does not create knowledge debt. It makes it visible.

  Before AI, messy knowledge created friction. People searched too long, asked the same questions, copied old templates, and interrupted the one person who still remembered the real process.

  With AI, weak knowledge can scale the wrong answer.

  That changes the risk category.

  The answer is not just “connect more sources.”

  The harder work is ownership:

  • which source is authoritative?
  • who keeps it current?
  • when does knowledge expire?
  • what happens when sources conflict?
  • which answers should the system be able to verify?

  You do not need a grand knowledge management transformation to start.

  Start where weak knowledge already hurts.

  Pick one workflow. Map the sources. Find the conflicts. Name the owner. Retire the dead material. Test the questions the AI system should answer reliably.

  That is boring work.

  It is also the difference between an impressive internal assistant and one people can trust.

  #EnterpriseAI#KnowledgeManagement#AITransformation

  
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  If AI makes implementation cheaper, engineering leadership does not become less important.

  It becomes more important because the bottleneck moves.

  When writing code is slow, weak judgment can stay hidden for a while. When every engineer can produce more output, weak judgment becomes visible much faster.

  The leadership question shifts from “can we build this?” to:

  • should we build this?
  • is the requirement clear enough?
  • where did the bottleneck move?
  • what needs review?
  • which AI-assisted workflow should become shared practice?
  • where are people over-trusting or under-using the tools?

  AI adoption in engineering is not just a developer productivity topic.

  It changes discovery, review, testing, onboarding, incident response, documentation, and the way teams learn.

  That needs leadership.

  Not command-and-control leadership.

  Leadership that makes private experiments visible, turns useful workflows into shared capability, and creates enough safety for people to say two things honestly:

  “I used AI here, and this is how I checked it.” “AI was not useful for this task.”

  Without that honesty, leaders get adoption metrics and lose operational truth.

  AI accelerates implementation.

  Leaders shape the environment where implementation becomes valuable.

  #EngineeringLeadership#EnterpriseAI#AITransformation

  

  sebastianstoehr.de

  The New Role of Engineering Leaders in AI Transformation

  Why cheap implementation makes engineering judgement more valuable, and why leaders must turn private AI experiments into shared team capability.