When You and Your Senior Engineer Disagree: How to Lead Without Pretending You're Always Right
The Moment Your Authority Meets Their Expertise
It's Tuesday afternoon, and you're in a design meeting discussing the approach for the upcoming data center network refresh.
You propose using a spine-leaf architecture with VXLAN overlay. It's modern, scalable, and aligns with where the industry is heading.
Your senior engineer - the one with 15 years of network architecture experience - speaks up:
"I don't think that's the right approach for our environment. Here's why..."
He lays out technical concerns. Valid ones. Points you hadn't fully considered. Alternative approaches that might work better for your specific constraints.
Now what?
Do you defer to his expertise? You're the manager, but he clearly knows more about this specific technology.
Do you stick with your decision? You're supposed to be the leader. Backing down makes you look weak.
Do you argue technical details? You might be wrong. That would be embarrassing.
Welcome to one of the hardest aspects of technical management:
Leading people who know more than you do in specific areas. Making decisions when your expertise is questioned and maintaining authority without pretending to be the smartest person in the room.
Six months into management, I'm navigating this constantly. Let me share what I'm learning about handling disagreements with senior engineers without destroying relationships or credibility.
Why This Is So Uncomfortable
Let me be honest about why these situations make me uncomfortable:
The Imposter Syndrome Trigger
What I'm Thinking:
"He's right, isn't he? He knows more about this than I do. Maybe I shouldn't be making this decision. Maybe I'm not qualified to be in this role. Everyone's going to realize I don't know what I'm doing."
The Fear:
That my lack of expertise in this specific area will be exposed. That people will question whether I should be managing this team. That I'm a fraud who got promoted beyond my competence.
The Reality:
Every technical manager managing specialists feels this. You can't be the deepest expert in every technology your team works with. That's not the job.
The Authority Question
What I'm Wondering:
"If I defer to his judgment, does that undermine my authority? Will people think I'm not really leading if I'm always agreeing with my senior engineers?"
The Flip Side:
"If I overrule him when he clearly knows more, does that make me the stereotypical bad manager who ignores expert input?"
The Tension:
You need to maintain authority and make decisions. But you also need to use your team's expertise. Finding the balance is hard.
The Relationship Dynamic
What I'm Worried About:
Disagreeing with senior team members damages the relationship. They'll resent me. They'll stop offering input. They'll think I don't value their expertise.
The Other Worry:
Always agreeing with them makes me look like I have no opinions or spine. They'll lose respect for me as a leader.
The Reality:
How you handle disagreement defines the relationship more than whether you agree or disagree.
The Stakes Feel High
What's at Risk:
Making the wrong technical decision could mean:
Project failure
Outages
Wasted budget
Team frustration
Damaged credibility
The Pressure:
You're responsible for outcomes. If you make the wrong call, it's on you. Even if you deferred to someone else's expertise.
The pressure of being responsible for decisions when you're not always the expert is something I explored in 5 Things I Wish I Knew Before Becoming a Manager - leadership means owning outcomes, not knowing everything.
Types of Disagreements (And How to Handle Each)
Not all disagreements are the same. The approach depends on what you're actually disagreeing about:
Type 1: They're Right and You're Wrong
The Situation:
You proposed something based on incomplete information or assumptions. Your senior engineer points out flaws in your reasoning or factors you didn't consider.
Example:
You: "Let's implement this routing protocol change across all sites simultaneously to save time."
Senior Engineer: "That approach creates too much risk. If there's an issue, all sites go down at once. We should pilot it at one site, validate, then roll out in phases."
Your Realization:
They're right. You were thinking about efficiency, but not risk management. Their approach is objectively better.
What To Do:
Acknowledge it immediately:
"You're right. I wasn't thinking about the blast radius. Phased rollout makes way more sense. Good catch."
Why This Works:
Shows you're open to input and not defensive
Demonstrates good judgment (recognizing good ideas)
Builds trust that you'll listen to technical expertise
Models the culture you want (changing your mind based on new information is a strength, not a weakness)
What NOT To Do:
Pretend you were "just testing them."
Get defensive about your initial suggestion
Agree but in a way that diminishes their input ("Well, obviously we'd do it that way")
Hold a grudge about being corrected
The Lesson:
Being wrong and admitting it quickly builds credibility. Pretending you're never wrong destroys it.
Type 2: They're Probably Right, But You Need To Understand Why
The Situation:
Your senior engineer disagrees with your approach, and their reasoning is solid, but you don't fully understand the technical details of why their alternative is better.
Example:
You: "Let's use BGP for this application."
Senior Engineer: "OSPF would be better for our use case. BGP adds complexity we don't need, and given our topology, OSPF convergence will be faster."
Your Position:
You know BGP and OSPF are both routing protocols. You understand the high-level differences. But you don't have deep expertise in the nuances of convergence behavior in different topologies.
What To Do:
Ask questions:
"Walk me through your thinking. Why would OSPF convergence be faster in our topology? What complexity does BGP add that we'd be avoiding?"
Not because you're testing them. Because you genuinely want to understand.
Why This Works:
You're learning (getting better at your job)
You're demonstrating that decisions should be based on reasoning, not authority
They feel valued for their expertise
You're making a better-informed decision
Then:
"Based on what you're explaining, OSPF makes more sense for this use case. Let's go with that approach. Can you document the reasoning so the whole team understands the decision?"
What NOT To Do:
Pretend you understand when you don't
Defer without understanding ("You know more, so we'll do it your way")
Feel embarrassed about asking technical questions
The Lesson:
Asking questions demonstrates leadership, not ignorance. You're making informed decisions, not just deferring to whoever speaks with confidence.
Type 3: You Disagree on Technical Approach (Both Valid)
The Situation:
You and your senior engineer have different technical approaches. Both have merit. Both have trade-offs. Neither is objectively "right."
Example:
You: "We should build redundancy at the network layer."
Senior Engineer: "We should build redundancy at the application layer instead. More flexible and cheaper."
The Reality:
Both approaches address the reliability requirement. They have different trade-offs in cost, complexity, and flexibility.
What To Do:
Acknowledge the validity:
"Both approaches work. Let's talk through the trade-offs."
Then discuss:
Cost implications
Complexity and maintenance
Flexibility for future needs
Team expertise and preference
Timeline and resources
Make a decision based on priorities:
"Given our budget constraints and timeline, I think we should go with application-layer redundancy for now. We can revisit network-layer redundancy if requirements change. Does that reasoning make sense?"
Why This Works:
You're not claiming one approach is technically superior
You're making a decision based on context and priorities
They understand the reasoning even if they disagree
You're using judgment, not just technical knowledge
What NOT To Do:
Claim your approach is technically better when it's really just a preference
Make it about authority ("We're doing it my way because I said so")
Ignore their concerns without addressing them
The Lesson:
Leadership is about making decisions based on context, priorities, and constraints - not just technical optimization.
Type 4: You Have Context They Don't Have
The Situation:
Your senior engineer's recommendation is technically sound, but the organizational, political, or strategic context changes the calculus.
Example:
Senior Engineer: "We should replace all this equipment with vendor X. Better specs, lower cost."
You: "I agree vendor X is technically better. However, leadership has a strategic relationship with vendor Y, and we're getting significant discounts across the organization by consolidating with them. The total cost of ownership favors vendor Y when you include that context."
What To Do:
Share the context:
"Your technical assessment is right. Let me share some organizational context that affects this decision..."
Explain the constraint:
Not as "leadership is forcing this," but as "here's the broader picture that influences the decision."
Acknowledge the trade-off:
"You're right that we're giving up some technical advantages. The trade-off is lower total cost and organizational alignment. Given priorities, I think that's the right call."
Why This Works:
They understand there's reasoning beyond the technical comparison
You're not hiding behind "management decision."
They see you're considering multiple factors
You're being transparent about trade-offs
What NOT To Do:
Keep context hidden and just override their recommendation
Make it seem like their technical analysis doesn't matter
Act like the organizational constraint is your preference
The Lesson:
As a manager, you have context that individual contributors don't have. Share it when it affects decisions.
Type 5: You Think They're Wrong
The Situation:
Your senior engineer recommends something you genuinely think is the wrong approach. Not just different - wrong.
Example:
Senior Engineer: "We don't need monitoring on these secondary circuits. They're just backup."
You: "I disagree. We need monitoring on all circuits so we know when backup fails, and we've lost redundancy."
This Is Hard:
They're the expert. But you think they're wrong. How do you handle this without either: a) Being dismissive of their expertise b) Implementing something you think is wrong
What To Do:
State your concern clearly:
"I have a different view on this. Here's my concern: if we don't monitor backup circuits, we won't know when they fail. We could be running without redundancy and not realize it until the primary also fails."
Ask them to address your concern:
"What am I missing? Why isn't that a concern worth monitoring for?"
Then:
Either they'll explain something that changes your mind, or they won't have a good answer.
If they don't have a good answer:
"I'm still concerned about that scenario. Let's implement monitoring on the backup circuits. The cost is low and the risk of not knowing about failures seems significant."
Why This Works:
You allowed them to explain
You stated your reasoning
You made a decision based on judgment
You didn't claim to know better - you weighed the risks differently
What NOT To Do:
Pull rank ("I'm the manager, we're doing it my way")
Dismiss their expertise
Implement your approach without explaining your reasoning
The Lesson:
Sometimes you have to overrule expert recommendations. Do it with reasoning and respect, not authority.
Making decisions with incomplete certainty is part of management, something I explored in When Your Team Is Right and Leadership Is Wrong - you won't always have perfect information.
The Conversation Framework That Works
Here's the structure I'm using when disagreements come up:
Step 1: Listen Fully First
Don't interrupt. Don't start formulating your counter-argument while they're talking. Actually listen.
"Walk me through your thinking. What are you seeing that I'm not?"
Why This Matters:
Half the time, they'll say something that changes your perspective. If you're already arguing in your head, you'll miss it.
Step 2: Acknowledge What's Valid
Even if you disagree overall, find what's valid in their position:
"You're right that [valid point]. That's a real concern."
Why This Matters:
Shows you're listening and thinking, not just waiting to argue. Makes them more receptive to your perspective.
Step 3: Share Your Perspective
Not as "here's why you're wrong," but as "here's what I'm thinking:"
"Here's where I'm coming from: [your reasoning]."
Why This Matters:
You're sharing reasoning, not asserting authority. Invites discussion rather than debate.
Step 4: Identify the Core Disagreement
Often, you're not disagreeing about what you think:
"It sounds like we agree on [X and Y], but we're weighing [trade-off] differently. Is that fair?"
Why This Matters:
Clarifies where the actual disagreement is. Often, it's not technical facts but priorities or risk tolerance.
Step 5: Make a Decision or Gather More Data
Then either:
"Based on this discussion, I think we should [decision]. Here's my reasoning: [explain]."
Or:
"I don't think either of us has enough information. Let's [research/test/consult] before deciding."
Why This Matters:
You're not endlessly debating. You're either deciding based on available information or determining what information you need.
Step 6: Document the Decision
Especially for significant decisions:
"Let me document this decision and the reasoning so we can reference it later and others understand why we went this direction."
Why This Matters:
Creates accountability and learning. If the decision was wrong, you can learn why. If it was right, you remember the reasoning.
When To Override Their Recommendation (And How)
Sometimes you genuinely need to make a decision they disagree with. Here's how to do it without destroying the relationship:
The Framework for Overriding
Only override when:
You have context that they don't have that changes the decision
The risk of their approach is unacceptable to you
Their recommendation conflicts with the broader strategy or constraints
You've genuinely evaluated their position and still disagree
Don't override because:
You want to assert authority
You're uncomfortable being wrong
You don't want to look like you're just deferring to them
Your ego is involved
How To Communicate the Override
Bad:
"I hear you, but we're doing it my way."
"I'm the manager, so I'm making the call."
"I disagree, so we're going with my approach."
Better:
"I've heard your concerns, and I've thought about this carefully. Here's why I'm still going with [alternative approach]: [specific reasoning]. I understand you disagree, and I'm open to revisiting this if we see issues, but for now, this is the direction we're taking."
Best:
"I've thought about your recommendation, and I appreciate the technical analysis. I'm making a different call for these reasons: [explain reasoning, including any context they might not have]. I know you disagree, and you might be right - we'll evaluate results and learn from this either way. I'm taking responsibility for this decision."
Why "Best" Works:
Acknowledges their input
Explains your reasoning
Shows you've thought it through
Admits you might be wrong
Takes responsibility
Keeps the door open to learning
After the Override
Check in later:
"I know you disagreed with the [decision]. How's it playing out from your perspective? Are you seeing the issues you were concerned about?"
Why This Matters:
Shows you're actually paying attention to outcomes
Demonstrates that you take their concerns seriously
Creates a learning opportunity
If they were right, you can adjust
When They Were Right and You Were Wrong
This will happen. How you handle it matters.
What To Do
Acknowledge it publicly:
In the next team meeting or 1-on-1:
"I want to revisit the decision we made on [topic]. [Senior Engineer] raised concerns about [issue], and I made a different call. Turns out, those concerns were valid. We're seeing [problems they predicted]. I should have listened more carefully. We're going to adjust to [their recommended approach]."
Why This Works:
Shows you're accountable
Demonstrates that you learn from mistakes
Builds trust that you'll admit when you're wrong
Models the culture you want (mistakes are learning opportunities)
Respects their expertise publicly
What NOT To Do
Don't:
Quietly change course without acknowledging they were right
Blame external factors instead of your judgment
Make excuses for why you made the wrong call
Act like it's not a big deal
Why These Fail:
If you don't acknowledge when they're right, why would they bother giving you input next time?
Learning from mistakes publicly is part of building a healthy culture, something I explored in Managing Your Team Through a Major Outage - a blameless culture starts with you admitting your own errors.
Building a Relationship Where Disagreement Is Healthy
The goal isn't avoiding disagreement. It's creating a dynamic where disagreement is productive, not destructive.
What Healthy Disagreement Looks Like
Your senior engineer feels comfortable:
Challenging your ideas
Explaining why they think you're wrong
Advocating for alternative approaches
Saying "I don't think that will work."
You feel comfortable:
Asking questions about things you don't fully understand
Admitting when they're right, and you're wrong
Making decisions that differ from their recommendations when needed
Saying "I don't know, what do you think?"
Both of you:
Assume good intent
Focus on outcomes, not ego
Learn from when you're wrong
Explain reasoning, not just positions
Maintain respect even in disagreement
How To Build This
1. Explicitly Invite Disagreement
In 1-on-1s or design discussions:
"I want you to push back if you think I'm wrong about something. I'd rather argue now than implement a bad decision."
2. Reward Dissent
When someone disagrees with you, and they're right, thank them publicly.
When someone disagrees with you, and they're wrong, thank them for the input anyway.
Never punish disagreement with good intent.
3. Be Vulnerable About Your Own Limitations
"I don't have deep expertise in [area]. I'm relying on you to catch things I miss."
4. Explain Your Decision-Making Process
Not just what you decided, but how you weighed factors.
This helps them understand that you're thinking through things, even if you reach different conclusions.
5. Follow Up on Outcomes
Circle back on decisions, especially ones where there was disagreement. What actually happened? Who was right? What did we learn?
What I'm Still Figuring Out
Six months in, here's what I'm still struggling with:
How To Balance Learning vs. Deciding
The Tension:
I want to learn from my senior engineers. But I also need to make timely decisions. How much time do I spend trying to understand vs. just trusting their judgment and moving forward?
What I'm Learning:
Depends on the stakes. High-stakes decisions warrant more time to understand. Low-stakes decisions can move faster with less deep understanding.
When My Gut Disagrees With Their Analysis
The Situation:
Sometimes the technical analysis says one thing, but my gut says something different. Maybe it's instinct from years of experience. Maybe it's anxiety.
The Question:
How much do I trust my gut vs. their analysis?
What I'm Learning:
Try to articulate what my gut is reacting to. Is it a real concern I can't quite verbalize? Or is it just discomfort with uncertainty?
How To Develop Technical Judgment Without Deep Expertise
The Challenge:
I need to evaluate technical decisions in areas where I'm not the expert. How do I develop good judgment without becoming an expert in everything?
What I'm Learning:
Focus on understanding trade-offs, risks, and constraints rather than technical details. Ask questions about "what could go wrong" and "what are we optimizing for."
How Much To Defer vs. How Much To Lead
The Tension:
If I defer to senior engineers on everything, I'm not really leading. If I never defer, I'm arrogant and ignoring expertise.
The Question:
Where's the line?
What I'm Still Learning:
This probably varies by situation and person. Still calibrating.
The Bottom Line: Leadership Doesn't Mean Knowing Everything
Here's what I'm learning about disagreeing with senior engineers:
Your job isn't to be the smartest person in the room. Your job is to make good decisions using the expertise available, including theirs.
Disagreement is healthy when done right. The best teams debate ideas vigorously and then commit to decisions together.
Being wrong and admitting it builds credibility. Pretending you're never wrong destroys it.
Authority comes from judgment, not knowledge. People respect managers who make thoughtful decisions, not managers who pretend to know everything.
You need to make decisions even with uncertainty. You won't always know who's right. Make the best call you can with available information.
How you handle being wrong matters more than being right. Everyone makes mistakes. Leaders acknowledge them, learn from them, and adjust.
Inviting disagreement is strength, not weakness. The best ideas come from debate, not from everyone agreeing with the manager.
Context matters as much as technical correctness. Sometimes the "worse" technical solution is the right business decision.
You're building a relationship, not just making decisions. How you disagree affects whether they'll give you honest input in the future.
Your senior engineers want to be heard, not necessarily agreed with. Most people can accept decisions they disagree with if they feel heard and understand the reasoning.
You don't have to know everything to add value. You add value through judgment, context, prioritization, and decision-making - not just technical expertise.
The Framework I Use Now
When my senior engineer and I disagree:
1. Listen fully to their perspective
What are they seeing?
What are their concerns?
What's their reasoning?
2. Share my perspective
What am I thinking?
What context might I have that they don't?
What are my concerns?
3. Identify the real disagreement
Are we disagreeing on facts or priorities?
Is this technical or contextual?
What's driving our different conclusions?
4. Make a decision
Based on reasoning, not authority
Explained clearly
Open to being wrong
5. Follow up
How did it turn out?
What did we learn?
Were they right?
6. Acknowledge when you're wrong
Publicly
Quickly
Use it as learning
Continue the Conversation
📧 Navigating technical leadership and team dynamics? Subscribe to my monthly newsletter for practical perspectives on leading technical teams, making decisions with uncertainty, and learning to manage people who know more than you. First Tuesday of every month. Sign up below!
How do you handle disagreements with your senior engineers? When do you defer vs. when do you override? Share your experiences in the comments or connect with me on LinkedIn - we're all figuring this out together.