The Lighthouse Team Trap

It begins well, and that is the problem. A sponsor wants to demonstrate that a new way of working can succeed in this organisation, against the widely held view that it cannot. So a team is assembled — good people, hand-picked, often the best available — given a visible piece of work, and shielded. The change advisory board will not apply to them. They get their own cloud environment rather than waiting in the platform queue. Their funding is protected from the quarterly reallocation. A senior sponsor takes personal responsibility for unblocking anything that blocks them, usually within the day.

Six months later the team has shipped something genuinely impressive, on a cadence nobody in the organisation has seen before, and the sponsor presents the results. The conclusion drawn is that the new way of working is proven and should now be rolled out.

It does not roll out. Within a year the phrase in circulation is that the organisation tried agile and it did not work here — a phrase that will be repeated for years by people who were not present, and which will be the first obstacle faced by whoever attempts the next change. The lighthouse team has not only failed to transfer its success; it has actively degraded the conditions for future attempts.

This is worth understanding in detail, because the lighthouse is one of the few antipatterns that is created deliberately, by capable people, with good intentions, on the advice of consultants who should know better.

How to recognise it

You are looking at a lighthouse team, rather than a legitimate pilot, when the exemptions are doing the work.

It has a list of things that do not apply to it. Not one or two accommodations, but a standing set: different governance, different funding treatment, different architecture review, different release approval, different hiring rules. If someone can enumerate the ways this team is exempt, that list is the mechanism of its results.

It was staffed by selection rather than by structure. The strongest engineers, the best product person, a senior coach, and often someone who has done this before at another company. The team is not representative of any team the approach will later be applied to.

It has a direct line to a senior sponsor who clears obstacles personally. This is usually presented as leadership support. It is more accurately described as a single individual substituting their own authority for organisational process, which works and does not scale, because that person has a finite number of hours and a finite amount of political capital.

It is working on something adjacent rather than central. A greenfield application, a new customer-facing product, a standalone service — something with few dependencies on the legacy estate. Not because that was the most valuable work, but because it was the work that could be done without negotiating with anyone.

Nobody else's experience has changed. The decisive test. Six months in, ask a team outside the pilot whether anything about their working life is different. If the answer is that they have heard the pilot is going well, the pilot has been running as an isolated system and has produced no organisational learning at all.

Its metrics are reported in isolation. Deployment frequency and cycle time for the lighthouse team, presented without the comparable numbers for the estate, and without any account of what the exemptions cost the rest of the organisation.

Why organisations do it

The lighthouse is not a mistake born of ignorance. It is a rational response to three real pressures, and anyone who has led change in a large organisation will recognise all three.

The sponsor needs evidence before they can spend political capital. Asking a board to change funding models, procurement, release governance and architecture review on the strength of an argument is not a winnable request. Asking on the strength of a demonstrated result is. So the sponsor needs a result quickly, and the fastest route to a result is to remove the constraints rather than to renegotiate them. This is genuinely sensible reasoning; it simply produces evidence about the wrong thing.

Changing the constraints is slow, and slow programmes get cancelled. Reforming a change advisory board, rebuilding a deployment pipeline or moving from project funding to product funding takes quarters and shows nothing for the first several months. A pilot shows something in eight weeks. Organisations reward visible early progress, and the lighthouse is the shape that delivers it.

Protecting the team is genuinely kind. Sponsors who have watched previous initiatives get ground down by governance want to give this one a fighting chance. Exempting the team feels like removing unfair obstacles, and in a narrow sense it is. The intention is to let the approach be judged on its merits rather than on its ability to survive bureaucracy.

The consultancy incentive points the same way. An external partner engaged to demonstrate value has a strong interest in a fast, visible success and a weaker interest in whether it generalises, particularly if the follow-on engagement is the rollout. This is not usually cynical; it is the natural consequence of contracting for a proof of concept rather than for a change in the system.

None of these are stupid. They are all locally correct, and together they produce a predictable failure.

Why the success cannot transfer

The experiment had no control condition, and more importantly it did not test the hypothesis anyone actually cared about.

The question the organisation needs answered is whether this way of working can succeed under its real constraints: its funding model, its release path, its risk governance, its architecture, its available people. The lighthouse team answered a different question — whether a hand-picked team with no constraints can deliver well — to which the answer was already known and was never in dispute.

So when the rollout begins, every removed obstacle returns at once. The second wave of teams is staffed from the actual talent distribution rather than the top of it. They are working on the legacy estate, where a change touches four systems and three other teams. They are subject to the change advisory board, the shared environment queue, the quarterly funding reallocation and the architecture gate. The sponsor who personally cleared blockers for one team cannot do so for thirty, and their attention has moved on to the next initiative anyway.

These teams then fail to reproduce the results, and they fail publicly, having been told the approach was proven. At which point the organisation has to explain the discrepancy, and it reaches for the explanation that requires the fewest people to be wrong.

There is a subtler harm. The exemptions were not free. Somebody else waited longer in the platform queue because the pilot jumped it. Somebody's budget absorbed the reallocation the pilot was protected from. The risk team carried an exception they were uncomfortable with. These costs were borne by people who received none of the credit, and they remember.

