The Pragmatic Path

You have shipped the prototype. It works on your laptop. On the customer's laptop it is a different story — the demo that won the room last quarter now takes ninety seconds to load, the dashboard drifts by a cent per thousand rows, and the engineer who wrote the worst of it has just handed in their notice. You are not lazy, not stupid, not under-resourced in any way that would be legible to a board. You are simply in the part of the project where the cost of what was deferred arrives in full.

The conversations begin to sound familiar. There is the product lead who can no longer distinguish a three-day task from a three-month one, because the team has stopped giving honest estimates and started giving safe ones.1 There is the CTO who hired a well-known consultancy and received, in return, an immaculate slide deck and a junior engineer billed at a rate that makes the CFO flinch. There is the founder who ran one two-week sprint with an external squad, saw a beautiful burndown chart, and then watched the codebase quietly decay once the squad had left.

And there is, almost always, the feeling that no one in the room can say the obvious thing: that the stack is not the problem, the methodology is not the problem, the people are mostly not the problem. The problem is that the structures which would let a small, honest team hold the line have been quietly dismantled — by process theatre, by staffing fashions, by a decade of outsourcing the act of thinking.

This essay is about what to do instead. It is written for the CTO who wants her team to grow into the shape of the problem, not around it; for the founder who has had enough of consultancies that sell hours instead of judgement; and for the engineering manager who suspects, correctly, that another framework is not what will save them.

Part IIWhy the usual moves fail

The first failure mode is the Agile Industrial Complex. An entire economy has grown up around the delivery of methodology as a product — certifications, coaches, tool licences, transformation programmes, two-day kick-offs that leave behind a Miro board and an invoice.2 The customer did not want a methodology. The customer wanted software that works and a team that can keep shipping it. What they received was a taxonomy of ceremonies.

The second failure mode is the body-shop trap. You hire the consultancy with the recognisable logo and the thick case-study book. What arrives is not the partner who sold the engagement but a rotating cast of engineers whose commercial incentive is to still be there next quarter. Their senior attention is a scarce resource rationed across twenty other clients. The juniors on the ground are competent and earnest and have never built anything from scratch that outlasted a contract. When the engagement ends, the institutional memory leaves with them. Your team inherits a codebase they did not write, cannot love, and must now maintain.

The third is the two-week shine. An external pair parachutes in for a sprint, produces a dazzling artefact — a working prototype, a migration plan, a polished dashboard — and departs. The artefact is genuine. The capability it implies is not. Without the same pair at the next sprint, the prototype does not evolve, the migration plan is not executed, the dashboard rots. Shine is a lagging indicator of understanding, and understanding does not transfer in two weeks.

The fourth is metrics of a dying project. When a project is genuinely in trouble, the dashboards grow. Velocity is reported to two decimal places. Burndown charts acquire forecasts. Standups lengthen. Retrospectives multiply. None of this produces code. The surest sign that a team has stopped delivering is that it has started measuring its delivery with increasing precision.3

Part IIIWhat actually works — the pragmatic path

The counter-narrative is unfashionably simple. Keep the work in-house. Let the people who will live with the software build the software. Invest in the structures — the codebase, the build, the test harness, the review culture, the mental models of the team — that make in-house work possible over years, not months. Rent engineering judgement when you need it, for as short a time as will do; keep what you learn from it forever.

In practice that resolves into three kinds of engagement, and I offer exactly those three.

Training

A team that cannot reason about its own code will not reason about anyone else's advice. Training is the highest-leverage intervention I know of: a week spent raising the floor of a team's shared understanding pays out for the life of the codebase. I run workshops on functional programming in .NET, on type-driven design, on building robust domain models, on LLM engineering grounded in something more than prompt folklore. Small groups, real code from your repository, outcomes you can point to.

Consulting

Second opinions from someone who has no incentive to still be there next quarter. I read your architecture, your hiring plan, your build pipeline, your estimation culture; I tell you what I think and why; I write it down. Days or weeks, not quarters. The deliverable is a document and a conversation, and the goal is that you no longer need me.

Engineering

Occasionally the right thing is to sit down and write code alongside your team. I take on focused pieces — a new subsystem, a difficult migration, an LLM integration that has to be correct and cheap at the same time — with a clear scope, a clear exit, and a strong preference for pairing with whoever will own it afterwards.

Part IVHow engagements take shape

Five shapes recur. The diagnostic is a short, sharp read of a situation — usually one to two weeks — that produces a written verdict and a list of moves ordered by cost and risk. It is the cheapest engagement I offer and often the most useful.

The workshop series is a rhythm of training sessions interleaved with real work: a cohort of engineers meets for half-days across several weeks, each session grounded in a piece of their own code. By the end the cohort has a shared vocabulary and a shared bar, and the codebase has moved too.

The architecture sparring partner is a months-long, part-time engagement. I am available for a standing weekly session and for asynchronous review of proposals as they arise. Your architects stay your architects; they simply have someone to argue with who has seen the failure mode before.

The focused build is a piece of engineering work with a defined edge — typically six to twelve weeks. I write code, your team reviews and pairs, and we are done when the piece is in production and maintained by people who are not me.

The LLM engagement is a hybrid: diagnostic, workshop, and focused build, shaped around a generative-AI problem that needs to be solved correctly rather than merely demonstrated. Evaluation, retrieval, cost discipline, the things that separate a demo from a product.

Part VAbout the author

Ronald Schlenker is a Frankfurt-based consultant who has spent the better part of two decades writing software in .NET, most of it in F#, most of it with teams who had to keep maintaining it after he left. He is a Recognized F# Expert, a maintainer in the fsprojects organisation, and the author of several open-source libraries in daily use in production systems.4 He spoke at BobKonf 2024 in Berlin on incremental computation and on building LLM-powered agents from primitives.5 Alongside the consulting practice he builds one hardware product with a friend — the PXL Clock — and shares technical essays and videos under The Pure State.