The First Opinion Always Wins

I don't remember where I first read the advice. It was years ago now, and I've long since lost track of who wrote it. But one sentence changed how I run technical discussions:

let the least experienced person speak first.

At the time it felt backwards. Surely the senior engineer should go first, since they know the system better and they've solved this exact problem before. For a long time I believed that too, until I started noticing what actually happens in architecture discussions and code reviews.

The Room Adapts, It Doesn't Agree

The first opinion almost always becomes the opinion. Not because everyone agrees with it, but because everyone quietly adapts to it. And it doesn't even have to happen in the room you're sitting in. Sometimes the first opinion was formed years before you joined, and you inherit it without ever seeing it questioned.

Someone experienced says, "we should split this into services, so teams can own their own piece." Nobody consciously stops thinking. But the conversation shifts anyway. It's no longer about whether the split makes sense, it's about how to draw the lines. The assumption became a fact, and almost nobody noticed the moment it happened.

Fifteen Repos, Three Teams

I joined an energy infrastructure team well after that exact decision had already been made, and taken further than anyone probably intended. Someone senior, years before my time, had decided early on to split the system into services along what looked, on a slide, like clean domain boundaries: metering, billing, contracts, tariffs, notifications, and so on. By the time I arrived, that idea had grown into fifteen repositories. In practice, the boundaries had never actually matched how the domain worked. A single change to how a tariff was calculated routinely touched four or five of them, in a fixed order, because the "services" weren't really independent. They were one system that had been cut apart along lines that made sense on paper and nowhere else.

I noticed the smell early and mentioned it during planning, the kind of conversation where technical debt gets weighed against feature work, with leadership in the room alongside the team. It came up as one item among many competing priorities, acknowledged but not urgent enough to greenlight yet. In the weeks after, I kept mapping the actual dependencies between the repos on my own time, sketching what a consolidated structure could look like, so that if the opportunity ever came to make the case properly, I wouldn't be starting from zero.

A few weeks later, a developer who'd just joined the team, a woman who had never heard me raise the concern anywhere, asked almost the exact question in a retro: why did adding one field to an invoice require six pull requests, three deploys in a specific order, and a shared Slack thread to coordinate all of it?

My first instinct was to jump in. I'd been sitting on nearly the same answer for weeks, and it would have taken ten seconds to say so. I held off instead, and let her keep talking. She walked the team through her own reasoning: which repos she'd had to touch, what broke when she got the deploy order wrong, why it felt like one system pretending to be five. Nobody had primed her to see it that way. She'd simply hit the friction directly and drawn her own conclusion.

If I'd spoken first, the retro would have become a discussion about whether I was right, a familiar problem, agreed to for familiar reasons, closed within a minute. Because she said it first, in her own words, backed by her own examples, it landed differently: not as the boss's old complaint getting confirmed, but as something the team arrived at together. That was enough to turn it from a line item in a planning doc into an actual initiative, and because I already had the dependency mapping done, we could move straight to proposing the consolidated structure instead of starting the investigation from scratch. We spent the better part of a year merging fifteen repos down to five that matched how the three actual teams worked. Nobody missed the other ten.

Inherited Decisions Deserve the Same Scrutiny

That's the quiet cost of experience, and not just yours. It's the experience baked into decisions you inherit. A rationale attached to a decision can outlive the conditions that justified it, and once it's inherited rather than made, it's even easier to leave unexamined, because questioning it can feel like questioning the people who came before you rather than the decision itself. Someone with less history on the team hasn't inherited that reluctance. They don't know which questions they're "supposed" not to ask, and that's exactly why they sometimes see what everyone else missed.

A Sharper Version of the Same Effect

It's a bit sharper in my current role, where I'm often the one with the final technical say. My word can genuinely end a discussion, not just steer it. But that's really just a stronger dose of the same effect: whoever's opinion lands first, whether in a meeting or baked into a decision from years ago, has an outsized chance of becoming the permanent answer. The size of the effect changes. The mechanism doesn't.

AI Has the Same Blind Spot

AI has made me think about this differently, too. Ask an AI to help design a system and it rarely questions the premise. "How should I split this into services?" It will happily help you split it into services. It almost never asks whether the boundaries actually match how the domain works, or whether it should be split at all. A curious junior developer often does. Not because she knows more. Because she knows less, and sometimes less is exactly what the conversation needs.

Knowing When to Spend It

None of this means experience doesn't matter. It's one of the most valuable things a team has. The trick is knowing when to spend it, and knowing that inherited decisions deserve the same scrutiny as new ones.

Sometimes the best contribution the most experienced person in the room can make isn't the first answer. It's the silence that lets someone else give theirs first.

I've started doing this on purpose. When we're discussing a new feature or a direction, I wait. I ask questions before I offer opinions, not because I don't have one, but because I know how much weight it carries once I say it out loud. More often than I'd like to admit, someone junior sees something I completely missed, or something I'd simply stopped seeing, because it had been there longer than I had.

The best teams I've worked with weren't the ones where the smartest person always had the answer. They were the ones where everyone felt safe asking the question nobody else was asking. Often it came from the most experienced person in the room. Just as often, it came from the newest one, as long as someone made sure they got to speak before the room quietly decided the answer without them.