The Orchestrator

A friend of mine, Pete Wagner, runs Wagner Custom Skis in Telluride, where the manufacturing process combines engineering, materials, customer information, design, production, and fulfillment. Pete is an engineer, and he is not a programmer in the sense most technology companies use the word.

That needs one qualification. By the company’s own account, Pete founded Wagner Custom in 2006 after converting the fitting software he had written for golf clubs into software that “designed all of the steps in the manufacturing process”; the Mountain Village factory builds about six pairs a day, each unique.¹ Pete wrote the software that is the product. What he called me for was the software around it.

For years, whenever Pete needed to change one of the systems supporting the business, he had a reliable solution. He would call me.

Sometimes he needed a small piece of code, sometimes help understanding how the manufacturing process should work inside the software, and sometimes we would just talk through a new ski shape or a new material. Then I would find a Saturday, or an evening, or a gap between other obligations, and make the change. The arrangement worked, and it also meant Pete’s ability to improve part of his own business depended on my availability. The system was not independent. I was the missing system.

Over the last year I have helped him set up a group of connected agents, each with a narrow job: one inspects the existing software, one helps plan a change, one writes and tests code, one reviews the result. They share enough context to work together, and they carry instructions about what they may change and what has to come back to a person.

The Introduction said that systems able to inspect a codebase, propose a change, run the tests, and prepare a release without a person correcting them at every step are not yet widely available, and Pete’s does not contradict that. It is a narrow system on a codebase I know, in one business, with a person one phone call away when it has to hand off. That is the scale at which Chapter 13 says to start, and I am not making a larger claim than that.

Pete still has an experienced engineer he can call, and that is me. When the system hits something it cannot explain, or when a change touches a part of the business nobody has tested, I can help, because the goal was never to pretend expertise had become unnecessary; it was to make expertise less of a bottleneck.

The moment that mattered came when Pete wanted to add a new file for a ski shape and integrate a new base material into the production system. In the past he would have called and asked whether I could take care of it, and I would have said I was busy and then agreed to do it anyway. This time he described the request to the agent system running in his business, and the system inspected the current code and production cycle, made the change, ran the relevant tests, and prepared the deployment without interrupting work already in progress — then reported what it changed, what it tested, and what still needed a human decision.

Pete called me afterward. “No offense,” he said, “but I love not having to call you.”

I understood what he meant, and I also noticed the first reaction sitting underneath the understanding, which was that it felt a little threatening. He did not need me for every small improvement anymore, and a relationship organized around my technical availability had just changed shape.

Then I thought about what had actually happened. Pete had gained independence, his business could move forward without waiting for me to find a Saturday, and he still needed help when a real problem appeared — he just no longer needed a programmer standing between every idea and every working change. That is what an orchestrated system should do: make the people who understand the work less dependent on an expert for every ordinary step.

Put the book’s vocabulary on that Saturday and each term lands on something you can point at. The request went from Pete to the system instead of to me, which is Chapter 1’s line between assistance and orchestration drawn through one afternoon: my typing did not get faster; the process lost a step, and the step was the programmer. What the system exercised was delegated intelligence in Chapter 3’s sense — it interpreted, chose, and acted — inside bounds it did not set, because the list of what it may change and what returns to a person was written before it ran, and I wrote it. The report is the decision record of Chapters 4 and 7 at a size that fits in an email, and the stop was the deployment: prepared, not performed.

One success also has limits. It is one run, graded by the person who built the envelope, and a change of the kind the system was built for; the record of a success is not the record of a failure handled, and Chapter 9 was about the second. And by Chapter 2’s test — can another qualified person take the work over from the register and the record — the arrangement passes for Pete and not yet for me. Chapter 13’s ninth item, teach another person, is the debt this Saturday left open.