#270 - Stop Being the Hero: How Developers Become Great Software Architects - Lee Atchison

[00:02:02] Introduction

Henry Suryawirawan: Hello, everyone. Welcome to another episode of the Tech Lead Journal podcast. Today, I have with me Lee Atchison. He’s someone who is very active in software architecture. He has done a lot of, you know, big distributed systems. And today we are going to talk about a book that I think is quite rare, available in the industry out there. The title is called The Software Conductor. So this book is basically telling us, you know, a journey about someone who is a hands-on developer turning into a software architect. So for those of you who are also interested in going through the same journey from, you know, maybe a hands-on software developer into software architect, I hope you can learn a lot from Lee, how we can transition in a much better way. So welcome to the show, Lee.

Lee Atchison: Thank you, Henry. It’s great to be here. I really appreciate you bringing me onto your show.

[00:02:53] What Is the Story Behind Writing “The Software Conductor”?

Henry Suryawirawan: Right. So maybe first of all, let’s start by, you know, asking you why did you come up with this book, right? Because I think, again, this is quite a rare topic, that people pick up in the industry, especially now given the AI craze that is happening. So maybe tell us the story behind why you wrote this book.

Lee Atchison: Sure. So actually, I wrote the book three times. Yeah, I started with what I called the tome, the big, thick architecture book that everyone writes, you know. And it’s like, it’s not my first book I’ve written. I’ve written for O’Reilly Media and other companies before. But this one was for another publisher that really wanted the big, thick architecture book about how to become an architect. And so I started writing that for them. We were… I was almost done. They were happy with the book. I absolutely was not. I didn’t like it, what I wrote. What I found was it was all technically correct and everything. Everything was great in it. But I found the book was lifeless. It didn’t really have a soul to it that I could feel proud about. And I didn’t know why.

So I decided to… You know, I broke the connection with the publisher, I canceled the contract, and we went our separate ways, and everyone was fine with that. But I tried rewriting it, thinking that maybe that’s what it took, but it didn’t do anything. It didn’t solve the problem. What I realized was that I was teaching architecture the way that I used to lead it when I wasn’t successful at leading it. And that is by, you know, from the front of the room with diagrams, telling people what to do. And that’s not the way you do architecture. That’s not the way you, that’s, you’re supposed to be when you’re a software architect. But that’s the way the book was feeling. And so I was, you know, the dictator of the page is the phrase I used at the time. And it was like, you know, I was dictating what to do, but I wasn’t giving guidance on what and why you wanted to do that, or how to actually make that happen. So I knew I had to do something different. I didn’t quite know what yet, but I knew I had to do something different.

But then I remember way, way back, very early in my career, I read a book called The One Minute Manager, which was, I read it when I first took on the f- my first employees working for me, and I took on people management responsibilities, and I wanted to be the perfect manager, the great manager. And so I read this book, and, you know, what it was, was it was a management book that taught me management by not being a management book, okay? You know, it was a story. And what– It was a story about how, you know, the path, a journey of someone becoming a manager and the lessons they learned along the way. And that’s when it clicked to me that that’s really what I needed to write for the software architecture journey. And that’s when I shifted gears entirely, and this, you know, 500-page tome turned into a 100-page story. And I wrote a, I wrote it in a story form, and the story form is what I ended up publishing. And think it tells the story that really needs to be told, which isn’t how to do architecture. There’s a lot of books that do that. But it tells you what being an architect, how that’s different from being a developer, and how to make the transition. And there’s a lot of stumbling blocks there, and it talks about how to make that happen, and it teaches that story along the way.

[00:06:22] Why Do Promoted Heroes Struggle as Software Architects?

Henry Suryawirawan: Yeah, very interesting story. You had to rewrite this book three times, just because you didn’t feel right, right? So I think many people in the industry still think architect works kind of like the way you describe it in the beginning, right? So they came with, I don’t know, like, the ultimate answer. They knew everything, and they dictated people on what to do. So I think I still see these kind of behavior still in the industry, I think, typically, right? So why the approach actually doesn’t work, right? So maybe from your experience, because you said it was the style that didn’t work for you. But why, you know, something that people need to be aware of?

Lee Atchison: Yeah, so I think what happens a lot of times, and this is certainly what happened with me, is the people who get promoted out of software development are the heroes of software development. You know, they’re … they do their job because, you know, they’re great at writing code. They write the best code. They go off and they do all the things they’re supposed to do, and they’re the ones that everyone turns to when something doesn’t work quite right or they wanna learn how something works. You know, they’re the ones that people turn to. They’re the heroes of the development organization. So let’s promote them. Let’s turn them into managers, or let’s turn them into architects. And that’s the way people turn into software architects, is from this hero mentality. Well, the hero mentality is a self-centered mentality where you’re asked to do something, you do it, and you move on to do something else. And that’s all it is.

And the architect role is a very different role, though. You don’t accomplish anything as a software architect. You accomplish through other people. And that’s where the story comes from, where … You know, the story I use throughout … what the story is about, I should give you a little bit of background what the story is trying to talk about in the book, is it’s a story of Aaron who meets someone who ends up being his mentor. His name is Anton, and he’s an orchestra conductor. And a very different career path, very different direction, but he learns how to become a software architect by talking to Anton, who’s the orchestra conductor. And there’s a real strong parallel, and it’s a parallel that I use a lot in my communication with people about software architecture. But there’s a very strong parallel between the being a orchestra conductor and being a software architect. Because an orchestra conductor is the only person of the orchestra who doesn’t make a sound, yet without them, there’s no music.

