Earlier in my career, I had the opportunity to be a manager. It was a valuable experience, but not one I was particularly excited about. Being a manager is hard, not to say harder than being an IC, just a different type of hard.
As an IC, you control a much larger portion of your impact. You have more direct influence over outcomes. In short, you have more control over your own destiny. I didn’t dislike being a manager. I struggled with the fundamental shift. To improve my performance meant helping others improve theirs. The goal was no longer to be a better developer, it was to be a better manager. And what I really wanted was to be a better developer.
One challenge I ran into repeatedly as a manager was Disagree and Commit. If you’re unfamiliar with it, the idea is simple. Everyone gets a chance to voice their perspective. Once a decision is made, whether by consensus or hierarchy, everyone commits to moving forward with that decision. They do this even if they disagreed.
It sounds great in theory. In practice, it often plays out very differently.
I’ve seen Disagree and Commit fail in predictable ways. The fix isn’t “more commitment” as a vague expectation. It’s a concrete practice: disagree clearly before the decision. Then execute to the letter after, surfacing deviations immediately.
Here’s 5 ways this plays out.
- Disagree (no commit)
- Disagree and Commit soft
- Disagree and I’ll Show You
- Disagree and Sure Boss (…but secretly I’ll show you)
- Disagree and Commit Hard
1. Disagree
In this situation, you just disagree whether this is with the group, or your manager. You just disagree, and then you leave. While this might on its face seem bad, it’s actually the least worst of the bad outcomes. Why? Because at least you know you disagreed. You all leave with the same mutual understanding of the outcome. Even if that is that you’ve disagreed. Knowing this lets you revisit the problem, maybe add different perspectives. Then you can try again to come to a consensus.
2. Disagree and Commit Soft
In this situation, you know the party that disagreed is only 30% (or less) sold. Which means, when they go to implement the solution, they’re only going to commit 30%. It’s not the best, but again not the worst. At least you’re aware. The person has made you aware they’re not committed to the outcome. This means most likely you’ll keep a closer watch on the deliverables. Have more check points, etc. Because you’re aware they might not be fully committed, you can guide the project. It’s generally not that big of a problem, at least they are trying.
3. Disagree and I’ll Show You
In this case, the person doesn’t actually agree, but they pretend to. You’re fully aware they don’t intend to commit. It’s akin to outright disagreement. However, they still believe their solution is the best one. So, they “commit” to doing it their way. This usually doesn’t happen in the first design session, or even the second. Early on, it stays at simple disagreement. This is the eventual outcome of that pattern. And again, it’s not the worst case. If you have even a bit of emotional intelligence, you know to keep a close eye on things. In the end, their solution might even turn out to be better. You leave the design session knowing one thing for certain. The agreed‑upon solution isn’t the one that’s going to be built.
4. Disagree and Sure Boss (but I’ll show you)
This is the most insidious case. I’ve seen it most often among high‑agency engineers early in their careers. These are people with strong opinions and enough skill to build a parallel path. The design meeting appears to end with alignment. Concerns are raised, discussed, and resolved. Everyone leaves believing there’s a shared understanding of the chosen direction. Commitment seems real.
But it isn’t.
Unbeknownst to the manager or the rest of the team, the “Sure, boss” party has a different plan. They intend to implement their own solution and prove, after the fact—that it was better. No warning. No escalation. Just quiet divergence.
It’s an extremely passive‑aggressive move, and in my experience, it happens more often than people like to admit. I’ll explain why.
There’s a structural tension between managers and individual contributors that explains why Disagree and Commit so often breaks down. It’s not about ego or malice. It’s about information asymmetry. As an IC, you operate with deep, high‑resolution knowledge of your domain. You live in the code. You understand the edge cases, the tradeoffs, the historical context, and the practical consequences of design decisions. Your manager doesn’t and realistically can’t have that same level of detail. Their attention is spread across multiple areas, each with its own complexity. Because of this, it’s easy for an IC to conclude: “I know more about this than my manager. Therefore, my solution is better.” And in a narrow sense, that’s often true. About your specific area, you probably do know more.
But the asymmetry cuts both ways.
Managers operate with a broader, lower‑resolution view. They’re part of conversations you’re not in. They’re aware of future plans and organizational constraints. They understand cross‑team dependencies. Long‑term bets may not be visible or even relevant to you in the moment. Design decisions are often influenced by that broader context, even when it isn’t fully articulated in the room.
This is where things go wrong.
When an IC leaves a design session believing they fully understand the problem. They quietly decide to implement a different solution. They’re acting on partial information. They may be optimizing locally while breaking alignment globally. And because the divergence is hidden, the manager assumes execution is proceeding as agreed and shifts attention elsewhere.
That false sense of alignment is what makes this failure mode so damaging.
In other disagreement scenarios, there are signals. You know things might go sideways, so you watch more closely. In this case, there are no signals. The result is only surprise later. Unwinding the decision is far more expensive than getting it right up front (or even midway).
Information asymmetry doesn’t mean managers are right and ICs are wrong. It means neither side has the full picture. Disagree and Commit only works when both sides respect that reality and when commitment is demonstrated through execution, not intent.
Think about it this way: so you prove your point. You show your manager that your solution was better. What did you actually gain?
Will this help you get promoted or move up? Probably not.
Why? Because being a good developer isn’t about having the best solution in isolation. Software is a team sport, and teams run on trust. Trust is foundational to software development. When you undermine that trust, you don’t just undermine the project, you undermine yourself.
From your manager’s perspective, you’ve demonstrated that alignment can’t be assumed. That you might say yes and do something else. The natural response to that isn’t more autonomy. It’s more scrutiny. More check‑ins. Less trust over time.
I think this “just do it my way” mindset often comes from the myth of the 10x developer. But 10x developers don’t succeed by working alone. They’re effective because they leverage relationships, build trust, and amplify the people around them. That’s how they achieve out-sized impact, not by quietly proving others wrong.
How can you do it differently? Disagree and Commit Hard.
When my manager asks me to do something I strongly disagree with, I start by asking questions. I ask until I understand the decision well enough that I could execute it myself. This part is critical. Asking questions is how you learn the perspective you don’t have.
I ask questions as if I agree, and I’m trying to figure out how to implement the plan. Why is this done this way? What problem does this solve? What happens if X changes? The goal is to gather enough context to reason clearly.
Only after that do I say my piece.
At that point, I can articulate my perspective precisely and explain why I think the decision may be sub-optimal. I’ve already done the work to understand the other side. Because of this, my disagreement is grounded and objective. It is not reactive and subjective. Objective reasoning matters here. Then I pause and let others ask questions. Ideally, this dialogue leads to a compromise. A solution that blends viewpoints rather than favoring a single perspective.
But sometimes it doesn’t. And that’s where Commit Hard begins.
Once execution starts, I implement exactly what was agreed upon. No quiet deviations. No “small improvements.” If I need to diverge from the plan, I raise my hand and communicate it immediately. Failing to execute the plan precisely brings you back to Disagree and Sure Boss territory. Not highlighting deviations also leads to the same place. That’s the outcome we’re explicitly trying to avoid.
Committing hard builds trust across the team and management chain, and it has two positive outcomes.
First, if the solution works. Along the way, you gain experience and learning a different approach. You learned why the decision made sense in the broader context. You build trust by delivering within the agreed ecosystem, and your team knows they can rely on you.
Second, and this one matters just as much. Sometimes the agreed solution doesn’t work.
But now the conversation is different.
You executed exactly what was agreed upon. There’s no “you didn’t really try it” or “you changed things along the way.” Your original concerns now carry more weight because you honored the agreement. You’ve built credibility not just with your manager, but with your peers. And you’ve earned leverage in the process, without boasting or trying to prove anything. From that position, you can calmly and credibly state that the solution needs to be revisited. Your perspective now holds more water.
That’s what Disagree and Commit, Hard looks like in practice.
As Wikipedia puts it, Disagree and Commit is a management principle, where people are encouraged to disagree while a decision is being made. However, once the decision is made, everyone commits to executing it. That commitment isn’t a suggestion or a soft alignment – it’s an agreement.
Software is built on trust. Trust between teammates. Trust between engineers and leadership. Trust between companies and customers.
I’ve practiced this for many years. More often than not, I’ve learned that the group, or my manager, had a clearer perspective than I did. I’ve learned one solution isn’t always the only solution. And in the rare cases where I was “right,” I didn’t win by proving it quietly. I won by committing fully and building trust. I showed that I cared more about the team’s success and my managers success than about being right. In the long run, those things matter far more than having the best solution in the moment.
If you don’t believe me, just try it for yourself. Or feel free to disagree and commit. Hard.
And as always Happy Coding!
“Understanding the other side is the best way to strengthen your own.” — Jim Rohn
Unparalleled Adventure 
Leave a comment