The Lesson at the Heart of The Software Conductor
|
By: Lee Atchison There's one idea in The Software Conductor that I keep coming back to, months after the book was finished. It's the one that took me the longest to really understand. It's easy to nod along with in the abstract. In practice, it costs something. It's the difference between conducting and playing. Not as a metaphor. As an actual description of what an architect's job is, and what it isn't. The Trap That Gets Almost EveryoneA conductor doesn't play every instrument. That much is obvious. But here's what's less obvious. A conductor who steps off the podium and picks up a violin when something goes wrong makes the music worse. The ensemble loses its coherence. The other musicians stop listening to each other and start watching the conductor. The music that results is less than what the musicians could have produced on their own. Most newly promoted architects do the equivalent of this on a regular basis. When something goes wrong, they jump in to fix it. When a decision needs to be made, they make it. When a team is stuck, they provide the answer. This feels like helping. It is helping, in the immediate term. But it produces a team that is progressively less capable of helping itself. The team learns to wait for the architect rather than developing the judgment to move forward on its own. This is what I call the Hero Trap in the book. The instinct that made someone a great developer is the willingness to dive in, to be the one who figures it out, to save the sprint. In the architectural role, that same instinct prevents the team from ever not needing to be saved. The conductor's job is not to play every instrument. It is to create the conditions in which each musician can find their part and play it well. When the music goes wrong, the conductor doesn't grab a violin. They listen for where the imbalance is, and they help the ensemble find its way back to coherence. That's the architectural role. It is responsible for harmony, not heroics. What the Teaching Approach Actually Looks LikeIn the book, Anton, the conductor who mentors Aaron, makes a distinction I've found useful in thinking about this. He says the hardest part of conducting isn't learning the notes. It's convincing the musicians that it's their music, not yours. The best architects I know operate this way. When a team is stuck on an architectural decision, they don't announce the answer. They ask questions that help the team develop the answer themselves. They surface the tradeoffs rather than resolving them. They make sure the team understands the reasoning behind each decision, so they can make similar decisions the next time without needing to escalate. This is slower, in the moment. It takes longer than just telling people what to do. But it compounds in the right direction. A team that has been taught to reason about architecture develops real judgment. That team can handle more without help next time. And the time after that. The dictating architect creates a team that is perpetually dependent. The teaching architect creates a team that becomes progressively more capable. The Organizational ConsequenceThere's a concrete organizational argument here that I think gets undersold in most discussions of architectural leadership style, so let me make it plainly. When an architect makes all the decisions, all the knowledge required to make those decisions stays with the architect. When they're on vacation, stuck in back-to-back meetings, or managing a crisis elsewhere, decisions get delayed or made badly. When they eventually leave the organization, that knowledge leaves with them. The transition is painful and slow. When an architect teaches rather than dictates, the knowledge distributes. It lives in the team. The team develops judgment that doesn't require the architect's presence to exercise. The architect becomes less indispensable in the best possible sense. They aren't doing less. They've built something that works beyond them. This is, ultimately, what a great architectural legacy looks like. Not the systems you designed. The judgment you developed in the people who will continue designing after you're gone. What's in the BookThe Software Conductor traces Aaron's journey from developer to architect through a series of conversations with Anton Weiss, a Seattle orchestra conductor who turns out to have a great deal to say about leading systems of complex, interconnected parts. The book alternates between narrative chapters, where the lessons land through story, and interlude chapters that unpack the ideas more directly for readers who want the practical application. The topics include the transition from developer to architect and what actually changes, how to lead without controlling, the architect as teacher rather than dictator, how to build judgment across a team, the big-picture vs. little-picture thinking shift, and how to understand your role as creating the conditions for others to do their best work. If you've been in this field for a while, some of it will feel familiar. The experience of recognizing something you knew but hadn't articulated is part of what the book is trying to produce. Other parts will be new. Or at least, they'll feel newly clear. Either way, I think it's worth your time. Which, admittedly, is what authors always say. But I wrote this one because the conversation needed to be had, and I haven't found it had this clearly anywhere else. The Software Conductor: A Journey of Discovery from Software Developer to Architect is available now in paperback, hardcover, and ebook. Pick up a copy here. And if you know someone making the transition from developer to architect, it makes a particularly good read for that moment in a career. Lee Atchison is a software architect, author, and technology thought leader. He is the author of Architecting for Scale (O'Reilly) and The Software Conductor, and was the founder and CTO of Product Genius, an AI startup. He writes about software architecture, cloud systems, and AI at Software Architecture Insights. |