For years, I was that engineer who obsessed over the perfect abstraction, the cleanest architecture, the most elegant solution. I'd spend hours refactoring code and building features that were interesting but not valuable. I was optimizing for everything except what mattered most: building products that people actually wanted.
This shift from code-centric to impact-centric thinking doesn't happen naturally. It required unlearning years of training that taught me to optimize for technical excellence. It also required embracing those conversations that make us feel uncomfortable at times to question assumptions we've held sacred.
What I've discovered is that the path from over confident engineer to builder is paved with disagreement. A very specific type of productive tension can be helpful for teams to confront what really matters.
The trouble with teams is that they develop unspoken rules, values, and habits that settle in over time. Everyone knows "this is how we do things here" until someone new joins and suddenly there's friction. Maybe you've been the newcomer who sees things differently, or perhaps you've been on the team when a fresh perspective comes to shake things up. In that moment, there's a choice: Do we smooth over the differences and keep the peace, or do we lean into tension and discover what really matters?
My goal here isn't to confirm what you already believe. Instead I plan to challenge you, to make you question the practices and assumptions that have defined your career. Because here's the truth: disagreement doesn't just make for better code—it makes for stronger teams and better products.
What I've learned is that there are three specific types of disagreement that, when embraced, become a competitive advantage.
Disagreement About Process
The first is disagreement about the process. Simply put, do less but more often.
Before we dive in, I want to recommend the book Shape Up, because it marks a defining moment in my software career. This book did something for me that I know it can do for you. It provides clarity about scope and brought to light arguably the most important skill of the current age given advancements in tooling especially.
If we had asked how long would it take to build Basecamp, we never would have got it done. But if we had asked instead, what is a version of chat, for example, that we could deliver by the end of the week? Well, that's something entirely different.
So when I say do less, but do it more often, I'm not talking about working fewer hours or Claude Code. I'm talking about agreeing to deliver less. And if we agree to this individually and collectively, we not only move quicker by cutting scope, but we de-risk the project by reducing time to market.
First you negotiate to the very essential core as the authors refer to it. Then you expand on this core over time until you reach a point where the effort outweighs the value people are getting from it. Consistent delivery allows you to find this sweet spot without the disappointment that's so rampant in our industry today.
Here's where the disagreement comes. When you start proposing this approach, you'll meet resistance and it will likely come from other programmers. We're trained to be meticulous and critical about details without exception. We're taught that shortcuts lead to technical debt, that rushing leads to bugs, that proper process prevents problems. This mismatch will put you into disagreements regularly. Your fellow engineers will push back.
Your instinct, like mine, might be to avoid that conflict and just go along with the existing process. But organizations move at the speed of trust. The consistency and frequency of delivery are valuable and offer the most effective way to build that trust. And this process helps you and the team build the muscle memory required for scope hammering, with the added bonus that it helps you get to market faster and validate your ideas and often your assumptions.
I was working with a team that historically delivered less often. Our standups were very technical and involved vague terms that kept our non-technical people at a distance. In short, this team isolated itself from collaboration and shared business objectives. I knew we could win the trust of our leaders by showing working software instead of making excuses. I knew this would invite more collaboration and foster real innovation. I knew proposing this would put me in direct conflict with the existing team.
So instead of debating pros and cons endlessly, I simply started doing the work and modeled it for the wider team. I certainly felt some tension, but when questioned, I pointed to our goals and made it clear I wasn't cutting corners but scope. I was intentionally choosing progress over perfection daily, and it was working.
In just a few short weeks, our business leaders felt at home in these standups because the discussion was much more outcome oriented. And this new energy and engagement brought a much faster feedback loop that our team had never seen, and it naturally helped us surface answers to questions we'd stumbled on just the day before.
To my surprise, most of the engineers followed my example, and the team made this transition from surviving to thriving. The cultural shift was uncomfortable at times but pushing through it transformed this company, allowing us to deliver more value more often.
Disagreement About Details
Nearly all software development policies and processes exist to prevent software from being released.
I frame it this way because we're going to be looking at disagreement in the details. And if you break down a lot of our jobs day-to-day, it is truly just managing these details.
What I'll be sharing here may challenge the very decision-making process that you have day-to-day. First, I want to start out by sharing the two different phases that show up in every project. You have the uphill work, where there's a lot of uncertainty and you're doing a lot of problem solving. Then there's the downhill work, where it's more about execution.
Early in the project, the details don't carry as much weight. But over time, as things become more clear, more understood, they become more important. The trouble shows up when we apply equal weight to every possible sharp edge and detail that we encounter. We rarely take the time required to consider how important one detail is versus another. So we just pile on the scope, which ultimately delays delivery.
This is where the daily demo comes in handy. Simply put, you're going to show the previous day's work. And the time pressure you feel to deliver frequently like this provides the forcing function required to cut scope aggressively. This magnifies the details that matter most and helps the team minimize a focus on edge cases that can be tackled another day.
The added bonus here of the daily demo is that working software quickly provides the clarity to set expectations. During these demos, make it a habit to encourage feedback from everyone involved. It doesn't mean that you commit to everything, but it does create this amazing feedback loop. And you do get a ton of value as a team here surfacing, not only problems, but often solutions.
And this is when those disagreements begin to surface. This style of work often conflicts with more traditional roles and even the reward systems that optimize for code above all else. Remind everyone that incremental investment leads to monumental advancement. We're not shooting for a big bang release. This is truly working lean.
One of the challenges with working lean is that decision-making day-to-day just looks radically different. One of the benefits though, is disagreement at this stage helps your team arrive at done more quickly by avoiding gold plating and bike shedding that run rampant when unchecked. The added bonus of course is you find technical issues faster because you're deploying more often. And equally important, you might flush out gaps in your domain knowledge by getting this in front of real stakeholders sooner.
Recently, I went through a code review and I was using just a dictionary instead of a type class in Python. During this review that was flagged and the engineer said this would be an improvement. And this reminded me that if we optimize for code on our teams and in our organizations, we're going to get more time in the code. It's only when you optimize for impact that you consider other factors like speed to market, learning, or simply return on investment.
Now the individual wasn't doing anything out of the ordinary. In fact, most of us are actually rewarded here to be champions of code above all else. And one of the challenges you're going to face here is that if the team is not aligned about what matters most, technical people, well, they'll do technical things but never lose sight of the impact.
Now this disagreement actually gave us an opportunity to discuss the real impact and investment of time. So we talked about whether this improvement was necessary for the current iteration and whether we could wait until we validated this feature with real users.
Now, I want to be clear. If you're working in a classic reward system, you may not always win these arguments. That's okay. Because you still shared something very important that technical people often miss, and that is the distinction between progress and perfection.
Disagreement About Purpose
For the final section here, we're going to talk about purpose and disagreement there. I recommend this book to you called Impact First Product Teams by Matt LeMay. In it, you will find the most practical career advice for someone writing software in 2025. It includes a call for action that will be difficult for most of us, but one that is necessary to grasp as we enter a future where the market is very different than it has been for most of my lifetime working in tech.
If nobody else is talking about it, ask about the highest impact work you can do. Avoid what Matt calls the "low impact death spiral." This is easy, but often not helpful work that product teams get trapped in.
Now there's a vast gap between the work and the impact, and we fill this with useful things like strategy, discovery, scoping, etc. This is often helpful, but the key here is throughout we should be making decisions with impact in view. But so often, the impact feels far away and the technical details are all too familiar, comfortable, and tangible.
And this is the deepest level of disagreement, the most challenging for teams, honestly: questioning not just how we do the work, but applying real judgment about what work we choose to do at all.
Something happened during our quarterly onsite that put our team's impact front and center. I put together a team building activity that essentially said, come up with the money to cover the team's cost each year, or we'll close up shop. Suddenly, every idea was on the table. This constraint stripped away all the comfortable busy work and forced us into difficult conversations.
Should we focus on saving money or making money? This, of course, divided the group initially. What features actually drive revenue versus features that are interesting? What problems are we solving that people will actually pay for?
After lots of refinement, thinking, and working through the problem and solution pairs, we landed on a single solution that everyone was energized about. The outcome was a clear, high-impact project with real potential to increase our revenue. And this type of disagreement is not only necessary, but critical for the longevity of the business. Without it, we choose to tackle low-risk and often low-value work that does little to move the business forward.
Your Competitive Advantage
My hope is that you will be set apart, not by following my advice or conventional wisdom from companies like Meta or Google, but by identifying those opportunities hidden in disagreement and turning them into your strategic advantage.
Here's the key insight: Humility is the prerequisite for productive disagreement because humility allows you to cut scope despite your intuition, ship imperfect code despite your instincts, and question the fundamental assumptions to surface truly high-impact work. With a measure of humility, this will bring your teams closer to impact, however that looks in your organization.
Remember, that lens you bring to the team is really important. It becomes a problem when you think it's the most important.
So disagreements are out there, and they're coming for you, whether you embrace them or not. The question is: will you see it as a burden or a competitive advantage?