And the same thing’s true in software architecture. A good software architect doesn’t write a line of code, doesn’t do anything, doesn’t, isn’t a, isn’t hero-developing code at all. They’re helping others to accomplish their goals and to create the systems and the processes and the flow. The flow is one of the words I use in the book. The flow between the different pieces to create a whole that becomes the system that’s being built. And that’s the difference. You- what you do as a software architect day-to-day is very different than what you do as a developer. Just like the conductor’s role is very different than the lead, you know, violinist. Their role is very different, and you don’t do the same sorts of things.

Henry Suryawirawan: Yeah, hence the title of your book, right? The Software Conductor. I actually like reading your book because I initially thought it would be, you know, like more prescriptive, a lot of, you know, all these theoretical thing. But the moment, you know, you brought up about the story, there’s a lot of parallel actually that I think readers can learn from there. And it’s a very light reading as well. So, and I like the w- what the phrase that you mentioned, right? As a conductor, right, he’s the only person who didn’t make the sound. Maybe just the moves, you know, this coordination thing. But there will be no music if, you know, he doesn’t do his work right. So I think we can see a lot in software development teams, right? An effective architect probably shouldn’t be the one who is writing the most code, you know, building all these, you know, frameworks and all that, right? But orchestrating people to work more effectively. So I really love that.

[00:10:52] What Does a Fractional Software Architect Actually Do?

Henry Suryawirawan: So maybe before we go into your book, right? So currently you are helping people as well in terms of doing software architecture, right? So sometimes doing fractional software architect and all that. So I rarely hear about fractional software architect. Maybe share a little bit more about this role, right?

Lee Atchison: Sure.

Henry Suryawirawan: What exactly do you do? Because if you are doing conductor as a full-time software architect, what does the fractional do actually?

Lee Atchison: Yeah, it’s a good question. It’s, and I’ll be completely honest, you know, the term fractional chief architect, it reads well on LinkedIn, but in practice, really what I do is I go and I help the organizations with their software architecture issues. So I’ll help maybe, you know, lead someone become a software architect or help an organization decide which direction they should be headed or where they’re doing things right or where they do- should be working differently. And a lot of that comes from my historical background, my background with Amazon in particular, and my focus on cloud computing. I have a lot of knowledge about a lot of the early days of the cloud and how things work and how to build cloud systems. And a lot of my consulting work as architecture is to bring in that expertise to help an organization that maybe hasn’t made a cloud migration yet and I help them figure out how to do that. So yeah, I think the, a real true chief architect isn’t something you can do fractionally from external. It’s something that’s part of the organization and needs to be part of the organization. But, what I do is I help those people make their jobs successful.

[00:12:29] Is Software Architecture an IC or Management Path?

Henry Suryawirawan: Right. Thanks for sharing that. Yeah, so I think another key parallel I would say, right. So for software developers who want to move on in their career, right, like being promoted and all that, typically there are two paths, right? Being the IC, right, maybe staff software engineer, principal software engineer and all that. And the other one is engineering management, right? Which is more like leading people, manage people and all that. Where do you see, you know, like software architect resides? Is it more on the individual contributor side? Is it more on the engineering management side? Because from reading your book, I can see there are still these two paths that architect is dealing with. So tell us where does, you know, software architect typically work in?

Lee Atchison: Well, there’s a lot of parallel between software architect and the dev manager role. You know, they typically both come from an individual contributor, and they move up usually as a result of being promoted, perhaps for the wrong reasons. Like I say, the hero developer moving into one of those roles. And they also share one other commonality, and that is almost every new manager I know and new software architect I know has the worst feeling about their job the first year. Because they don’t know what they’re supposed to be doing, and they don’t know how they’re judged. And how they’re judged and how they’re, what’s considered successful is radically different than what they were doing before. But that’s kind of where the similarity ends. And then there’s some meaningful difference between those two, the management role and the software architect role. And that is the management role gets authority, right? You know, they have an org chart, they have direct reports, they have a structural title. The architect gets none of that. You know, they have to lead teams just like the manager does, but they lead teams that they don’t manage. They lead teams that they are not organizationally in control of. So they have to lead by influence. And every time they go into a room, they have to prove their ability to lead over and over and over again because it’s not granted to them by the organization, it’s granted only by their actions and how they, and what they do.

And so the manager’s unit of work is people, careers, things like that. But an architect’s systems and decisions, yet they have to work with those systems and decisions not directly, but through other people. So in some aspects, the architect role is harder, but it’s just, it, I don’t think really it’s harder. I think it’s just different. And quite frankly, it’s a very different role. I’ve done both. I learned very early in my career that I was a good architect. I wasn’t a good manager. I hate managing large quantities of people. I’ve managed large groups of people before, and, you know, I don’t wanna deal with those issues. I’m glad to have mana- a manager do that for me. I’d rather deal with the systems, de- work with people, but deal with the systems. And so that’s what worked for me. Other people are different. Other people like the people aspects. But they’re similar. They’re parallel steps maybe, if you will, up the management, up the organizational food chain, if you will. But they’re very different, as far as the skills and the sorts of mindset that it takes to become each of those two different roles.

[00:16:08] Do You Need to Know Everything to Lead with Influence?

Henry Suryawirawan: Yeah. Leading with influence, I think it’s always hard, right? So it’s easier when you have the authority, definitely, right? So which brings me to the question, right? Because if you have to lead with influence, isn’t that you should, you know, have the skillset, I mean, like, or the perspectives from other people that you seem to know many things, right? And you’re the smart guy. You have dealt with a lot of things in the past as well. Like is that the true way of leading with influence? Or, you know, is there a way where you actually don’t need to know everything, but somehow you can lead with influence more effectively?

