I’ve watched a lot of developers make the move into architecture. The ones who struggled the longest weren’t the ones who didn’t understand distributed systems or couldn’t draw a useful architecture diagram. Most of them had plenty of technical depth.

What they struggled with was something harder to name.

It usually came out in small ways at first. An architect who kept rewriting code during a code review instead of asking questions. A senior architect who volunteered to take on a critical bug fix personally because “it would be faster.” A new principal engineer who stopped going to team planning sessions because “that’s not what I should be doing anymore,” and then six months later admitted they felt disconnected and useless.

All of these are versions of the same problem. The identity they had built their career on, “I am the person who builds things,” was no longer the job description. And nobody had helped them build a new one.

The competence trap

Developers become good developers by being the person who knows things and builds things. That’s the loop: learn, apply, get better, get recognized, get more opportunity, repeat. The reward system in software development is tightly coupled to personal technical output.

That loop creates a specific kind of identity. You are competent because you can do things other people can’t. You add value by doing those things. Your standing in the room is based on your technical credibility, which is demonstrated by doing.

Now move that person into an architecture role. Their technical credibility is real. They absolutely know things. But the way that competence is supposed to be expressed has fundamentally changed. You no longer add value by building. You add value by enabling others to build better than they would have on their own.

That’s a different answer to the question “what do I actually do here?” And for someone whose identity has been built on the previous answer, the new one can feel hollow for a long time before it starts to feel true.

The moment it usually comes to a head

There’s almost always a specific moment in a new architect’s first year where this identity tension gets acute.

The honeymoon period of the new role is over. They’ve been in meetings, drawn diagrams, reviewed designs. And someone asks some version of the question: “What have you been working on lately?”

And the honest answer is uncomfortable. “I’ve been in a lot of conversations. I’ve been thinking about how we should restructure the data layer. I’ve been trying to get the platform team and the product team aligned on the API contract. I’ve been reviewing and providing feedback on a lot of designs.”

None of that sounds like working to someone whose definition of work is “producing tangible output.” Including, often, the architect themselves.

This is the moment where a lot of people start drifting back toward implementation. Not because the architectural work isn’t important, but because the psychological feedback loop is much weaker. Building something gives you immediate evidence that you did something. Shaping a conversation that eventually leads to a better system decision gives you evidence three months later, indirectly, and it’s hard to draw a clear line from your contribution to the outcome.

What the new identity actually looks like

The identity shift that works involves moving from “I am the person who builds the best things” to “I am the person who creates the conditions for the best things to get built.”

That sounds like a small reframe, but it isn’t. It changes almost everything about how you think about your day, your value, and your success criteria.

When your identity is the first version, a week where you didn’t write code is a bad week. When your identity is the second version, a week where you unblocked three teams, shaped two major technical decisions, and built alignment between two groups that were heading for a costly collision is an excellent week. Even though your GitHub activity is empty.

The practical work of building this new identity involves a few things. First, getting explicit about what architectural output actually looks like. It’s documented decisions, design reviews, shared frameworks, improved team processes. Second, finding ways to make that work visible, both to yourself and to the people you work with. Third, getting comfortable with a longer feedback loop. The work of architecture compounds over months and years, not days and weeks.

The thing nobody tells you

What I wish someone had told me earlier, the discomfort you feel in the first year of an architecture role isn’t a signal that you’re in the wrong job. Rather, it’s a signal that you’re doing it right.

If you’re comfortable, you’re probably still doing developer work in an architect costume. If you’re a little disoriented, a little unsure whether you’re adding value, a little frustrated by the ambiguity of the role, that’s the transition actually happening.

The identity shift takes time. It takes practice. And it takes a willingness to sit with the discomfort long enough for the new answer to start feeling true.

The developers who make it through that transition tend to find something they didn’t expect on the other side. The work starts to feel bigger. The impact becomes harder to measure but easier to see. And the orchestra starts to sound like something you could never have produced with just one instrument.

Let me give you the numbers straight, because I think the industry has done a lot of hand-waving around them and that isn’t helping anyone.

Programmer employment in the U.S. fell more than 27% over the past two years. Entry-level technology hiring at the largest firms is down 25% year over year. These aren’t rounding errors or statistical noise. They represent hundreds of thousands of people who were working in software and aren’t anymore, and a significant reduction in the new-graduate hiring pipeline that has historically replenished the field.

At the same time, the Bureau of Labor Statistics projects growth of 18% over the next decade for the role they classify as “software developer,” which skews heavily toward design-oriented, architectural, systems-level work.