What it costs

The organisation learns nothing it can use. Six months and a substantial investment produce a single data point about a condition that will never recur. Every genuine question — can the release path support this, will the risk function accept a different assurance model, can a typical team do this — is exactly as open as it was at the start.

The next attempt inherits a poisoned phrase. "We tried agile and it did not work here" is enormously durable. It survives the departure of everyone involved, gets repeated in interviews and steering committees, and functions as a complete argument requiring no evidence. The most expensive product of a failed lighthouse is this sentence.

The pilot team is left stranded. They spent six months working in a way they found better, and are now returned to the standard environment, or dispersed to seed other teams where they have no exemptions and no authority. Attrition among exactly the people you least want to lose reliably follows. Being shown a better way of working and then having it withdrawn is more demoralising than never having seen it.

Resistance hardens into something justified. People who objected early — the risk officer, the platform lead, the finance partner whose budget was raided — were overruled rather than engaged, and were then proved right when the rollout failed. They are now both more powerful and more certain. Their objection was information about a real constraint, which is the argument in resistance-is-information, and it was treated as an obstacle instead.

The real constraints are still there, now with less time and credibility available. The deployment pipeline is exactly as slow. The funding model is unchanged. But the appetite for another programme is gone, and the budget has been spent proving something that was not in question.

What to do instead: a thin slice through the real gates

The alternative is not to abandon piloting. It is to change what the pilot is testing. Instead of protecting a team from the system, push a small piece of work all the way through the system and use it to find out precisely where the system breaks.

Take a real change on the real estate. Something small, genuinely valuable, and touching the parts of the architecture that everything touches — not a greenfield side project. The value of the exercise comes from the friction, so choose work that will encounter it.

Go through every gate, deliberately, and instrument each one. The change advisory board, the architecture review, the security assessment, the environment request, the release approval. Do not seek exemptions. Record for each gate how long it took, what it asked for, what it actually caught, and what it would take for it to be satisfied by evidence produced automatically rather than by a document and a meeting.

Bring the gate owners in as participants. Invite the risk officer to watch a deployment. Ask the architecture reviewer what assurance they would accept in place of the review. Most gate owners know their control is crude and are open to a better one; what they will not accept is having it removed without a replacement. Treated as designers of the new control rather than as obstacles to it, they become the most effective advocates you have, because their endorsement carries weight with exactly the audience that discounts yours.

Fix one constraint properly, for everyone, rather than routing around it for one team. The output of the slice is a ranked list of constraints with measured costs. Take the top one and remove it across the estate. Every team gets slightly faster. That is a result that transfers by construction, because it was never local.

Change what you report. Do not report the slice team's cycle time. Report the constraint map: here are the eleven gates a change passes, here is the time and value of each, here are the three we are removing and what replaces them. This is a much less exciting presentation and a far more useful one, and it keeps the conversation on the system rather than on a team.

Lighthouse pilot	Thin slice through the gates
Team is exempted from constraints	Team goes through every constraint
Staffed with hand-picked people	Staffed with a normal team
Greenfield, low dependency	Real estate, high dependency
Tests whether good people can deliver	Tests whether the system permits delivery
Output is a success story	Output is a ranked, costed constraint map
Gate owners are bypassed	Gate owners co-design the replacement
Result is local and does not transfer	Result is systemic and transfers by default

If you already have a lighthouse

Most people reading this are not designing a pilot; they are partway through one. The situation is recoverable if you act before the rollout is announced.

Start by writing down every exemption the team currently holds, honestly and in full. This list is the real finding of the pilot, and it is more valuable than anything in the results deck. Each item is a constraint that would have prevented the result, which makes it a prioritised work queue for the organisation.

Then change what the pilot is for while it is still running. Take the next piece of work and put it through one of the gates the team has been skipping, and treat the friction as the deliverable. You will lose some of the velocity story and gain the only evidence that matters.

Reframe the reporting before someone else frames it for you. The message is not that the new way works; it is that here are the specific things that had to be suspended for it to work, here is what each costs the organisation every day, and here is the order in which we propose to fix them. This is defensible, it is true, and it does not set up the failure that follows a proof claim.

Finally, do not disperse the team into a rollout as individual evangelists. People carrying a way of working into an environment that does not support it, without authority to change that environment, burn out and leave. Keep them together, aim them at the constraint list, and let them do the platform and governance work that makes the second wave possible.

What to do on Monday

Write the exemption list for whatever pilot your organisation is currently running — and if you are told there are no exemptions, ask the team directly rather than the sponsor. Teams are usually entirely candid about which rules do not apply to them.

Take the top item on that list and find out what it would cost to remove it for everyone. Not to grant another exemption; to fix it. Get a rough number and a named owner. That single line item is more useful to your organisation than another quarter of pilot metrics.

Then go and ask one team outside the pilot whether anything about their working life has changed in the last six months. Their answer tells you what your transformation has actually delivered so far, and it is the number you should be reporting.