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.

Every so often I hear someone describe another person’s success as luck.

“They were in the right place at the right time.”

“They happened to meet the right person.”

“They caught the wave before everyone else.”

Maybe. But the longer I’ve been in business, the less convinced I am that luck arrives out of nowhere.

What I’ve noticed is that the people who seem lucky are usually the ones who have spent years putting themselves in a position where opportunities can find them.

From the outside, success often looks sudden. From the inside, it rarely is.

Luck Likes Preparation

In the Microsoft 365 space, I’ve seen this play out countless times.

Someone appears to become an overnight authority on Copilot. Suddenly they’re speaking at events, being interviewed, attracting new clients, and building a strong reputation.

What people don’t see are the hundreds of hours spent before that point. The early morning study sessions. The testing in trial tenants. The failed experiments. The blog posts that hardly anyone read. The presentations delivered to small audiences before bigger opportunities appeared.

When Microsoft 365 Copilot became a major topic, the people who had already been investing time in understanding the technology looked lucky.

The reality was that they had simply done the work before the opportunity arrived.

Luck often arrives disguised as preparation.

Opportunities Usually Start Small

Most people are waiting for a big break.

What I see instead is a series of small breaks that compound over time.

A single LinkedIn post leads to a conversation.

That conversation leads to a meeting.

The meeting turns into a project.

The project creates a customer reference.

The reference opens another door.

None of those events look significant on their own, but together they create momentum.

I often compare it to using Copilot in Outlook. You don’t suddenly save ten hours a day. What happens is that you save a few minutes here and there. A faster email response. A quicker summary of a meeting. Less time searching through conversations.

Individually those gains feel minor.

Repeat them every day and the impact becomes substantial.

The same applies to career growth, business development, and personal learning. Small actions performed consistently create outcomes that seem lucky to everyone else.

The Work Nobody Sees Matters Most

One of the lessons that continues to stand out to me is that visible success is only a small part of the story.

The public sees the presentation.

They don’t see the preparation.

They see the successful project.

They don’t see the problems solved along the way.

They see the confident recommendation.

They don’t see the years spent learning enough to make that recommendation with confidence.

That’s why I encourage people to focus less on chasing opportunities and more on becoming ready for them.

Spend time learning.

Build relationships before you need them.

Share what you know.

Experiment with new tools.

Ask questions.

Stay curious.

In my experience, these activities rarely deliver immediate rewards. What they do instead is increase the number of situations where good things can happen.

And that’s where luck begins to appear.

Luck Is Often a By-Product

When I look back across my own career, many of the most valuable opportunities seemed unexpected at the time.

A conversation led to a partnership.

A presentation led to a client engagement.

A blog post opened a door I didn’t know existed.

None of those outcomes were planned in detail.

What was planned was the effort beforehand.

The study.

The writing.

The testing.

The willingness to keep moving forward even when there was no immediate payoff.

That’s why I’ve come to believe that luck isn’t something you wait for.

It’s something you quietly create.

The harder you work, the more skills you build. The more skills you build, the more opportunities you recognise. The more opportunities you recognise, the luckier you appear.

And from where I’m standing, that’s a much better strategy than hoping luck simply turns up on its own.

I hear culture talked about as if it is something written on a wall, captured in a values statement, or mentioned during onboarding. That is the easy version. The harder version is what happens on a normal Tuesday when something is broken, unclear, duplicated, delayed, or ignored.

That is where culture shows up.

Not in the big presentation. Not in the annual planning day. In the small moments where someone decides whether to leave the problem sitting there or do something useful about it.

The warning sign is hesitation

One of the quietest culture problems in any business is when good people start waiting for permission to care.

They see a clumsy process, notice a client communication could be clearer, or hear a decision drift past without an owner, and tell themselves it probably belongs to someone more senior.

None of that looks dramatic. Everyone looks polite, busy, and professional.

But the business is paying a tax every time that happens.

The work gets slower. The standards get softer. Small issues become normal. People learn that caring too much creates extra work, so they keep their heads down. That is how ordinary cultures become fragile cultures.

Ownership has to be visible

If I want a team to lift its standard, I cannot just tell people to take responsibility. I have to make it practical.

That means making it clear that improvement is not reserved for managers. If a client onboarding checklist in SharePoint is out of date, the useful response is not to complain about it in the background. Fix it, or at least raise it clearly in the right Teams channel with enough context for someone to act.

If a meeting ends with vague actions, do not let them vanish into the air. Use Copilot in Teams to summarise the discussion, check the actions, and then make sure the next steps land somewhere visible, such as Planner or a shared work tracker.

That is not bureaucracy. That is housekeeping.

The point is not that every person can change every decision. The point is that every person can make the problem clearer, remove friction, and stop the next person tripping over the same thing.

Quiet leadership matters

The best ownership I see is often quiet. It is not the person dominating the room. It is the person who notices a gap and calmly closes it.

They ask the extra question. They document the missing step. They follow up after the meeting. They update the shared note. They make the next handover cleaner than the last one.

In an MSP or any service business, that behaviour compounds quickly. Clients feel it when internal ownership is strong. Tickets are cleaner. Handover notes make sense. Recurring issues get spotted earlier. The client does not have to re-explain the same problem three times.

That is culture in operational form.

I am not interested in a team where people only do what is printed beside their name. That might keep the lights on, but it will not build something excellent.

The better standard is this: if you are close enough to see the issue, you are close enough to help move it forward.

That does not mean being reckless or ignoring roles, approvals, or security boundaries. It means acting like the quality of the whole business matters, not just your own narrow lane.

Shared ownership is not a slogan. It is a habit. It is built in the everyday choices people make when there is no applause attached.

And if you want to know the real strength of your culture, do not just listen to what people say in the meeting. Watch what they clean up afterwards.