I've sat in plenty of meetings where two smart people seemed to be arguing about the same decision and never got any closer to agreement.
Should we build it properly or ship something rough this week? Should we hire the more experienced person or the cheaper one? Should we keep the product simple or add the feature customers keep asking for?
The longer I've spent around product and engineering teams, the more I've realised that a lot of disagreements aren't really about the decision itself.
They're about what each person is trying to optimise for.
One person is optimising for speed. Another is optimising for quality. Someone else is optimising for cost, control, flexibility, reliability, or future optionality. They can all be looking at the same situation, using the same facts, and still arrive at completely different answers.
Not because one of them is irrational.
Because they're aiming at different targets.
What are we arguing about?
This shows up everywhere once you start looking for it.
An engineer says a quick fix is a bad idea because it'll create more work later. They're optimising for maintainability. The CEO says that it has to go out today. They're optimising for speed.
Both positions can be reasonable.
The trouble starts when each side assumes that their optimisation goal is the obvious one. Then the conversation becomes frustrating. The solution keeps getting debated, but the real disagreement is further upstream.
You're not actually arguing about the quick fix.
You're arguing about whether this is the kind of moment where speed matters more than cleanliness.
The best answer
This is why so much advice sounds contradictory.
Move fast.
Do things properly.
Focus
Keep your options open.
Default to action.
Think long term.
All of these can be good advice. All of them can also be terrible advice.
It depends what you're trying to optimise for.
If you're a tiny startup with six weeks of runway, optimising for elegance is probably a luxury that you can't afford right now. If you're running software used by millions of people, optimising only for speed is how you create a tangled mess that becomes impossible to unpick.
The same decision can be smart in one context and reckless in another.
That's why I get nervous when people talk about best practices as if they exist in a vacuum. Most of the time a best practice is just a trade-off that made sense for someone else's optimisation goal.
Copying it without understanding the goal underneath is how you end up solving the wrong problem extremely well.
Engineering is full of trade-offs
Software teams are particularly good at disguising value judgments as technical debates.
We talk about architecture, abstractions, infrastructure and process as though there is an objectively correct answer if only we're smart enough to find it.
Usually there isn't.
There are just trade-offs.
A more robust system is often slower to build. A more flexible design is often harder to understand. A more polished product can take longer to ship. A safer process can reduce mistakes whilst also reducing momentum.
None of those things are free.
So when two engineers disagree, it's often not because one understands systems and the other doesn't. It's because one is optimising for scale in six months and the other is optimising for delivery this week.
That's a much easier disagreement to resolve, because at least now you're talking about the real thing.
Business decisions work the same way
This isn't just an engineering problem.
I've seen businesses optimise for growth and accidentally destroy profit. I've seen businesses optimise for profit and slowly stop growing. I've seen founders optimise for headcount because a bigger team feels like progress, and others optimise for calm because they don't want to spend their life managing a complicated machine.
Again, none of those are automatically wrong.
But they lead to very different decisions.
Should you raise money or stay small. Should you automate everything or keep things manual for a while. Should you chase enterprise customers or lots of smaller ones. Should you build the custom system or live with the annoying workaround.
You can't answer any of those properly until you're clear on the thing you're trying to maximise.
Some disagreements disappear once you name the goal
I've found that one of the most useful questions in any messy decision is also one of the simplest.
What are we optimising for here?
Not in the abstract. Not as a company value written on a wall somewhere. In this specific decision, right now, what matters most?
- Speed?
- Reliability?
- Learning as quickly as possible?
- Reducing support load?
- Buying ourselves options for later?
Once that's explicit, a lot of the heat leaves the room.
You may still disagree, but now the disagreement is concrete. Maybe you think the business should be optimising for retention and I think it should be optimising for growth. That's okay. At least now we're not pretending the argument is about whether a queue should be introduced or a page should be redesigned.
We've finally reached the actual decision.
It's personal
The same pattern shows up in personal life more than I'd like to admit.
People optimise for money and then wonder why they feel time-poor. They optimise for comfort and then feel stuck. They optimise for freedom and then get frustrated by the instability that comes with it. They optimise for status and discover they don't especially like the life attached to it.
I think a lot of quiet dissatisfaction comes from winning at the wrong thing.
Or from never stopping to ask what the thing even was.
It's very easy to inherit someone else's optimisation goal without noticing. A bigger house. A more impressive title. Faster growth. More output. More efficiency. More, generally.
Then one day you realise you've been very effectively solving for a life you don't actually want.
Which is annoying, because once you've optimised a system for years it's a bit inconvenient to discover the metric was wrong.
Make the trade-off on purpose
None of this means you can avoid trade-offs. It just means you can make them on purpose.
Every meaningful decision gives something up to get something else. The mistake is thinking there's a version where you get all of it, or assuming that the cost you're paying is accidental rather than chosen.
If you know you're optimising for speed, then some mess is part of the deal. If you know you're optimising for quality, then some slowness is part of the deal. If you know you're optimising for simplicity, then some flexibility has to go.
That's fine.
The pain usually comes from pretending you can optimise for everything at once, then acting surprised when reality refuses to cooperate.
Ask the question earlier
The older I get, the more I think this question belongs near the start of things, not halfway through an argument.
What are we optimising for in this team? In this product? In this season of the business? In this stage of life?
Because once the target is clear, a lot of decisions stop feeling moral and start feeling practical.
You're not choosing between right and wrong.
You're choosing between trade-offs in service of a goal.
And if the discussion still feels confused, it's often because the optimisation goal hasn't been said out loud yet.
Most people think they're arguing about the answer.
Quite often they're actually arguing about the question.
