Independent Technology Counsel — by 23AG
Honest reads on what to build, what to kill, and what to stop arguing about.
Inside Velocity is a symptom, p.2 · Microservices, the honest case, p.2 · The seed-stage analytics trap, p.3 · Engagements & rates, back page.
In most teams I’ve sat with, the standup isn’t the bottleneck — the dependency graph is. When a one-line change needs three teams and a deploy freeze, that’s structure talking, not effort. Reorganise the seams before you reorganise the people.
The pattern isn’t the problem. Applying a distributed-systems answer to a monolith question is. If a team can’t ship one clean monolith, it won’t ship clean services — it’ll ship a monolith with network calls bolted in between.
A spreadsheet and one Postgres table will outlast three BI tools bought ahead of the questions they were meant to answer. Build for the question on the desk today, not the one in the investor deck.
Moscow — The Leader
Most engagements open with the wrong question. Here is the one that actually moves things.
Before a single tool is chosen, three questions should already have plain answers: what constraint are we removing, what does success look like in six months, and — the one most teams skip — who owns the result the day I leave. None of these are technical. All of them decide whether the work survives contact with reality.
Teams reach for a framework first because it feels like progress you can point at. But a stack is a consequence, not a starting point. Pick the constraint, name the owner, and most of the architecture argues itself. Skip that, and you get a beautiful system that no one is accountable for and no one quite uses.
So my first deliverable is rarely a diagram. It’s a sentence: this is the decision, this is who owns it, this is what we’ll regret if we get it wrong. Everything after that is execution — and execution is the easy part. The honest read on most “technology problems” is that they were ownership problems wearing a hoodie.
Patterns from recent engagements, set down before they fade.
Every engagement opens the same way. What problem are we actually solving — not the stated one, the real one beneath it. Who owns this in twelve months. And what definition of “fixed” would make this a success. That’s not pre-work; it is the work.
The highest-leverage thing a new CTO sets isn’t a hire or an ADR. It’s the minimum acceptable standard for a commit, a deploy, a postmortem. Teams that inherit a high bar protect it. Teams that inherit a low one rarely raise it without pain.
The projects that fail share a tell: a model with good eval numbers and no one who wants the output. The question is never “should we use AI.” It’s which human decision we’re augmenting, and what that person actually needs to say yes.
The most underrated line item in any architecture is the one labelled “dull.” Postgres, a queue, a cron. Reach for the exciting thing only when the boring thing has visibly run out of room — and write down the day it did.