Three years ago, a graduate engineer named Priya asked me why our payment reconciliation job ran every fifteen minutes. She had been with us for six weeks. The honest answer was that it had run every fifteen minutes since 2016, when a batch file from our old acquiring bank arrived on that cadence. The bank had switched to a real-time webhook two years earlier. Nobody had noticed. We were holding settlement data for up to fourteen minutes for no reason at all.
Her question cost nothing to answer and saved us an embarrassing amount of latency in the merchant dashboard. I have watched this pattern repeat for most of my career, and I have stopped treating it as a happy accident. The best ideas in my engineering org disproportionately come from the people who have been here the shortest. Not always. But often enough that I now build for it on purpose.
The Strange Value of Not Knowing How Things Work
There is a specific kind of blindness that comes with expertise. Once you understand why a system is the way it is, you stop seeing the way it is as a choice. It becomes weather. The senior engineer who built the reconciliation job knew exactly why it ran every fifteen minutes, and that knowledge is precisely what stopped him from questioning it. He had the context that made the design feel inevitable.
A junior engineer has no such context, and that is not a deficiency. It is a fresh pair of eyes attached to a brain that has not yet learned which questions are supposedly stupid. When Priya asked about the fifteen-minute job, she was not being clever. She genuinely did not know it was a question you were not supposed to ask. That is the whole point. The most valuable questions in any mature codebase are the ones everyone else has quietly agreed to stop asking.
I have come to think of institutional knowledge as a double-entry ledger. On one side it buys you speed and safety. On the other it accrues a debt of unexamined assumptions that compounds silently. Junior engineers are the only people who can see the balance without prejudice, because they have not signed the ledger yet.
The Questions Seniors Have Trained Themselves Not to Ask
If you sit in enough architecture reviews you notice the shape of the silence. A senior proposes a design. Everyone nods. The design has three questionable assumptions baked into it, and nobody raises them, because raising them would signal that you do not understand the constraints. Expertise, past a certain point, becomes a social contract about which topics are settled.
Junior engineers have not signed that contract. They ask the things that make experienced people wince and then, twenty minutes later, quietly concede the point. In my experience the highest-leverage questions tend to cluster:
- Why do we run this on a schedule instead of reacting to an event?
- Why does this data live in three places, and which one is actually correct?
- Why is this a manual step that a person does at 9am every day?
- What happens if this external call just never comes back?
- Why do we have a service for this at all, instead of a function?
Every one of those questions has surfaced a real problem for me at least once. The manual 9am step turned out to be a compliance control that a single analyst had performed for four years with no documented backup. When she went on maternity leave, we found the gap the hard way. A junior had flagged the risk months earlier and been told it was "just how we do onboarding checks." He was right and we were wrong, and I have not forgotten it.
What It Costs When You Ignore Them
The failure mode here is not that juniors have no good ideas. It is that the organization has no path for a good idea to travel from a junior mouth to a senior decision. The idea gets raised in a standup, meets a wall of context and mild condescension, and dies. The person learns the lesson quickly: keep your head down, ship your tickets, stop asking why.
That lesson is expensive. You are paying a full salary for a fresh perspective and then systematically training that perspective out of the person over their first six months. By the time they are senior enough that people listen, they have absorbed all the same assumptions and lost the very thing that made their early questions valuable. You spend two years turning an asset into a liability and then wonder why nobody challenges the architecture anymore.
The most dangerous phrase in an engineering org is not "we have always done it this way." It is a junior engineer who has learned to stop saying "but why do we do it this way?"
Onboarding Is a Diagnostic, Not Just a Cost
Most teams treat onboarding as pure overhead. You measure it in time-to-first-commit and try to shrink it. I have started treating the first month of every new hire as a free external audit of our own confusion. The things that confuse a competent new engineer are, almost without exception, the things that are genuinely confusing. The map is wrong, not the traveler.
So I ask new engineers to keep a running document during their first four weeks. Every time something does not make sense, every time they have to ask a colleague to explain a decision, every time the documentation lies to them, they write it down. No filtering, no politeness. At the end of the month we read it together. It is one of the most useful documents the team produces, and it costs almost nothing because they were going to hit those walls anyway. We just started writing down where the walls are.
One new hire's list noted that our API returned amounts in three different formats depending on the endpoint: minor units in one place, decimal strings in another, floats in a third. Everyone here more than a year had internalized which was which. To her it was obviously a bug waiting to round someone's money incorrectly. She was right. We standardized on integer minor units the next quarter.
You Have to Make It Safe to Be Wrong
None of this works if being wrong is punished. And most of a junior engineer's questions will be, strictly speaking, wrong. They will propose rewriting a service that exists for a regulatory reason they have not encountered yet. They will suggest caching data that legally must be fetched fresh. The ratio of naive questions to genuine insights is not flattering, and if you only reward the insights you will never hear enough questions to find them.
The move that changed things for me was learning to answer the naive question with the full reason rather than a dismissal. When someone asks why we do not cache a certain balance, "we can't, regulatory" is a conversation-ender that teaches them to stop asking. "We can't, because for this product class the regulator requires the displayed balance to reflect cleared funds within a defined window, and here's the actual rule" is a conversation that makes them smarter and keeps them asking. It takes ninety seconds longer. It is worth every second.
There is a self-interested angle too. Explaining the reason out loud is how I discover the reasons that are no longer true. Half the time I start answering "we do it this way because of X" and realize mid-sentence that X stopped being true eighteen months ago. The junior did not need to be right for the question to be valuable. They just needed to make me say the reason out loud.
The Expertise Trap and Sunk Cost
There is an uncomfortable driver underneath all of this. Senior engineers are emotionally invested in the systems they built. I built a fraud-scoring pipeline eight years ago that I was quietly proud of, and for years I defended its architecture with more energy than the architecture deserved. It was clever. It was also more complicated than the problem required by 2022, and it took a second-year engineer asking "couldn't this just be a lookup table for most cases?" to make me see it.
He was mostly right. About seventy percent of our fraud decisions did not need the pipeline at all; they needed a good rule set and a fast path. The expensive model was doing real work on the remaining thirty percent. My expertise had let me build the sophisticated version, and that same investment stopped me from noticing most traffic did not need it. Sophistication is a trap that catches skilled people specifically.
Juniors have no sunk cost. They did not build the thing, so they can ask whether it should exist. That neutrality is a feature you cannot buy from anyone with tenure, and it has a short shelf life. Use it before it expires.
How I Actually Harvest This Now
Good intentions do not survive contact with a sprint. If you want junior insight to reach decisions, you have to build a channel for it, because the default channels all filter it out. A few things that have worked concretely for me, none of them expensive:
The onboarding confusion log I mentioned is the highest return. Beyond that, I put the newest engineer on the team in the room for architecture reviews with an explicit job: their only responsibility is to ask why. Not to contribute to the design, not to prove they belong, just to interrogate the assumptions. It reframes the naive question as the assigned task rather than a risk to their reputation, and it gives the seniors permission to be interrogated without losing face.
I also stopped assigning brand-new engineers only to the safest corners of the codebase. The instinct is to protect the important systems from inexperience. But those systems are exactly where a fresh perspective pays off most, and where our assumptions are most calcified. Pair a junior with a senior on the scary service, and tell the junior their confusion is data. The senior explains, and half the time the act of explaining reveals the rot.
What This Is Not
I want to be precise, because this argument gets stretched into something silly. I am not saying junior engineers are secretly better than senior ones, or that experience is a liability, or that you should run your platform by polling the intern. That would be idiotic. When our settlement system throws an exception at 2am, I want the person with fifteen years of scar tissue on the call, not the person who joined in March. Experience is what keeps the money moving and the regulators calm.
The claim is narrower and more useful. Junior engineers are not a better source of solutions. They are a better source of questions, and questions are the scarce resource in a mature organization. The senior engineer's job is to have the judgment to know which question is worth chasing. It is a partnership, and the failure is treating it as a hierarchy where insight is only permitted to flow downward.
The Window Closes Faster Than You Think
Priya runs a good chunk of our payments platform now, and she is very good at it. I have noticed, with some sympathy, that she asks "why do we do it this way?" a little less often than she used to. The context has settled over her the way it settles over all of us. That is not a failing on her part; it is the natural cost of getting good at something. So my job, and yours if you lead engineers, is to keep hiring the next person who has not yet learned which questions are forbidden, and to actually listen when they open their mouth in the first month. The window is short. Do not waste it teaching them to be quiet.