On the difference between being right and being useful
There was an engineer on a team I joined early in my career who knew everything. Or at least, he performed that role with great dedication.
You would not finish your sentence before he had a solution. You would open a pull request and find twelve comments before you had even poured your morning coffee. Any architectural discussion became a monologue with a brief question-and-answer section at the end, where the answers were his regardless of who had asked.
He was not wrong often. That was the strange part. His solutions were usually sound. His code was clean. His instincts about performance problems were sharp. By every measurable standard he was excellent.
But the team was quietly miserable.
The Meeting That Changed How I Think
About two years into leading my first team, I had become that engineer.
I did not see it happening. You never do. It feels like helpfulness from the inside. You know the answer, the discussion is going in circles and you have deadlines. Offering the solution feels like the responsible thing.
Then one morning I walked into a sprint planning session and noticed something. When I spoke, people stopped taking notes. They stopped offering alternatives. They nodded, typed something brief and waited for me to continue. The room was not thinking together. It was listening to one person think out loud.
A junior engineer on the team had a proposal for how we should handle background job retries. She had clearly thought about it. She had brought a short doc. I interrupted her three sentences in to explain why we should use a different approach. Looking back now, my approach was not obviously better. It was just the first one that came to my mind, and I had the authority to make it land without challenge.
She did not say much for the rest of that meeting. She said less and less in the meetings that followed.
That cost us something I cannot put a number on.
What Engineers Confuse About Confidence
Technical confidence is a useful thing. The ability to move quickly through a problem space, to recognise patterns, to reach a decision without needing three committees and a spreadsheet, these are genuine skills and teams need people who have them.
But there is a version of technical confidence that has nothing to do with ability. It is the performance of certainty. It is speaking before thinking because the silence makes you anxious. It is treating your first instinct as your considered judgment. It is confusing speed of response with quality of response.
The engineer who always has an answer is often doing something different from solving the problem. They are managing their own discomfort with ambiguity. The room is uncertain, the problem is unresolved and the quickest way to feel in control of that situation is to produce a solution. Any solution. Quickly.
This works in the short term. It feels like leadership. It sounds like expertise. It produces action.
What it does not produce is the best outcome, or a team that grows, or a culture where people bring their real thinking to the table instead of the thinking they expect you to accept.
The Cost of Speaking When You Should Listen
I have watched this pattern play out enough times to catalogue what it takes from a team.
The first thing it takes is alternatives. The moment someone with authority proposes a solution, the search for other solutions largely stops. People tend to build on the proposal rather than challenge it, not because the proposal is necessarily correct but because disagreement carries social risk. You might be wrong. You might offend. It is easier to find reasons the first idea works than to argue for a different one from scratch.
The second thing it takes is the growth of the people around you. A junior engineer who never gets to work through a problem in front of the team, who always receives the answer before finishing the question, is not learning to think. They are learning to wait. Their problem-solving muscle does not develop because it never has to carry weight.
The third thing it takes is information. The person with the most authority in a room rarely has the most complete picture of any given problem. The engineer who actually builds the feature knows the edge cases. The one who debugs production knows where things break in ways that never appear in architecture diagrams. The product manager has context about the customer’s actual behaviour that none of the engineers have read. When one person dominates the conversation, this information sits unspoken. It does not make it into the decision.
What “I Don’t Know” Actually Signals
I have been in rooms where a senior engineer says “I don’t know” and watches the room immediately become more engaged. Something relaxes. Other people start thinking out loud. The quality of the conversation rises.
This surprises people the first time they see it, but it makes complete sense. When the most senior person admits uncertainty, it signals that the problem is genuinely open. That signals that other contributions have a real chance of changing the outcome. That makes contribution worthwhile.
“I don’t know” from someone with authority is not a confession of weakness. It is an invitation. It says: this space is not already claimed. Bring what you have.
The engineers who have stayed with me longest, whose opinions I seek out when a decision actually matters, are almost always the ones who speak with care. They do not rush to fill silence. They ask questions before they offer answers. When they do speak, it lands differently because you can tell they have actually thought about it rather than reached for the nearest solution.
The Three Kinds of Silence in a Room
Not all silence means the same thing and learning to read the difference changed how I facilitate discussions.
Processing silence
Someone is thinking. The idea is still forming. If you fill this silence with your own voice, you interrupt a thought that might have been valuable. Wait.
Reluctant silence
Someone has something to say but is calculating the risk of saying it. Maybe they are junior. Maybe they tried to contribute earlier and were interrupted. Maybe they just need one more beat of permission. A direct question to that person, a simple “what do you think about this part?”, often breaks this open.
Empty silence
Everyone has said what they have to say. The discussion has reached its natural end and the room is waiting for a decision. This is the silence you should fill. Quickly, clearly and without reopening everything that was already resolved.
The engineer who always has an answer treats all three as the same. They fill them all. They rob the first, dismiss the second and often confuse the third with the first two.
How I Changed
I started by making one rule for myself in meetings: I do not speak in the first ten minutes unless I am asked a direct question.
This was harder than it sounds. The instinct to contribute, to demonstrate value, to move things forward, is strong and it does not feel like ego in the moment. But sitting with that instinct and letting other people go first changed what I heard. I started noticing things I had been overriding.
The second change was asking questions before offering solutions. Not leading questions that telegraph the answer I already had. Real questions, the kind where I genuinely did not know what the other person would say. “What is the part of this problem that bothers you most?” produces different information than “Have you considered approach X?”
The third change was being public about uncertainty. When I said “I’m not sure about this yet,” I watched how the room responded. It made space. The discussion moved differently. More people contributed. Some of those contributions were things I had not thought of, and a few of them were better than what I had planned to say.
None of this made me less effective. If anything, the quality of the decisions coming out of those rooms improved because they incorporated more thinking from more people.
The Engineer Worth Listening To
The engineers I most want in a room when a real problem needs solving are not the ones who answer fastest. They are the ones whose answers land with weight because you can feel the thought behind them.
They ask before they answer. They change their minds when the information changes. They name what they do not know. They create space for the people around them to think instead of consuming that space themselves.
They are comfortable being uncertain in public. And because they are comfortable with it, the people around them become comfortable with it too. That changes what a team is willing to bring to a problem.
The engineer who always has an answer is impressive in a room of strangers. The engineer who knows when to ask is irreplaceable in a room of people trying to build something real.
The smartest person in the room is often the one who talks the least.
You probably already know who that is on your team.
One Last Thing
There is a specific moment I have noticed in retrospect that usually signals I am about to say something I should hold back. It is the feeling of mild impatience, a slight urgency to move things forward, a sense that the discussion is taking longer than it needs to.
That feeling is real data. It means something is unresolved and the discomfort of that ambiguity is pushing me toward action. The action it pushes me toward is speech, usually premature speech dressed up as leadership.
When I feel that now, I pause. Sometimes just for five seconds. Sometimes for the rest of the meeting. I ask myself: whose thinking would benefit from space right now? Usually the answer is not mine.
The engineers who shaped how I think about this are not the ones who impressed me with what they knew. They are the ones who asked me a question I had not thought to ask myself and waited, genuinely, for my answer. Not to confirm their own view, but because they actually wanted to hear mine.
That is the standard I try to hold myself to. I do not always reach it. But I know now what it looks like when someone else does, and I know the effect it has on the people around them.
It is one of the most underrated things you can practice as an engineer. And unlike most skills in this field, it does not require a computer.