Enthusiasm Sounds Like Expertise — Until Something Goes Wrong

Enthusiasm can sound a lot like expertise when you’re listening to a sales pitch.

Someone is excited. They’re confident. They lean forward when they talk. They tell you what they can do, how fast they can do it, how much better things will be once they’re involved. They make big promises, and they may truly believe every word they’re saying.

And sometimes that energy is convincing enough that you think, “This person really knows what they’re doing.”

That’s the tricky part.

Confidence is persuasive. Excitement is persuasive. A person who says “absolutely, we can do that” quickly and without hesitation can feel more competent than the person who pauses, asks questions, and says, “Maybe, but we should look at a few things first.”

But those two responses can come from very different places.

One might come from enthusiasm that hasn’t been tested yet.

The other might come from experience.

And if you’re hiring someone to work on something important — a website, an application, a marketing campaign, a business system, a technical project, a design project, or really anything that matters to your business — that difference can cost you a lot of money, time, stress, and trust.

I don’t say that to make enthusiasm sound like a bad thing. It’s not. Enthusiasm is valuable. I would much rather work with someone who cares than someone who is completely checked out. I like working with people who are excited about solving problems. I like seeing someone take pride in their work. A person who brings energy to a project can be a great asset.

But enthusiasm by itself is not expertise.

And one of the most important things experience teaches you is that things go wrong.

Not always dramatically. Not always catastrophically. But they go wrong in ways that people without experience often don’t even know to look for.

That’s one of the biggest differences between someone who is new and someone who has been through enough projects to have scars.

A new person may be thinking mostly about what’s possible.

An experienced person is thinking about what’s possible, what’s likely, what’s risky, what’s missing, what could break, who needs to be involved, what assumptions are being made, and what happens if those assumptions are wrong.

That may not sound as exciting in a sales conversation.

But it may save the project.

I’ve met people who are brand new at something and absolutely certain they can handle it. They’re not lying. They’re not trying to be reckless. They may genuinely believe they can do the job. They may have watched a few tutorials, completed a few small projects, built something that looked impressive, or used new tools that helped them move quickly. Their confidence may be completely sincere.

The problem is that they haven’t seen enough go wrong yet.

They haven’t lived through the ugly projects.

They haven’t dealt with the difficult customers.

They haven’t experienced the unexpected technical failures.

They haven’t watched a “simple” request turn into a complicated mess because of one hidden dependency.

They haven’t seen how one decision made casually at the beginning can become expensive later.

They haven’t learned which promises are easy to make and which promises you should be very, very careful making.

That kind of knowledge usually doesn’t come from reading a blog post or watching a video. It comes from doing the work long enough to see patterns. It comes from having to fix things. It comes from being responsible when things don’t go according to plan.

And honestly, that’s a lot of what experience is: pattern recognition built from consequences.

When you’ve been through enough projects, you start recognizing the warning signs early.

You hear a request and think, “That sounds simple, but I know where that can get complicated.”

You see a proposal and think, “There’s a missing step here.”

You hear a deadline and think, “That might be possible, but only if certain decisions are made quickly.”

You hear someone say, “We just need a simple integration,” and you know enough to ask, “With what system, using what API, with what permissions, and who controls the data?”

You hear someone say, “We want to redesign the website,” and you know the conversation probably isn’t just about design. It may involve content, search visibility, lead generation, analytics, redirects, hosting, performance, accessibility, mobile experience, forms, email deliverability, CRM connections, and a dozen internal opinions that haven’t surfaced yet.

That’s experience.

It doesn’t always show up as a flashy answer. Sometimes it shows up as caution.

And caution is underrated.

In a sales pitch, caution can sound less impressive than confidence. If one person says, “Absolutely, we can do that,” and another person says, “Yes, but before we do, there are three things we need to check,” the first person may sound more capable.

But the second person may be the one who actually knows what they’re doing.

That’s not always easy to recognize, especially if you’re not an expert in the thing you’re hiring for. You may not know which questions should be asked. You may not know what usually goes wrong. You may not know whether the confident answer is well informed or just optimistic.

That’s why enthusiasm can be so misleading. It fills in the gaps. When we don’t know how to evaluate the technical details, we often evaluate the presentation. We evaluate confidence. We evaluate personality. We evaluate how good the proposal looks. We evaluate how quickly someone responds. We evaluate whether they make us feel like the problem is under control.

Those things matter, but they are not the same as expertise.

The danger is that someone can be very good at sounding like they understand a problem before they’ve actually understood it.

They can use the right language.

They can repeat terms they’ve heard.

They can show examples that look polished.

They can promise results.

They can make the whole thing feel easy.

But real expertise often comes with a certain respect for complexity. Not fear. Not negativity. Not an unwillingness to take on challenges. Just respect.

