Steer
Money already spent gets no vote.
The second job begins
Funding committed the money. The investments are running. And this is precisely the moment when the gap between the portfolio as chosen and the portfolio as it actually behaves begins to open.
The gap is not a surprise. It is a structural feature of any complex set of investments running simultaneously through a shared organisation. The selection criteria assessed each investment on its own merits — its value, its strategic fit, its individual risk, its cost. They did not, and cannot, assess the investment as a member of a set: how it will interact with the others, what it will need from shared resources, which of its assumptions depend on something another investment is also depending on, what it is quietly blocking. The choosing was about which investments. Steer is about what happens when all of them are trying to run at once.
This is where the portfolio’s second job — making the chosen mix work together — becomes concrete. And it is where the method’s claim to do something useful, beyond the obvious discipline of choosing carefully, stands or falls.
What Steer is for
Steer is not a monitoring process. Monitoring — collecting status from running investments, summarising it upward, presenting a colour-coded dashboard to a governance forum — is something most portfolios already do, at considerable effort and with limited return. Monitoring asks: how are things going? The answer it receives is the answer the investment wants to give, which is the answer most likely to leave its funding undisturbed. The eighteen-month green status that turns red the day the investment is cancelled was not produced by a corrupt monitoring process; it was produced by a monitoring process that had no mechanism other than self-reporting.
Steer is not a monitoring process. It is a decision-forcing process. Its purpose is to surface the problems that no single investment owner can or will surface alone, and to produce decisions — not reports.
The distinction is not subtle. A monitoring process produces information. A Steer process produces choices: this team waits while that one gets the scarce resource; this dependency is unblocked by changing the sequence; this investment is paused because what it is blocking is more valuable; this duplication is eliminated by merging two workstreams. Information is an input to Steer. Decisions are its output. An investment that presents its problems in a Steer forum and receives only acknowledgement has not been steered. A problem acknowledged is not a problem resolved.
The anatomy of a Steer problem
The problems Steer exists to solve fall into a small set of categories, each with a distinct character and a distinct kind of resolution.
Dependencies
A dependency exists when one investment’s ability to proceed depends on an output, decision, or action from another investment or another part of the organisation. Dependencies are the most common source of delay in a running portfolio, and they are invisible to the individual investment owner: the owner of Investment A can see that A is waiting for something; they cannot see, from inside Investment A, why Investment B has not yet produced it, whether B has been reprioritised, or whether the decision that would unblock both of them is sitting in someone’s inbox waiting for a meeting that has not been scheduled.
Managing dependencies at the portfolio level means maintaining a live picture of what is waiting for what, across the whole set, and treating each significant dependency as a portfolio problem rather than a bilateral negotiation between the two teams involved. The bilateral negotiation is the default; it is slow, it escalates only when the teams have already exhausted their own options, and it produces a settlement based on the relative seniority of the sponsors rather than the relative value of the investments. Portfolio-level dependency management asks which resolution serves the whole mix best, and makes that the decision.
Scarce resource contention
Some resources are scarce across the portfolio: a specific technical capability, a subject-matter expert, a test environment, a regulatory specialist, a technology platform that can only support one major change at a time. When multiple investments need the same scarce resource simultaneously, the resource must go somewhere — and where it goes is a portfolio decision, not an individual investment’s decision.
The common failure is to leave this decision to the people who can see only their own piece of it: the resource is pulled in multiple directions, gives a little to each claimant, and contributes fully to none. The result is the dilution described in Chapter 1, now operating within the running portfolio rather than across the funded set. Steer resolves resource contention by making the competition visible — the resource-contention view shows which investments are competing for the same resources — and by making a clear, portfolio-level decision about the allocation. One investment gets the resource. The other waits, or is rescheduled, or is partially paused. The decision is uncomfortable and specific and necessary.
“Shared-resource contention resolved by the portfolio is uncomfortable for someone. Shared-resource contention not resolved by the portfolio is uncomfortable for everyone, indefinitely.”
Sequencing
Not every investment can run at full pace simultaneously, even if each is independently funded and staffed. Some create dependencies for others; some compete for the same window of organisational attention; some are building on foundations that another investment is laying. The optimal sequence for the running portfolio — which investments run at full pace in which period, which slow down to allow others to complete a prerequisite, which defer their peak resource use until the constraint has cleared — is not the same as the schedule each investment would choose for itself.
Sequencing decisions belong to the portfolio, not to the individual investment. An investment asked to slow down so that another can proceed faster is not being managed badly; it is being managed as part of a set. The Steer process owns the sequencing view — the picture of how the investments’ timelines interact — and makes the adjustments needed to keep the whole set moving at the pace the pool and its capacity can support.
Duplication
Two investments building the same thing is waste. Three investments each building a slightly different version of the same capability, in different parts of the organisation, because no one looked across the whole set, is the kind of waste that compounds: the three versions are incompatible, the organisation ends up running all three in production, and the integration problem arrives later as a crisis.
Duplication is almost never visible from inside either of the duplicating investments. Each owner has a legitimate need; each is building a legitimate solution to that need; neither can see that the other exists, or that the capabilities they are building will turn out to overlap. The Steer process finds duplication by looking across the whole set with a single view — the portfolio dashboard and the dependency map together show where workstreams are converging on similar territory — and resolves it before it hardens into a structural problem.
Resolving duplication rarely makes anyone happy in the short run. It means telling one investment — or both — to change what it is doing, to use what the other is building, to merge, or to stop. These are the conversations that no individual sponsor can initiate without appearing to attack a colleague’s programme. The portfolio forum is the right place to have them, precisely because it holds the mandate to look at the whole.
Blockers the investment cannot clear alone
Some of the problems a running investment encounters cannot be resolved by the investment itself. A decision that requires a stakeholder outside the investment’s sponsor chain; a dependency on a supplier relationship owned elsewhere in the organisation; a regulatory query that requires a response from the legal function that the investment’s programme manager cannot compel. These blockers are not failures of the investment — they are failures of the interfaces between the investment and its environment, and those interfaces are the portfolio’s to manage.
The decision and escalation log is the mechanism: a running record of the blockers that have been identified, who is responsible for resolving each one, and by when. Items on the log are not problems awaiting resolution; they are commitments to specific resolutions, owned by specific people, with specific dates. A blocker that has been on the log for three consecutive Steer cycles without progress has not been escalated — it has been catalogued. Cataloguing is not Steer.
Steer forces decisions
The thread running through all four problem categories is the same: each requires a decision that is uncomfortable in some dimension — who waits, who gets the resource, whose timeline changes, whose workstream is modified or stopped — and each decision is one that no individual investment owner can make alone, because the decision’s consequences fall on the whole set. This is the portfolio’s second job in its most operationally demanding form.
A Steer process that does not produce these decisions is not a Steer process. It is a status collection exercise — valuable, perhaps, as information, but not as portfolio management. The test of a well-run Steer process is not the quality of its dashboards. It is whether, when two investments need the same architect, the portfolio says clearly that Investment A gets the architect this quarter and Investment B waits — because A is on the critical path that unlocks B’s market — and whether that decision is implemented, not merely noted.
The measure of a Steer process is not the quality of its status pack. It is the number of decisions it produces, the speed with which those decisions are implemented, and whether the consequences are absorbed by the right investments rather than deferred until they become a crisis.
Producing decisions requires decision rights — clarity about who has the authority to make which calls — and decision rights require the operating model. Chapter 10 develops the full decision-rights picture. What matters here is the principle: Steer must have the authority to make the decisions it needs to make, or it degrades into a forum where problems are named and nobody acts.
Feeding hard truths to Review
Steer is where the optimism of selection first meets the friction of reality. Every investment was chosen on a view of its forward value and its delivery risk that was formed in advance of the work. As the work proceeds, that view is updated — sometimes positively, more often not — and the updated view belongs in the portfolio’s next re-decision, which is Review’s job.
Steer’s contribution to Review is the honest account of what is actually happening: which investments are progressing as expected, which are struggling, which have surfaced information that changes the assessment of their forward value, and which have blocked or been blocked in ways that have real cost implications. This is the hard-truths function, and it is structurally important that Steer, not the investment itself, is the primary source of it.
An investment asked to self-report to a Review forum has a structural incentive to report charitably. It has a sponsor whose commitment is attached to the investment’s success, a team whose work is being assessed, and a set of assumptions it was funded on that it has every reason to protect. Steer’s view is not self-reported; it is the portfolio’s view of the investment from outside, synthesised from the dependency map, the resource-contention picture, and the escalation log. When these two views diverge — when the investment’s self-report says “progressing well” and the Steer process says “blocked on three dependencies, consuming a scarce resource needed elsewhere, and six weeks behind the sequence it was funded on” — the portfolio has the information it needs, and Review can act on it.
The Steer toolkit
Four instruments support the Steer process. They do not replace judgement; they provide the visibility without which the judgements cannot be made.
The portfolio dashboard and health view is the at-a-glance picture of the running set: the investments, their status against the funding commitment, any flagged issues, and the overall health of the mix. It is the starting point for every Steer meeting. Its purpose is not to report that everything is fine — if everything is fine, the meeting can be short. Its purpose is to surface quickly the investments that need the Steer process’s attention.
The dependency map shows what is waiting for what, across the whole running set, with the critical-path implications of each dependency. It answers the question: if this dependency is not resolved by this date, which investments are affected, and how? Maintained as a live document rather than a one-time snapshot, it is the instrument that makes sequencing decisions discussable.
The decision and escalation log records every blocker, decision, and escalation that has emerged from the running portfolio: what the issue is, who is responsible for resolving it, by what date, and what happened. It is the accountability record of the Steer process. An issue on the log is a commitment, not an observation.
The resource-contention view shows where the portfolio’s scarce resources are currently allocated across the running set, and where contested demands for them exist. It makes the invisible visible: without it, each team knows only its own resource situation; with it, the portfolio can see the collision and decide who gets priority.
Steer at three settings
| Aspect | Lean | Managed | Enterprise |
|---|---|---|---|
| Steer forum | Regular check-in with the owner and key leads; can be brief and informal | A standing Steer meeting on the cadence, with representation from each running investment | A formal Steer forum with defined attendees and decision rights; may have sub-forums by portfolio tier |
| Dashboard | A shared list or board visible to the owner | A structured portfolio health view, updated before each Steer meeting | A governed dashboard, updated continuously, with defined health metrics and thresholds |
| Dependency map | The owner’s working knowledge, made visible when needed | A maintained dependency map, reviewed at each Steer meeting | A formal dependency register with impact analysis and critical-path tracking |
| Resource contention | Owner resolves directly, visible to all involved | A resource-contention view reviewed at the Steer meeting; decisions made in the meeting | A formal resource-allocation view; significant contention escalated to the governing board |
| Escalation log | A shared list of blockers and who is resolving them | A structured log reviewed at each Steer meeting, with owners and dates | A formal escalation register with SLA tracking for resolution |
At the Lean end, the failure mode is running Steer as a social update rather than a decision forum. When the portfolio is small enough that everyone knows everyone and the relationships are good, problems surface informally — which is fine — but the decisions are also made informally, which means they are sometimes not made at all, or made inconsistently, or made without the portfolio picture that would produce a better outcome. The discipline at Lean is to keep the decision moment real, even if the surrounding process is minimal: the resource goes somewhere specific, the dependency is unblocked by a specific action, the blocker is owned by a specific person with a specific date.
At the Enterprise end, the failure mode is the inverse: a Steer process so procedurally elaborate that it consumes more management attention than the problems it is solving, produces reports that take longer to prepare than to read, and escalates at a speed that makes its resolutions irrelevant by the time they arrive. The portfolio dashboard that takes three days to produce weekly is not a decision tool. Enterprise Steer needs the substance of every category above — visible dependencies, resolved contention, cleared blockers, sequenced work — at a tempo the organisation can actually respond to.
Steer does not end at a pre-determined point. It runs continuously while the portfolio runs, updating its views and producing its decisions as each cycle of the cadence arrives. What it is preparing for — at each cadence — is Review: the moment at which the whole running set is re-opened, re-valued, and re-decided. That is the next chapter.