Disagreeing Professionally

Most engineering disagreements start somewhere reasonable. If you’ve worked on enough software projects, you’ve probably experienced this. A design review opens with a question about architecture. Someone raises a concern about the implementation. A few minutes later, the conversation has shifted, and people are no longer weighing options. They are defending the ones they proposed.

The shift is subtle, and it happens on strong teams too. What began as a technical discussion becomes a personal one, and the decision-making gets further away.

Episodes 1 through 3 covered influence, mentorship, and standards. All three rest on something less visible: the ability to disagree with someone and keep the working relationship intact. The best technical leaders aren’t the ones who avoid disagreement. They’re the ones who know how to disagree without damaging relationships.

Disagreement Is a Sign of a Healthy Team

Engineering involves trade-offs rather than single correct answers. Two capable engineers can read the same requirements, weigh cost, timeline, maintainability, and risk differently, and land at different solutions.

Different priorities. Different experiences. That’s normal. In fact, teams where nobody pushes back tend to produce weaker solutions. What matters is not how often a team disagrees, but whether the disagreement produces a better decision. Healthy disagreement forces us to examine assumptions, consider alternatives, and make better decisions. The goal isn’t to eliminate disagreement; it’s to make it constructive.

Engineering involves trade-offs rather than single correct answers. Two capable engineers can read the same requirements, weigh cost, timeline, maintainability, and risk differently, and land at different solutions.

Different priorities. Different experiences. That’s normal. In fact, teams where nobody pushes back tend to produce weaker solutions. What matters is not how often a team

Challenge Ideas, Not People

Consider two versions of the same feedback:

"This design may not scale well once we add more integrations."

"Your design doesn't scale."

The technical content is nearly identical, but the two generate very different responses. The first invites a conversation about integration volume. The second asks the other engineer to defend themselves before they can even engage with the concern.

Consider two versions of the same feedback:

"This design may not scale well once we add more integrations."

"Your design doesn't scale."

The technical content is nearly identical, but the two generate very different responses. The first invites a conversation about integration volume. The second asks the other engineer to defend themselves before they can even engage with the concern.

Small choices in phrasing carry real weight in written review comments, where tone is easy to misread, and there is no body language to soften it.

Stay Curious Longer

A habit worth building: ask one more question before offering an opinion.

What led you to this approach?
What constraints were you optimizing for?
What alternatives did you rule out, and why?

Sometimes the answers confirm the original disagreement. Other times they reveal that both engineers were solving slightly different problems, or that a constraint existed which was never written down anywhere. In NetSuite environments, where a customization decision often traces back to a business process nobody documented, that missing context shows up more often than people expect.

A habit worth building: ask one more question before offering an opinion.

What led you to this approach?
What constraints were you optimizing for?
What alternatives did you rule out, and why?

Small choices in phrasing carry real weight in written review comments, where tone is easy to misread, and there is no body language to soften it.

Sometimes the answers confirm the original disagreement. Other times they reveal that both engineers were solving slightly different problems, or that a constraint existed which was never written down anywhere. In NetSuite environments, where a customization decision often traces back to a business process nobody documented, that missing context shows up more often than people expect.

Changing Your Mind Is a Leadership Move

Technical leadership is sometimes confused with having the final answer. It sits closer to caring more about the best answer than about whose answer it was.

Some of the most respected engineers have a habit that shows up surprisingly rarely. When presented with better information, they say, "Good point, let's go with that," and move on. There is no drawn-out defense of the original position.

That willingness usually earns more credibility than winning the point would have. Teams read it as a signal that the engineer evaluates ideas honestly, which makes their agreement worth more when it does come.

Technical leadership is sometimes confused with having the final answer. It sits closer to caring more about the best answer than about whose answer it was.

Some of the most respected engineers have a habit that shows up surprisingly rarely. When presented with better information, they say, "Good point, let's go with that," and move on. There is no drawn-out defense of the original position.

That willingness usually earns more credibility than winning the point would

Technical leadership is sometimes confused with having the final answer. It sits closer to caring more about the best answer than about whose answer it was.

