Learning as a deliverable

In 1985, the Danish computer scientist Peter Naur, the N in BNF, wrote an essay called "Programming as Theory Building" that quietly explains most of what's wrong with how companies buy software. His argument: a program is not the source code. The program, in any meaningful sense, is the theory of it that lives in the heads of the people who built it: why the boundaries sit where they sit, which parts are deliberate and which are scar tissue, what was tried and abandoned. The text can be handed over. The theory can't be, at least not by handing over documents. When the people who hold the theory leave, Naur argued, the program is effectively dead, however well-commented the code is. Whoever inherits it can still modify the text. But without the theory, every modification is guesswork.

Read that back as an engineering leader who has ever hired a consultancy, and it should raise the hair on your neck. When a vendor builds your system, ships it, and leaves, what exactly did you buy? You own the text. If your team never built the theory, you own a liability with a login page and, conveniently for the vendor, a standing dependency on the only people who understand it.

That's the trap "Learning Is Paramount" exists to refuse.

Theory transfers through work, not documents

If Naur is right, and a career of maintaining other people's code has convinced me he is, then knowledge transfer can't be a deliverable scheduled for the end of an engagement. A wiki dump and two recorded walkthroughs in the final week transfer text, not theory. Theory transfers one way: by building the thing together.

So pairing is how we work by default, not a special occasion. Your engineers and ours, same problem, same screen. It looks less efficient on a spreadsheet, two people, one keyboard, until you account for what's actually being produced. Pairing through the whole engagement means the theory is being built in your team's heads at the same time the code is being built in the repo. There's no handoff cliff at the end, because there's nothing left to hand off.

We also name, before the work starts, the specific skills your team will walk away with. Writing it down turns a vibe into a scoped commitment we can be held to. "Your engineers will be able to extend the agent harness, tune the retrieval pipeline, and run the evaluation suite without us" is a promise with a test at the end. "We'll do knowledge transfer" is not.

Practice is paid time

The research on expertise is blunt about one thing: people don't get better just by doing the job. Anders Ericsson's work on deliberate practice, the research that got flattened into the "10,000 hours" cliché, actually showed that improvement comes from structured practice at the edge of your ability, with feedback, on time set aside for exactly that. Twenty years of experience can be one year repeated twenty times if all you ever do is deliver.

That's why practice and research time at Sigao is paid time, not a hobby we expect people to fund with their evenings. An hour spent trying a technique that might not pan out is an hour the delivery schedule visibly pays for, and we consider it bought at a discount, because the alternative is engineers whose skills quietly freeze at whatever the last engagement demanded. I run our software engineering practice, and I'll tell you plainly: keeping the quality bar high and keeping people learning are not two jobs. They're the same job on different time horizons.

The same logic applies to mistakes. Ours get written up, shared, and folded into how we onboard the next person. A mistake that's been metabolized into the firm's practice was tuition. A mistake that's been buried is a mistake you've committed to repeating.

The exit test

Here's the honest test of a consultancy's values: what does it want your team to look like on the day it leaves? There is a business model, a common one, where the answer is "dependent." Knowledge hoarding turns vendors into permanent fixtures; every undocumented decision and unshared skill is an annuity.

We think that model deserves to die. An engagement should leave our people, your engineers, and your users more capable than it found them. That isn't a warm sentiment; it's the deliverable we're proudest of, because it's the one that keeps compounding after the invoices stop. The code we ship will eventually be rewritten; all code is. What your team learned building it alongside us is the part you keep.

Sources

• Peter Naur, "Programming as Theory Building", Microprocessing and Microprogramming, 1985.
• K. Anders Ericsson, Ralf Th. Krampe, and Clemens Tesch-Römer, "The Role of Deliberate Practice in the Acquisition of Expert Performance", Psychological Review, 1993.