AI Gave Managers Another Invisible Job

AI did not arrive in my work through one decisive meeting.

There was no announcement that managers would now be responsible for guiding adoption, interpreting policy, checking quality, managing anxiety and redesigning workflows. Nobody formally added “figure out how we should use AI” to my job description. It happened through small things that were easy to miss at first.

More tools started offering AI features. People began connecting AI to the systems they already used, some of which contained confidential or sensitive information. “Use AI” became a common instruction, delivered with the casual confidence of “send me the link.” There was an assumption that we should all be moving faster, but very little discussion about where we were going or what we might be carrying with us.

We were adopting AI before we had stopped to ask how we wanted to use it.

Because I noticed that gap, it quietly became part of my work.

I started thinking about the skills the team would need, not only the AI tools we could give them. I thought about how we would review AI-assisted work, how our existing quality checks might need to change and what our workflows should look like when part of the work was being generated rather than written from scratch.

These were not entirely new management responsibilities. Managers have always helped teams adapt to change, maintain standards and develop new capabilities. What was new was the number of decisions arriving at once, wrapped in the suggestion that AI was mainly a productivity tool.

The productivity was visible. The management work around it was not.

There is a strange contradiction in being expected to guide people through a technology that everyone is still learning. A manager is often the person people look to for clarity, yet there was no neat course I could take that would explain all of this. There was no settled set of practices waiting for us on the other side of a certification.

People would use unfamiliar terms as if we had all agreed on their meaning. I would sit quietly, make a note and research them afterwards because I had no clue what they were talking about.

I was embarrassed by that at first.

I am a process-driven person. I like to understand the basic rules and then shape my work around them. I do not need every answer before I begin, but I do need to know where the edges are. With AI, the edges kept moving. The tools were changing, expectations were unclear and many of the people speaking most confidently were learning in real time too.

If I am honest, there are still things about AI that I do not know. I am learning every day. The difference is that I no longer see not knowing as evidence that I am behind. It is simply the reality of working with something that is developing faster than our shared understanding of it.

My team did not respond to that uncertainty in one uniform way either. Some people were afraid of falling behind. Some worried about what AI might mean for their jobs. Some were embarrassed that they did not know how to use the tools. Others felt pressure to appear enthusiastic, even when they were uncertain or unconvinced.

Those reactions could not be resolved by telling everyone to experiment.

Enablement is not merely giving people access to a tool. It means helping them understand what the tool can do, where it can mislead them and what good work looks like when AI has contributed to it. It also means making room for people to admit what they do not understand without treating their uncertainty as resistance.

Managers find themselves holding all of that alongside delivery deadlines, support work, team development and the ordinary unpredictability of leading people. We are expected to encourage experimentation while setting boundaries that may not yet exist. We need to support people who are anxious without making promises about a future we cannot predict. We need to welcome speed while remaining suspicious of what speed can conceal.

We learned something about that last part the hard way.

For a while, we were moving so quickly that we did not notice some errors were going unhandled or were not being logged at all. AI had helped accelerate part of the work, but the surrounding systems had not necessarily kept pace. The output arrived faster. So did the consequences of anything we failed to notice.

What appeared to be saved time returned as bug fixing and support. We prioritised the most important problems, improved our processes and learned from what had happened. We keep fighting the good fight, as people in software tend to say when the alternative is staring silently into the middle distance.

The lesson was not that we should stop using AI. It was that speed changes where the work happens.

When producing something becomes easier, reviewing it may become more important. When a tool creates a plausible answer in seconds, people need stronger judgement about whether that answer belongs in the product. When more work can move through a system, the weaknesses in logging, error handling and review become easier to reach.

That judgement does not appear automatically because a company has bought an AI tool. Someone has to help the team build it. Someone has to notice when the workflow no longer reflects the way the work is being done. Someone has to ask whether the policies are clear, whether sensitive information is protected and whether the team understands that an AI-generated result is still their responsibility.

Often, that someone is a manager who noticed.

This is why I have become more willing to push for processes and policies, even when doing so makes me the person slowing down an enthusiastic conversation. If a new tool can connect to confidential systems, we should understand the security implications before treating adoption as inevitable. If we cannot explain how AI-assisted work will be reviewed, we are not ready to call the resulting speed an improvement.

Asking those questions can feel uncomfortable when everyone else appears ready to dive in. Nobody wants to be known as the person standing beside the exciting new swimming pool asking who checked the depth.

But sometimes leadership means being that person.

It means asking questions when enthusiasm is making questions inconvenient. It means pushing back when “everyone is doing it” becomes the only justification available. It means listening to the feeling that something is not quite right, even if you cannot yet express the concern in polished technical language.

Managers should not have to become AI experts overnight. We do, however, need enough confidence to make uncertainty visible. We need permission to say that a policy is missing, a workflow is not ready or a risk has not been considered. We need time to build the processes that turn experimentation into work the team can safely own.

Senior leaders also need to recognise this as real work.

AI adoption does not happen because access has been granted and a message has been sent encouraging everyone to use it. It happens through hundreds of smaller acts: researching unfamiliar concepts, answering worried questions, establishing boundaries, reviewing output, repairing weak processes and helping people adjust to a new relationship with their own expertise.

That work belongs somewhere. If it is not planned for, it will still happen, but it will happen quietly in the gaps around everything managers were already expected to do.

AI gave managers another invisible job. Perhaps the first step is simply to make it visible.