01
Entry 01
This is the can’t-leave-the-laptop pattern — it shows up everywhere AI has a board mandate and no product owner.
The AI pilot that can’t leave the laptop
Situation
AI is obviously important. Management has said so, loudly, since last spring. A small team has built a promising prototype — a ChatGPT wrapper, a retrieval demo, something that works on one engineer’s machine with a paid API key. Everyone agrees it should be in the product by Q3. No one has said what problem it is supposed to solve for which customer, on which data, at what reliability. The vendor demos keep promising the same three things.
How it usually ends
The prototype never leaves the laptop. The budget line survives one more quarter by being renamed. Two years later, someone cheerful is hired to start an AI initiative and the cycle restarts.
What I’d do differently
Begin with an AI Adoption Review: a short diagnostic that answers three questions in writing. What, in your product, does AI make measurably better for a real user? What data, infrastructure and evaluation loop does that require? What is the smallest thing we can ship in six weeks that you can defend in a board meeting? No platform pitch. No framework purchase. The output is a shortlist of AI moves that fit your product, your stack, your team — each with effort and risk estimates. Then — only then — hands-on engineering to bridge the gap from capable to shipped, pair-programmed with your people so the know-how stays when I leave.
02
Entry 02
Fifty hands cost more than ten minds — in the end, and sometimes in the middle.
Fifty developers, none of them yours
Situation
The pressure is real. A roadmap item is late, a competitor is closer than anyone wants to admit, and the cheapest way to look like you are moving is to buy capacity. A staffing agency sends a deck with smiling faces. An offshore partner promises a bench. Suddenly there are fifty people on the project, seven Slack workspaces, three time zones, and one exhausted tech lead trying to keep a mental map of who is allowed to merge what.
How it usually ends
Quality becomes a lottery. When the contract ends, the knowledge leaves with it. Your in-house team — the people who actually pay for the roof — is quietly worse at the product than before.
What I’d do differently
Software craftsmanship is not an arbitrage play. The move is an In-House Upskilling Sprint: pair-program with the senior half of your team for a quarter, on a real problem that is already on the roadmap. Code reviews that teach rather than gate. Architecture decisions written down where the team can defend them. Dedicated spikes on the techniques they don’t yet have — AI tooling, DSLs, functional architecture where it earns its keep. You bring in the turbo-boost; your people keep the result. After a quarter, the product carries your team’s fingerprints, not a consultant’s.
03
Entry 03
Green dashboards on cold projects — the saddest lie in our industry.
Coverage at 92%, shipping at zero
Situation
A team has been doing everything right, or everything that sounds right. Unit tests added. Coverage climbing. Static analyzers adopted. Dashboards set up, and the dashboards are green. And yet features take three sprints. Release day is a ritual of incantations. Nobody refactors anything central because nobody remembers why it’s central. The project is still broken; it has been metrically broken for six months.
How it usually ends
Someone proposes a rewrite. The rewrite is approved partially, funded partially, staffed with whoever is available. Eighteen months later, the rewrite is a new legacy with slightly newer dependencies.
What I’d do differently
When a project has fallen in the well, ropes from above are the answer — not more metrics. An Architecture Second Opinion, written: what’s working, what’s decaying, what to cut and what to keep. The pragmatic question is always the same: does this change produce value now, or over time? If neither — cut it. Then a Pragmatic Delivery Review to identify the two or three practices that actually produce value and recommend what to drop. You will not get a rewrite pitch from me unless a rewrite is genuinely cheaper than the rescue — which is rare. The goal is software that stays soft: changeable, understandable, and cheap to move.
04
Entry 04
The “two-week shine” — it costs twice once you count the loss of faith afterwards.
Two weeks of clarity, then gravity
Situation
You paid for the workshop. You hired the well-known consultancy. For two weeks, everything was inspired. There was a deck. There was a slack channel called #transformation. Someone said the word psychological safety in a meeting and nobody laughed. Then the normal gravity resumed. The certificates went in the drawer. The ceremony schedule came back. The budget line is smaller, and the problem is exactly the same size as before.
How it usually ends
Quiet. A year later, a new consultant arrives with a new deck. The team has learned, correctly, not to get too excited this time.
What I’d do differently
A useful engagement ends with something your team owns — not a certificate, not slide 42. So every shape I offer is built around that rule. Training on your codebase, not on a sample repo. Consulting that leaves a written argument — a decision they can defend after I’m gone. Engineering pair-programmed with your people, handed back fully documented. If a piece of the work can’t be handed off, I say so before the kick-off. The measure of success is simple: can your team ship the next thing without me? If yes, it worked. If no, it didn’t — regardless of how good the two weeks felt.