Deciding well is solved.For me.

The talk kept the claim open for everyone else. This is the one case I can close, because the decision is written down and you can read it.

· 5 min

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, and let agentic AI work inside it. The talk says the method is not proven yet and asks to be tested.

One case is closed, and it is mine. Not because the outcome was good. An outcome says nothing about how a decision was made; a coin toss ends well half the time. The case is closed because the decision was made the way the method says, and everything it rested on is written down where you can read it. This post walks through it in the order it happened.

The question came first

The break 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 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 when the rating was a go. The third checked the process and the correspondence, so a reply was not missed and a promise not forgotten.

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. The rubric here was the colleagues'. When a posting rated high, it was because people who had watched me work would have said so, and that made the rating worth reading instead of flattering.

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. 12 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 stay is stated first, and I had not stated it: 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. And the honest line held: what it cost on paper it paid back in every room.

The decision

The offer accepted is an architect role at 80% in a product company outside finance, from October, chosen for the culture. It was chosen while three processes in finance were still open, two senior engineering roles, one past its second round and one a day from an offer, and a hands-on lead role at a higher salary range, and all three were withdrawn.

The criterion was written before the offers arrived, not after: values over pay, a product company, a day kept free. The fifth day goes to formal education in how AI is led and governed in an organization, from 2027. Had the criterion been written after, this paragraph would read as a justification. It reads as a comparison because it was one.

Why that is deciding well

Question first. The evidence in one record that every application and every reply went into. Agents inside written boundaries, rating and writing and checking, never choosing. The owner choosing, against a criterion that existed before the options did. And the whole of it on a public timeline, figures included, so that anyone can check whether this post says what the record says.

That is the method the talk proposes, run once, on one person, on one decision. It 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. Mine was. If you decide differently and it works, I want to know where this breaks.

Rests on · Career break · Application tooling · Building fast is solved. Deciding well is not. · Turn your work history into code · Deciding well