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

  1mo ·

  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

  
• 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

  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

  2mo ·

  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.

• 

  Sebastian Stöhr

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

  2mo ·

  Most companies do not start their AI journey with an operating model. They start with a mess: ChatGPT tabs, Copilot habits, Claude research workflows, hidden scripts, and prompts nobody owns.

  I do not think that first mess is the problem.

  It is often the first honest signal that people are trying to make AI useful in their actual work. None of that usually starts in a steering committee.

  The problem starts when the mess becomes invisible infrastructure.

  • Sensitive data goes into tools nobody cleared.
  • Three teams build the same workflow separately.
  • Quality standards differ from team to team.
  • A useful experiment quietly becomes business-critical.
  • Nobody can explain who owns it.

  The usual reaction is policy theater: approvals, boards, templates, and procurement gates for every small experiment.

  That does not create control. It pushes the work underground.

  The better path is an Enterprise AI toolbox.

  Not one assistant for everyone. Not chaos forever.

  A practical toolbox separates the layers: everyday assistants, team workflows, shared knowledge access, production agents, and reusable assets.

  The core move is to let AI work graduate.

  Exploration should stay lightweight. Pilots should document users, data, risks, and review. Managed workflows need quality gates and owners. Production services need the same discipline as any other business-critical system.

  Too little control creates risk and duplication. Too much control kills the learning you need to manage the risk.

  I wrote the full article on moving from AI tool chaos to an Enterprise AI toolbox without killing the curiosity that created the first useful use cases.

  Link in the comments.

  What is the biggest challenge you are facing when moving AI from scattered experiments to something the organization can actually rely on?

  #EnterpriseAI#AITransformation

  Stop Turning AI Chaos into policy theater

  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
• 

  Sebastian Stöhr

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

  2mo ·

  Enterprise AI agents do not fail because they cannot generate text.

  They fail when they do not understand the context.

  A few weeks ago I wrote about the “Confluence Graveyard”: the place where important knowledge slowly gets lost across old pages, tickets and documents. Since then, I made great progress: The knowledge base is now kept up to date regularly, currently twice a day, by consuming relevant tickets, pages and documents. It is already being used to enrich agentic workflows — for example to interpret numbers with more context and create better reports.

  Google recently introduced the Open Knowledge Format, which specifies best practices to share knowledge for agentic use cases. They kept it super simple:

  • Markdown files
  • YAML metadata
  • Normal links
  • Versionable structure
  • Readable by humans and usable by agents

  And importantly: it does not force a fixed domain structure.

  That makes it very compatible with real enterprise work, where each organization needs to model its own products, metrics, processes and decision history.

  For me, this confirms an important direction:

  The next step for enterprise AI is not only better prompts. It is better shared context.

  
• 

  Sebastian Stöhr

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

  2mo ·

  The best first AI agent for your company is boring. On purpose.

  We’ve all seen the demo: the agent plans a project, browses the web, writes the code, updates three systems. Genuinely impressive. But it skips every question that actually decides whether an agent ships: What is it allowed to touch? What can it change? Who’s accountable when it’s wrong? How do you even know it’s wrong? In a keynote you can wave those away. In a real company, they are the project.

  So my advice is almost annoyingly modest. Don’t start with the agent that “does my job.” Start with a narrow workflow that already happens every day, has clear inputs and outputs, can be checked in seconds, and fails in ways you can recover from.

  Two tests decide it: is it bounded, and is it reviewable?

  Drafting release notes from merged pull requests passes both. So does classifying incoming tickets against a taxonomy you already use. Nobody puts these on a conference slide. They also work.

  Boring isn’t the consolation prize here. It’s the strategy. A bounded agent that works the fiftieth time builds more trust than a flashy one that fails once. And trust is the thing you actually need before you earn the right to do anything ambitious.

  Autonomy should be earned through evidence, not assumed because the tech is exciting.

  🦾 Which boring workflow would your team automate first?

  #EnterpriseAI#AIAgents#AITransformation#AIStrategy

  

  sebastianstoehr.de

  Start With Boring Workflows