Beakman, Ford, and dividing to deliver

Growing up, I never missed Beakman's World on TV Cultura. It was loud and weird, and it taught me how things work. One episode stuck with me for life: the one about Henry Ford and the assembly line. The idea that you could take an enormous, intimidating task, building an entire car, and turn it into a sequence of small, repeatable steps that anyone could do well.

Decades later, that's still how I think about delivering software. The instinct most teams have, when faced with something big, is to map every requirement before writing any code. It feels responsible, but that's how the project stalls.

Forty endpoints and a squad stuck in the spec

One example I keep coming back to: a squad was running late on an integration with around forty endpoints. The team was paralyzed, trying to fully specify all forty before building anything. The spec kept growing, the deadline kept moving, and nothing was actually working.

So I asked a different question: what if, instead of mapping all forty endpoints, we built the whole thing end to end with just one? One endpoint, but wired through the entire system, from request to response, authentication, error handling, logging, the lot. Suddenly the team had something real running. They could validate the approach by running it. And, just as important, they had the feeling of completeness, the proof that the path worked. After that, the remaining endpoints stopped being a wall and became a checklist. Each one was just more of a road they'd already paved.

The same trick, in CRM migrations

I do the same thing on data migrations. The temptation is always to map all the fields before moving a single record. Instead, I start with one simple, representative example and push it all the way through. That one record teaches you the real shape of the connection, the auth quirks, the rate limits, the fields that don't line up, far faster than any mapping document. And it gives the client something to see and react to within a few days.

It didn't change with AI. It got more important.

I see people making the same old mistake with a new tool: trying to build a complex AI solution all at once, with the prompt, agent, tools and evaluation going in together. As Matt Pocock has put it, software engineering processes still apply, even with AI in the loop. The model changes how you write the code; the discipline of shipping a thin slice, validating it and iterating still holds.

Ford simplified the process, one station at a time, and I saw it on a kids' science show before I ever wrote a line of code.