Some of the most respected engineers have a habit that shows up surprisingly rarely. When presented with better information, they say, "Good point, let's go with that," and move on. There is no drawn-out defense of the original position.

have. Teams read it as a signal that the engineer evaluates ideas honestly, which makes their agreement worth more when it does come.

That willingness usually earns more credibility than winning the point would have. Teams read it as a signal that the engineer evaluates ideas honestly, which makes their agreement worth more when it does come.

Know When to Escalate and Move On

Not every disagreement needs a meeting. Not every meeting needs an escalation. Most technical debates can be settled by returning to requirements, data, or an existing team convention. Some cannot. Two reasonable options remain on the table and further discussion yields no new information.

When a discussion reaches that point:

Write down the trade-offs on both sides
Bring in whoever owns the decision
Make the call
Commit to it as a team, including the people who argued the other way

Not every disagreement needs a meeting. Not every meeting needs an escalation. Most technical debates can be settled by returning to requirements, data, or an existing team convention. Some cannot. Two reasonable options remain on the table and further discussion yields no new information.

When a discussion reaches that point:

Write down the trade-offs on both sides
Bring in whoever owns the decision
Make the call
Commit to it as a team, including the people who argued the other way

Unresolved debates cost more than imperfect decisions. A team moving forward on a good option generally outperforms a team still deliberating over the best one.

Unresolved debates cost more than imperfect decisions. A team moving forward on a good option generally outperforms a team still deliberating over the best one

Respect Doesn't Require Agreement

One of the biggest lessons we’ve learned is this:

You can strongly disagree with someone’s idea while still showing some respect.

An engineer can think an idea is wrong and still treat the person who proposed it as capable. Those two things sit together comfortably, though teams sometimes behave as though they cannot.

Teams that get this right create an environment where people raise concerns early, because they trust that it will be heard rather than dismissed.

One of the biggest lessons we’ve learned is this:

You can strongly disagree with someone’s idea while still showing some respect.

An engineer can think an idea is wrong and still treat the person who proposed it as capable. Those two things sit together comfortably, though teams sometimes behave as though they cannot.

Problems surface while they are still cheap to fix, and quieter engineers start contributing to discussions they would otherwise sit out. Psychological safety often gets described as a soft benefit. In practice it shows up as fewer late-stage surprises.

Teams that get this right create an environment where people raise concerns early, because they trust that it will be heard rather than dismissed. Problems surface while they are still cheap to fix, and quieter engineers start contributing to discussions they would otherwise sit out. Psychological safety often gets described as a soft benefit. In practice it shows up as fewer late-stage surprises.

Final Thoughts

Technical leadership isn’t measured by how often you win an argument. It shows whether the team reaches better decisions, and whether people still want to work through hard problems together afterward. Arguments won is a poor proxy for either.

That means listening before responding, and remembering that the person on the other side is not your opponent but working on the same problem together. The best engineering decision is rarely the one that protects someone's position. It is the one that moves the team forward.

At ATSOURCE, we build NetSuite teams where that kind of technical discussion is part of how the work gets done. Let's talk about what that looks like for your organization.

Meet the Author

Jona has over a decade of experience in SuiteCloud Development on the NetSuite platform. She specializes in implementing advanced solutions and has led teams in creating high-quality software. Jona holds multiple certifications and has been recognized with awards like the Summit Award and Quality Champion Award.

Get in touch

Episode 4: Leading Without Becoming a Manager: Disagreeing Professionally

Disagreement Is a Sign of a Healthy Team

Challenge Ideas, Not People

Stay Curious Longer

Changing Your Mind Is a Leadership Move

Know When to Escalate and Move On

Respect Doesn't Require Agreement

Final Thoughts

Meet the Author

Tags

Accelerate ERP Success with Expert Solutions

Episode 3: Leading Without Becoming a Manager: Raising Standards Without Becoming the Code Police

Episode 2: Leading Without Becoming a Manager: Mentoring Without Micromanaging

Episode 1: Technical Leadership Starts With Trust, Not a Title

Your ERP Expert Staffing Solutions

Solutions

Staff Augmentation

Netsuite Services

About Us

Blogs

Get Hired

FAQs