"You can see it again here: we all have to play together, or it doesn't work." That sentence opened a discussion in one of our recent team meetings, and it told me more about our AI adoption than any roadmap. My answer was: the biggest change-management challenge at XALT right now is getting everyone to dare to ask dumb questions. And to let others see when you don't know something.
In this post I explain why this is the real bottleneck of change management for AI adoption, what I actually look for in new colleagues, and which rules we take from it for our own team.
AI agents make not knowing visible
It used to be possible to close knowledge gaps quietly. You read up, asked a colleague in private, or waited. With shared AI agents, that no longer works. When a team works in the same sessions, as we described in our post on OpenClaw Multiplayer in the enterprise, everyone sees everyone else's prompts. Every question to the agent is a question in front of the whole team.
That sounds uncomfortable at first. I mostly see the upside, because gaps cannot be hidden anyway. In the meeting I put it like this: "As CEO, I see who has knowledge gaps somewhere. I see it all the time. It's not as if nobody notices." So hiding a gap protects nobody. It only costs time, because you learn alone and slowly instead of with the others and fast.
Research has described this pattern for a long time. In her study of psychological safety and learning behaviour in work teams, Amy Edmondson showed that teams learn when their members believe they will not be punished for questions, mistakes and doubts. With AI, that link matters more, because tools and ways of working now change from one month to the next.
Not knowing is fine. Standing still is not.
When a new colleague joins us, I check exactly one thing: can this person learn fast enough? Prior knowledge comes second. An example from the meeting: if a project manager joins who has never worked with stories and never built a plan, that is no problem. But two weeks later, they need to have it down. That can be learned. It only becomes a problem when someone won't be taught and stands still.
For AI adoption, that means the question "who already knows how to work with agents?" helps you little. The better question is: who tries it, shows the interim result and asks for feedback? That is how you recognise learning speed:
- Someone asks the question early, instead of arriving three days later with a finished but wrong result.
- Someone shows the prompt and the work in progress, even when both are still rough.
- Someone takes a correction on board and applies it on their own the next time.
- Someone passes on what they learned, so the next person gets there faster.
Feedback needs a structure
Asking questions is one half. The other half is how the team responds. In the meeting, a colleague suggested collecting feedback systematically: "It's actually simple. You have a certain structure, you don't have to overdo it. But today nobody feels attacked." That is where the idea of feedback training for the whole team came from.
The point behind it: without a shared form, feedback quickly gets personal. Someone who hears "you did that wrong" after a weak agent result will not ask the next time. A light structure is often enough:
- Observation first: what happened in the result, without judging the person?
- Effect second: what does it mean for the client, the project or the next steps?
- Suggestion last: what would a better prompt, context or workflow look like?
- Feedback right in the shared session, so everyone learns from it, not just one person.
The team's memory inside the agent
A third thought from the meeting was about project history. A colleague said to me: "What I really like is that you have the history of a project. That will take load off you." We have Loom recordings from several years, and an agent can now make them searchable.
For the question of asking, this matters more than it sounds. People who can ask the agent first are more likely to ask at all. A new project manager does not have to ask three colleagues about a client's background. She asks the agent, reads up and comes into the conversation with a better question. The first follow-up question in the meeting came right away, by the way: where are these recordings actually stored? That is exactly how it should go. Before you feed years of recordings into an agent, settle storage location, access and retention.
What you can change in your team
- Say openly that questions are welcome, and as a leader, ask the first visible dumb question yourself.
- Judge new people by their learning speed and agree on a clear time frame, such as two weeks for a new tool.
- Give the team a simple feedback structure and practise it together before agents are in wide use.
- Make project knowledge available to agents, with a settled storage location and clear access rights.
- Let work with agents happen in shared sessions, so good questions and good answers are visible to everyone.
If we get this right, we have a really strong team. That is how a colleague summed it up at the end of the meeting. We need no more tools for it. We need people who dare to learn out loud. If you want to feel what that is like, you can start with me: in 90 minutes of vibe coding every question is allowed, and you finish with a working solution. For whole teams, there is our vibe coding workshop.