The industry isn’t shrinking. It’s being redrawn. And the line being drawn right now is one you need to understand, because your career is going to end up on one side of it or the other.

What’s actually being separated

The line isn’t between AI and humans. That framing is too simple and it leads to the wrong conclusions.

The line is between execution and origination.

Execution is the work of producing a known output from a known specification. Write this function. Implement this interface. Generate this boilerplate. Translate this requirement into running code. AI handles execution with great competence, increasing speed and dramatically decreasing cost.

Origination is the work of deciding what to build, why to build it this way instead of that way, what the implications are over a three-year horizon, and how all of these systems are going to fit together into something that serves actual people in actual organizations. AI does not do this. Not today, and not for the foreseeable future.

Execution is the majority of what a typical developer’s day looks like. That’s not a criticism. It’s an accurate description of where software development effort actually goes.

Origination is what architects do.

The mistake I see people making

When I talk to senior developers who are anxious about the AI shift, I notice a pattern. They’re watching what AI can do to individual tasks, and comparing it to their own ability to do those same tasks. “Can AI write this code as fast as I can?” And then they’re either reassured (no, not quite, I’m still faster) or anxious (yes, and it’s getting faster).

That’s the wrong comparison.

The right comparison is: “What kind of work is my organization still going to need humans to do in five years?” And the answer to that question is almost entirely in the origination category. Synthesis, judgment, systems thinking, trade-off evaluation, cross-team coordination, long-term architectural direction. The work where the value comes from experience, context, and judgment rather than the speed of execution.

If your career is built primarily on execution speed, the trend line is uncomfortable. If your career is built on origination depth, the future looks very bright.

AI makes origination work more valuable, not less.

AI does this by raising the floor of what execution can produce and therefore raises the stakes for whether the architectural decisions behind the execution are any good.

What this means practically

The developers who navigate this well aren’t the ones who get better at competing with AI. They’re the ones who move decisively to the work AI can’t do.

That’s the architect track. Now, this isn’t necessarily the formal “senior architect” title, though that matters too. Rather, more fundamentally, it’s shifting the center of gravity of your work from implementation to design, from execution to origination, and from building things to shaping the conditions under which the right things get built.

Most developers I know are ready for this shift earlier than they think. The technical foundation is usually there. What’s missing is the mental model for what the work actually looks like, and the confidence to step into a role that doesn’t reward the same behaviors that made you successful as a developer.

That’s the problem this Substack and the book behind it are trying to solve.

The honest caveat

I want to be careful not to make this sound simpler than it is.

Not every developer wants to be an architect. The architect track is genuinely different from the deep technical individual contributor track, and both are legitimate paths. If your joy is in the craft of building things with your own hands, there’s still a version of that career that works in an AI-augmented world. It just looks different than it did five years ago.

And the transition to architecture isn’t automatic. Wanting to do architectural work doesn’t mean you’re automatically good at it. There’s a real skill set to develop, and it starts with understanding what the job actually is.

That’s what I want to spend the next several weeks unpacking here.

The numbers are what they are. The question isn’t whether the industry is changing. It’s whether you’re going to get ahead of it.

Here’s a question I like to ask when I’m talking to clients. “What does a conductor actually do?”

The answers are predictable. “They keep everyone in time.” “They tell the musicians what to play.” “They interpret the score.” All of those are technically correct. But none of them get at the thing that makes the metaphor useful for software architects.

The conductor doesn’t make a sound.

Not one note. In a full symphony orchestra, you have a hundred or so musicians producing some of the most complex, layered, technically demanding music human beings have ever written. And the person standing in front of them, the one who shapes everything about what comes out of those instruments, produces exactly nothing.

This is the part that I find the most interesting. This is the part that matters.

What the conductor actually does

A conductor shapes outcomes they don’t personally execute. They hold the whole picture while each musician focuses on their part. They listen for what’s missing as much as what’s there. They communicate intent without prescribing every detail of how that intent gets realized. And they create the conditions where a hundred skilled people, each doing their own work, produce something none of them could have produced alone.

That is, almost exactly, what a software architect does.

A developer writes code. They produce something concrete, measurable, and immediate. There’s a tight feedback loop: write, run, see the result. The work of the developer is technical mastery, but it is direct execution with recognizable results.

An architect does something different. They quite simply create the conditions for great software to exist. They work at the level where the decisions are about systems, not implementations. Where the question isn’t “how does this function work” but “why are we building this system this way, and what does that choice imply?”

