Context and the cost of moving fast without it.

Here is an interesting short of British sitcom that I came across.

(Summary if you haven’t watched it: Two engineers follow a blueprint and build a well with a light at the bottom, only to realise at the end they were supposed to build a lighthouse.)

Agile has given us speed. AI is giving us more of it. But speed is only valuable when you are pointed in the right direction. And in my experience, the question of direction gets assumed far more often than it gets verified.

I have seen this play out twice, in very different ways, and the contrast still stays with me.

We were two years into what would become a three and a half year project. High paced, long running, the kind where context lives in people’s heads as much as in documents.

A team lead moved on and someone new joined in their place. We did what we usually do, onboarded them with the business context, what we had achieved, what we were working towards, the upcoming release plan. Thorough by most standards.

A few days later we were in sprint planning. Mid discussion, the new joiner stopped and asked “But… why are we doing this story this way? I can see the business goal but why this approach?”

I had done the homework. I had a workflow shared and signed off by all stakeholders. But homework and perspective are not the same thing.

What followed was a short divergence. Slightly uncomfortable at first. But we ended with suggestions that were not only technically cleaner but also better for the end user. We held a short follow up, estimated both the original scope and the new approach, and took it to the client with our analysis. As expected users approved it.

We saved time, reduced tech debt, and shipped something better. All because someone new enough to question the obvious did exactly that.

The blueprint was right. It just needed someone willing to turn it around and look again.

A different project, a similar pattern, but this time the cost was harder to see coming.

We brought in a specialist temporarily to build a POC for a technically complex piece of work. The intent was clear internally, build it mindfully enough that it could scale up and be used by the core team in the actual product without starting from zero. We kick started the POC with close deadlines. The onboarding discussion was brief. We wanted to start ASAP. The POC was ready on time. The client approved the full module. It felt like a big win.

Then integration started. What had looked clean in isolation quickly unravelled. What was built to impress had not been built to scale. We ended up redeveloping everything.

The well had a beautiful light at the bottom. It just wasn’t a lighthouse.

Looking at both stories, the easy conclusion is that context wasn’t shared. But that’s only half the picture. The context existed in both cases. What was missing was simple : The willingness to pause and ask why.

In retrospect, in broader scale across my experience I realise it is not an information problem. It is a culture problem. And it shows up not in your onboarding documents or sprint ceremonies but in the moment someone asks “why are we doing it this way” and the room either leans in or moves on.

Agile has shortened the feedback loop. But if your sprint reviews are demonstrating progress rather than validating direction, you’re just digging wells faster. Hoping someone else will point it out.

And now we have AI in the mix. Development speed is increasing at a pace we haven’t seen before. AI doesn’t pause to ask why. It executes, generates, and ships. Which means if the blueprint is upside down, we will know later, at greater cost, and with a much deeper well to climb out of.

Next time you are in a planning discussion, don’t just ask what. Ask why. And whether there is a better way.

We Thought We Were Building a Lighthouse. We Built a Well. was originally published in Technogise on Medium, where people are continuing the conversation by highlighting and responding to this story.