Deciding well is solved.For me.

The claim, and the one case I can close

The talk I gave on Sep 24 makes one claim: building fast is solved, and deciding well is not. Its answer is a method, not a result. Write down what is decided and why in a mental model — Markdown files in git, not a picture in someone’s head — and let AI agents work inside it. The talk says the method is not proven yet and asks to be tested.

One case is closed — mine — and only in one sense. The decision was made the way the method says, on reasons that stood before the offer came, and anyone can check it against them. This post walks through it in the order it happened. Closed does not mean the outcome was good.

A good outcome does not, by itself, prove a good decision; a coin toss ends well half the time.

The question came first

The break came after years of leading technology, first as a CTO, then as head of technology. It began with one question, written down before the first application:

What do I like doing, rather than what am I used to being hired for?

That is a different question from which job to take, and the difference is the point. A job is an answer, and an answer chosen before the question is a habit.

Two tracks stayed open on purpose, hands-on engineering and architecture, because I did not know which was the answer and did not want to settle it by taste. The market was allowed to answer, and the applications became the experiment: which track would lead to interviews, and which interview would say something about the question.

The facts were kept in one place

An experiment needs a record. One CV in Markdown was the source, every application an overlay on it that selected, reordered and overrode, never a copy, and git held what was sent where. When a fact changed, it changed once and reached every dossier. When an interview said something, the note went beside the overlay that had produced the application.

The record held one line it could not cross: no certification claimed that I did not hold, no cloud named that I had not run, a gap stated rather than covered. On paper that costs. A dossier that says no TOGAF and no AWS fits fewer postings than one that stays quiet. In the room it buys the opposite: nothing I said had to be defended, and the conversation could go to what I had done.

The agents rated, never decided

Three AI agents ran on every posting, each under a written file that said what it might do and what it might not. The first read the posting against the record and against something I could not have written myself: the feedback former colleagues had given me, in writing, on what I should work on. It rated the match. The second wrote the application once I had read the rating and said go. The third checked the process and the correspondence, so a reply was not missed and a promise not forgotten. I gave every go and sent every application myself.

None of the three decided anything. That is the boundary the method draws, and it is worth stating plainly, because it is the part most easily lost:

An agent that rates is useful exactly as long as its rubric is not its own.

Here the rubric came from former colleagues. When a posting rated high, the rating was grounded in feedback from people who had watched me work, and that made it information rather than flattery.

What the evidence said

Between Jun 9 and Aug 20, 2026, 25 applications went out: 16 for senior engineering roles, 5 for architect roles, 3 for leadership roles and 1 for a business engineer role. The leadership applications were a check on the premise, whether what I was used to being hired for still held, and not a third track. The business engineer role sat between the two tracks. Twelve reached an interview or an invitation to one.

By track: all 3 leadership applications led to an interview, 7 of the 16 engineering ones did, 2 of the 5 architect ones did, and the offer I took was one of those two.

The figures stand on the timeline, in the career break’s own entry.

The declines said as much as the interviews. An employer reads a former CTO applying for an engineering role as a flight risk, unless the CV says up front that the move is meant to last. Mine did not: three employers in 27 years is the fact, and it was not on the first page. The story of going back near the code has to be told as a choice, not as a step down, or the reader tells it as a step down for you.

The decision

The choice would be made on one criterion: values over pay, a product company, a day kept free.

By September the break had answered its question, and not through the figures: they showed only that the premise still held and that both tracks were open. What I like doing, I found by doing both, in four months of building two products in the open beside the search. It is modeling how a business works, and AI used with responsibility inside a company rather than merely used.

The role that fits it is an architect’s, and it is the more lasting one. With the right guardrails an agent writes code faster than any team, so pure development will change, while deciding what gets built will not. That is the talk’s claim, applied to my own career. The offer I accepted is an architect role at 80%, four days a week, in a product company outside finance, from October. The fifth day goes to formal education in how AI is led and governed in an organization, from 2027.

Three hiring processes in finance, the industry most of my career was spent in, were still open when I chose, and I withdrew from all three. Two were senior engineering roles, one past its second round and one a day from an offer. Both were hands-on work, but on the track that agents change fastest, and either would have been chosen for its pay and not for the question. The third was a hands-on lead role at a higher salary range, which would have been my previous role again under another name.

The choice rests on one thing only the role itself can confirm: that the company’s culture is what the interviews showed. That is the risk I took with it.

The criterion came before the offer, not after.

Why that is deciding well

Four things made it a good decision, whatever the outcome. The question came before the first application; the facts stayed in one record; the AI agents rated against a rubric not their own and decided nothing; the criterion came before the offer. That is the method the talk proposes, run once, on one person, on one decision. All of it stands on the public timeline, figures included, so anyone can check this post against the record.

One case proves nothing about a team, and I am not claiming it does. A team decides among people who disagree, with a record nobody keeps in one place, under a pressure a career break does not have. Whether the method survives that is the open question, and it is why the talk’s proposal stays a proposal.

So the claim stands as the talk made it.

Deciding well is not solved. For me, it was.

If you decide differently and it works, I want to know where this breaks: write to me.