I have sat in plenty of meetings where everyone seemed to understand a term except me. A new acronym appeared on a slide, heads nodded around the room, and the conversation moved on. For years, the temptation was to stay quiet and work it out later. I did not want to be the person who slowed things down.

Now I see that moment differently. If I do not understand something, there is a fair chance somebody else is equally lost. The difference is that nobody wants to say so.

Questions expose the real work

I have learned that a simple question can be more useful than an impressive answer. “What does that mean in practice?” can uncover assumptions, vague thinking and risks that polished language has hidden.

This matters even more with AI. The vocabulary is arriving faster than most people can absorb it. Agents, grounding, orchestration and retrieval are discussed as if they have always been part of ordinary business conversation. They have not. Pretending otherwise does not make anyone more capable. It only makes the room less honest.

When I am working with Microsoft 365 Copilot, I treat uncertainty as a starting point. If I receive a long technical email in Outlook, I can ask Copilot to explain the unfamiliar concepts in plain language, identify what decisions are being requested and suggest questions I should take back to the sender. That does not replace my judgement. It gives my curiosity somewhere productive to go.

The same approach works in Teams. After a meeting, I might ask Copilot what terms were used without explanation, where the discussion relied on assumptions, or which points need clarification. The value is not in looking clever. The value is in leaving the meeting with fewer gaps hidden behind polite nodding.

Expertise is not knowing everything

The longer I work in technology, the less impressed I am by people who always need to appear certain. Technology is too broad, and it changes too quickly, for anyone to know everything. Real expertise is often visible in the quality of the questions someone asks and in how quickly they can turn an unknown into something useful.

I would rather work with a person who says, “I have not come across that before. Show me how it works,” than someone who fills the silence with confident guesses. The first response creates progress. The second creates risk.

For MSPs, this is especially important. Clients do not need us to perform certainty. They need us to investigate carefully, explain clearly and be honest about what we know. A technician who raises a hand early can prevent hours of rework. A business owner who asks what a Copilot proposal will actually change in the client’s day can stop a shiny but pointless project before it starts.

Curiosity needs practice

I do not think curiosity is a personality trait reserved for naturally inquisitive people. I think it is a professional habit. I can practise it by keeping a short list of things I did not understand during the week, then using Copilot in Word or Loop to explore them, organise my notes and identify what deserves deeper learning.

The goal is not to remove every gap. That is impossible. The goal is to become comfortable enough with the gap to examine it openly.

I no longer see “I don’t know” as an admission of weakness. I see it as the first accurate statement in a useful conversation. What matters is what I do next: ask, test, read, listen and come back with a clearer view.

Knowledge has limits. Curiosity keeps moving.

I’ve lost count of how many times a business owner has told me they’ll bring Copilot in “once we’re ready”. They mean it kindly. They want their data tidy, their policies signed off, their people trained, their SharePoint folders renamed from Final_v3_actual_final. And then they wait. Months pass. The readiness never quite arrives, because readiness isn’t a destination. It’s a story we tell ourselves to justify not starting.

Nobody learns to swim by reading about water. You learn by getting in, going under a little, and coming up knowing something you didn’t know before you got wet.

Confidence Is a Result, Not a Prerequisite

The people I see getting real value from Copilot didn’t feel ready either. They just opened Outlook one busy Tuesday, hit the Copilot button, and asked it to draft a reply to a client email they’d been avoiding. The draft wasn’t perfect. They fixed it. Next time it was faster. That small, slightly awkward first attempt taught them more than any rollout plan ever could.

Waiting to feel confident before you start gets the order backwards. Confidence is what you earn after you’ve fumbled through the first few goes. Ask Copilot in Teams to summarise a meeting you half-missed, and yes, the first summary might skate over the thing that actually mattered. So you learn to prompt it better. That’s not failure. That’s the lesson doing its job.

Small Goes Under, Not a Deep End