Lee Atchison: Well, the– you can’t be successful if you have the mindset that you have to know everything. And so you shouldn’t have that mindset. You don’t know everything, and you, you shouldn’t act like you know everything either. And the real thing that, the thing that you do as the architect isn’t to know everything, but to know how everything works overall, and let the depth of what is needed come from the individuals. And so you need to know that these areas work well with these people doing these sorts of problems and working. The– and the problems they’re running into are gonna be the sorts of things that this group over here can solve for them and work with them. And then make the connections and make sure they’re talking, and make sure all the right pieces work together correctly, both as an organization and people talking, but also as a system and an application talking within itself. And so, you very much have a breadth-first approach when you’re an architect. You have to know a little bit about a lot of topics. You have to know a little bit about everything going on within the organization, but you don’t know the depth. You don’t need to know the depth. And in fact, you fail if you rely on your depth, because you shouldn’t have all the answers. You should garnish the answers out of the individuals within the organization.

[00:18:08] What Are the Four Ways Architects Fail in Hero Mode?

Henry Suryawirawan: Yeah, so I think it’s always the hardest thing, right? Especially if you were promoted because you are the hero, right? So-called the rockstar developer, right, in the past. I think it’s always difficult to go to this mode, right? Simply because, if you like being hands-on, right, it’s always the first thing that you have to let go, right? So tell us maybe from your experience, how do you actually let go? How do you actually let go writing code, knowing about the system inside out and all that?

Lee Atchison: So I think the biggest thing is, you know, if you know the… There’s four real ways that you can fail as an architect, and they all come back from this hero mode, right? You know, the first one is to think that you have to have all the answers. We talked about that briefly a little bit. But good ideas aren’t yours, they’re the ones that you get out of other people. And so if you… You don’t want to have all the answers, but you want to have ability to get the good answers out of other people.

And what’s important about that is that become- makes you an enabler of decisions within the organization. A good architect doesn’t make all the decisions. A good architect makes sure that good decisions get made within the organization, and that’s how you scale an organization. I mean you can’t scale an organization if all the decisions have to come through a central point. You scale an organization by making sure that decisions can flow outwards.

And that also is a way to spread knowledge. You can’t scale an organization if all the knowledge is centralized in one person, as well as the fact that that is risky for the organization to have all knowledge in a single person. And if you’re, if a single person’s making all the decisions, all the knowledge is within that one person’s mind. But if, again, if you successfully make it so that the rest of the organization makes the decisions, that means the knowledge and the experience it takes to make those decisions is also distributed, and that helps make the organization grow as well.

And it also helps make sure that you’re doing, you know, the last part of the architect role, which is really important, and that is growing your own successor, right? You don’t want to… Everyone should always be growing their successor in whatever job they’re doing. But that’s also true with a software architect, and that’s something that a lot of software architects don’t do. By making all the decisions, you’re not growing a successor. But by allowing others to make the decisions and to grow their knowledge of how the system works, you’re building in your own succession plan as you go along.

Henry Suryawirawan: Wow. I really like, all these, so-called failure modes, right, that you mentioned, right? So I think they shouldn’t know everything, right? They should not make all the decisions. They should not hold all the knowledge and information, right? And they should not be always the one there, right? So you have to grow your successor as well. So I think that’s really beautiful.

[00:21:06] What Five Questions Help Architects Spot Problems Before They Break?

Henry Suryawirawan: So maybe let’s dive deeper into the book, right? So I think I like the first few chapters. This is like also the Phoenix Project and all those, those kind of book, right, where you tell the gloomy story first, right? How it all started, right? All this chaos.

Lee Atchison: Yeah.

Henry Suryawirawan: Yeah. So I like to pick up from, you know, like the story behind the first few chapters of your book, right? You’re basically advising architect to actually figure out potential imbalance that they can observe within the system, within the team members and all that before it actually breaks. Because typically in the industry, many software architects work by, you know, chaos, right? When something breaks already, they get pulled in to fix the issues. But actually you mentioned that software architects needs to observe, right? Like a conductor, observe, see where potentially things might break before it actually breaks. So tell us why this importance is something that architect need to be aware of.

Lee Atchison: Yeah, it’s, you know, the thrive in chaos is really the place that the heroes love and where the heroes thrive. You know what the story in the book I talk about is Aaron, who’s the hero developer that becomes architect. He’s the one that when the system breaks, everyone gets into Slack and asks him, “What’s wrong? What’s wrong?” And his first instinct is always to sit down at a computer, find the problem, fix it, and move on. And that causes him to always be working till 2:00 in the morning and, you know, all of those sorts of normal hero things that you have to go through, and he’s just gotten tired of that. And that’s where he’s, that’s when he’s pulled away by his friend who, and brought to a concert with this orchestra conductor who’s doing the concert and where he’s at, where he loves what this person is doing. And he meets the conductor, and the conductor tells him, the conductor’s name is Anton, and he tells Aaron that he always asks his orchestra members five questions.

And the same five questions, adjusted appropriately, are great questions for the architect to be asking for the organization to get out of the hero mode. You know, the five questions the the conductor always asks is, you know, “What are you playing?” Which is, you know, to his, to the, to the, you know, the violinists and the oboe players, et cetera. What are you playing? And that’s really the same thing as the architect saying, “What’s your purpose? What are you trying to accomplish? Who are you playing with?” That’s really your dependencies, your both bidirectional dependencies, who you depend on, who depends on you. “Can you hear each other?” That’s really about communicating. Are the individual parts of the organization that need to be working on a problem talking appropriately and doing the right things? “Are you in tune?” You know, are you following the right standards, the right shared expectations, the right systems? That’s the analogy there. And one that’s maybe not the perfect match is, “Do you know when to stop?” And that is, you know, what, do you know when to give up and have somebody else take over from where you were? What are your constraints? Where does your part end and somebody else’s part begins? And architecture really is useful when it stops pretending to be mystical. I mean, you know, people think of architecture as a mystical concept, and it’s really best when you can come down and say, “No, it’s really the same as this.” And if you make this work, it really is nothing mystical about it anymore.

