When Experience Stops Being an Asset

Experience is one of the most valuable things someone can bring to a team — until it becomes the reason ideas get dismissed before they're fully explained. There's a thin line between judgment and ego.

Someone is walking you through a proposal. You’re three paragraphs in when you hear it: “yeah, we already tried that.” End of conversation. The room closes before they finish the sentence.

Not necessarily because the proposal is bad. But because the person across the table has twenty years of experience, knows how these stories end, and their pattern recognition already fired the alarm.

If you’ve seen that moment, you probably remember it.

Experience is real and it matters

Before getting into what goes wrong, let’s say the obvious: experience genuinely matters. A professional with ten or fifteen years in a domain has something no manual or model can fully replicate — accumulated context. They know which projects failed and why. They know which proposals look good on paper and blow up in production. They know when the problem you’re describing isn’t the real problem.

That kind of judgment is rare and expensive. In data projects especially, where design mistakes get paid for over years, having someone like that on the team is a real advantage.

The problem isn’t experience. The problem is something specific that sometimes happens to experience.

When does experience become a problem?

There’s a moment — not always obvious — when experience stops being a tool for making better decisions and starts being a way of protecting the image of the person who has it.

The practical difference is subtle but important:

• Judgment grounded in experience: “This won’t work because in similar contexts X happened, and we have the same underlying condition here.”
• Ego dressed up as judgment: “This won’t work.” (And if you ask why, the answer is vague or circular.)

The first is valuable. The second is noise that also happens to carry authority.

How do you tell them apart in real time? Not always easily. But there are signals: when the objection arrives before the other person finishes explaining, when the reasons are generic (“those things never scale”, “we’ve seen this before”), or when the person objecting has more to lose if the proposal succeeds than if it fails.

What this looks like in practice

In data and tech teams this pattern shows up regularly. A few concrete versions:

The one who dismisses new tools without evaluating them. DuckDB, dbt, Polars — anything that didn’t exist when they built the current architecture. “We already have something that works” is a valid answer sometimes. But when that answer arrives without actually looking at what the new tool does, what’s happening isn’t technical judgment. It’s preservation of the status quo.

The one who always has a case from ten years ago. “At my previous company we tried something like that and it was a disaster.” Could be useful information. Could also be a completely different situation used as an argument from authority. Without context for why it failed, the case only says “I saw something similar go wrong” — not “in your specific situation, this will go wrong.”

The one who reads every new idea as implicit criticism. If proposing a different architecture triggers defensiveness before curiosity, the person probably isn’t evaluating the proposal — they’re evaluating what that proposal says about their previous work. “The new approach is better” implies “the previous approach was worse,” which triggers protection mechanisms that have nothing to do with the technical analysis.

The one who needs the team to ask permission to explore. A healthy team can evaluate a new tool, run a proof of concept, and report results without needing the senior’s prior approval. When that permission becomes implicitly required, the cost of innovation goes up and the team starts self-censoring.

None of these involve bad intentions. But the result is the same: the team discards options before evaluating them.

Why healthy teams tolerate this pattern

Because questioning someone more senior carries social costs. The person who asks “why exactly won’t this work?” can seem disrespectful, presumptuous, or lacking in trust. So nobody asks.

This creates an information problem: the team acts as if the senior is right, even though nobody has verified whether they are. Experience, instead of being one input into the decision-making process, becomes the final veto.

In startups and growing companies, this can be especially costly. Conditions change fast. What worked five years ago may not be the right approach today, and what failed ten years ago might work now with different tools.

The nuance worth keeping

Not all resistance to new ideas is ego. Sometimes the veteran is right and the proposal really is bad. Sometimes what looks like stubbornness is the person seeing something you don’t yet.

The difference is whether the resistance comes with reasoning or without it. If someone can explain specifically what condition would make the proposal work or fail, you’re dealing with genuine judgment. If the answer is “trust me, I’ve seen this,” the only argument is authority, not analysis.

In healthy teams, this can be said out loud. In less healthy teams, questioning someone more senior carries social costs, so nobody does it, and the problem becomes invisible.

What happens when that person is you

The uncomfortable part: this happens to anyone with enough experience. It’s not a character flaw — it’s a fairly natural process. When you’ve invested a lot of time learning to do something a certain way, someone showing up with an alternative triggers something that feels like a threat, even when it isn’t.

A few questions worth asking yourself:

• Can you explain your objection in concrete terms, or are you saying “it won’t work” and expecting to be believed?
• When was the last time you changed your mind about something technical based on new information?
• Is there any condition under which you’d recognize that the proposal has merit?

If the answers are uncomfortable, it’s probably worth taking another look at the idea you just dismissed.

Experience doesn’t lose value because you can question it. The opposite, actually: the professionals who generate the most value are the ones who accumulated years of context and kept the ability to revisit it when it matters.

Frequently asked questions

How do you distinguish between reasoned objection and ego dressed as judgment?

The clearest signal is whether the objection comes with specific reasoning or not. “This won’t work because X condition in your company is different from the cases where this succeeded” is judgment. “This won’t work, I’ve seen it” is authority without analysis. If you ask for the specific conditions under which the approach would succeed or fail and they can’t give them, you’re dealing with authority, not judgment.

How do you build a team culture where people can push back without social cost?

By modeling the behavior from the top. If the senior on the team celebrates when someone challenges them with good reasons and changes their position when it makes sense, the team learns it’s safe to do that. If the senior gets defensive when challenged, the team learns the opposite. Culture isn’t declared, it’s practiced.

Does this apply to data architecture decisions specifically?

Especially to those. Architecture decisions have long-term effects and are difficult to reverse. A warehouse implemented five years ago might still be in use even when better alternatives exist, simply because changing it has friction and the team that built it feels that changing it implies it was wrong to begin with. The right architecture for a company today may not be the same as what was right for that company five years ago.

---

If you’re building data teams or making architecture decisions, schedule a call. An outside perspective often reveals what internal conviction can’t see.