Your Team Is Building AI Tools After Hours. That's a Management Failure.
Someone on my team built a reporting solution that answered a real need we had. It worked. It was exactly the kind of thing I had been hoping AI would make possible.
They built it after hours.
Not because they were blocked, and not because anybody told them to do it quietly. They built it in the evening because making it work required experimenting with our AI tooling, and nothing I had said made that count as work. I had given the team training. I had given them tools. I had given them encouragement. What I had not given them was permission to spend a Tuesday afternoon on it.
What I had actually done wrong
I asked my team to use AI. That was the instruction, more or less: here are the tools, here is the training, please use them.
“Use AI” is not a priority. It is a direction of travel with no destination attached, and it quietly leaves every judgment call to the individual. Is it worth two hours to get this working? Should I stop doing the thing I am measured on to fiddle with a tool? Nobody says no to those questions out loud. They just answer them the same way you would: by getting on with the work they are actually accountable for.
A priority looks different. “Reduce the time from idea to code in production” is a priority. It names a thing that is currently too slow, and it makes an afternoon spent making AI fit that problem obviously legitimate. The team no longer has to guess whether the experiment counts.
I had supplied everything except the one thing that authorized spending time.
The gap between using AI and making it fit
Here is the part I underestimated. Getting from “I tried the tool” to “the tool now does this job well” is real work, and somebody has to do it.
That work is Building the scaffolding that makes a general tool good at your specific job: saved instructions and prompts, reusable commands, connections to the systems you actually use, and the trial and error of finding out which of those survive contact with real work. It is unglamorous, it rarely finishes in one sitting, and it is invisible in anybody’s output for the week it takes. , and it is exactly the work that has no home in a normal sprint. It does not ship a feature. It does not close a ticket. It shows up on no roadmap. So it gets done by whoever cares enough to do it in their own time, or it doesn’t get done at all.
Gallup’s February 2026 survey of 23,717 US employees puts a number on why this matters. Among people with AI tools available, 88% of those who strongly agree that AI “integrates well with the systems and processes” they use are Gallup’s threshold is using AI a few times a week or more. It is a low bar on purpose: the survey is separating people who have folded AI into the rhythm of their work from people who open it occasionally and then forget about it. The second group still counts as having “adopted” AI in most companies’ numbers. . Among those who do not strongly agree, only 55% are frequent users.
That is one of the widest gaps in the survey, and it is a gap about fit rather than enthusiasm. Integration is not a property the tool arrives with. It is a thing somebody builds, in hours that somebody has to authorize.
This is not a rare failure
I assumed this was something I had got wrong on my own. It looks more like the default.
Ernst & Young surveyed more than 1,000 US desk workers across six industries and found 85% were learning to use AI outside of work. The explanation offered in the reporting is the same one I had created for my own team: day-to-day responsibilities leave little room to explore the tools. One worker in that coverage calls it a “learning tax,” paid in evenings and weekends because the workday is full of meetings and deliverables.
There is a name on this site for using AI tools your employer never sanctioned: shadow AI. What I had produced was the other half of it. The tools were sanctioned. The time was not.
It also explains something that can look like people not caring.
Somebody tries AI on a task. It doesn’t quite fit. They go back to the old way. From the outside, that looks like a lack of interest.
Usually it isn’t. The next step was to keep working at it until it did fit, and nobody had told them that was allowed on a Tuesday afternoon. The people who get the most out of AI keep refining the output instead of taking the first answer. That takes time, and time is the one thing only you can give them.
Finding the priority: change what you ask in a 1:1
I could not name a useful priority by myself, because the specifics live with the people doing the work. So the 1:1 changed.
A standard 1:1 is status, blockers and career. None of those surface the thing you are looking for, because the thing you are looking for is not news. It is the same four hours every week, and it has been that way so long that nobody thinks to raise it. You have to ask directly.
Three questions, which I now ask regularly:
- “What takes up the most of your time?” The plainest version, and it gets at volume. Anything that consumes a large, repeating share of somebody’s week is a candidate whether or not it looks like an AI problem.
- “Is there a part of the process where you have to wait on someone else?” The most useful of the three. Waiting tells you where the slow step is, and the slow step is the only one worth speeding up. Make anything else faster and the work just waits longer at the slow one, so nothing finishes any sooner. That is the whole point of the AI productivity paradox.
- “If there was one part of your job that you could remove, what would it be?” The emotional one, and it surfaces things the other two miss.
Those three are what I ask. There is also something I tell the team, so they can spot candidates without waiting for a 1:1: if there’s a part of your job that you dread doing, that’s a great candidate to offload to AI.
Dread is a reliable signal because people are precise about work they resent, and it is a test somebody can apply to their own week without me in the room. The toolkit’s pilot step asks a one-off version of the same thing when you are hunting for your first use cases. The difference here is that it does not expire. Asking is how you find the first few candidates. Handing people the test is how you stop being the only person looking for them.
Two other things worth knowing. These questions are general enough to work with technical and non-technical teams alike, which matters if you run sessions across a company rather than one function. And ask where they think AI would help, not only where you think it would. They are closer to the work than you are, and the person doing a task every week has a better view of which part of it is worth attacking.
What to do with the answers
The answers are raw material, not a plan. What turns them into a priority is picking one and saying it out loud.
- Name the destination, not the tool. “Reduce the time from idea to production.” “Cut the time it takes to answer a customer.” Something the team already agrees is too slow.
- Say that developing it counts. Explicitly. The sentence people need to hear is that time spent making AI fit this problem is work, not something to be done around work.
- Then name who owns it, which is the argument in Who Owns AI Adoption? That post is about who, and this one is about what for. A named owner with no destination drifts, and a destination with no owner does not move at all. You need both.
The takeaway
I did the parts of AI adoption that are visible. Training, tools, encouragement, enthusiasm. Then somebody built the most useful thing my team got that quarter on their own time, because I had never said that building it was part of the job.
Name one thing AI is supposed to make faster, say that developing it counts as work, and find the candidates by asking better questions in your one-to-ones. The tools were never the constraint. The permission was.
Sources: the integration figures are from Gallup’s AI in the Workplace: What Separates Adopters and Holdouts (opens in a new tab), a survey of 23,717 US employed adults conducted 4 to 19 February 2026 with a margin of error of ±0.9 points. The 85% learning outside work figure is from an Ernst & Young survey of more than 1,000 US desk workers across six industries; I am relying on reporting of that survey rather than the original release, which I could not reach, so treat the figure as approximate. The experience is my own, from running AI workshops and adoption with my own team and designing sessions for other teams at varying technical levels. The claim that permission rather than tooling was the binding constraint is my reading of what happened, not something either survey tested.
Related: Who Owns AI Adoption? When It’s Everyone’s Job, It’s Nobody’s is the ownership half of this problem. Shadow AI: You’re Probably Using AI Your Company Never Approved is the same shape one level down, where the tools are unsanctioned rather than the hours.