An experienced person has usually learned that the first version of the problem is rarely the whole problem.

The thing a client asks for is often not the thing they actually need. Or it is the thing they need, but it depends on seven other things being true. Or it can be done, but not in the way they imagined. Or it can be done quickly, but not cheaply. Or cheaply, but not well. Or well, but not without changing some expectations.

That’s not because experienced people want to make everything complicated. It’s because they’ve seen how expensive oversimplification can be.

I think about this a lot with websites and digital projects because people often underestimate what sits underneath something that looks simple.

A website can look finished on the surface. The homepage loads. The images are nice. The buttons work. The pages exist. The design looks clean.

But that doesn’t necessarily mean the project was done well.

What about the structure?

What about the content strategy?

What about search engine visibility?

What about page speed?

What about mobile behavior?

What about accessibility?

What about security?

What about backups?

What about tracking?

What about form notifications?

What about spam protection?

What about redirects from the old site?

What about broken links?

What about ownership of accounts?

What about plugin updates?

What about future maintenance?

What about the client’s ability to actually use the thing after it launches?

A person can produce something that looks good quickly and still miss things that matter. And sometimes those missing things don’t become obvious right away. They show up later, after launch, when traffic drops, leads stop coming in, forms don’t deliver, pages break, updates fail, or no one knows how to change anything without calling the original developer.

That’s where experience matters.

Experience is not just the ability to create something. It’s the ability to anticipate what the thing will need to survive after it’s created.

And I think AI is making this distinction even more important.

AI can now help people produce impressive-looking work very quickly. A website. An application. A logo concept. A marketing plan. A proposal. A content outline. A strategy document. A pitch deck. A piece of code.

That’s powerful. I use AI. I think it can be incredibly useful. It can speed up parts of the process, generate ideas, reduce repetitive work, and help capable people do more.

But AI also makes it easier to create the appearance of expertise.

Someone can use AI to produce something that looks finished, sounds polished, and feels professional. They can generate a proposal full of confident language. They can create a design mockup that looks impressive. They can produce code that appears to work. They can generate a marketing plan that uses all the right terminology.

But getting something to look finished and understanding everything underneath it are two different things.

That gap matters.

A person who doesn’t deeply understand what they’re producing may not know whether the AI output is good. They may not know what’s missing. They may not know which assumptions are wrong. They may not know what will break under real-world conditions. They may not know whether the recommendation is appropriate for the specific business, audience, budget, goals, and constraints involved.

AI can give a novice a much louder voice.

It can give them better-looking materials.

It can help them move faster.

But it does not automatically give them judgment.

And judgment is one of the biggest things you’re actually paying for when you hire an expert.

You’re not just paying for the final deliverable. You’re paying for the decisions that shape that deliverable. You’re paying for the ability to know what matters, what doesn’t, what’s risky, what’s avoidable, what’s worth spending time on, and what is going to create problems later.

That’s hard to evaluate from the outside.

Because, again, enthusiasm can sound like expertise.

A person with limited experience may say yes to everything because they don’t yet know why they shouldn’t.

They may promise a timeline because they haven’t had enough timelines collapse.

They may promise a feature because they haven’t maintained that feature for two years.

They may promise a result because they haven’t seen all the reasons results vary.

They may promise an easy process because they haven’t managed enough messy ones.

An experienced person may still be optimistic, but their optimism is usually more qualified.

They might say, “Yes, that’s possible, but let’s confirm the requirements.”

Or, “We can do that, but I want to understand who will maintain it.”

Or, “That timeline may work if content is ready before design begins.”

Or, “That integration sounds straightforward, but we need access to the documentation.”

Or, “Before we rebuild this, let’s check what’s currently driving your traffic so we don’t accidentally remove something important.”

Those answers are less dramatic. They don’t always create the same instant excitement. But they are often the answers that protect you.

And that’s the thing I wish more people valued when hiring: the expert who slows down at the right moments.

Not slow for the sake of being slow. Not bureaucratic. Not indecisive. But careful where care is needed.

There is a difference between hesitation and wisdom.

There is a difference between negativity and risk awareness.

There is a difference between someone who is afraid to do the work and someone who knows what needs to be checked before the work begins.

A good expert should not make everything feel impossible. That’s not what I’m saying. I don’t like working with people who shoot down every idea either. The best people bring both imagination and discipline. They can see what’s possible, but they also know what can get in the way.

That balance is what you want.

Enthusiasm tells you what’s possible.

Experience tells you what could get in the way.

And when you’re choosing someone to help with an important project, you probably want both.

You want someone who cares enough to be excited and experienced enough to be careful.

So how do you tell the difference?

How do you separate genuine experience from enthusiasm that hasn’t been tested yet?

