Every team has one: the engineer who knows everything. Not the person who quietly knows a lot—the one who will tell you, at length, why your approach is wrong, why the current architecture is a disaster, and why they saw this coming three quarters ago. I call this person the Blocking Call. They insert themselves into every decision, hold the floor in every review, and turn a 15-minute standup into a hostage situation. If you’re a team lead, an engineering manager, or just a colleague trying to ship software without losing your mind, you need a strategy. Not a personality transplant—a systems-level fix.
This is not a post about firing anyone. It’s about debugging a team dynamic that quietly destroys throughput, morale, and code quality. The know-it-all engineer is a symptom of a broken feedback loop, not the root cause. Treat them like a legacy system: you don’t rewrite it on day one. You instrument it, find the failure modes, and patch the interfaces.
The Know-It-All as a System Failure
Let’s define the entity. The engineer who knows everything—call them the Omniscient Engineer—exhibits three consistent behaviors:
- Unsolicited architecture reviews in every pull request, even for a one-line CSS fix.
- Historical revisionism: “I told you this would happen” after every incident, regardless of whether they actually did.
- Conversation monopolization: their voice is 70% of every meeting, and their opinions arrive pre-packaged as facts.
Why does this happen? Not because they’re evil. Usually, it’s because the team has no explicit decision-making process. When there’s no clear owner for a technical choice, the loudest voice fills the vacuum. The Omniscient Engineer is a race condition: they win the lock on every discussion because nobody else bothers to compete. The result is a single-threaded team—one person’s brain becomes the bottleneck, and everyone else’s context switches to “waiting for the lecture to end.”
This matters because software teams are supposed to be concurrent systems. Multiple people should be able to make progress in parallel. When one engineer becomes a blocking call, the whole team’s event loop stalls. Deployment frequency drops. Code review latency spikes. People stop proposing ideas because they know they’ll get a 40-minute rebuttal. That’s not a personality problem; that’s a throughput problem.
Signals You’re Dealing with a Blocking Call
You don’t need a psychology degree to spot this. Look at your operational signals:
1. Code review latency is bimodal
Most reviews get approved in under an hour. But any PR that touches a certain module—or any PR from a certain engineer—sits for three days. The Omniscient Engineer is the reviewer. They’re not busy; they’re composing a treatise. Every comment is a lecture, every suggestion is a rewrite, and the author eventually gives up and implements whatever was demanded just to unblock the merge.
2. Incident postmortems turn into blame archaeology
After an outage, the team should be asking “what failed and how do we prevent it?” Instead, the Omniscient Engineer spends 20 minutes explaining how they predicted this exact failure in a design doc from 2019. The postmortem becomes a performance review of everyone else’s foresight. Action items get buried under a pile of “I already knew that.”
3. Documentation is stale, but the engineer’s memory is not
The Omniscient Engineer rarely writes things down. Why would they? They’re the living documentation. When a new hire asks how the billing service works, the answer is “go ask Dave.” Dave will then spend 45 minutes explaining the entire history of the billing service, including the three times he saved it from collapse. The wiki stays empty. The bus factor stays at one. And Dave feels indispensable—because he is, and that’s the problem.
Why “Just Talk to Them” Doesn’t Work
Managers love the direct approach: “Have a candid conversation. Give feedback. Set expectations.” Here’s what actually happens. You sit down with the Omniscient Engineer and say, “Hey, I’ve noticed you dominate technical discussions. It’s making it hard for others to contribute.” They respond with a 20-minute explanation of why their contributions are necessary, how the team would have shipped three broken features without their intervention, and how they’re just trying to maintain quality standards. You leave the meeting feeling like you’re the problem. They leave the meeting feeling vindicated.
Why? Because the Omniscient Engineer is not wrong about everything. They often do have valuable knowledge. The issue is the signal-to-noise ratio. For every useful insight, there are nine unsolicited opinions, three historical digressions, and one passive-aggressive comment about the current codebase. Direct feedback fails because it targets the person, not the system. The person has a defense mechanism: their expertise. The system has a flaw: no mechanism to separate signal from noise.
The Systems Fix: Three Interventions
You can’t change the engineer’s personality. You can change the interfaces they interact with. Here are three interventions that work, in order of increasing invasiveness.
Intervention 1: Time-boxed technical discussions
Introduce a rule: any architectural debate that lasts more than 15 minutes gets moved to a written design doc. The doc has a template: problem statement, proposed solution, alternatives considered, tradeoffs, and a decision deadline. The Omniscient Engineer can write as much as they want—in the doc. But the meeting ends on time. This does two things. First, it forces the engineer to structure their arguments instead of free-associating. Second, it creates a written record that others can respond to asynchronously. The loudest voice becomes just another comment thread.
I’ve seen this work on teams where the Omniscient Engineer was also the most productive coder. They initially resisted—”I don’t have time to write docs”—but once they realized the doc was the only way to get their opinion heard, they adapted. The key is enforcement. If you let the 15-minute rule slide once, it’s dead.
Intervention 2: Explicit decision ownership
Every technical decision needs a named owner. Not a committee, not a consensus—a single person who makes the call after gathering input. The owner is responsible for writing a one-paragraph decision record: what was decided, why, and what alternatives were rejected. The Omniscient Engineer can provide input, but they don’t get a veto. If they disagree, they can write a dissenting comment in the decision record. That’s it.
This works because it removes the ambiguity that the Omniscient Engineer exploits. When there’s no clear owner, every discussion is a free-for-all, and the loudest voice wins. When there’s an owner, the discussion has a deadline and a decision-maker. The Omniscient Engineer’s opinion becomes one input among many, not the final word. I’ve used this on teams where the know-it-all was also the most senior engineer. It didn’t silence them—it just made their input proportional to their actual authority.
Intervention 3: The “No Unsolicited Advice” rule
This is the nuclear option, but sometimes it’s necessary. The rule: no one may give technical feedback on a pull request or design unless the author explicitly asks for it. The author can ask for specific types of feedback: “Please review the error handling in the payment retry logic” or “I’m not sure about the database schema—thoughts?” But general comments like “Why didn’t you use a message queue?” are off-limits unless requested.
This feels draconian, but it works because it flips the default. The Omniscient Engineer’s power comes from unsolicited intervention. When they have to wait for an invitation, their influence drops dramatically. They can still share their knowledge—but only when it’s wanted. I’ve seen this rule transform a team where code reviews had become a gauntlet of unsolicited architecture lectures. Within two weeks, review latency dropped from days to hours. The Omniscient Engineer was initially furious, then confused, then—surprisingly—relieved. They didn’t have to police everyone’s code anymore.
What Not to Do
Some common responses make the problem worse:
- Public shaming: Calling out the engineer in a team meeting. This creates a martyr, not a change.
- Isolation: Moving the engineer to a solo project. Now you’ve lost their knowledge and created a silo.
- Promotion: Making them a tech lead or architect. This legitimizes the behavior and gives them a bigger microphone.
- Ignoring it: Hoping they’ll mellow out. They won’t. The team will just learn to route around them, which creates shadow decision-making and even more confusion.
The Long Game: Turning the Omniscient Engineer into a Force Multiplier
Here’s the uncomfortable truth: the Omniscient Engineer often has valuable knowledge. The goal is not to silence them—it’s to convert their monologue into a library. The interventions above do that. Time-boxed discussions force them to write. Decision ownership forces them to respect boundaries. The no-unsolicited-advice rule forces them to wait for an invitation. Over time, the engineer who once dominated every meeting can become the team’s most reliable source of written technical context.
I’ve seen this transformation happen exactly once. It took six months, two awkward conversations, and one incident where the engineer’s unsolicited advice would have actually prevented an outage—but they held their tongue because of the rule. The team shipped a bug, the engineer was vindicated, and the rule was almost repealed. But the manager held firm. The next time, the engineer wrote a design doc instead of interrupting a meeting. The team read it. The bug was avoided. The engineer got the credit they craved, but through a channel that didn’t block anyone else.
That’s the end state: the Omniscient Engineer becomes a cached expert. Their knowledge is available on demand, but it doesn’t block the main thread. The team’s throughput recovers. Code review latency drops. Incident postmortems focus on systems, not personalities. And the engineer who knew everything finally learns the one thing they didn’t: how to share knowledge without holding the team hostage.
FAQ: Handling the Engineer Who Knows Everything
What if the know-it-all engineer is also the most productive person on the team?
This is the hardest case. You can’t afford to lose their output, but you also can’t afford the bottleneck they create. The solution is to separate their individual contribution from their team influence. Let them keep writing code—lots of it. But apply the interventions to their interactions: time-boxed discussions, decision ownership, and no unsolicited advice. Their productivity doesn’t give them a license to block others. If they threaten to leave, let them. A team that depends on one person’s goodwill is already broken.
How do I know if I’m the know-it-all engineer?
Ask yourself three questions. Do you speak more than 50% of the time in most meetings? Do you leave more than three comments on an average pull request? Do you find yourself saying “I told you so” more than once a month? If you answered yes to two or more, you might be the Blocking Call. The fix is simple: write more, talk less. Put your opinions in design docs. Wait for people to ask for your input. You’ll be surprised how much more weight your words carry when they’re not competing with your own voice.
What if the entire team has accepted the know-it-all’s behavior as normal?
This is a cultural problem, not an individual one. The team has normalized the bottleneck. The fix is to make the cost visible. Start tracking code review latency, meeting time, and decision turnaround. Show the team the data: “Our average PR sits for 2.3 days. Our standups run 40 minutes. Our postmortems produce zero action items.” Then propose the interventions as experiments, not punishments. “Let’s try time-boxed discussions for two weeks and see if review latency drops.” When the data improves, the culture shifts. The know-it-all doesn’t have to change their personality—the team just stops rewarding the behavior.
Can a know-it-all engineer ever become a good tech lead?
Yes, but only if they learn to delegate decisions and document their knowledge. The best tech leads are force multipliers, not bottlenecks. If the engineer can shift from “I’ll make the call” to “I’ll write the decision record and let the owner make the call,” they’re ready. If they can’t, they’ll be a disaster as a lead—a single point of failure with a title. Watch how they handle the interventions above. If they adapt, promote them. If they resist, keep them as an individual contributor and protect the team from their influence.
Next on the Debug Log
This is part of a series on team dynamics as systems failures. Next up: “The Silent Engineer Who Knows Everything but Won’t Say a Word”—the inverse problem, and why it’s just as dangerous. Subscribe to the blog or check back next week. And if you’ve got a war story about a know-it-all engineer, drop it in the comments. I read them all, even the ones that tell me I’m wrong.