Here, in the world of architecture, the output isn’t a commit. The output is a decision, a framework, a direction that dozens of other people will spend months executing.

That’s a very different job. And the transition from one to the other is harder than most people expect, because it looks like a promotion but it’s actually a transformation.

The hardest word to stop saying

I’ve watched a lot of developers make the move into architecture. The ones who struggle almost always have the same problem. They keep saying “I’ll just...”

“I’ll just write a quick prototype to show them what I mean.”

“I’ll just fix this one thing while I’m in here.”

“I’ll just handle this edge case since I already understand the system better than anyone else.”

The “I’ll just” instinct is a developer instinct. It’s a good instinct when you’re a developer. It produces results, it unblocks teams, it gets things done.

But when you’re an architect, “I’ll just” is the beginning of a bottleneck. Every time you pull the work back to yourself, you’ve subtracted one opportunity for the team to grow. You’ve reinforced the idea that the system can’t move without you. And you’ve forced the organization to move only as fast as you can move yourself.

The conductor who grabs the oboe and plays the solo themselves isn’t helping the orchestra. They’re undermining it.

It’s not about being hands-off

I want to be careful here, because this is where the metaphor can mislead people.

The best conductors I know of, musically and architecturally, are deeply hands-on in a very specific sense. They’re present. They’re listening hard. They have strong opinions about what’s happening and they make those opinions heard.

They’re not passive.

They’re not absent.

They’re not delegating into a void and hoping it works out.

The difference is where they put their hands. The conductor puts their hands on tempo, dynamics, interpretation, cohesion. They work on the music, not the instrument. The architect puts their hands on decisions, trade-offs, direction, the shape of the system over time. They work on the architecture, not the implementation.

That distinction sounds clean on paper. In practice, it requires a kind of discipline that doesn’t come naturally to people who spent years being rewarded for exactly the opposite behavior.

What this means on Monday morning

If you’re making the transition from developer to architect, here’s a useful question to ask yourself at the end of each week: “What did I actually produce this week that wasn’t code?”

A decision documented. A trade-off explained. A design reviewed and improved. A conversation that unblocked three people’s work. A framework that a team can now use without asking you first.

Those are the outputs of an architect. They’re less visible than code. They don’t show up in a pull request. They don’t always feel like work in the same immediate, satisfying way. But they’re the work that scales.

They’re the notes that make up the music.

The violin is a beautiful instrument. But someone has to put down the bow and pick up the baton.

That’s what this transition is really about.

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.

Hello friends,

The Software Conductor is now available worldwide!

I’ve been writing this book for the better part of three years. It started as a “Think Like a Software Architect” guide. I wrote the tome, lots of pages, nice and thick, just the way tech books should be. I even had a publisher ready to publish it and I had mentioned it on social media.

But, I hated it.

So, I dropped the publisher. I scraped most of the book. And I started over again. I needed something that was useful, and timely. Not long and dull.

The Software Conductor was the answer. It’s the answer to a question I’ve been hearing from developers, architects, and engineering leaders almost every week:

In this new AI world, how do I stay relevant?

This isn’t a long book, it’s less than 150 pages total. And it’s not a text book.

Rather, it’s a story...

It’s the story of Aaron Blake, a senior developer who is burning out doing exactly what AI is starting to do well. He meets a symphony conductor named Anton Weiss who teaches him the difference between playing an instrument and conducting an orchestra.

By the end of the book, Aaron has done the hardest thing a developer can do. He has become an architect.

Interspersed between story chapters are practical interludes that turns the story’s lessons into a working framework. It reads like a novel, but gives practical and actionable advice.

If you’ve ever caught yourself wondering whether the path you’re on is the right one for the next ten years, this book is for you.

Buy Now on Amazon

Lee

The book that AI made urgent.

Programmer employment in the U.S. fell more than 27% in two years. AI is absorbing the routine parts of software work, and the only path forward is architecture: synthesis, judgment, and original thinking that AI cannot do.

The Software Conductor is the story of Aaron Blake, a senior developer who learns from a symphony conductor what it really means to lead software. A violinist makes sound. A conductor makes music. A developer writes code. An architect creates the conditions for great software to exist.

The metaphor isn’t a clever framing device. It’s a working mental model. Each story chapter pairs with a practical interlude that turns the lesson into a Monday-morning framework, so the book reads like a novel and works like a handbook.

This is the book for the senior developer who suspects they’re ready for more, the new architect who feels lost without the keyboard, and the engineering leader supporting people through the transition that AI is now making urgent.

Welcome to The Software Conductor.