Understand, plan, execute, verify

Most people treat quality and speed as a tradeoff. Do it fast and it will be sloppy; do it well and it will be slow. I stopped believing that a while ago. The tradeoff is real only when work has no shape. Give it a shape and quality and speed come from different places, so you can have both: quality comes from gates between the steps, speed comes from running things in parallel inside them.

The shape I use is four steps, and each step has an exit gate - a question I have to answer before I am allowed to move on. Not a checklist to recite. A question with a real answer.

Understand. Restate the task in one sentence. List what I know, what I need to find out, and what only someone else can decide. The gate: can I predict what done looks like? If I cannot state the success criterion in a sentence, I do not understand the task yet, and anything I build is a guess wearing work clothes. This is the cheapest step and the most skipped one. Diving in feels like progress; it is usually just motion.

Plan. Break the work into pieces, and get honest about which pieces depend on each other and which do not. Then surface every fork that belongs to someone else - scope, approach, tradeoffs - before executing, not after. The gate has two parts: are the pieces independent enough to run at once, and has the person who owns the direction seen the forks? Five minutes here routinely saves an hour of confidently wrong execution. The plan does not need to be elaborate. It needs to exist, and it needs to name the dependencies instead of pretending there are none.

Execute. Run every independent piece at the same time. These days most of my engineering team is a fleet of AI agents, which makes the parallelism literal - I can hand out five pieces of work in one motion and get five results back in roughly the time one would take. But the principle is older than the tools. It is how you run any team, and it is how you run yourself: batch the independent work, sequence only what genuinely depends on something else, and keep the coordination in one place. The gate: everything came back, and nothing failed silently. A piece that half-finished and got carried forward anyway is a defect you planted yourself.

Verify. The work is not done when it is written. It is done when something other than its author has checked it. Run the actual build, not the mental one. Have fresh eyes read it - a colleague, a reviewer, a second pass with real distance. The author is the worst available verifier of their own work, because the author checks the thing against their intent instead of against reality. The gate: no high-confidence issue remains unaddressed. Fixed, written down as a known limitation, or explicitly accepted - but never silently skipped.

There is a quiet fifth step I hold separate: leave a record. Wire the result into wherever the next person will look, and write down what surprised you. Work that cannot be found later is half-done, and a lesson that dies with the task will be paid for again.

A concrete example. I recently needed a long reference document on a topic I only partly knew. Understanding took one conversation - the success criterion was a document a stranger could act on without asking me anything. The plan decomposed the research into five independent angles. I dispatched all five at once as parallel workstreams, each with an explicit instruction: return your findings as a report, do not write any files. Two of the five wrote files anyway. The verify gate is where that surfaced - I deleted the partial files, read all five reports in order, and wrote the synthesis myself rather than letting any one workstream merge the others. The whole thing took about half an hour. Done sequentially it would have taken multiple hours, and without the verify gate the two rogue files would have shipped as half-finished fragments sitting next to the real document.

That example happens to involve AI agents, but notice that nothing in it depends on them. Replace the workstreams with five people, or five evenings of your own time, and every step and every gate holds. The gates are just the questions a good senior person asks by reflex: what does done look like, what depends on what, did everything come back, who checked it. The loop exists because reflexes fail when you are tired, rushed, or excited - which is exactly when the work matters most. Writing the questions down means you cannot quietly skip one.

Why doesn't the ceremony slow you down? Because the costs and savings are lopsided. The gates cost minutes - a sentence, a short list, a review pass. The parallelism saves multiples - five pieces in the wall-clock time of one. And the understand and plan steps prevent the most expensive failure there is: executing the wrong thing quickly. Fast wrong work is not fast. It is slow work with a delay before you find out.

I skip the loop for trivial things - a one-line fix, a typo - and I try to say out loud that I am skipping it. That sounds like ceremony, but it is the opposite: the failure mode of any process is that exceptions become silent, then normal, then the process is fiction. Naming the skip keeps the loop honest.

The trap to name: the loop can become theater. You can recite all four steps, hold none of the gates, and produce the same sloppy work with better paperwork. I have done it - a plan written after the execution it claims to have shaped, a verify pass that was really the author admiring their own output. The gates only work if you want the true answer to the question, and no shape can manufacture that. What the shape does is make self-deception harder and visible. Whether you look is still up to you.

That, in the end, is the claim. Quality and speed trade off in unshaped work because every corner cut is invisible until it fails. Shape the work, and the corners have names. You still choose what to cut - but you choose it looking at it, and most of the time, once you can see the corner, you find you did not need to cut it at all.