Henry Suryawirawan: So yeah, I like the five questions you mentioned, right? So first, do you know what is your purpose, right? Like what are you playing in the whole, you know, orchestra, right? What you’re playing, who you are, you know, playing with, you know, like the team members, your dependencies, right, your stakeholders and all that. Can you hear each other? I think this is a very important question, I feel, ‘cause sometimes we just do our work, but we don’t actually kind of like listen to each other, right? Sometimes especially with, when you work with third parties, right, dependencies and all that, you just focus on your own. And then are you in tune? This is also another thing. I feel it’s important, right, because sometimes you just do the thing, but you may not be in tune with others, right? Maybe from architecture, be it, you know, the integration side or be it the API spec or be it even like how you collaborate with each other, right? So I think that’s important. And yeah, the last one, know when to stop, right? Know when probably, you know, there are constraints, maybe there are danger signs, and how to loop in other people to help. I think this is also very important. So I really like this question. I think everyone who listen can really ask this as well, maybe, as part of your role, right, or maybe just as a reflection within your software team, right? So I think this is always a good thing to reflect.

[00:25:57] Why Is Empathy at Scale a Crucial Skill for Software Architects?

Henry Suryawirawan: So another thing that I pick up from the book, you mentioned that architect is actually empathy at scale. So this is the side which I think did not get covered a lot in a lot of resources I read about software architecture. So knowing how, you know, other people work, right, empathize with them, their situations, their problems and all that, not always necessarily just focus on, you know, the system, the code, right, or the binaries, right? So tell us why architects should also pick up this empathy at scale.

Lee Atchison: Well, you know, you’ve heard this before, but, you know, there’s three things. There’s technology, there’s process, and there’s people. You need all three of those for a system to work. Architects really at the center of all three of those. They have to know the technology. They help create the processes, or they’re at the center of the processes, but they can’t do any of that on their own. They have to do it with people. So they’re really at the middle of that people part, and that’s where the empathy comes from. You know what? Most failures in the system are, they’re not really bugs, they’re connections that have gone awry or have gone quiet. So there are teams that have stopped talking to each other, or service owners that no longer talk to each other, or services that, you know, that aren’t, are no longer in sync and no longer working correctly.

So the code problems that exist that create the bugs, that create the problems are the symptom, but the connection between the people is really the cause of that. So, you know, in practice, what architects really have to do is they have to, you know, listen for the human concern inside, you know, a technical objection. If someone has a technical objection, what is the real reason behind that objection? Is it really a technical issue, or is there an emotional or a human reason behind it? Not necessarily emotional, but a human reason behind it. Pushback from people is rarely about a legitimate design decision, and it’s usually more about, you know, fear of a change or fear of a loss, or fear of doing something that… you know, it’s around fear, right? It’s around fear of not getting what makes sense for them to do.

So stop telling people what to build and start asking them, “What do you need to build?” Or, “What do you need to accomplish what you want to do?” And then your job then is to fulfill those needs with all the other teams then to create the flow that works off, works together. The flow is the orchestra and working to create music instead of just noise. And the flow for a software architecture is creating the system that takes all the needs of everyone’s into account as the system is built and created.

Henry Suryawirawan: Yeah, so I think, I always remember whenever I have discussions with architect, we always argue about, you know, the best, you know, I don’t know, like programming language, tech stack, frameworks, you know, software architecture and things like that, right? But what you’re saying is actually architects should be able to kind of like pick the cue from the human aspects, right? Not necessarily just the best ideas win, right? So, but understand the concerns that people have, you know, the fear, especially when we wanna change something, right? So definitely these aspects is kind of like probably undertrained for some architects because typically like what you said, right, they are having hero mentality, they wanna dictate stuff, and they wanna come up with the best answers for other people to follow.

[00:29:34] Why Should Software Architects Act as Mentors Rather Than Dictators?

Henry Suryawirawan: So empathy, I think it’s something that architects need to be aware of. Which leads me to the next question, which is kind of like a bit interrelated, right? So you mentioned that architect should be a mentor, right? Teaching people how to do stuff, right, instead of being the dictator, right? Instructing people to do it this way, right? So tell us this difference of, you know, like being a teacher, being a mentor versus someone who dictates stuff.

Lee Atchison: Yeah, so I, you know, in about the middle of the book, I’m not sure exactly where, what chapter number it is, Aaron and Anton in their mentor relationship, Anton has another friend who he introduces Aaron to, and that is, Marcus, who is an offensive coordinator for a football team. And, you know, and Aaron, you know, loves this because he loves football, right, and everything. And he… Marcus asks Aaron, “What do you think my job is?” And Aaron says, “Well, you design all the plays for the team, right?” You know. And Marcus says, “No, designing plays is only about 20% of my job. The other 80% is teaching people how to see.” And that was really the driver behind this mentoring aspect, is he saw his job not at coming up with the plays, but to figuring out what is keeping other people from being able to do the plays that they need to be able to do. How, what’s keeping them from fulfilling their role within the constraints of the football team? And, you know, you can’t lead a team when you’re trying to catch the ball, right? So if you’re still trying to design the play, if you’re still trying be the person that catches the ball, you can’t be the one that figures out who should be where, and why when a play fails, it’s because, you know, so and so wasn’t able to fulfill their role. Well, why weren’t they able to? And what happened? And what can you do to make that better?

