Software Delivery Trade-offs
- Myles Henaghan
- Nov 11
- 5 min read
Updated: Nov 12
If you’ve ever worked in an engineering environment where everything is a priority, you’ll already know that not only is nothing a priority. Over time, it leads to burned-out teams, frayed trust and services held together with human duct-tape.
In my experience, the problem usually isn’t effort; it’s direction. Strategy, when it exists, is more often half-finished, too abstract, or quietly buried under a new set of “urgent” initiatives. Everyone’s busy, few are aligned. A thousand well-meaning micro-decisions invisibly pulling in different directions.
Trade-offs form the backbone of your strategy. When that backbone's missing, people create their own versions. We have to decide what to protect, what to compromise, and what to ignore. Then....more often than not, chaos follows, but it’s polite chaos: jammed calendars, endless OKR/KPI debates, and the comforting illusion of outputs as progress.
The Hierarchy of Engineering Needs (HoEN) is how we surface those hidden trade-offs. It gives a clear snapshot of your delivery system and the forces acting on it - showing where culture has quietly taken the place of strategy. When strategy is vague (or “still in draft mode”), trade-off sliders give teams something to unblock decisions by showing where flexibility exists and where it doesn’t, making unspoken priorities visible.
HoEN - Flow Level
Before we can talk about trade-offs, we need to be clear on what’s actually being traded. Every organisation is juggling at least four competing forces; new value, reliability, culture, and governance.
Every team wants/needs all four, but in reality, we're constantly leaning one way or another. And that’s the point. Strategic decisions are not about finding balance, they're about making the tension intentional. Because if you don’t choose your trade-offs, your system will make them for you. Or as a colleague once put it, Value Creation vs Value Protection.
In the context of HoEN, the flow level represents:
The capability to enjoy the high throughput of things of new value while building the trust of customers, users and stakeholders in services already delivered.
Sounds like a fluffy LinkedIn comment right? To any seasoned Engineering Leader, statements like these wear a little thin, and we agree. In reality, there are four recurring dimensions for high-performing software teams:
Delivering small batches of high-quality work frequently. Hypothesis-driven, super-fast feedback. Learning focused.
Proactive management where service health trends. Meeting and exceeding expectations for speed, accuracy, availability.
Information flows freely. Curiosity over blame. Quicker, more informed decisions. Based on Ron Westrum's organisational culture research.
Consistency, compliance, standardisation of cross-cutting practices.
Four must-haves. Pick any two (for now).
Trade-off Sliders - truth serum for priorities 💉
When applying HoEN we use three of the flow needs as default trade-off sliders - like the home stereos with presets for Rock, Classical, Jazz etc. Sometimes a delivery system has been set to startup Rock mode when, now that the stakes are higher, they are better off changing to Jazz if not Classical in some areas.
To optimise a delivery system, we ask leaders to express their level of flexibility for each dimension. We help teams through this with trade-off sliders or investment trade-offs
E.g: Would you defer standardisation to deliver new value faster this [quarter/year]?
When/where would you chose more reliability over feature delivery?
Trade-off Sliders instructions
Limit of 4 Sliders
All must be positioned
No two sliders at same position
Consider next [12] months
We've found sliders to be great to give direction to teams. They suck out of people's minds what are the true conflicting agendas, and which ones are truly more fixed vs flexible relative to each other. This in turn breaks prioritisation deadlocks (everything is never an equal priority), and allows the pursuit of all dimensions while staying aligned on the how to make the inevitable big and small decisions to follow.
Using trade-offs for stack-ranking
With trade-offs agreed, it is then much easier to start ranking one supporting need or capability above another.
E.g. A scaling team with some established and emerging products. Capacity constrained, they need to hire more, use off-shore teams, and of course, do more with AI! They have a diverse collection of components and tooling.
Trade-offs: Strong push on standardisation, more flexible on throughput of individual teams vs overall reliability / quality of service.
Example HoEN Constraints identified
Constraint | Symptom | Good Idea |
Deployment Solutions | Fragmented inconsistent pipelines | Codify a standard pipeline definition for our common component types |
Local Dev & IDE | Days to get new starters working | Have each team codify local dev setup scripts to work atop standard machining build |
APIs & SDKs | No standard API patterns | Move all APIs to definition language x, add real and mock clients for internal APIs |
Technical Capability | Teams split on frontend-backend | Formalise the emerging shared UI components library for easier adoption with 'back end' teams |
They all look like good ideas, right? If we were to choose only [one], which would it be and why?
For prioritisation calls, we use the tradeoffs to now convert into more traditional weightings & scoring (similar to investment buckets).
From Sliders to Scores:
Score initiatives 0–10 for each dimension. Have each initiative sponsor explain / justify how much the initiative contributes to each dimension.
Give each dimension a weighting (sum = 100) to reflect the trade-offs.
Give the initiatives a weighted score - and discuss again. True benefits and assumptions will be clearer - similar to T-shirt sizing of backlog items.
Discuss and revisit assumptions and weights. Up to three rounds normally finds the consensus on the impact-ranking of each initiative.
The stack-ranking exercise helps with two other challenges in software teams - show people clearly why the answer is no or not now on their preferred initiative, reinforce the three truths we find in all software delivery systems:
Always too much to do.
Everything is always breaking.
Importance is temporary.
What about a culture trade-off?
Culture is much more output and outcome than an input. Fundamentally, we see engineering culture as something that manifests itself over time. It is influenced greatly by the choices people make and see being made on a daily and annual basis.
What gets measured?
What gets delayed?
What gets protected?
Symbiotically, when teams start openly using tactics like trade-offs and balanced scorecards in decisions and prioritisation, it has a direct impact on culture. This impact comes from modelling systems-thinking behaviour and removing as much ambiguity as possible on the forces pushing and pulling the organisation.
Trade-offs become fingerprints of your organisation’s intent.
Every choice (e.g. what to automate, standardise, or delay?) sends a signal about what you value most right now. Over time, those signals become your culture. If you're feeling stuck chasing the illusion of balance, switch instead to documenting the tension.
Harmony does not exist for Engineering systems. They are continually adapting to external and internal forces. So forget about balancing things for more than several months.
Instead the people operating in software delivery need conscious tension to pull tight in the right directions.
HoEN gives you the language, the sliders, and the shared understanding to make those tensions visible. Use it to tune your system on purpose and intent - don't just hope it sounds right. 🎛️
Comments