How I work

Method

How I tend to work when the problem is not already neatly defined.

Most of the work I take on starts before the answer is obvious. There is usually already something there: a website, a publishing process, an archive, an operational routine, a piece of software, or a group of people who each understand a different part of the problem.

I usually begin by finding out how the work is actually being done. Once I understand enough, I make some kind of model of it: perhaps a map, a schema, a prototype, a structured set of records or simply a clearer account of what depends on what. Then there is something concrete enough to change, build, test or hand over.

Read the situation

If someone asks me to rebuild a website, automate a process or add AI, I do not assume that the request tells me where the real problem begins. Long-running systems collect workarounds, naming conventions, spreadsheets, old integrations, exceptions and decisions whose reasons may have disappeared. Some of that is simply mess. Some of it is knowledge.

Finding the difference usually means following the work rather than just reading the brief. I may read source material, reproduce a process, trace where records come from, look at the tools people really use, or talk to the person who knows why an awkward workaround still exists. I am trying to understand enough to know what can change safely, what needs preserving and where the problem is actually located.

With London Drawing, for example, moving video was only part of the problem. A recording belonged to an event, a date, a model or subject, a set of metadata, a website page and a future publishing workflow. At IMLPO the picture was broader again: membership, renewals, payments, events, suppliers, communications, access and responsibilities all affected one another. In both cases, understanding the surrounding work changed what a sensible solution looked like.

Sometimes this stage leads to a rebuild. Sometimes it points to a smaller repair, better documentation or a decision to leave a useful part alone.

Make a workable model

Once I understand enough, I usually need to get it out of my head and into something we can look at together. Depending on the problem, that might be a process map, a content model, an inventory, a schema, a set of rules, a prototype or a cleaner canonical record. Making the model is not an academic exercise. It is a way to find out whether we agree about the problem.

Once something has a shape, missing steps, duplicated information, contradictory versions and unclear responsibilities become much easier to see. It also becomes easier to separate different kinds of claim. A source may say one thing, an AI system may extract or suggest another, a rule may produce a result, and a person may still need to make the final judgement. I try to keep those things separate so that a suggestion does not quietly become a fact.

That is also how I think about AI in practical systems. It is very useful for working through messy material, comparing versions, extracting candidate information, drafting, exploring alternatives and helping to build software. If the same facts should reliably give the same answer, an ordinary rule is often better. If a judgement belongs to a person, I want the system to make room for that judgement rather than bury it inside a model response.

The Lettings Compliance Checker is a useful example. AI-assisted development helped with implementation and analysis, but the compliance evaluation itself is deterministic. The tool used to help build the product is not automatically the right tool to decide the outcome.

I also use prototypes as a way of thinking. Putting a rough interface in front of somebody often exposes questions that are difficult to see in a specification: two fields that are really different things, a missing approval step, or a sequence that makes sense on paper but not to the person who has to use it. A prototype can be useful even when what it proves is that the first idea was wrong.

Put it to work

Eventually something has to change in the real environment. That may mean a WordPress implementation, a publication workflow, a migration, a dashboard, an internal tool, a piece of software, documentation or a handover. The form varies, but this is the point where the model meets actual use.

AI-assisted development has changed how much of this stage I can carry myself. Coding agents let me move quickly between the domain model and working software, but I still want to know what has actually been tested, what remains provisional, and what happens when real data is incomplete, contradictory or simply awkward.

I am careful about claims of readiness. A feature that passes automated tests is not the same as one I have watched work in a browser, and neither is the same as a system operating reliably for a client. I try to describe the state it is really in and then test the next thing that matters.

Documentation belongs here too. Sometimes that means technical notes; sometimes a decision record, context pack, operating guide or handover. If I leave a system behind, I want somebody else to be able to understand it and change it without having to start the investigation again.

How this shows up in the work

The sequence changes from project to project. Sometimes most of the work is in understanding what already exists; sometimes the model is clear and I can move quickly into implementation. A few projects show the range better than another list of principles.

Trigger SMARTS. I learned the hotel-signage problem through live operations before the software became a reusable multi-hotel model. The later product structure came from what the earlier working versions revealed.

Richard Craven / Cravenverse. The work began with books and publishing. As the catalogue grew, recurring characters, places, editions and source material created a different problem: how to keep an interconnected body of work usable and reviewable.

London Drawing. A video migration only made sense once the relationships between events, recordings, metadata, the website and the future publishing workflow were made explicit.

Lettings Compliance Checker. A rule-heavy domain needed repeatable evaluation, so the product uses an explicit deterministic core while AI assists development, analysis and other work around it.

Not every project needs the whole sequence

This is a description of how I tend to work, not a process that every project has to pass through from beginning to end. Sometimes a short investigation is enough. Sometimes the problem is already well understood and the useful thing is to build it. Sometimes the first model changes the brief so much that the right next step is smaller than anybody expected.

The How I Help page describes the different kinds of engagement more directly. The Work pages show what this approach has looked like in real projects.