From advice to experiment

We spend a lot of time in rooms where people are trying to improve the way work happens. Better conversations. Better decisions. Less thrash downstream.

It’s easy for that to stay at the level of principles. The slide deck version of reality.

So before writing anything about Agile Coaches and Discovery, we tried to do the thing we’re often encouraging others to do: treat it as an experiment. Go to the source. Notice patterns. Stay close to what’s actually happening.

We reached out to Agile Coaches and asked a simple question: how does Discovery work in your organisation, and what role do you realistically get to play in it?

Not a survey to “prove a point”. More a way to test whether the gap we’ve been sensing is real.  And if it is, what shape it takes across different contexts.

What came back was more consistent than we expected. Different organisations, different titles, similar tension: coaches are often close enough to feel the consequences of upstream decisions, but positioned too far downstream to influence them early.

Discovery can feel out of reach.

A lot of coaches described the same experience: Discovery is where direction gets set, but it isn’t a place they’re consistently invited into.

Not because anyone is trying to exclude them. More because Discovery tends to “belong” to whoever is already carrying it. In many organisations, that’s a small set of Product and UX people trying to do three jobs at once: make sense of customer input, align stakeholders, and keep delivery moving.

When that’s the reality, Discovery becomes fragile. It runs on individual stamina rather than a clear shape. And it quietly teaches everyone else a lesson: unless you’re in the core group, you’re not really part of the work until something is ready to build.

Coaches often come in later, once a direction has hardened into a plan, and are asked to help teams execute smoothly. Which creates a particular tension: being accountable for flow and outcomes, while having limited influence over the conditions that produced the work in the first place.

One coach put it plainly, from inside a highly regulated product environment:

“I’m spending more and more time on the interfaces between my department and the rest of the organisation.

We build highly regulated products — high complexity, long timelines from idea to something shippable — and Discovery/UX sits well outside my department.

Still, your point lands: when agile coaches can span Discovery and Delivery, there’s real value to harvest. I see that most clearly in organisations up to a few hundred people. Once you get to ~1000, silos form quickly and cross-cutting opportunities become rare.”

The gap shows up as rework, not drama

When coaches talked about Discovery being under-supported, they weren’t describing a philosophical problem. They were describing a cost.

The cost shows up later, when a team starts delivering and realises they’re answering questions that could have been answered earlier. Or when “requirements” arrive that are really unresolved decisions wearing a different outfit. Or when feasibility becomes a late-stage negotiation, instead of a constraint that shaped the thinking from the start.

This is the pattern underneath a lot of delivery pain:

Discovery is treated as informal work. Delivery is treated as “the real work.” So the organisation invests in execution hygiene downstream, while upstream work remains dependent on heroics, personal relationships, and whoever has time.

From the outside it can look like delivery is slow. From inside the system, it often looks like delivery is doing the wrong kind of work: too much clarification, too much backtracking, too much rebuilding shared understanding that never quite formed upstream.

If you’ve ever watched a team lose weeks to “small changes” that weren’t small at all, you’ve seen this gap in action.

What coaches do about it

Even when coaches aren’t formally “in” Discovery, many of them end up working on it anyway — just indirectly.

Not by taking over product work. More by trying to change the conditions around it: how decisions get made, how conversations are structured, how cross-functional input is included early enough to matter.

In the interviews, we kept seeing three broad patterns.

Some coaches act as bridge-builders. They create touchpoints between Product, UX, and Tech before things solidify. Sometimes that looks like coaching a Product Lead on how to run a Discovery session that can actually hold disagreement. Sometimes it’s as simple as making sure engineering is present while the problem is still being framed — not after a solution has already been chosen.

Others focus on capability-building. They look less at individual workshops and more at the organisational system: funding, cadence, decision forums, and who owns what. They’ll coach leaders to stop treating Discovery as “extra” and start treating it as work that needs time, clarity, and stable responsibilities.

And then there are the skeptics — often for good reason. They’ve seen Discovery turn into activity without decisions: lots of sessions, lots of artefacts, very little change in direction. Their caution isn’t a lack of ambition. It’s pattern recognition: without a decision-making spine, “more Discovery” can just mean “more meetings.”

None of these stances are right or wrong. They’re adaptive responses to the context coaches are operating inside.

This isn’t a facilitation problem

It’s tempting to treat this as a skills gap. To assume the answer is better workshops, sharper prompts, cleaner artefacts.

But what we heard points somewhere else.

The recurring issue isn’t that people don’t know how to facilitate Discovery. It’s that Discovery often doesn’t have enough structure around it for facilitation to stick. No protected capacity. No clear decision rights. No shared cadence that brings Product, UX, and Tech together early enough to shape the problem.

So the work gets done in fragments. A customer call here. A stakeholder conversation there. A late engineering “sanity check” once a direction is already emotionally committed to. The organisation then experiences the downstream effects as delivery churn — but the root cause sits upstream.

Several coaches described feeling stuck in this loop: teams get blamed for execution issues that are actually decision issues. And the fix becomes “be more agile in delivery,” when the harder conversation is about how the organisation makes choices before delivery begins.

If Discovery is where the big bets are made, then treating it as informal work is a structural decision — whether anyone intends it or not.

What we’re left wondering

One way to read all of this is as a role question: should Agile Coaches be more “upstream”?

But the coaches we spoke to weren’t asking for territory. They were pointing at a load-bearing part of the system that often has no stable home: cross-functional sense-making, decision hygiene, and the ability to hold uncertainty long enough to learn something real.

In some organisations, that work is funded and explicit. In others, it’s squeezed into the edges of already-full roles. And when it breaks, it shows up downstream as rework, frustration, and the familiar feeling of “we’re building, but we’re not aligned.”

So maybe the question isn’t whether coaches can contribute to Discovery.

It’s whether the organisation is willing to treat Discovery as real work — with the capacity, participation, and decision structures that make it possible.

A provocative question

What changes in your Discovery work if Agile Coaches and Engineers are in the room early enough to shape the question — not just validate a direction that’s already been chosen?

If you’re curious about the practical moves here, we’re hosting a webinar to dig in.