And so a mentor really is all about helping individuals overcome their obstacles versus telling them what they need to do. You know, there’s all sorts of people who can tell them what to do, who can teach them what to do. Their job is to help them overcome the obstacles from being able to accomplish what their job is. That’s part of the biggest change there, right? You know, they’re a teacher, not a dictator, but they’re also a obstacle remover, not a dictator, right? They’re the ones that help them figure out how to learn, how to do what they need to do, not actually tell them what to do.

Henry Suryawirawan: Yeah, teaching others how to see. I think that’s a pretty good way of summarizing it, right? So enable other people, right, to make decisions, right? Coming back to what you mentioned in the beginning, right? So making sure that people can make good decisions by themselves, right? And such that the decision can flow, right? It’s not like always coming to you as a bottleneck at the end of the day.

Lee Atchison: And as an architect there’s actually a good test of this, by the way, if I could get this in. And that is, you know, if you– when you go into a room where a decision’s being made, the question you should ask yourself as an architect is, can that same decision be made next time without you in the room? And if the answer is no, you didn’t teach, you decided. If the answer is yes, you’ve taught, and you are a successful architect. That’s really the key. You wanna make it so that decisions can be made, not make the decisions.

Henry Suryawirawan: Right. Wow, I think it’s, that’s quite important point because people assume after decision is made, then yeah, just move on and do the thing, right? But yeah, I actually think that if you can explain the rationale and spread the reason why, right, and let others also make the same decisions probably next time, I think that’s a very good effective way of measuring whether you have done all this teaching aspect versus the dictating aspect, right?

[00:33:49] How Do Architects Manage Constant Context Switching?

Henry Suryawirawan: So I think really love that. So one other part typically a software architect does the role is actually to be pulled in so many different directions, so many different systems, fixing fires here, you know, dealing with other problems somewhere. And there’s a lot of context switching. There’s a lot of things that us software architects need to know how. And when you talk about the empathy as well, there’s a lot of people aspects that software architects need to deal with. Maybe, you know, working with the rockstar developers, maybe working with tough stakeholders and things like that. Is there any advice here that you can give architect as well such that, you know, they can manage this context switching and, you know, the dynamics, the complexity that they have to deal with?

Lee Atchison: Yeah, and again, I think the, the biggest thing is to understand your responsibility as the architect is not depth, it’s breadth. And so, you know, you need to depend on your experts to have the depth of knowledge as needed to solve a given problem. But you need to know enough about it in order to find how the decisions they’re making impacts the rest of the project or the rest of the system or rest of the organization. And so you need to know enough to be able to do that. And so you can go to the other groups and say, “Hey, this is what’s going on here. How does that impact you?” You’re still asking questions, you’re still letting them make decisions, but you’re the ones that are one that’s fostering the flow between them to create that knowledge and make that knowledge work.

So the real important things here is, you know, as a developer, you focus. You focus on a thing. But as the architect, you need to do a lot more context switching with a lot more smaller granular pieces. You work with sand, not big rocks, using the, you know, the, using that analogy. You work with sand, not big rocks. So you need to be able to flow the sand through the system versus understanding how a big rock works. And that’s really the biggest thing to do.

How do you make that happen? You know, staying away from the deep conversations is the first one. Staying out of the deep conversations is, you know, is the most critical piece. Asking more questions than statements. You’ll find as an architect, you should be asking more questions than you’re making statements. If you’re not make- asking more questions than statements, you’re not understanding how your organization works. And then I guess the rest of it is also part of the mindset and the, of what it is to be an architect. Because an architect is someone that can’t sit down and focus for long periods of time. They have to be able to context switch and flip back and forth from different areas and different topics, and be able to make a cohesive whole out of all of that. And so you have to be able to do a fast context switch in order to be a successful architect. And frankly, if you can’t, then maybe a senior arc- a senior developer role is a better role for you than an architect role.

Henry Suryawirawan: Yeah. I can see now a clear distinction, right? So if you like being hands-on doing deep focus work, right, and know the details and all that, probably like something like principal software engineer, you know, like being a real IC is something that is more appropriate for you. Although I think there are a lot of, how should I say, a perspective change that must happen in the industry because again, like I can see in the industry, people think architect is the ultimate person who makes a lot of decisions and, you know, like orchestrating others, dictating others to do stuff. So I think hopefully the perception can change as well, especially with the appearance of your book right? So yeah, hopefully that people can become better architect.

[00:37:37] Why Was AI Excluded from “The Software Conductor” Book?

Henry Suryawirawan: So I wanna touch on, you know, the big elephant in the room, definitely, right, the AI thing. So for a resource that come quite recently, your book actually very little I see, touching about AI

Lee Atchison: Yep.

Henry Suryawirawan: Which I think these days architects also have to deal with AI, I guess, right? So tell us the reason why you didn’t involve AI at all in the book.

Lee Atchison: It was actually intentional. I had initially written several chapters actually on AI and I decided just to strip them all out because, you know, for a couple of main reasons. One is, you know, the transition to architecture is really something that’s been around for 30 years, right? The architecture role has been around for 30, 30+ years. years And AI is such a new thing in that the things you need to learn to become an architect have nothing to do with AI. AI is a symptom of why people are looking to move to become an architect, or moving to become more of a principal engineer, moving into management, moving into whatever, because they’re afraid of their traditional software developer roles going away. It’s a symptom, but it’s not the role.