Drowning a little every day doesn’t mean throwing your team off the boat. It means deliberate, survivable exposure. Pick one repetitive task this week and hand it to Copilot. Draft the weekly client update in Word. Ask Copilot in Excel to explain what’s driving the number in a spreadsheet you inherited and never fully understood. Have it pull the three key points out of a forty-message channel in Teams before your Monday catch-up.

None of these are bet-the-business moments. Each one is a small go under the surface. Some will work beautifully and some will come back wrong — and the wrong ones are where the real learning lives, because they teach you where the tool’s edges are and where your own judgement still has to sit on top.

The businesses that stall are the ones treating adoption like a single, perfect dive that has to be flawless. The ones that get somewhere treat it like laps. A bit every day. Slightly uncomfortable. Steadily better.

The Water Was Never Going to Be Warm

Here’s the part nobody wants to hear: it never feels comfortable at the start, and that discomfort is not a signal to wait. It’s the signal you’ve finally begun. The team that’s “not ready” but using Copilot daily is six months ahead of the team that’s still perfecting its readiness checklist — because they’ve been quietly getting better the whole time the other one was preparing.

You don’t need clean data to draft an email. You don’t need a governance framework to summarise a document. You need a task, a first attempt, and the willingness to be a bit rubbish at it for a week.

What I’m watching now is how quickly the gap widens between the businesses that started imperfectly and the ones still waiting to feel ready. My honest read? The water’s fine. Get in.

A few weeks ago I sat with a business owner who’d been quietly avoiding Copilot for months. Not because he doubted it — because he was worried he’d look foolish in front of his own team. He’d typed one clumsy prompt, got a mediocre answer, and decided the whole thing wasn’t for him. I told him the honest truth: your first attempt was always going to be a bit rubbish. Mine were too. That’s not the exception. That’s the process.

We’ve built up this strange expectation that new tools should work perfectly the moment we touch them. AI has made it worse, because the demos look so slick. So when reality delivers a bland summary or a reply that misses the mark, people don’t think I need to adjust — they think this doesn’t work. And then they stop.

Getting It Wrong Is the Point

Here’s what I’ve noticed working with people on Copilot. The ones who get value fastest aren’t the smartest or the most technical. They’re the ones willing to look a little silly while they learn. They’ll ask Copilot in Outlook to draft a reply, read it, wince, and then say “no, make it shorter and less formal.” That second and third pass is where the magic actually happens. The first prompt is just you clearing your throat.

I watched someone ask Copilot in Word to pull together a proposal from three older documents. The first version was a mess — it grabbed the wrong figures and buried the point. Instead of giving up, she told it exactly what was wrong. Ninety seconds later she had something genuinely usable. If she’d walked away after attempt one, she’d have told everyone Copilot “couldn’t do proposals.” Instead she’d learned how to steer it.

Small, Low-Stakes Failures

The trick is choosing where you’re allowed to get it wrong. Don’t stake your reputation on a board paper for your first go. Start somewhere forgiving. Ask Copilot in Teams to catch you up on a meeting you missed and see how close it lands. Have it summarise a long email thread in Outlook before you reply. If it’s off, you’ve lost nothing and learned how it thinks. These little experiments cost you a minute and quietly build the instinct you’ll lean on later.

What surprised me most is how quickly that instinct transfers. Once you’ve learned to nudge Copilot in Excel toward the right analysis, you already know how to nudge it in PowerPoint, or in a Loop page, or anywhere else. The skill isn’t the tool. The skill is being comfortable with the first answer not being the final one.

Give Yourself Permission

So I’d offer the same thing I offered that business owner. Give yourself permission to be a beginner again. Expect the early attempts to disappoint you. Treat each poor result as a clue, not a verdict. The people falling behind right now aren’t the ones failing — they’re the ones so afraid of failing that they never start.

I’m watching this play out across dozens of businesses, and the pattern is consistent. Comfort with imperfection is becoming its own competitive advantage. The willingness to fumble, adjust, and try again is quietly separating the people who’ll thrive with these tools from the people who’ll keep waiting for them to be “ready.” They already are. The question is whether you are.