The idea for this article started while I was working on improving how quarterly planning is done for a SaaS company. I wasn’t trying to fix estimations; I was trying to design a more systematic, consistent way for Product and Engineering to prepare for planning discussions — something that would make those conversations clearer, less chaotic, and more aligned from the start.
But as I went deeper into that work, I kept recognising patterns I had seen years earlier in a software house. Completely different environment, completely different incentives — and yet the same kinds of tensions appeared.
In product companies, the struggle shows up during quarterly planning: how to balance tech debt, foundational work, and feature delivery. In agencies, it shows up during presales: how to scope and size projects so Sales can win deals without burying Engineering.
Different settings, different vocabulary — but the same underlying friction.
And that’s when it clicked: what we often treat as ‘estimation problems’ or ‘prioritisation disagreements’ are really symptoms of something deeper. They’re the outcome of organisational dynamics: incentives, silos, trust gaps, and groups optimising for different definitions of success.
This article is about why alignment breaks in the first place — and what teams can do to rebuild it.
Agencies: built-in conflict of interest
Inside a software house or agency, estimation usually happens during presales: Sales, Product/Design and Engineering sit down with a potential client to price the work.
Once you understand what motivates each group, the tension is obvious:
Sales wants to sell. Their success is closing the deal.
Engineering wants realism. Their success is not inheriting a disaster.
If the client walks away because the estimate is high, Engineering pays no price.
If the deal closes with unrealistic timelines, Sales doesn’t stay to deal with the fallout.
These incentives collide long before a single line of code is written. You don’t need a psychology degree to predict the outcome: incorrect estimates and plenty of mutual frustration. Sizing becomes a negotiation, not a forecast.
Startups: alignment through shared reality
In most small product companies, people sit close enough (literally and culturally). Alignment happens almost by osmosis. Everyone knows the runway, the existential risks, the upcoming investor demo. Engineering understands why the shortcut is needed now, and Product understands when the tech foundation is cracking.
Proximity builds empathy. It’s hard to demonise someone whose desk is two meters away. Trust forms because everyone is living the same reality.
Scale-Ups and Growth companies: misalignment returns
As companies grow, specialisation creates silos, and silos unintentionally recreate the agency dynamic — inside the same organisation.
Product now has quarterly targets and market pressures. Engineering has stability, scalability, and tech-debt concerns. What used to be a shared conversation becomes two competing presentations.
One group talks in outcomes while the other group talks in systems. Both sides feel misunderstood. And because people are no longer sharing context naturally, they rely more heavily on assumptions about each other’s motives — usually incorrect ones.
This is why delivery debates in large product orgs can feel eerily similar to those in agencies. Different structure, same ‘us versus them’ dynamics.
What Engineering can actually do
Technical correctness alone rarely convinces anyone outside Engineering.
Influencing cross-functional partners isn’t ‘manipulation’ or ‘politics’ — despite how often those words get thrown around in engineering circles.
If you want your priorities taken seriously, you need to explain them in terms that match the other person’s goals and pressures.
This means:
describing the problem and proposed solution in plain, non-technical language
explaining why the business should care
providing sizing ranges instead of perfect numbers
showing costs (time, AWS bill, human capacity)
showing value (revenue impact, churn reduction, reliability gains, capacity unlocked)
bringing evidence: benchmarks, industry standards, competitor expectations, customer impact.
Here are two concrete examples:
Instead of saying:
“We need to rewrite the caching layer.”
Say:
“Our cache misses spike during peak traffic and slow down checkout. Rewriting this layer is likely to reduce abandoned carts by ~4–7%, based on last quarter’s data.”
Instead of saying:
“We have too much tech debt.”
Say:
“We spend 10 engineer-hours per week fixing the same recurring incident pattern. Fixing the root cause gives us half a sprint of capacity back every month.”
You just turned a couple of mystical creatures — Technical Debt™ and Refactoring™ — into increased revenue and regained velocity.
What Product should own
Most product KPIs point toward shipping new features, not improving architecture or reducing incident load. When Product owns only the roadmap — and Engineering owns all the tech debt and on-call pain — conflict is inevitable.
Because if the system collapses in the middle of the night, guess who wakes up? And if only one side feels the pain, only one side sees the problem.
Product should own part of the business-facing stability outcomes — not just features.
Think about metrics such as:
reliability-adjusted delivery capacity (how incidents reduce roadmap throughput)
customer-visible error rates (how often users experience degraded service)
performance or outages impacting churn/conversion
performance-adjusted funnel conversion (how slower performance reduces signup-to-activation or trial-to-paid conversion)
These are not deeply technical metrics. They’re business metrics tightly connected to system health — and when Product owns even a portion of them, the conversation shifts from negotiation to collaboration. And because system health is what keeps core features stable, any erosion there instantly undermines the value of even the most innovative new features, making it essential that Product cares about this just as much as extending functionality.
The Human side of it all
At the end of the day, working in software means working with people — and people are driven by incentives, fears, pressures, and their own definitions of success.
Engineers often assume that the facts should speak for themselves, while Product and Business operate in a world of ambiguity, trade-offs, and shifting priorities. When these worlds collide, it’s easy for each side to see the other as unreasonable. But once you understand what the other person optimises for, planning becomes easier, conversations become more honest, and collaboration becomes less adversarial.
Understanding what drives someone — what they fear, what they optimise for, what success means to them — helps a ton. It’s called emotional intelligence, and it’s not discussed often enough in tech organisations. It’s a skill most engineering cultures undervalue.
Closing thoughts
None of this is simple, and none of it changes overnight. These dynamics are universal — they show up in agencies, startups, scale-ups, and multi-thousand-person organisations. They’ve existed for decades. They’re baked into structure, incentives, communication patterns, and the simple fact that different groups optimise for different things.
No single engineer can reshape an entire organisation’s culture.
Of course, it doesn’t have to be this way. Misalignment isn’t inevitable — it’s the result of how organisations are designed. Incentives, reporting structures, budgeting, and accountability frameworks are leadership choices. Usually, only executives have the authority to reshape them. This article isn’t a guide for C-level redesign; it’s written for the people working within those constraints, trying to make collaboration possible despite them.
But even within those constraints, understanding these dynamics does change how you operate.
Because your ability to collaborate, prioritise, and estimate honestly isn’t only about technical competence. It’s about whether you feel safe enough to be honest in the first place.
If you don’t trust that your estimation will be respected…
If you suspect someone will immediately pressure you to ‘shave 30% off’ because a competitor claimed a miracle timeline…
If you’ve seen your cautious realism turned into a negotiation tactic…
If the culture rewards shipping new features over owning long-term stability…
…then, of course, you won’t plan and estimate realistically. You’ll protect yourself, you’ll pad numbers, or you’ll underplay risks just to avoid conflict. On the flip side, when trust exists — when Product, Sales, and Engineering believe one another are acting in good faith — everything gets easier.
Trust is a force multiplier, whereas lack of trust is a tax. And incentives are the quiet engine behind it all. If Product is rewarded exclusively for shipping features, they will push for features. If Sales is rewarded for closing deals regardless of feasibility, they will close deals regardless of feasibility. If Engineering is rewarded only for stability, they will overcorrect toward safety. These aren’t dysfunctional behaviours, they’re all very logical.
There are entire books that explore these patterns from different angles:
The Five Dysfunctions of a Team helped me see how trust (or the lack of it) quietly shapes most of the misalignment we observe in cross-functional work.
How to Win Friends and Influence People helped me understand the interpersonal side — how people think, what they respond to, and why feeling heard matters more in collaboration than most engineers expect.
Thinking, Fast and Slow highlighted how our own cognitive biases, shortcuts, and flawed intuitions influence decision-making — especially under pressure or uncertainty. It explains why otherwise rational people misjudge risks, cling to anchors, avoid unpleasant truths, or talk past each other without realising it.
Those and other non-technical books helped me understand that many ‘technical’ problems in organisations actually start as people problems — misaligned incentives, cognitive biases, fear, or simple misunderstandings.
Pay attention to incentives and culture, and you’ll quickly understand why some teams are struggling while others thrive.
None of this is rocket science, but it is people science. It’s the part of software that nobody teaches in computer science classes. Yet.
Saaajmon, great piece - your analysis of incentives and trust gaps really hits my heart:D
In all the work we did at shoshin.pm with our clients we’ve observed basically the same pattern.
One thing I’d add is that many of these frictions can actually be reduced if the organisation has a well-defined and well-operationalised strategy, because every solid strategy framework - Three Horizons, GLE, whatever you pick, doesn’t matter - ultimately forces an explicit answer to how we respond to what matters today, in the next few quarters, and in the longer term.
When that isn’t articulated, each function optimises for its own horizon, and the lack of shared allocation rules creates the exact tensions you describe. Commercial will push for results here and now, engineering will push for stability, Product will ask but ok, where do we have space for new solutions to our customers problems? With a clear strategic model that translates into capacity allocation across horizons, a lot of the “misalignment” becomes solvable rather than systemic.
Obviously it’s not that easy - even with the crispiest strategy those gaps and misalignments still exist, that’s why the operationalisation part is so important.
Looking at imaginary example (obviously idk what’s exactly Netflix strategy), you could say Horizon 1 is keeping streaming reliable and performant, Horizon 2 is scaling proven bets like personalized recommendations, and Horizon 3 explores new areas such as gaming or interactive formats. Now if (leadership) you decide that you’re going to spend in those horizons 60/30/10% of your capacity, it gives you a tool to distribute focus principles across the teams.
So difficult to share all the thoughts in one comment, but if you would be open I’d love to chat with you on this topic on our beginners mind podcast?