One of the best ways is to ask a very simple question:

“What have you seen go wrong with projects like mine?”

Then listen carefully to the answer.

That question changes the conversation.

It moves the person out of pure sales mode. It asks them to draw from real experience. It gives them a chance to show you whether they’ve actually been around the kinds of problems your project may face.

Someone with genuine experience usually has stories.

They can tell you where projects fail.

They can tell you what surprises people.

They can tell you what clients often underestimate.

They can tell you what they watch for early.

They can tell you what they do differently now because of what they’ve learned.

They can tell you about the time content delays pushed a launch back. Or the time a third-party system didn’t behave the way the documentation said it would. Or the time a redesign hurt search traffic because redirects weren’t handled correctly. Or the time too many decision-makers slowed everything down. Or the time a client wanted a feature that sounded simple but required ongoing maintenance no one had planned for.

Those stories matter because they reveal more than technical knowledge. They reveal judgment.

They show that the person has had to navigate reality, not just theory.

Reality is where projects get complicated.

In theory, everyone delivers content on time.

In reality, content is often late.

In theory, all integrations work as expected.

In reality, APIs change, access is missing, permissions are wrong, documentation is outdated, and support takes three days to respond.

In theory, the client knows exactly what they want.

In reality, seeing the first version often changes the conversation.

In theory, everyone agrees on the goals.

In reality, sales, marketing, operations, leadership, and customer service may all want different things.

In theory, a project is just a project.

In reality, it is people, timing, technology, budget, priorities, communication, assumptions, and decisions all moving at once.

Experience teaches you to account for that.

That’s why “What have you seen go wrong with projects like mine?” is such a useful question.

A shallow answer might sound like, “Nothing really. We’ve got it covered.”

That may be true, but I’d be cautious. If someone has never seen anything go wrong, they may not have done enough. Or they may not be paying attention. Or they may be unwilling to have an honest conversation because they think admitting risk will hurt the sale.

A better answer sounds more specific.

“Well, with projects like this, delays usually happen when content isn’t ready, so I’d want to create a content plan early.”

Or, “The biggest issue I’ve seen is scope creep, especially when new features get added after development starts. I’d recommend we define priorities up front.”

Or, “If we’re replacing an existing website, we need to be careful with redirects and page structure so we don’t lose search visibility.”

Or, “The risk is not building the thing. The risk is whether your team can maintain it after launch, so I’d want to make sure the backend is easy for you to use.”

Or, “This can work, but the third-party integration is the unknown. I’d want to test that before we commit to the full build.”

Those answers tell you something.

They show that the person is not just imagining the happy path. They understand the rough edges.

And every real project has rough edges.

That doesn’t mean you should only hire people who have done your exact project a hundred times before. Sometimes a smart, capable person can adapt. Sometimes newer people do excellent work, especially if they are honest about what they know and careful about learning what they don’t. Everyone starts somewhere.

The issue is not whether someone is new.

The issue is whether their confidence is proportional to their experience.

A newer person who says, “I haven’t handled that exact situation before, but here’s how I’d approach it, and here’s what I’d want to verify first,” may be far more trustworthy than someone who says, “No problem,” to everything.

Humility is a good sign.

Specific questions are a good sign.

Clear boundaries are a good sign.

A willingness to identify risks is a good sign.

Overconfidence without detail is a warning sign.

If someone can’t explain what might go wrong, they may not know.

If someone acts like nothing could go wrong, they may not be prepared when something does.

If someone promises everything will be easy, they may be selling you the version of the project that exists before reality gets involved.

And reality always gets involved.

This is especially important because business owners and decision-makers are often under pressure when they hire. They need something fixed. They need something launched. They need more leads. They need a better website. They need software that works. They need a system that saves time. They need help, and they’re hoping the person in front of them can provide it.

When you’re in that position, it feels good to hear certainty.

It feels good to hear, “Yes, we can absolutely do that.”

It feels good to hear, “That won’t be a problem.”

It feels good to hear, “We can move fast.”

And sometimes those things are true.

But certainty should be backed by substance.

If someone is confident, ask what their confidence is based on.

Have they done this before?

What happened?

What problems came up?

What would they watch out for this time?

What information do they need before they can give you a firm answer?

What assumptions are they making?

What would change the timeline or budget?

What part of the project is most uncertain?

These questions don’t need to be hostile. This isn’t about trying to catch someone or make them uncomfortable. It’s about having a more honest conversation before money is spent and expectations are set.

A good professional should welcome that conversation.

They may not have perfect answers to everything, but they should be able to talk thoughtfully about the work. They should be able to explain their process. They should be able to identify risks. They should be able to say, “I don’t know yet,” when they don’t know yet.

That last one is important.

