Make Better Decisions With Context

Letting AI address the cost of knowledge transfer and adapting to new ways of building software.

One of the most stressful parts of leadership is making decisions with limited context. Hesitation is rarely an option, so you need to be quick. In my previous agency we called this seagulling. Where I live on the south coast of England, seagulls are the apex predator and their favourite prey is chips from unsuspecting tourists. All that fatty food goes in one end and needs to come out the other. Hence seagulling. Our leadership team would swoop down with minimal context and ruin your favourite shirt.

Occasionally, escalations arrive well-packaged: with a clear summary enabling an informed decision. But more commonly you get a partial picture, with more visceral emotion than context. They arrive suddenly and with urgency, often after a fumbled back-and-forth between external vendors, your team and the client. Your best employees manage you, so you need to be aware of how they are presenting the problem. You have to wade through the friction and messaging before unpicking what the actual problem is.

I struggle with these decisions. I am conscious of not having enough technical, strategic or stakeholder awareness to make informed decisions. I also need to factor in wider commercial and agency considerations the project team doesn’t see. The consequences of these decisions can be widespread and long-lasting, yet as leaders we often make them with patchy, limited context. I will often hesitate to be too decisive for fear of seagulling.

Context is the bottleneck

Without clear understanding of a problem, leaders are forced to make seagulling decisions. Context is the bottleneck. Transferring knowledge is difficult and time-consuming, so we see it approximated. But in doing so, we lose all the complexity and nuance of how we got here. We see this in agile projects all the time: project awareness gets lost and distorted as it moves from BA through UX to designers, engineers and beyond. Each discipline applies its own filter to the project. The central vision of any project can swiftly become obscured and lost behind layers of filtered thinking.

Trying to capture everything in the hope of catching complexity and nuance doesn’t work either — that way lies a firehose: a sea of noise with no hope of uncovering the signal. You need a sherpa to identify the signal. But that sherpa is usually your team, and of course they have a horse in the race.

As enterprise projects become more complex (and AI is adding another layer to our stack), so we are also seeing the work cycles compress. AI is driving more work, more ambition, more scope. The context bottleneck is getting worse, not better.

AI can help context

AI is making the problem worse, but it can also improve things. Most AI talk is focused on individual productivity: faster emails, faster pitch decks, faster code generation. This is fine for entrepreneurs and engineers. But what about the C-Suite? Context feels like a great place to start. Remove the subjective filter and managed messaging and use AI to provide the right level of context as you need it.

Once you start thinking in systems and identifying the gaps, the problem becomes clear. You see how costly the knowledge transfer is between disciplines, and how much gets lost. Enterprise production teams are unwittingly playing a large, costly game of Telephone. AI can help manage that loss.

A source of truth

I have been experimenting with integrating AI into my workflow for a while, and have hit a number of challenges. I have explored generating artefacts: project plans, documentation and tickets. I have found limited success because I am imposing old workflows on a new paradigm. Big planning documents and verbose tickets are artefacts of an old methodology: shaped by the limits of human attention and focus rather than the limits of the tool.

AI can be truly agile where humans, often, could not. AI can change direction, undo, redo, modify — all with minimal fuss. Humans find change difficult.

But one AI experiment has stood out above all others. Prototyping.

I have been prototyping for years, with mixed success. It was always time-consuming and risky. Make the prototype look too much like the proposed final site and you hit the uncanny valley — the client constantly needs reassurance that the final version “won’t be like this”. Make it too abstract and it serves little purpose. Either way, once it’s created and explored it is often swiftly abandoned.

AI is changing this. Creating a prototype is now cheap; iterating one has become efficient. Prototypes no longer need to be discarded — they can be living, interactive documents of ideas and decisions. If we can iterate, adapt and pivot quickly at low cost, we no longer have the lock-in of forcing early project decisions. We can respond to new information as our knowledge deepens during the project. We can become truly agile.

This isn’t a new pattern. When Frank Gehry was designing the Guggenheim Bilbao, he hit a problem: his curves wouldn’t translate to technical drawings. So his team adopted CATIA, software originally built by Dassault to design jet fuselages. The Guggenheim was fully constructed on a computer; only after the digital twin was complete did construction begin in the real world. The model is the building.

Stopping the Telephone game

For Gehry, ideas were not caught in abstraction, written down and then interpreted by different trades. Ideas were demonstrated in their digital form, a fully interactive rendering of the building itself. No misinterpretation, no ambiguity. The best way to address knowledge gaps is not to let them develop. Let the prototype be the what.

I have long been frustrated by how much work we do to do the work: Figma files, Confluence pages, Jira tickets. All just work to do the work. But a prototype is a starting point of the work. A seed for a set of evolving ideas. The prototype is the product.

I used this technique in a recent project. We moved from confused discussion to immediately exchanging clear ideas. The prototype became our shared mental model to exchange ideas and transfer knowledge. It enabled us to collectively challenge assumptions and make key decisions. The client could interact with something tangible. We removed the indecision and anxiety of the unknown.

Beyond the prototype

Unlike Gehry, we’re not transferring ideas between different media. We are building our prototype from the same material as the final product: code. This is important, and it could lead to a new method of software development.

We’ve spent years being mindful of meticulous planning. And we needed to: code was expensive. Code was expensive to write, expensive to change and expensive to maintain. Making changes mid-flight can be disastrous to timelines and budgets.

Agile always sounded great in theory, but the reality was always far more brittle. Agile evangelists would present it as if engineers were sculpting with clay: easily adding new parts, removing unneeded sections and shaping new forms. In reality, it was more like working with marble: every chisel mark irreversible, every cut considered and planned. It’s why most organisations engaged in “faux Agile”: still requiring big upfront plans, fixed timelines and pre-defined budgets.

But suddenly, AI is making code more like clay for engineers. Changing direction, rebuilding sections, adjusting logic, switching out vendors. This all becomes more trivial. We are heading towards becoming truly agile, and AI and prototyping are at the core of the revolution.

An evolving prototype lets understanding flow through teams: from discovery into UX, design, engineering and beyond. But it can also feed context into the C-Suite. The what becomes unambiguous.

AI is challenging methodologies and limitations we have worked within for decades. It can translate ideas across teams without losing context, and feed the same context to decision-makers. Seagulling could become a thing of the past.