Senior in judgment, hands-on in practice
Building got cheap, and the fashionable conclusion followed fast: senior people should finally step off the keyboard. Let the agents build. Orchestrate, delegate, decide. I think the early stage points exactly the other way. AI did not make seniority less important. It made it the last scarce thing.
Because what does senior actually mean? Not years, and not a title. Judgment. And judgment, in practice, is the ability to see trade-offs. Every decision that matters in an early product is a trade-off: what to build and what to skip, how much solution a problem deserves, what a choice will quietly take from you six months out. A junior conversation compares options by what they offer. A senior one compares them by what each gives up. And the best version of seniority is rarer still: finding the move with fewer trade-offs than it seemed to have, the path where you do not have to choose at all.
Here is the part that changed. Trade-offs are not abstract. They come from the material: what things take in effort, time, and money to build, to maintain, to undo. AI is rewriting those numbers every few months. Which means judgment has a shelf life now. A leader who stopped building in 2022 is weighing 2026 decisions against a 2022 trade-off table, and most of its rows are wrong.
That is why the two halves of the title are not a balance to strike between leading and doing. They are one capability, and the two axes give you four places to end up:
| Hands-on | Not hands-on | |
|---|---|---|
| Senior judgment | The early-stage advantage. You see the trade-offs because you are inside them. | Stale judgment. Weighing today's decisions with yesterday's trade-off table. |
| Judgment missing | Beautiful software nobody uses. The building feels like progress, so nothing corrects you. | Not in the game. |
Four of my own projects taught me this map, each from a different corner.
Tributo is the clean case. I joined a shapewear brand as CTO, a title that says lead the engineers. The store ran on a Shopify template doing millions in sales, held together by more than thirty plugins, because the product needed things Shopify does not really give you: garments with up to a hundred variants, add-ons hacked in through yet another plugin, customization the platform was never designed to carry. Shopify was not wrong; it was limited for this use case, and the plugin pile was the tax on that limit. So the real decision was this: keep optimizing on an unstable, unreliable base, or spend months building our own frontend and remove the restriction at the root. I could make that call because I could weigh both sides with my own hands. I would be writing the custom variant and add-on software myself, so I knew exactly what the second path would take. And I knew where to refuse the trade entirely: we kept Shopify's backend and checkout, because payments and compliance are the worst possible place to be original. Conversion roughly doubled, and the store still runs on that software more than a year after I handed it off.
SuperMenu is the mirror, and the thesis is worthless without it. There the hands were never the problem. We built everything: the interactive menu, the back office, a real recommendation engine. The judgment is what failed. We pivoted from marketplace to SaaS in a room, by reasoning, without customers in the loop, and the pivot quietly invalidated our core technical asset: collaborative filtering needs a city's worth of dishes and ratings, and a single restaurant has neither. The recommender never launched. Hands-on without judgment produces beautiful software nobody uses. I know because I own the repo.
Amiko is the loop at its tightest. It is my own second brain, built solo, and every architectural trade-off gets settled the same way: I feel it the next morning. Markdown files for the knowledge I want to own, because portability and a readable history are worth more to me there than query speed. A database for what machines write at volume, because at volume the trade flips. Nobody had to brief me on any of this. I live inside the consequences daily, which is the fastest correction mechanism judgment can have.
Wispal is where the obvious objection gets an answer. If AI writes the code now, what does hands-on even mean? Typing? No. At Wispal I have started moving parts of the building itself onto agents: written business context they work against, hooks that block dangerous actions, checks on the paths where money moves. It is early and partial, and I say that plainly. But the direction is the point. When agents build, the judgment does not disappear; it moves into the harness. What an agent may never touch, what must be verified before a deploy, what context it builds from: those are trade-off calls, and you can only make them if you are close enough to the material to know where it breaks. Hands-on is not loyalty to typing. It is a refusal to let your sense of the trade-offs be secondhand.
Two boundaries, so this stays honest. First, this is a stage argument, not an identity. At scale the CTO role genuinely changes: it becomes about leading people and leading systems more than about building, and that version is real and right, later. Whether that role even survives AI in its current form, or collapses into one product person doing design and engineering with agents around them, is a different question. Second, staying hands-on is itself a trade-off. Time spent building is time not spent selling, and I have paid that price more than once. I am not claiming the overlap is free. I am claiming that early, it is the better trade.
So: senior in judgment, hands-on in practice. Not a compromise, and not a phase you graduate out of at the first hire. In the early stage they are the same muscle. The hands keep the judgment current, and the judgment is what makes the hands worth putting on the work.