“I don’t know yet” can be a very professional answer.

It depends what comes after it.

“I don’t know yet, but here’s how we’ll find out” is very different from guessing.

One of the most expensive things in a project is a bad assumption made confidently.

Someone assumes the old website pages don’t matter.

Someone assumes the client has all the content ready.

Someone assumes the software can connect easily.

Someone assumes a plugin will handle it.

Someone assumes users will understand the interface.

Someone assumes the team has time to maintain the new system.

Someone assumes the deadline is flexible.

Someone assumes the budget can stretch.

Someone assumes no one else needs approval.

A lot of project trouble begins with assumptions that were never tested.

Experience teaches you to test them earlier.

That is why the experienced person may ask more questions at the beginning. They are not trying to complicate the sale. They are trying to uncover the hidden parts of the project before those hidden parts become expensive.

That can be frustrating if you just want a quick answer.

But quick answers are not always valuable answers.

Sometimes the most valuable answer is, “Let’s slow down for a minute.”

Again, enthusiasm has its place. I don’t want to drain the energy out of work. Good projects need momentum. They need people who care. They need creative thinking and a willingness to solve problems. If someone has no enthusiasm, that’s its own problem. I don’t want to hire someone who treats every project like a burden.

But enthusiasm needs to be paired with reality.

Otherwise, it can become dangerous.

The enthusiastic beginner often sees the destination clearly but not the terrain.

The experienced professional sees both.

They know there may be hills, detours, weather, traffic, mechanical problems, and a few places where the map is wrong.

That doesn’t mean they don’t want to go. It means they know how to prepare.

And preparation is a huge part of expertise.

When I think about the people I trust, they are not always the people with the flashiest pitch. They are the people who can tell me what they’re thinking. They can explain tradeoffs. They can say, “Here’s the benefit, here’s the risk, and here’s what I recommend.” They don’t need to pretend everything is simple to prove they’re competent.

In fact, the more someone understands a subject, the more comfortable they usually are discussing nuance.

They don’t have to hide behind certainty.

They know where certainty is appropriate and where it isn’t.

That’s a sign of maturity.

It is also a sign that they’ve been accountable before.

Accountability changes how people talk.

If you’ve had to stand behind your work after launch, you speak differently than someone who only focuses on getting the job.

If you’ve had to clean up a rushed decision, you speak differently about shortcuts.

If you’ve had to explain to a client why something took longer than expected, you become more careful about timelines.

If you’ve inherited messy projects, you become more careful about structure.

If you’ve watched something fail because nobody asked the right question early enough, you start asking that question.

That is the value of experience.

It is not just years. Years alone don’t guarantee wisdom. Someone can repeat the same mistakes for a long time. But real experience — the kind that includes paying attention, learning, adapting, and improving — changes how you approach the work.

It makes you better at seeing around corners.

That’s what you are often hiring when you hire an expert: someone who can see around corners you don’t know are there.

So the next time you’re talking to someone who is making confident promises, pay attention to how they handle risk.

Do they acknowledge it?

Do they ask thoughtful questions?

Do they have examples?

Do they understand what can go wrong?

Do they explain how they prevent problems?

Do they tell you what they need from you for the project to succeed?

Do they talk only about the finished result, or do they understand the path required to get there?

And ask the question:

“What have you seen go wrong with projects like mine?”

Then be quiet and listen.

The answer may tell you more than the pitch.

If they have real experience, they probably won’t struggle to answer. They may even appreciate the question because it gives them permission to talk honestly about how projects actually work.

They may say, “Here are the biggest things I’d watch out for.”

They may say, “This is where clients usually get surprised.”

They may say, “This is the part I’d want to validate first.”

They may say, “I’ve seen this go sideways before, and here’s how I prevent that now.”

That is the kind of answer that builds trust.

Not because it promises perfection, but because it shows awareness.

I don’t trust people more when they pretend nothing can go wrong. I trust them more when they can tell me what might go wrong and how they plan to handle it.

That is more valuable than a perfect-sounding pitch.

Because in the real world, projects are not protected by enthusiasm alone.

They are protected by judgment, communication, process, preparation, and the willingness to be honest before problems become expensive.

So yes, hire enthusiastic people. Work with people who care. Choose people who have energy and ideas and want the project to succeed.

But don’t mistake excitement for expertise.

Don’t mistake confidence for competence.

Don’t mistake a polished proposal for proven judgment.

Don’t mistake fast output for deep understanding.

Especially now, when tools can make almost anyone look more capable on the surface, it is worth looking underneath.

Ask better questions.

Listen for real stories.

Pay attention to whether the person understands failure, not just success.

Because enthusiasm tells you what’s possible.

Experience tells you what could get in the way.

And when you’re choosing an expert, you probably want both.