Early at Capital One, I was in an architecture review with a group of engineers working through an architecture problem that had been giving us fits for a few weeks. The room had a “white beard” engineer, a couple of senior engineers, and a couple of newer folks who were, I think, somewhere in their second or third year. The white beard had been at Capital One since before the junior engineers in the room had learned to walk. White beard started his career on mainframes, had personally vetted half the vendors Capital One still employed, and when he spoke — softly, slowly and deliberately, like someone who had learned there was no upside in rushing — everyone including SVPs listened carefully and took notes. The white beard had proposed an approach. It was technically sound and everyone more or less accepted it, and we were moving into the implementation details when one of the junior engineers — she had been quiet for most of the meeting — said something like “I might be missing something, but could we also just…” and then described an approach that was significantly simpler, would have taken about a third of the time to implement, and had better failure characteristics than the solution we were all about to commit to.
She almost didn’t say it. I watched her start to raise her hand meekly and then pull back, and then after a few seconds she spoke anyway. Later, when I talked to her about it, she told me she’d almost kept it to herself because she figured if it were that obvious, someone smarter would have already mentioned it.
That stayed with me for a long time.
The thing I’ve come to believe is that seniority creates a kind of acoustic dampening in technical discussions. The more experienced voices fill the room first and loudest, and there’s enormous social cost to being visibly wrong in front of a white beard — or, more precisely, the perceived cost is enormous, whether or not the actual cost is. Junior engineers in those rooms are performing a real-time calculation: if I say this thing and I’m wrong, what does that do to how I’m seen? And the answer, in most engineering cultures, is “something not good.” So they wait. They stay quiet unless they’re very confident. They let the senior engineers converge on a solution, and sometimes that solution is fine and sometimes it’s the second-best answer to the problem.
The structural issue is that the people with the most to gain from being right — the junior engineers still building their reputations, for whom a good idea in front of the room is real career currency — are also the people who perceive the highest risk from being wrong. And the people who can most afford to be wrong — senior engineers who’ve already established credibility — are the ones whose voices fill the room first and carry the most weight. That asymmetry reliably suppresses exactly the kind of fresh-perspective thinking that produces the best technical outcomes.
What I changed after that Capital One experience: I started separating idea generation from idea evaluation in technical discussions. Before a design or scoping session, I’d ask everyone — including the most junior person in the room — to write down at least one approach to the problem we were discussing, asynchronously, before the meeting. Then we’d spend the first part of the meeting reading those through together, without identifying whose idea was whose, and evaluating them on the merits. Not permanently anonymous — people would own their ideas once they were on the table — but the initial reaction happened before the room knew the source, which stripped away a lot of the status signaling that normally shapes which ideas get serious attention.
It’s not a perfect system. Nothing is. But what I noticed is that when an idea had already gotten positive reactions from the room before people knew it came from the junior engineer, it was much harder for the white beard to dismiss it without engaging with the actual substance. The idea had already cleared the first filter.
Amazon has a version of this baked into its meeting culture. After the silent reading period that opens most working sessions, it’s the most junior person in the room who speaks first. The most senior person — VP, SVP, whoever — goes last. It’s not a suggestion. It’s just how it’s done. And the effect is exactly what you’d expect: by the time the senior voice weighs in, there are already three or four perspectives on the table that couldn’t have been anchored or pre-filtered by it. The senior person is reacting to ideas, not setting the frame that everyone else has to respond within.
I didn’t fully appreciate how load-bearing that convention was until I saw what happens in rooms without it.
The junior engineer from that Capital One session went on to become one of the stronger senior engineers I worked with. I’ve thought about that a lot. Not because I discovered her — she would have found her way regardless. But I keep coming back to the calculation she was running when she almost didn’t speak. She looked around that room, weighed the risk, and said it anyway. I got lucky. Most of the time, the room doesn’t.
Think about the last brainstorming session you ran. Who spoke first? Who spoke last? Who didn’t speak at all? Those three questions will tell you more about your engineering culture than any engagement survey.