Well, my view on AI is AI is driving a need for more judgment within all of the development roles. Judgment’s becoming more important than anything else in, in the age of AI. So a software developer needs to grow in judgment in order to– in their ability to make judgment calls in order to be a better software developer. That’s critically important. But that’s nothing to do with the transition to architect which is a totally different thing altogether. That hasn’t been, that whole process hasn’t been affected by AI, and really isn’t affected by AI because it’s a different process that goes on there.

So now, I use AI in the subtitle of the book because it’s what’s driving the urgency for the need for this book, right? Because people want to know what’s next in their career, and this is one avenue that’s next in their career. And they want to know that because of AI. But really nothing about the transition is AI-specific. So I intentionally left AI out of the narrative.

Henry Suryawirawan: Right. so yeah, for people who are wondering, when you read about this book, why no AI part in this software architecture transition? So I think you get the answer there.

Lee Atchison: But it really is a human story, right? It’s a human s- the transition to architecture is a human story, not a, not an AI story.

[00:40:24] Does AI Really Turn Every Software Developer into a Tech Lead?

Henry Suryawirawan: Yeah. What I hear typically in the industry when people mention about, you know, the impact of AI to the jobs, right? Many people say that software engineers, just like what you mentioned, right, so they need to make a lot of judgment, judgment calls. And people associate this with, you know, every software developers now has to turn into something like a tech lead or software architect. So it’s like everyone starts as a software architect as a tech lead. So tell us your view on this. Is this the right framing of, you know, our new role as a software developer?

Lee Atchison: So I’ve written recently about a report that came out of GitClear just recently, and they’ve actually done a couple of different AI-related reports recently. And, but this most recent one, what they’ve discovered by examining GitHub repos that are public is that refactoring, in the age of AI, refactoring code is down 70%. Cross-file connectivity, is down 35%. Legacy code maintenance is down almost 75%. And code duplication and masking of errors is up significantly. What this really is showing, this is the effect of AI slop in our s- in our code base, is what’s happening.

So where, you know, AI isn’t replacing what developers are doing. They’re replacing… They’re enhancing what developers are already doing. So the best developers who write great code can use AI to write more and more and more great code. While early developers or lesser developers or the newer developers or the less experienced developers, when they use AI, they write poor quality code in general, and they write more of it using AI. And that’s what’s happening here, is that AI is enhancing the amount of code that’s produced, but it’s not enhancing the quality of code produced unless it is being done by people who can create the quality of code.

That’s why judgment, I mentioned judgment earlier, that’s why judgment is gonna be the tool of software developers in the future. And that’s why that’s gonna be really what’s important here. Notice I didn’t say architecture. Notice I didn’t say management. Notice I didn’t say principal level engineer. I said judgment, and judgment’s at all levels.

So it’s really important, you know, we start teaching this more with, and we start… And actually what, the software architect’s role in this is to help engineers understand the importance of judgment in what they’re doing, and that’s the role of a software architect in this whole process, is more of their mentoring role, if you will. But that’s really the solution to this issue. It’s not to up-level engineers and say, “All engineers now are gonna be senior level engineers, or tech leads, or whatever.” We have the need for all the roles within the organization that we had before. We still have those needs in the future organization, but we have a higher need for judgment in all those roles because AI is going to assist us, but not solve all of our problems.

Henry Suryawirawan: Wow, I like your framing of this, right? So yeah, people have to learn how to make a good judgment, right? Learn how to notice things when it goes sideways, right? So for example, coming back to earlier discussion, right, a good architect will actually figure out the imbalance that is happening, right? Maybe the risk of, you know, AI-assisted code, you know, churning out more code, but not with a good quality, right? So all these aspects definitely, maybe need people to actually learn the patterns, right? Like again, like teaching how, how to see, right? Teaching others how to see. And then making, you know, this intervention, you know, making sure there’s a guardrail policy in place, right? And ultimately making good judgment, right, such that your, you know, I don’t know, your architecture, your code quality is still kind of like in a good state.

[00:44:34] Is AI Policy and Governance Part of the Software Architect Role?

Henry Suryawirawan: So mentioning about judgment, you know, people associate also a lot with, you know, guardrails. You know, policy, governance on when using AI, right? Because it’s so much easy to produce code these days, but if you don’t have good judgment, good quality of, you know, governance and all that, right, people will still, you know, I don’t know, like follow the way AI advise stuff, right? So how can an organization do this better? Is this one part of a architecture, sorry, one part of architect’s role as well to actually come up with the policy and governance or is this something that someone else, kind of like have to make decision?

Lee Atchison: So it’s a good question. I think, you know, the architect’s role is to help create the environment where the guardrails are built and created correctly. They’re not the ones who come up with the governance, they’re the ones that help create them. And really, the right guardrails aren’t really policy documents, right? The right guardrails are the right process that allows developers to create what they need to create and to be proud of what they create. You know, they, the developers need to still be responsible for everything they produce, whether AI wrote it or they wrote it. And so their own self-guardrails become really the first line of defense to make that happen. I don’t think we’re seeing enough of that yet. I don’t think we’re seeing enough focus on that yet. I think we’re seeing developers realize that, “Hey, I can do, I can write 10x more code because I don’t have to pay attention to it as much anymore. I can do all these things and look at, I acted like 10 engineers. Isn’t this great?” That’s not the right role for them. Their role for them is to use AI to help alleviate the things that slow them down and to make it harder for them to write code, but not remove the responsibility for the code they develop.

