Senior engineering leaders often get stuck as the default escalation point to unblock situations. It makes sense that Commercial pushes for revenue and Product pushes for features, but when these clash, Engineering is forced to absorb the friction.
This also happens within Engineering, where dozens of teams might not adjust their roadmaps for a company-wide critical initiative: everyone in the meeting agrees on the urgency, but then the roadmaps are not updated. Both types of situations boil down to their performance metrics telling them not to change their direction.
The common response from senior leaders is to escalate this situation and seek a top-down approach. But this approach fails to solve the root cause of the misalignment, and trains the organisation to hold out until there is a mandate. Waiting for line managers to self-correct does not work when they are judged only on their local delivery.
Exposing the real limits
Discussing each team’s internal OKRs doesn’t solve the core issue, because you cannot win a debate over someone else’s metrics. To solve the misalignment, you need to move the discussion away from internal roadmaps and translate the technical limits into a shared reality. For example, if a system was built to cache 250 items and Commercial wants to integrate with a partner that requires 2,500 items, that is an architectural limit that would take time to change and introduces other risks.
There are two mechanisms that I use to ensure alignment with Commercial:
Cost-of-delay: When you calculate the cost of delaying an architectural change or system update, you move the discussion to potential impact on revenue. That gives Commercial the data they need to reduce or stagger scope.
Readiness assessment: When working with third parties, Commercial teams on both sides often agree to aggressive timelines based on high-level assumptions. Instead of pushing back on those dates, ask Commercial to speak directly to the partner’s technical teams, which will show their real technical readiness. For example, while 90% of the integration might be ready in three months, they might need another two months for the other 10%.
Providing this data changes the dynamic completely and moves you from the engineering bottleneck saying no to a launch date, to giving Commercial the data they need to reprioritise their partnerships.
Shared data can solve a disagreement, but when the same conflict is faced repeatedly, it means that the different leaders are being measured against incompatible outcomes. At this point, the executive team will need to either change the goals, or add a shared outcome that makes the trade-off part of everyone’s expectations.
Making alignment easier
The most challenging part of horizontal leadership is ensuring alignment without direct authority. Exposing the constraints works well for Commercial, but aligning internal technical teams requires a different approach: you must make the path of least resistance align with the wider priority.
One way of reducing friction is allowing a team to take operational risk instead of creating an engineering bottleneck. For example, if Finance pushes back on the technical work required from them, you offer them a choice: drop their roadmap to deliver the new work, or accept the risk of manual reconciliation until they have capacity. In this case, agreeing to the operational risk is cheaper than pushing for the engineering priority. This however must have an expiration date, because otherwise the temporary workaround will become a permanent operational burden.
In situations where teams are blocked or completely unable to change their roadmap (e.g. they already had tight compliance deadlines to meet), you will also need to solve their capacity constraints by temporarily reallocating engineers to that team. This is a deliberate trade-off to keep the initiative moving: use it to either absorb the new work or backfill their core roadmap. As with operational risk, this extra capacity must be linked to a milestone to avoid them becoming permanent team transfers. But remember that moving engineers doesn’t create capacity, it moves the delay somewhere else where the impact is lower, so every reallocation must explicitly mention the work that will be delayed and the impact of that delay.
Finally, making alignment the path of least resistance sometimes means that you need to accept short-term architectural debt for third-party integrations to protect larger commercial outcomes.
Stepping out of the middle
Making alignment the easiest option introduces a risk: moral hazard. If you regularly make alignment easier by reallocating capacity or allowing manual workarounds, you risk teaching the organisation that you will absorb the cost if they hold out long enough.
That is why moving from vertical management to horizontal leadership means that you stop acting as the default escalation point. Instead, you need to expose the system’s constraints and force other departments to prioritise their roadmaps against those constraints. They keep control of their targets, but they have to own the trade-offs required to hit them.
Not every disagreement can be resolved through influence, so the lowest leader who owns both outcomes must decide what the company will sacrifice. You need to ensure the trade-off is explicit and the data-informed decision is made.
If the same teams repeatedly need intervention from senior leadership to reach alignment, the long-term answer probably is an organisational design change. In this case, you should focus on reviewing ownership, team boundaries or the architecture.
Following this approach, your authority comes from making system-level trade-offs explicit and securing collective commitment on what actually gets sacrificed.