Coaching above team level is the work of changing how an organisation funds, cuts and coordinates teams. The skills are durable and the dedicated job title is contested: many organisations have cut coaching headcount, and the roles that remain sit inside large multi-team programmes.
Assumes you know: Having worked inside a delivery team long enough to have watched a plan fail for structural reasons, Knowing what Scrum and Kanban prescribe, at the level of the source documents, Comfort doing arithmetic on dates, counts and percentiles without a tool
Overview
What this area actually covers
Agile coaching, in the sense this section uses the phrase, is the work that
starts where a single team's practice stops. A team can run excellent
retrospectives, forecast honestly and still take five months to put a change in
front of a customer, because the delay lives in the queue in front of its board,
in the two other teams whose code it needs, in an approval gate nobody owns and
in a funding cycle that fixed the scope before anything was learned. This area is
about that layer: how many teams contributing to one product coordinate, how the
structures around them are changed, and what a person with no positional
authority can actually do about either.
Three activities sit inside it and are worth naming separately, because a job
advert will use one word for all three. The first is coaching in the strict
sense — leaving the answer with the person who owns the problem, working on how
teams, managers and executives make decisions rather than on the decisions
themselves. The second is scaling: the mechanics by which five or fifty teams
share a cadence, an ordered backlog and an integration point, which is where
SAFe, LeSS, Nexus and Scrum@Scale live. The third is organisational change —
funding models, intake paths, team boundaries, incentives and reporting lines —
which is where the durable improvements actually come from and where a coach's
access is usually weakest.
The boundary with adjacent areas is worth drawing sharply, because it is the
commonest source of a wasted engagement. Scrum's own mechanics — the events, the
artefacts, the accountabilities, how to run a useful retrospective — belong to
the Agile, Scrum and Delivery section and are assumed here rather than
re-explained. Owning dates, budgets and a cross-team plan is delivery or
programme management, which shares vocabulary with coaching and differs
completely in accountability. Deciding which teams should exist and what each one
owns is architecture and organisational design; a coach influences it and does
not own it. And the technical capability that makes small releases possible —
trunk-based development, contract testing, deployment automation — is engineering
work that no amount of coordination substitutes for. A coach who cannot say which
of those four a problem belongs to will spend a year improving meetings.
What gets wrongly bundled in is mostly certification content. A two-day course on
a framework's ceremony inventory is not this subject, and neither is the
facilitation toolkit — the ice-breaker, the dot vote, the timeline retrospective
— useful though those are. Those are technique. The subject is diagnosis: given a
slow programme, working out whether the constraint is practice, coupling,
boundaries, funding or measurement, and being honest about which of them you have
been given permission to touch.
This section has one subsection, and it carries the whole of the interview
material because that is how the questions arrive in practice — not as "tell me
about coaching" but as a described mess with several teams in it.
Subsection
What it is for
Scaled Agile
SAFe and LeSS described accurately, cross-team dependency work, facilitation at programme scale, and the measurement that tells you whether a rollout changed anything
Scaled Agile covers four things that arrive together in real interviews. It
covers the frameworks mechanically: what a release train is, what a planning
increment buys and what it costs, what LeSS removes and why that demands more of
an organisation rather than less, and where Nexus, Scrum@Scale and Team
Topologies sit relative to both. It covers dependency work — not the register and
the escalation path, which are administration, but the ladder of options from
reserving capacity through contribution rights to redrawing a boundary, and which
of those a coach can realistically reach. It covers facilitation at a scale where
technique stops being cosmetic: a room of a hundred people planning a quarter, a
programme retrospective whose items have no team that can own them, a system demo
that gets cancelled precisely because it is the event most likely to produce bad
news. And it covers measurement, which is where most candidates are weakest and
where interviewers probe hardest, because a rollout reported entirely in teams
trained and boards migrated has been designed so that nothing can come back
negative.
It exists as a single subsection rather than four because the questions do not
separate. Asked how you would measure whether a scaling rollout is working, the
answer immediately requires a view on what the framework was supposed to change,
which requires a view on where the elapsed time currently goes, which is a
dependency question. Open it expecting scenarios: a team that refuses the
rollout, two teams on incompatible cadences, a sponsor six months in who wants to
know whether the money bought anything.
Where it sits in a real business
Coaching at this level sits between a funding decision and a delivery capability,
and its subject is the distance between them. Money arrives in an organisation
attached to something: an annual project budget with a scope agreed in a business
case, a regulatory deadline, a board commitment, a customer contract with dates
in it. That commitment then has to become work done by teams whose whole method
assumes the scope will change as they learn. Nearly every dysfunction this area
studies is a symptom of that mismatch being managed by process rather than
resolved.
Follow one customer-visible change through a large organisation and the shape
becomes obvious. A request enters through an intake path — a committee, a demand
board, a product council — which meets on a cycle and therefore imposes a floor
on lead time that no team practice can lower. It is sized, funded and admitted to
a programme. It is decomposed across teams, which is where the coupling shows: if
the teams are cut by technical layer, one customer-visible change needs a
front-end team, a services team and a data team, and each of those has its own
priority order set by someone else. It waits. It integrates, usually later than
anyone planned. It passes a change-approval gate. Eventually it is released, and
only then does anyone learn whether it was worth building.
Loading diagram…
The thing to look at is how much of that path a team can influence. Boxes four
and five are the only ones inside a team's reach, and they are usually the
smallest share of the elapsed time; boxes two, three and seven belong to
policies, and box one to an organisational habit. That distribution is the reason
this area is about organisational change rather than about practice — and the
reason a coaching engagement with no access to the people who own policy produces
better meetings and an unchanged lead time.
Where the money actually moves is worth stating plainly. An organisation buys
coaching for one of three reasons, and they behave very differently. Some buy it
because a programme is late and visible, in which case the sponsor wants the date
and coaching is what they were sold; some buy it as part of a framework rollout
with a budget, a plan and a certification target, in which case the measures are
adoption measures and the engagement will be judged on them; and a few buy it
because a genuinely curious executive wants to change how the organisation makes
decisions, which is rarer, harder and the only version where the work described
in this section is fully possible. Finding out which of the three you are in is
the first week's job.
Who does this work
The titles in this space are unusually unreliable, so it helps to describe the
jobs and then attach the labels loosely.
Role
What the day is
Who they answer to
Accountable for dates
Scrum Master
One or two teams, facilitation and impediments
Delivery or engineering lead
No
Agile Coach
Several teams and their managers, practice and diagnosis
Programme or transformation lead
Usually not
Enterprise Agile Coach
Executives, policy, funding and structure
A senior sponsor
No
Release Train Engineer
Facilitating one train of five to twelve teams
Programme management
In practice, partly
Delivery or Programme Manager
Plan, budget, external dependencies, reporting
Programme or business owner
Yes
Engineering Manager
People, capability, and increasingly the events too
Engineering leadership
Shared
Transformation Lead
The rollout itself as a programme of work
An executive sponsor
For the rollout
The advert that says "Agile Coach" may be any of the middle four. One is a
genuine coaching role with no delivery accountability; one is a scrum master
across several teams at a higher band; one is a delivery manager whose
organisation prefers a softer word; and one is a framework rollout specialist
funded by a transformation budget. They have different daily work, different
measures and different politics, and accepting one while expecting another is the
commonest career mistake in the field. Two questions settle it early, and both
should be asked in their words rather than yours: who is accountable for the
dates, and what am I measured on.
What none of those titles carries is the ability to change a policy, and the
route from noticing one to changing it is the shape of most real weeks.
Loading diagram…
The interesting exchange is the fourth one, where the manager agrees and cannot
act. Nothing in a coach's toolkit resolves that, and the final question is the
one the engagement actually turns on — which is why access to a sponsor who owns
budget matters more than any facilitation technique.
A day in the genuine version is mostly conversations, and less of it is with
teams than newcomers expect. A morning might be one coaching conversation with a
scrum master who cannot get a straight answer out of a platform team, an hour
tracing five delivered items end to end to find out where the elapsed time
actually went, a difficult meeting with a manager whose reporting habit is
teaching four teams that instrumenting themselves is dangerous, and a paper for a
sponsor that says the honest thing about what six months has and has not changed.
Almost none of it produces an artefact anyone can point to, which matters more
than it sounds — the role has no natural evidence of its own contribution, and
the practitioners who last are the ones who keep a written record of what each
removed impediment was costing before it went.
Demand, adoption and how that is changing
This is the part of the page most likely to be unwelcome, so it is worth being
direct. Demand for the dedicated agile coaching job is genuinely contested and
has contracted in a number of organisations. Cost pressure from 2022 onward fell
hardest on roles whose contribution to output was difficult to evidence, and a
coach working above team level is close to the definition of that: the benefit is
diffuse, delayed and shared with everyone who was also present. Several large
employers eliminated their agile-role populations outright rather than trimming
them, which is a signal about how the role was valued rather than about how many
people were needed. Anyone considering this as a career should assume the title
is cyclical and that the first cut in a downturn lands here.
Three further forces are worth understanding, because they change what remains
rather than only how much. The work was absorbed rather than deleted: engineering
managers, tech leads and product managers now run the events and hold the
improvement conversations themselves, and that is often a better arrangement,
since the person facilitating also has the authority to act on what surfaces. The
credential became cheap — when a short course produces a certificate, the
certificate stops distinguishing candidates, and interviewers respond by probing
judgement instead. And a decade of framework rollouts produced enough sponsors
who have seen one fail that "we are adopting a scaling framework" is now
frequently met with a request for evidence, which is progress and also makes the
selling harder.
What has held up is specific and worth naming. Large multi-team programmes in
regulated industries still coordinate genuinely hard work across many teams, and
somebody has to do it; those roles are often titled Release Train Engineer or
programme lead rather than coach. Consultancies continue to sell transformation
work, with the politics that implies. And the skills — diagnosis, facilitation
at scale, flow measurement, dependency reduction, having a difficult conversation
with a sponsor — are in demand everywhere and are increasingly expected of people
whose title is something else. That is the honest shape of the market: a strong
second capability attached to engineering, product or delivery credibility, and a
fragile only capability.
What makes it hard
The first difficulty is that the interventions that work require authority the
role does not have. A coach can see that the funding model makes iterative
delivery impossible in principle, that the intake committee sets the floor on lead
time, that teams cut by layer guarantee four-way coordination on every feature.
None of those is changeable by facilitation. Influence is the only instrument,
it works slowly, and it works through people whose own position is often what the
change would remove. This is not a complaint about organisations being difficult;
it is the actual content of the job, and a candidate who describes it as a
communication problem has not done it.
Second, the structural fix and the survivable fix are usually different things,
and choosing between them is a judgement rather than a technique.
Loading diagram…
The edge worth following is the one from the coordination box to the last one. A
well-run coordination mechanism makes a structural problem comfortable, and
comfortable problems do not get fixed — so the honest test of a scaling framework
used as a transition is whether the share of work needing another team falls year
on year. If it does not, the framework has become the permanent arrangement, and
that is a defensible choice only if somebody has chosen it deliberately.
Third, measurement in this area is subtle in a way that catches out people who
are good at it at team level. Percentiles do not average, so four teams each
reporting an eighty-fifth percentile of eight days do not give a programme
percentile of eight days. Worse, the programme's item is not the team's item: a
customer request crossing three teams accumulates its waiting time in the gaps
between them, which belong to no team's measure and no team's accountability, so
every dashboard can be healthy while the organisation is slow. A coach who cannot
do that arithmetic out loud will be handed six months of green adoption metrics
and have nothing to say about them.
Fourth, the pressure on the coaching stance is constant and mostly invisible.
Leaving the answer with the person who owns the problem is slower, uncomfortable
for everyone in the room, and reads to an impatient stakeholder as the coach not
contributing — which is why coaches abandon it under pressure and become the
team's most senior task-assigner. Holding it requires somebody senior to have
agreed in advance that your value is not measured in decisions made this week,
and that is a conversation to have at the start rather than at the first
escalation.
Finally, and least often said, the role attracts people who want to help and
punishes them for it. Being liked by every team after six months usually means
the uncomfortable habits were left alone: the retrospective with no actions, the
estimate nobody believes, the dependency everyone has stopped mentioning. The
work exists to change something, and changing something is uncomfortable for
somebody.
Why study it
Study this if you already lead across teams and the parts that hurt are
structural. If you are an engineering manager, a tech lead over several teams, a
delivery manager or a programme lead, the material here is directly load-bearing:
knowing why coordination cost grows faster than team count, which measures
survive being made targets, what a planning event is actually for, and how to
argue for contribution rights instead of another weekly forum. None of it is
taught anywhere in an engineering career and all of it comes up.
Study it if you are heading into an organisation running a scaling framework and
want to be useful inside it rather than sceptical about it. Describing SAFe's
mechanism accurately, including what its quarterly batch costs, is a far stronger
position than either defending it as doctrine or dismissing it as not really
agile — and given who is hiring, the organisation is quite likely to be running
it.
Study it if you are already a scrum master and want the next thing to be a real
step rather than a title change. The step is diagnosis and organisational
literacy, not another certificate, and the interviews for the roles that remain
are scenario-driven precisely because the certificates stopped distinguishing
anyone.
Do not pursue this as an entry route into technology. The certification industry
markets coaching as an accessible way in, and it is one of the worst available:
the market for a certified beginner with no delivery track record is thin, the
roles that exist increasingly go to people with engineering, product or delivery
credibility, and the title is the first one cut when budgets tighten. Do not
pursue it if you want work whose contribution is legible — this is the wrong
field for anyone who needs to point at something they made. And do not pursue it
if what you actually want is authority over delivery; that job exists, it is
called programme or delivery management, and going after it directly is faster
and more honest than approaching it through coaching.
Your first hour
Do not read a framework. Take a programme or team you know and trace five
recently delivered customer-visible changes from the moment someone asked for
them to the moment a customer had them, marking every interval where the item was
waiting rather than being worked on. Use whatever evidence exists — ticket
timestamps, pull request dates, deployment logs, release notes — and accept that
the numbers will be rough.
ITEM TRACE - five delivered changes, request to production
id requested released elapsed worked waiting longest wait
---- ---------- --------- ------- ------- -------- ---------------------
A-14 02 Mar 11 Apr 40d 9d 31d 19d in platform queue
A-17 09 Mar 02 May 54d 12d 42d 23d awaiting intake
A-22 16 Mar 24 Apr 39d 8d 31d 17d in platform queue
A-29 30 Mar 19 Jun 81d 14d 67d 34d change approval
A-31 06 Apr 15 May 39d 11d 28d 16d in platform queue
worked share of elapsed: 54 of 253 days = 21%
same wait three times: platform queue, 16-19 days, every time
Then write four sentences: what share of the elapsed time was waiting, which
single wait appears most often, who owns the thing that causes it, and what would
have to change for it to be shorter. That page is the artefact, and it is roughly
what a competent coach produces in a first fortnight — it is also a better
interview answer than any framework recital, because it is specific and someone
can check it.
If you have no programme to trace, do it from memory on one you were part of. The
recall will be poor and it does not matter; the value is in noticing which
intervals you cannot account for, because those are the parts of the delivery
path you have never actually looked at.
What this is not
It is not Scrum with more teams. The events scale badly and the structures scale
worse, and the questions that dominate at this level — how work is funded, where
team boundaries sit, which approvals still exist, whether the measures are honest
— are not addressed by any team-level framework. Someone who arrives at a
multi-team programme with only Scrum has the wrong toolkit rather than an
incomplete one.
It is not framework expertise. Being able to recite a framework's roles,
ceremonies and artefacts is the screening round, and it settles nothing, because
the material is public and everyone has the certificate. Framework
fundamentalism — treating the prescription as the argument, being unable to say
what a practice is for without naming its source — actively costs credibility
with engineering audiences, and it costs the ability to adapt a practice to a
context it does not fit, which is most contexts.
It is not a route to authority. A coach recommends and does not decide, and the
recommendations that matter most concern things owned by people who did not hire
them. Any version of this role that quietly acquires delivery accountability has
become a different job, and pretending otherwise is how coaches end up owning a
date they cannot influence.
It is not therapy, and it is not the professional coaching discipline either,
though it borrows genuinely useful technique from it. The subject here is an
organisation's structures and flow of work, and a practitioner whose entire
repertoire is questions and reflection will produce a well-facilitated
conversation about a problem nobody in the room has the authority to solve.
And it is not a guaranteed career. This page would be less useful if it pretended
the title were safe. The capability is durable, transfers into engineering
management, delivery and product, and is worth having; the job market for the
standalone title is narrower than the training industry suggests, and anyone
entering it should plan for the version of their career where the title
disappears and the skills do not.
The frameworks administer dependencies rather than removing them, so the only
honest measure of a scaling rollout is whether the organisation needs less of it
each year.