You know, when I was… You know, I do a lot of writing of code on my own simply because, you know, I don’t get to do it professionally as much anymore, but I still love to code, so I write a lot on my own. But what I find is that, you know, I used to spend a lot of my time writing code, with dealing with bottlenecks in the code writing process itself. You know, what API parameters are needed for so and so, and how does this loop variable work. You know, all those sorts of little things that you, that take up 90% of your brain and 90% of your actions. Well, all that goes away with AI. AI can do all of that for you. You know, just build this API for me, fine, no problem. But that doesn’t change your job. Your job is still to make sure that the code that gets created is the code you want to get created, and is the right code and the right shape and the right size and everything’s correct. What AIs really should be doing for you is removing the obstacles for you to do what you really want to be doing, which is developing a good system.

Henry Suryawirawan: Yeah. So I think it’s a very important reminder, right? So because people think now with AI they can just produce a lot more code, a lot more output, right? But slowly the responsibility of understanding the system, understanding how the code gets produced is something that is kind of like starting to get eroded, right? People will start… I think I keep hearing as well, like in the conversations or in some posts that people say, oh, Claude says this, or maybe, I don’t know, AI suggests me that, or I don’t know how it got produced in the first place, right? So all these are kind of like signs, right? People call this also cognitive debt, intent debt, right? So, using the triple debt model that, you know, Margaret-Ann Storey came out, recently as well. So I think definitely there’s a lot of risk of using AI not in the right way. I like the way that you mentioned that it should not remove the responsibility of developer in deciding, right, the right size of the code, the right shape of the code, right, the right quality of the code. So definitely, it’s something, very important.

[00:48:41] What Are the Dangers of the AI Dark Factory Trend?

Henry Suryawirawan: So talking about, you know, removing responsibility, I’ve seen some trends in the industry where people, their ultimate aim is actually to create this thing called, I don’t know, like dark factory thing, right? Just like the photo, borrowing from a photo analogy, right? You have the dark room where, you know, photos get produced. In this case it’s dark factory, like you have a dark room where code gets produced somehow by AI. So a lot of things are turning into this trend now. Like people want to reduce number of developers and have AI fully automate it and build the system for us. This seems to be, you know, in contrast to what you just mentioned, right? So tell us about the danger of this trend.

Lee Atchison: First of all, I really think this trend, as we’re talking about, is on the rise of the hype curve, and it’s due for a big fall here coming very soon. So because I… W- it… And I, and you’re already starting to see some of this happen, right? You’re seeing, you know, vibe-coded applications that can’t go the next step because nobody understands how it works. And it’s too complex and too involved, and the bug rate becomes too convoluted for anyone to really understand what’s going on, so you have to throw it away and start over again, you know. And that’s what you get when you build a system that’s not understandable. And that’s what vibe coding does for you, is it builds systems that is not, that are not understandable.

Now I’m not against vibe coding. I think vibe coding’s great for prototyping, for trying new ideas, and to say, “Hey, what if we wanted something like this? Build it up, test it out. Everything’s great.” And it’s also great for maybe creating the initial foundations of an application. But it’s not great as a way of replacing the developer. And so these dark rooms we’re talking about here aren’t the way the software should be created, nor will it be created in the future. I think the whole concept of this dark room is a trend that’s going to disappear. It’s not gonna be long-term sustainable, and it’s not the way that we’re gonna be seeing software developed, you know, 10 years from now.

If you’re a new developer coming out, you know, that’s just starting into the industry now, you’re not gonna be replaced by a dark room. You might be replaced by engineers who can make better use of AI than you, and that’s something you should be aware of. You should make good use of AI in your job, but you’re not gonna be replaced by a dark room. That is just not the way it’s going to be. But hype is hype, and that’s what we’re seeing the hype with right now.

I see this very similar to the hype with the cloud computing. You know, I was very, very intimately involved with cloud computing. I was involved with the early days of creating cloud computing and when working at AWS. And we saw the same thing, or I saw the same thing. You know, everyone said, “Everything’s gonna be moving to the cloud, and nothing’s gonna exist anywhere but in the cloud. And oh, by the way, it’s all gonna be serverless.” And I… You have no idea the number of people who came to me at trade shows and s- and, you know, they would, you know, introduce me and say, “Oh, I love what you do. I love what you’re doing. Hey, I wanna tell you, we built our entire company using nothing but serverless code. Aren’t you proud of us?” And then I say, no. Did you use serverless for what it’s intended for, but not everything, right, you know. And so I think the same thing’s true here. I think, you know, AI is great at helping you build applications, and AI is the best thing to happen to software development ever. It’s also the worst thing to happen to software development ever.

And I think we’re, as we sort out the worst things from the best things, we’re gonna figure out the best things. Just like with cloud computing, we figured out, you know, the cloud native model and what works in the cloud and what doesn’t work in the cloud. That same thing is going to happen here with AI. In fact, I’m, I, One of my articles that’s going to go live, I think on Tuesday, is about AI native and how it compares to cloud native, and the move towards an AI native world, and what does that mean. And what you’re gonna find is it looks very different than the hype you’re seeing now. Just like the cloud looked very different than the cloud hype was when it first started. So don’t be distressed by the world of hype of AI right now. It’s going to settle down, and when it settles down, it’s gonna settle down to the point where AI is a truly useful tool for us, but isn’t replacing everything we do.

[00:53:23] What Are the Most Important Aspects of Being an AI-Native Team?

Henry Suryawirawan: Yeah. Maybe if you can get, give us a glimpse, because by the time this episode gets released, I’m sure your article has been published as well. So tell us some important aspects of being an AI-native team or organization.

Lee Atchison: Oh, sure, yeah. So the, you know, the big thing that I talk about with in the article is about the AI-focused applications and how you build an application that’s AI-native. And the fallacy that people are running into now is they say, “Well, let me add a chatbot and maybe one or two of my processes I’ll replace with an AI agent, and everything… now I’m an AI app. And, you know, look, I’m AI-centric now, right?” Well, AI-native is more about things like looking at what AI is good at and using, you know, structuring your application to take advantage of those things, but not everything.

