What should I do when I disagree with a senior engineer or tech lead?

Disagreement is part of the job

Engineering teams make better decisions when people speak up. Most good tech leads know this and genuinely want to hear concerns, especially before something is built. What they do not want is resistance that shows up late, arrives as criticism in front of others, or turns into quietly building something different.

So the question is not whether to disagree. It is how.

Step one: understand their reasoning

Before you argue, ask. Senior engineers often know about constraints you do not: an upcoming feature that needs the flexibility, a past incident, a team agreement, a performance requirement. A curious question costs nothing:

"I want to make sure I understand the approach. What made us go with a separate service here rather than keeping it in the existing module?"

Sometimes the answer resolves your concern completely. That is a win, not a loss.

Step two: raise it early and in the right place

Timing matters more than wording. A concern raised during planning is useful. The same concern raised after two weeks of work is expensive for everyone.

If the discussion is happening in a meeting, it is fine to ask a question there. If you think the decision is actually wrong, a short private message or quick call is usually better. It lets them consider it without feeling challenged in public.

Step three: bring evidence and an alternative

"I do not like this" is an opinion. Compare it with:

"I am worried about how many moving parts this adds for a feature with low traffic. On my last project, a similar setup took us a lot of time to debug. Would a simpler version inside the current service work for now, with a clear point where we would split it out if load grows?"

That message states the concern, gives evidence, offers an alternative and ties it to a shared goal. It is very hard to take personally.

Useful kinds of evidence:

Step four: disagree and commit

After you have made your case clearly, the lead may still choose their approach. Then your job is to build it properly, not half-heartedly, and not to say "I told you so" later. This is often called disagree and commit, and it is one of the clearest signs of maturity on a team.

It is fine to leave a record, for example a short note in the ticket or design document: "Considered a simpler approach; chose this one because of X. Revisit if Y." That protects the team, not your ego.

When it is more serious

A few situations justify escalating beyond the lead:

• Security or privacy risks that are being ignored.
• Something illegal or unethical.
• Repeated decisions that clearly harm users or the team, after you have raised them directly.

Even then, raise it with the lead first, then with your manager, calmly and with specifics. Going around someone before talking to them directly almost always backfires.

What not to do

• Arguing in a group channel in a way that forces people to take sides.
• Quietly building your own version instead.
• Bringing it up weeks later when changing course is costly.
• Making it about their skill rather than the decision.
• Giving in silently and then complaining to teammates.

The long game

Every time you disagree well, the lead learns that your concerns are thoughtful and worth hearing. Over time they start asking for your view before they decide. That is how influence grows, long before any title changes.

A worked example

A composite I hear often: a lead proposes adding a caching layer with a separate store for a page that currently loads in under half a second. A junior engineer thinks it is unnecessary. Here is how the conversation went well:

1. The junior asked privately why the cache was needed. The lead said a marketing campaign was expected to multiply traffic in two months.
2. The junior had not known that. The concern changed from "this is unnecessary" to "is this the simplest way to handle the spike".
3. They brought a quick measurement: the page's slowest query, and how a database index alone improved it.
4. The lead agreed to add the index first, load test, and only add the cache if the numbers required it.

Nobody lost face. The team got a simpler system, and the lead learned that this junior thinks carefully. That is the outcome to aim for.

A self-check before you raise it

Ask yourself honestly:

• Do I understand their reasoning well enough to explain it back to them?
• Is my concern about users, reliability, cost or time, or is it mostly taste?
• Do I have evidence, or only a feeling?
• Would I still raise this if it were my own idea being questioned?

If most answers point to taste without evidence, it may be worth letting this one go and saving your credibility for the disagreements that matter. For how to put your reasoning across clearly when you do raise it, see how to explain technical ideas to other engineers.

If you are still stuck

Read Twelve moves that take you from mid level to senior and The habits that make an engineer worth routing work through. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.