When AI Changes the Work, Leadership Has to Change with It

I don’t mean it as a way to avoid a decision. Sometimes the answer genuinely isn’t settled yet, and that is happening a lot as AI becomes part of everyday product work. I see this with designers who once delivered static prototypes and are now building coded ones. That changes what design owns, what engineering inherits, and where friction happens between the two.

It also creates a whole set of questions we didn’t have before.

How technical do designers need to be?
How should we manage token usage and context?
How much does code quality matter in a prototype?
What should engineering expect when that work is handed off?

We are still figuring out the standards, and I wouldn’t assume the answers we use today will still be the answers in six months.

McKinseyhas found that AI adoption is moving faster than leadership readiness. Their argument goes beyond leaders simply needing to know what AI can do. As AI starts changing the structures of the work itself, leaders need enough firsthand fluency to understand its limitations, question its output, and make informed decisions about how people work, who owns what, and what needs to change. Understanding the technology at a high level is no longer enough. Leaders can’t treat AI as something they learn once and then move on from.

None of this means the work can stop while leaders catch up. Teams still need direction. Decisions still have to be made, even as the tools, roles, and expectations shift beneath them.

So the leadership question becomes, “How do we move forward thoughtfully when the answer isn’t certain?”

For me, meeting that challenge requires putting curiosity before certainty.

Saying “I don’t know yet” is still an act of leadership

There is a clear distinction between saying “I don’t know yet” and abandoning your team.

The phrase fails when no one takes ownership, clear next steps are omitted, and team members are left without direction. It becomes useful when you follow it with a plan, such as, “I don’t know yet, but here’s what we know so far and what I think we need to figure out next.”

I’ve grown comfortable with this method because revealing my thought process often adds more value than simply handing down an answer. When team members see what factors I’m weighing, where uncertainty remains, and what might change my perspective, they gain a foundation to engage with. They can question the logic and point out blind spots.

Amy Edmondson described a similar approach in a 2024 Harvard Business Reviewdiscussion about decision-making under uncertainty. She talks about getting more comfortable with not knowing, favoring learning over knowing, and testing until there is enough confidence to act. Not absolute confidence. Enough.

A leader can provide clear direction on next steps without claiming that every detail is finalized.

Curiosity as a method, not a personality trait

Recently, I noticed designers burning through their Claude usage very early in the month. The easy explanation was that people were using too many tokens. That did not tell me much. I wanted to know why.

So I started digging. I asked a few designers to analyze their own usage patterns and compared their results with mine. I looked through documentation. I paid attention to model choice, context management, how long conversations were allowed to run, and how much of the codebase each interaction pulled in. I also talked with other people in the company about how they were using the tool and asked AI systems to help me interrogate some of the patterns I was seeing.

That sent me in a direction I had not expected. Designer behavior did not map neatly to developer behavior.

A designer working visually may spend much more time saying, essentially, “Move this. Try that. No, go back. Make this responsive. Change that state.” It is a different interaction pattern from a developer working inside a more compact codebase in VS Code. More back-and-forth can mean more context, more repeated code, and more usage. Suddenly the question was not “Why are designers using so much?” It was “What is it about this workflow that is expensive?”

Changing the question gave me a much better place to start. I still do not think I have a final answer. What I have is a better explanation than I started with, a few things worth changing, and a better idea of what I want to watch next.

That is the kind of curiosity I find useful at work.

Notice something odd.
Get specific about the question.
Look at more than one source.
Talk to the people actually doing the work. Make a call when you have enough to go on, then keep paying attention.

Judgment is knowing what you know and what you don’t

Curiosity can also pull you past the edge of your expertise. AI makes that edge easier to cross because it lets people produce work in domains where they have some knowledge, but not necessarily deep experience.

I have enough technical background to inspect code structure, recognize patterns that concern me, communicate with engineers, and suggest an approach. That has been useful as our design work has moved closer to code. But I don’t work inside the development team’s production codebase every day, and that matters.

Sometimes the right thing for me to say is, “Here is how I think this should work and why. I may be missing something about this codebase, so I want someone who works in it every day to validate that.”

I don’t see that as stepping back from an opinion. I see it as testing the opinion before I ask other people to trust it.

The same thing applies when I am trying to influence a team without formal authority. I cannot declare a standard and rely on my title to carry it. If I think we should change how we work, I have to show people what I see and why I think the change is worth making. Previous credibility helps. So does evidence. And sometimes someone closer to the problem has a better answer.

I would rather revise my recommendation than keep defending something once better information shows up.

Eventually, experimentation needs rules

None of this means teams should stay in experiment mode forever.

Eventually, experimentation has to turn into a shared way of working.

That becomes more important once AI-assisted work is part of regular delivery. Without clear expectations, different teams build different habits, quality gets harder to judge, and people keep solving the same problems from scratch. The freedom that helps in an early experiment can become expensive when it turns into the default operating model.

Deloitte’s 2026 research on agentic AIfound that adoption was outpacing governance, with only 21 percent of surveyed organizations reporting a mature governance model. That gap makes sense. A team can start using a new tool tomorrow. Building common expectations takes longer.

But “the tools are changing” cannot become a permanent reason to avoid standards.

A team can say, “This is the approach we are using right now because it is the best one we have evidence for. Follow it. If the evidence changes, we will change the standard.”

I actually like that kind of rule. It gives people something concrete to work from without pretending the decision is carved in stone.

A standard gives people something to work from now, even if we revise it later.

Curiosity before certainty

The more I work this way, the less I think leadership is about one person having the best answer in the room.

No single team sees the whole picture. Design sees one set of problems. Engineering sees another. Product, QA, security, operations, customers, and leadership each see different parts of the same change.

Someone still has to make sense of it.

That means paying attention to repeated problems, knowing who needs to be in the conversation, and deciding when there is enough evidence to move. Sometimes it also means changing your mind in public.

I expect the tools we use a year from now to be different. Some of the practices I believe are right today will probably change with them.

What matters more to me is whether people understand how we got to the decision, what informed it, and what could make us revisit it.

When AI Changes the Work, Leadership Has to Change with It was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.