You know, for instance, AI is non-deterministic. Most applications and most application development models right now are very deterministic, but can take advantage of non-deterministic aspects for various parts of what they’re trying to accomplish. Well, if you can feather out what parts of your application are enhanced by non-deterministic and use AI there, and keep the parts that aren’t out of that and keep them deterministic, you’re gonna be better off. So understanding the deterministic versus non-deterministic aspect is a great part of that.

You see now, what people are doing now though, is they’re doing things like how do we make AI more deterministic? And that’s not the right model. The AI native model is to leverage the non-determinism to… for the parts of your application that are enhanced by non-determinism. That’s one of the things. I think I come up with four things. I don’t remember what they all are offhand in the article, in this article, but that was one of the big ones.

And, you know, another one is sizing. I think a lot of things you see nowadays is a lot of companies that are just adding AI to their application say, “Okay, I’m gonna add a chat box, and I want it to be smart, so I’ll use the biggest model I can find, and I’ll use that for everything.” Well, the vast majority of what you need your, to use your, in your application for AI doesn’t need Fable or Opus. It works just fine with Haiku, you right? You know, you don’t need the power of a super strong model. You need just some non-deterministic help in building things and making things work and to, and to munge things. And so, another aspect of an AI native application is to understand the size and cost of model that’s appropriate for the type of job you’re trying to do, and then apply it in the right place and at the right time. So that’s another aspect of it.

The article will be on, in my newsletter at softwarearchitectureinsights.com. Hopefully you can put a link to that in the show notes. And it’ll be there. I’m not sure when this ar- when this episode will come out, but it’ll be there in the history if it’s not the most recent issue. It’ll be be one of them in the, in near past and you’ll be able to see it. But I write a lot about AI there, and I write a lot about software architecture there, obviously. And that’s just one of the topics I’m, I’ve been working on recently.

Henry Suryawirawan: Nice. Yeah, we’ll definitely put that in show notes. I was laughing when you mentioned like, people are trying hard to make AI more deterministic. I guess that’s kind of like the wrong trend that people are doing, I guess. Especially if they really still rely on the LLM, right? So the technology, the fundamentals behind all this, you know, AI model that we see in the industry. Because the LLM itself works probabilistically, right? So that means non-deterministic. So I think that’s a very good call-out that, I think we still have to remember, right? Remind ourselves, even though AI seems to be more like smarter, more powerful, seems to be able to do a lot of things, don’t forget like all the things that they produce are actually non-deterministic. And sometimes when you write software, you want to be more deterministic rather than non-deterministic. And I think AI is the best thing that happens to software development, but it could also be the worst thing. So I think that’s another one that I really like. So it’s like a double-edged sword. Pick the side that you prefer, I think, right, to summarize.

[00:57:52] 3 Tech Lead Wisdom

Henry Suryawirawan: Yeah. So Lee, thank you so much for this conversation. I think many people hopefully learn a lot about how to transition to becoming a good software architect, right? Remember, it’s the orchestra rather than the dictator. so before I let you go, I have one last question that I would like to ask you. I call this the three technical leadership wisdom. if you can think of them just like an advice you wanna give to the listeners before we close the conversation, that would be great.

Lee Atchison: Sure. I think you, you probably have heard all three of them so far in what I’ve been saying about the book. But, you know, the first one is, you know, listen before you lead. You know, the conductor’s most powerful tool is silence to listen. And that’s just as critical to us as software architects.

The second one is to judge… When you look at your week that you’ve just completed, judge the week by what your team shipped, not what you’ve shipped. Because your- what you do is less important than what your team does, and your value is really to make your team more productive. And to think that way is part of the process of moving out of the hero mentality.

And the third one, and this applies to everybody, not just software architects, but work yourself out of a job on purpose. Your job, your p- your, one of your main jobs is to always find your replacement and to train your replacement. And we don’t do enough of that as an industry. And it will hurt you and your opportunities to move on. I have seen so many people, in fact, it’s happened to me, where I couldn’t move on to the next job because I was too valuable in the job I was currently doing because nobody else could do it. And that’s my failing, not anybody else’s. So work yourself out of a job, always.

Henry Suryawirawan: Right. So one thing that people are trying to do is to use AI more to replace themselves. But there’s a lot of worry about, you know, junior developers who need to step up and become the successor. Yeah. So yeah, I think the, again, it’s a trend that many people are picking up. So hopefully we still ha- got junior software developer being able to transition to senior to software architect, right, to engineering managers and all that. So yeah, hopefully the, the trend is not going to the wrong ways.

So Lee, if people love this conversation, they wanna reach out to you, ask you more questions, or, you know, buy the book, is there a place where they can go online?

Lee Atchison: Sure. I’ll give you three, three places they can go. First, if you’re interested in the book, you can go to thesoftwareconductor.com and the book is there, and it’s available on Amazon. It’s available in some tech bookstores. And so you can get it any place that you would buy technical books. And if you wanna find out more about me and the things that I do, you can go to leeatchison.com. And if you want to read my writing and my articles and subscribe to my newsletter, softwarearchitectureinsights.com is where I do all of my weekly newsletter and my weekly writings.

Henry Suryawirawan: Yeah. And I would like to also call out that Lee has written quite a number of books, right? Not just, you know, like being a software architect, but the, like the usual architecture stuff as well. So make sure you check them out as well. So Lee, thank you so much for being in the show. I learned a lot personally. So hopefully other people can also learn from this conversation, so thank you for that.

Lee Atchison: Thank you, Henry. It was great to be here.

– End –