There's a line that separates two ways of thinking about technology programs. Most organisations manage on the wrong side of it.
Above the line
Above the line is where business outcomes live.
Above the line questions:
- Why are we doing this?
- What business outcome changes if we succeed?
- What's the expected return on this investment?
- How does this connect to strategic priorities?
Below the line questions:
- Are we on schedule?
- Is scope being tracked?
- Are the reports being produced?
- Is the team at capacity?
Both sets of questions matter. The problem isn't asking below-the-line questions — it's asking only those.
Below the line
is where most consultants live. It's the world of delivery management — are we on schedule? Are we within budget? Did we follow the process? Is the team being productive? This work matters. But it's execution without direction. Manage a program solely from below the line, and technical milestones get hit while business value gets missed.
You can't get above-the-line results from below-the-line solutions
A program can be green across every RAG status. Every sprint delivered on time. Every deliverable signed off. And still generate zero measurable business value.
Signs you're managing below the line:
- Success is measured by RAID log hygiene, sprint completion, or on-time delivery
- Leadership asks "are we on track?" and the answer is velocity charts
- Nobody can articulate what business metric actually changes if this program succeeds
Signs you're above the line:
- Every steering committee starts with "what did we get for what we spent?"
- Scope decisions are made against a business outcome, not just a budget
- The program has a defined investment thesis — a measurable return it's expected to generate
Softwired leads from above the line.
I make digital and technology transformation happen below the line — the delivery, the execution, the technical work. That work is real, it matters, and I'm good at it. But I lead from above it.
Every piece of delivery stays anchored to a business outcome you can measure.
In practice, that means:
1. Investment thesis before scope.
Before I write a single line of scope, I define the return this program needs to generate. That return has to be specific and measurable. If I can't define it, the scope doesn't get written.
2. Above-the-line metrics before below-the-line tracking.
What business outcomes am I chasing before what delivery milestones am I hitting? The milestones are evidence of progress toward the outcome, not proof of it.
3. Steering committees that make decisions.
A steering committee should make business decisions, not receive status updates. Show Jira ticket tables at an executive meeting, and you're managing below the line.
4. Every deliverable anchored to an outcome.
Not to a feature. Not to a milestone. To something that moves a number your organisation cares about.
The practical test
Ask this about your current program:
What business metric will measurably change because of this program, and how will we know if it worked?
If you can answer that clearly — you're above the line.
If the answer is "we'll have delivered the platform" or "we'll have completed the implementation" — you're below it.
That's the work Softwired does — delivery that moves the number that matters.
