Why I Wrote The Software Conductor

A few years ago, I was talking with a senior developer at a company I was consulting for. He was sharp, technically deep, and had been doing great work for nearly a decade. His manager had just asked him to start doing less actual software writing, and more helping the rest of the team decide what to build.

“I don’t know what I’m supposed to do now,” he told me. “I know I’m not supposed to just write code anymore. But nobody has told me what I amsupposed to do.”

I’ve had that conversation more times than I can count. And I’ve never found a book that fully answers the question he was asking.

This is what The Software Conductor is about.

The gap that kept bothering me

There are excellent books on software architecture. Fundamentals of Software Architecture by Mark Richards and Neal Ford is one of the best. If you want to understand patterns, trade-offs, and how to think about system design, it’s the place to start.

There are also excellent books on engineering leadership. Camille Fournier’s The Manager’s Path has helped more senior engineers navigate the people side of the job than almost anything else I know of.

But neither of those books addresses the specific, disorienting, deeply personal experience of becoming an architect. The moment when you realize you can’t just solve the problem yourself anymore. When your job is no longer to write the answer, but to create the conditions for the right answer to emerge. When your instinct is to open the IDE and your job description says “lead the system.”

That gap has always bothered me. And it bothered me even more as AI started changing the landscape.

The part AI made urgent

In the past two years, programmer employment in the U.S. fell more than 27%. AI coding assistants are absorbing the parts of software work that used to be a developer’s runway. Routine implementation, boilerplate, even significant chunks of system-level code.

I’m not one for panic. But I am one for honesty. And the honest read of the data is that the execution layer of software work is being compressed by AI, while the origination layer (synthesis, judgment, design thinking, the work of creating the conditions for a system to exist) is becoming more valuable, not less.

That’s the architect’s work. And it’s the work that most developers don’t yet know how to step into.

The window isn’t closing. But it is narrowing. And a lot of senior developers who are perfectly positioned to make this transition are stalling out, waiting for someone to hand them a map.

This book is the map.

Where the metaphor came from

I’ve been thinking about the conductor analogy for a long time. I first used the analogy in a course I built for LinkedIn Learning six years ago. A conductor doesn’t make a single sound. They don’t play an instrument. They stand in front of people who are far more technically skilled at their individual instruments than the conductor will ever be, and they shape something those people couldn’t create alone.

That’s the architect’s job.

A violinist makes sound. A conductor makes music. A developer writes code. An architect creates the conditions for great software to exist.

When I started writing the book, I knew the metaphor needed to be more than a clever framing device. So I built the whole story around it. Aaron Blake is a senior developer who is burning out doing exactly the kind of work AI is starting to do well. He meets Anton Weiss, a conductor at the end of a long career, who teaches him what it actually means to lead without controlling. To listen as much as you speak. To shape outcomes you don’t personally execute.

The story isn’t about music. It’s about the transition most developers need to make right now and don’t know how to name.

What this Substack is going to be

Every week for the next several months, I’m going to be writing here about the ideas in the book. Not summaries or excerpts — real working material. The frameworks, the conversations, the specific situations architects face that nobody prepares you for.

Some of it will expand on what’s in the book. Some of it will go places the book didn’t have room to go. All of it will be practical, in the sense that good architecture is practical: grounded in real problems, aimed at real outcomes.

If you’ve already read The Software Conductor, welcome. There’s more where that came from.

If you haven’t read it yet, you can find it on Amazon in softcover, hardcover, and Kindle. And you’re in the right place to start.

The orchestra is waiting. Let’s pick up the baton together.