> ## Content Index > Fetch the complete content index at: https://www.shiftharness.tech/llms.txt > Use this file to discover other available public pages before exploring further. # Top 5 Issues Companies Face Starting AI Adoption - URL: https://www.shiftharness.tech/top-5-issues-companies-face-starting-ai-adoption/ - Published: 2026-08-20T21:04:20.000Z - Updated: 2026-08-20T21:04:20.000Z - Description: Eighteen months in, the licenses are paid and the dashboards haven't moved. AI adoption fails as procurement and succeeds as role redesign. Five issues that compound in this exact order. - Author: Sergii - Tags: AI Adoption, AI in Software Delivery, Delivery Teams, AI Strategy, AI Enablement > "AI is everywhere but I'm not seeing it in our numbers." That sentence is the one I hear most often from tech-company owners eighteen months into AI adoption. They've bought the licenses and the team is using Copilot. Someone ran a workshop, and a few pilots were declared successful and quietly shelved. And the delivery dashboard looks the same as it did before any of it started. The tools get blamed first, then the people, then the model version. None of those is usually the root cause. The one that keeps showing up is that AI adoption is being treated as a procurement event when it is a redesign of how each role does its work. Until that frame shifts, the five issues below keep compounding, though they do not arrive in one universal sequence. The short answer, for anyone who wants it before the argument: when licenses are paid and usage is up but AI delivery metrics have not moved, the tool is rarely the whole story. What is missing is an AI operating model that ties role-level redesign to AI training, AI tool selection, an AI security policy and a named measure per role. The five AI adoption issues below are five of the places that missing layer shows itself, and the five I see most. This essay is the diagnostic vocabulary I wish I'd had when I started doing AI-transformation work in delivery orgs. Each issue has a symptom you can see from the CEO chair, a root cause sitting one layer underneath, and an implication for what a production-grade AI operating model would do instead. ## AI adoption fails because companies buy tools instead of redesigning roles The symptom is the one in the opening sentence: licenses bought, training booked, no shift visible in the delivery metrics that matter to the business. Cycle time looks the same, defect density looks the same, and so does the proportion of effort going into rework. Sometimes throughput drops for a quarter because people are context-switching between the old workflow and a half-built new one. The root cause is that nobody redesigned the role. Buying a license for a developer is a procurement act. [Redesigning the developer role is an operating-model act](https://www.shiftharness.tech/ai-adoption-operating-model/). The two look superficially similar and are deeply different. A redesigned role specifies which tasks now use AI, which tasks now have a different acceptance criterion because AI is producing the first draft, which review steps got compressed and which got added, and how the role's output is measured now that the input mix has changed. None of that is in a license agreement. The implication is that AI adoption belongs to the head of the role, not to IT. The head of QA owns the redesigned QA role, the head of PM the redesigned PM role. IT owns provisioning, and the platform, security and access controls the redesigned role has to run inside. When the redesign is delegated to IT, the result is provisioning without redesign, which is the state I see most often eighteen months in. The redesigns that stick are the ones where the role's head sits in the redesign sessions and personally rewrites the role's daily artefacts. ## Without an AI security policy, shadow AI is already inside your company ![Two binder spines side by side: a 'Shadow AI Register 2026' binder beside a 'Sanctioned Tools - Approved' binder, each in a brass label-holder.](https://storage.ghost.io/c/73/3e/733efc05-c397-4cf1-b19b-527c1b07dee7/content/images/2026/08/image-2-6.png) The symptom is harder to see, because unsanctioned use leaves no trace in the vendor and spend records you would think to check first. Engineers paste production code into ChatGPT to debug it. Account managers paste customer emails into Claude to draft replies. A product manager pastes a section of the roadmap into Gemini to summarise it for the board pre-read. None of it shows up in the procurement system because none of it is being procured. It's happening on personal accounts. The counter-move is [the AI security policy you ship before any AI tool](https://www.shiftharness.tech/ai-security-policy-you-ship-before-any-ai-tool/). The root cause is that no policy tells anyone what is sanctioned, what is forbidden, and what data may leave which system under what conditions. In the absence of one, people apply the rule they apply to every other tool that helps them get their work done faster: they use it. The fault is structural, not behavioural. If a fast tool exists and the company hasn't said anything about it, the staff who care about doing their job will use it. The implication is that the AI security policy is not the last step of an AI adoption programme. It is the first. Until there is a sanctioned-tools list and a data-handling rule per data class, every other investment in AI adoption is being made on top of an uncontrolled surface. The policy doesn't need to be long. It needs to name the sanctioned tools, name the data classes that may and may not enter them, and name who reviews exceptions. That document, ratified at the executive level, defines the boundary. What turns the boundary into governed practice is the set of controls implemented behind it and the AI governance that keeps reviewing them, because a policy on its own does not discover unsanctioned use, constrain what a sanctioned tool may touch, or revoke access when access should end. Put interim controls in place immediately, then advance role-level redesign, AI training, AI tool selection and measurement in parallel inside those controls rather than waiting for a clean handover between stages. ## A vendor webinar is not training; role-specific reskilling is The symptom is a calendar invitation. I keep watching the same sequence run: someone from the AI vendor delivers a one-hour overview session, a screenshot of it goes into the all-hands deck with the faces blurred, and the training row on the AI adoption roadmap gets checked off that afternoon. Six weeks later the usage report comes back and the only behaviour that changed is that the people who were already curious about AI are using it more. The people who weren't are using it exactly as much as they were before the session, and the roadmap still shows training as complete. The root cause is that the training was generic. It wasn't anchored to the role's daily artefacts. A developer does not need a tour of the Copilot interface; the developer needs a structured walk through how the code-review checklist changes when AI is producing the first commit, how the test-writing step shifts, and what the new failure modes look like when AI gets confident in the wrong direction. A QA engineer does not need an overview of test-generation tools; the QA engineer needs a curriculum that rebuilds test design around the assumption that production code will arrive faster and with different defect patterns. A PM does not need a Gemini demo; the PM needs a redesigned discovery workflow. The implication is that every role gets its own AI-fluency curriculum, written by the head of the role, anchored to that role's daily outputs, and assessed against changes in those outputs. Generic training is procurement wearing an enablement badge; role-specific reskilling is the change itself. The cost is worth stating plainly. Building an effective role-specific curriculum takes the role owner's own time, and it does not stay built: it needs rebuilding as the tooling moves under it. Across a delivery org with several distinct roles, it becomes a standing claim on senior people's calendars. That is the cost of the change actually happening. ## Nobody owns AI tool selection The symptom is a list of subscriptions: three code-assistants, two writing tools, a meeting-summariser, a "company GPT" experiment, a vector database somebody set up, and an agent platform that one squad demoed. None of them are deeply adopted, and all of them are billing monthly. The CFO asks who owns the AI tool stack and the answer is everyone and no one. The root cause is that tool selection was treated as a buy-the-best-tool problem. It is a fit-this-tool-to-this-role problem. Procurement evaluates vendors, which is a different exercise from evaluating whether a tool fits the way a role actually works. When the loudest engineer in the office advocates for a specific assistant and there is no role-level criterion to push back with, the loudest engineer wins. Multiply that across departments and the result is sprawl by enthusiasm. The implication is that tool selection is a role-level decision with explicit fit criteria written down before the evaluation starts. The criteria are not generic; they describe the workflow the tool is being adopted into. For QA, the criteria might describe how the tool integrates with the existing test-management system, what the audit trail looks like when an AI-generated test fails, and how the tool's output is reviewed before commit. For PM, the criteria are different. Procurement still runs the vendor process, pricing, security review, contracts, but procurement does not own the selection. The head of the role does. The sprawl I keep seeing is what happens when nobody is allowed to say no, so moving the decision to the head of the role is what stops it. ## If no delivery metric was named, no change can be reliably attributed ![A 'Cycle Time - Pre vs Post' baseline document on a binder, its two-column table comparing pre-rollout Q3 2025 and post-rollout Q1 2026 numbers, footer 'Baseline owner: Head of Delivery', with a pen alongside.](https://storage.ghost.io/c/73/3e/733efc05-c397-4cf1-b19b-527c1b07dee7/content/images/2026/08/image-3-6.png) The symptom is the one this article opened with. The CEO looks at the delivery dashboard and the numbers look the same as they did before AI was anywhere in the conversation. The instinct is to conclude that the AI investment did not work. Sometimes that is true. More often the truth is narrower: no delivery metric was named at the start, no baseline was captured, and any change that did happen cannot now be cleanly separated from everything else that moved. The root cause is that the AI rollout was scoped around inputs (tools deployed, licenses provisioned, training delivered) instead of around outcomes (cycle time on a specific workflow, defect density on a specific product surface, rework percentage on a specific class of work). Input metrics are easy to capture and cannot establish an outcome change on their own. Output metrics are harder to capture and are the ones the CEO cares about. The implication is that every AI investment must name the delivery metric it will move, the baseline must be captured before the rollout starts, and the measurement window must be long enough to tell signal from noise. If no metric and no baseline were defined, the work may still have changed, but the company cannot reliably detect that change or attribute it to AI. Record AI exposure by workflow, pair any throughput measure with a quality and rework guardrail, and preserve a comparison through a staggered rollout or a matched cohort. Without that design, the number eventually read is confounded by everything else that moved in the same window. In an effective redesign, the first artefact of every role redesign is the metric definition and the baseline reading. Without that document, the rollout is theatre. ## The shift the five issues actually point to is operating-model, not tooling Read the five issues again as a single sentence and what they say is that AI adoption has been mis-classified. It has been treated as a wave of tooling decisions. It is a redesign of how the work gets done, and these five issues are where that mis-classification surfaces most visibly. [A production-grade AI operating model addresses all five as one working system](https://www.shiftharness.tech/ai-operating-model/) rather than five separate purchases: a security policy that lists the sanctioned tools and the data classes that may enter them; role-level redesigns owned by the heads of those roles, anchored to the daily artefacts the role produces; reskilling curricula that match the redesigned roles; tool-selection criteria owned by the heads of roles, with procurement running the buy but not owning the choice; and a delivery-metric per redesign with a captured baseline. The same five issues, rewritten as five of its artefacts. They make the model inspectable and they are not the model itself. A programme can ship all five documents and still stall. The model is larger than the five: it also sets the incentives each redesigned role answers to, and the cadence on which the whole thing gets reviewed and recalibrated. Neither is in this list, and both are where these five quietly come undone. The reason this reframing matters for a CEO reading this is that the cost of fixing five issues one at a time is much higher than the cost of recognising them as a single underlying problem. Eighteen months in, the question is no longer whether to invest in AI. The question is whether the org has the operating model to convert that investment into delivery. There's a version of that question you can put to your leadership team on Monday, and it takes about ten minutes to answer badly: of the five issues above, which one has a named owner today, and which one is owned by nobody? Whatever comes back unowned is what's still compounding. Start there, not with the next tool evaluation. > **AI Transparency Notice:** This article and its accompanying images were created with the assistance of generative AI. The author directed the content, contributed the underlying ideas and analysis, and reviewed the final publication. ## Frequently Asked Questions Why isn't our AI adoption showing up in delivery metrics?▸ Usually because the rollout was scoped around inputs rather than outcomes, and no baseline was read before it started. Licenses provisioned and training sessions delivered are easy to count and tell you nothing about whether the work changed. Cycle time on a named workflow, defect density on a named surface, and rework share on a named class of work are harder to capture and are the numbers a CEO is actually asking about. When those were never named up front, the dashboard can move and still leave you unable to say the movement came from AI rather than from a hiring round, a scope change, or a quieter quarter. The repair is a measurement design: name the metric the rollout is supposed to move, read its baseline before anything ships, log which workflows actually got AI exposure, put a quality and rework counterweight next to any speed number, and keep a comparison alive by rolling out in waves or against a matched cohort. How long does it take before AI adoption shows up in delivery numbers?▸ There is no calendar answer, and figures quoted in weeks are usually measuring adoption rather than delivery. The window is set by the metric you chose, not by the rollout: it has to be long enough that a real shift clears that metric's own week-to-week noise. A defect-density measure on a low-volume surface needs longer than cycle time on a team that ships daily. Two things shorten the wait more than anything else. Read the baseline before the rollout, so you are comparing against a real number rather than a memory. And keep a comparison group, because a wave rollout lets you see the gap between exposed and not-yet-exposed teams months before a single trend line becomes readable. Do we need an AI security policy before rolling out AI tools?▸ Yes, and the sequencing is the whole point. Without a sanctioned-tools list and a data-handling rule per data class, staff are already using AI on personal accounts, because a fast tool nobody has said anything about is a tool people will use. That is shadow AI, and it is structural rather than a discipline problem. The policy itself does not need length. It needs to name what is sanctioned, name which data classes may and may not enter those tools, and name who rules on exceptions. Ratified at executive level, that document sets the boundary. What holds the boundary is what you build behind it: the controls that surface unsanctioned use, scope what a sanctioned tool can reach, and end access when it should end, plus the AI governance that keeps checking they still work. What is role-level redesign and how is it different from AI training?▸ Role-level redesign changes the work; AI training explains the tool. A redesign specifies which tasks in a role now start from an AI draft, which acceptance criteria change because of that, which review steps disappear and which get added, and how the role's output is measured once the input mix is different. Training that follows a redesign teaches people to run that new shape of work, including its review steps, its escalation paths and its security obligations. Training without a redesign leaves everyone doing the old job with a new tool open in the next window, which is why usage rises and delivery does not. A developer redesign rewrites the code-review checklist and the test-writing step. A QA redesign rebuilds test design around code arriving faster and failing differently. Who should own AI tool selection at a tech company?▸ The head of the role being equipped. Procurement runs the commercial process, pricing, contracts and vendor diligence, and security, privacy and legal each sign off inside their own control boundary, but none of them owns the choice. The head of QA judges QA tools against workflow-fit criteria the role wrote down before the evaluation opened: how the tool meets the existing test-management system, what the audit trail looks like when an AI-generated test fails, who reviews output before it reaches a commit. The same pattern applies to PM, Dev, SA and BA. Leave the decision inside procurement and you get a subscription list assembled by whoever advocated loudest, because a vendor evaluation is not built to assess workflow fit. What is an AI operating model?▸ An AI operating model is the working system a company runs to decide where AI is allowed to act, who carries the outcome and the risk, how human and AI work hand off to each other, which shared platforms and controls that work sits on, what review standard applies, how each role's performance is judged, and how often the whole arrangement gets re-examined. The AI security policy, the role redesigns, the reskilling curricula, the tool-selection criteria and the per-redesign delivery metric are its artefacts. They make the system inspectable and they are not the system, which is why programmes that ship all five documents can still stall. It is what you have instead of treating AI adoption as a purchase.