# Software Architecture: Influence, Judgment, and AI Strategy

**Podcast:** Tech Lead Journal
**Published:** 2026-10-12

## Transcript

The people who get promoted out of software development are the heroes of software development.
They do their job because they're great at writing code.
They're the ones that everyone turns to when something doesn't work right.
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.
Today's guest is Lee Atchison, author of The Software Conductor and early AWS cloud veteran.
on how developers can become great software architects.
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.
These architects also have to deal with AI.
Your book actually, very little I see, touching about AI.
The architecture role has been around for 30 plus years.
And AI is such a new thing.
The things you need to learn to become an architect have nothing to do with AI.
AI is driving a need for more judgment within all of the development roles.
Judgment's becoming more important than anything else.
Notice I didn't say architecture.
I didn't say management.
I didn't say principal level engineer.
I said judgment and judgment's at all levels.
The software architect's role in this is to help engineers understand the importance of judgment and what they're doing.
Hey, quick pause.
My goal with Techly Journal is simple.
Learn from the best in tech so we can all grow together.
If this resonates with you, hit subscribe to follow the channel.
It's the biggest way for you to support the show and help us keep bringing great guests and insights to you.
Thanks for being here.
And let's get back to it.
Hello, everyone.
Welcome to another episode of the Tech Digital 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 maybe a hands-on software developer into software architect, I hope we can learn a lot from Lee how we can transition in a much better way.
So welcome to the show, Lee.
Thank you, Henry.
It's great to be here.
I really appreciate you bringing me onto your show.
Right.
So maybe first of all, let's start by asking you, why did you come up with this book?
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.
Sure.
So actually, I wrote the book three times.
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.
I, 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.
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'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 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 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, it was a story and what it was a story about how, you know.
the path 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 hundred page story.
And I wrote it, I wrote it in a story form and the story form is what I ended up publishing.
And, uh, I 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.
Yeah, very interesting story.
You had to rewrite this book three times just because you didn't feel right.
So I think many people in the industry still think architect works kind of like the way you describe it in the beginning.
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 this kind of behavior still in the industry, I think, typically.
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 something that people need to be aware of?
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.
They do their job because 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 and they want to learn how something works.
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 and 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.
The story I use throughout...
What the story is about, I should give you a little bit of background of 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 being an orchestra conductor and being a software architect.
Because an orchestra conductor is the only person in 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, 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.
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 violinist.
Their role is very different and you don't do the same sorts of things.
Yeah, hence the title of your book, right?
The Software Conductor.
I actually like reading your book because I initially thought it would be more prescriptive, a lot of...
you know, all these theoretical things.
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 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, building all these frameworks and all that, but orchestrating people to work more effectively.
So I really love that.
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.
What exactly do you do?
Because if you are doing a conductor as a full-time software architect, what does the fractional do, actually?
Yeah, it's a good question.
And I'll be completely honest.
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 lead someone to 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 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 architectures to bring in that expertise to help an organization that maybe hasn't made a cloud migration yet and help them figure out how to do that.
So, yeah, I think 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.
Right.
thanks for sharing that yeah so i think um another key parallel i would say right so um for software developers who want to move on in their career right like being promoted and all that typically there are two parts right being the ic right maybe staff software engineer principles of engine 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 parts that architect is dealing with.
So tell us where does, you know, software architect typically work in?
Well, there's a lot of parallel between software architect and the dev manager role.
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, a 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.
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.
And what they do.
And so the manager's unit of work is people, careers, things like that.
But an architect's is 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, 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 want to deal with those issues.
I'm glad to have a manager do that for me.
I'd rather deal with the systems, 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.
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 skill set, I mean, or the perspective 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?
Well, 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 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, and the problems they're running into are going to 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 breath-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.
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, 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?
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 you don't want to have all the answers, but you want to have the ability to get the good answers out of other people.
And what's important about that is that 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 a single person is making all the decisions, all the knowledge is within that one person's mind.
But 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 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.
Wow.
I really like all these software 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 success as well.
So I think that's really beautiful.
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 those kind of book, right?
Where you tell the gloomy story first, right?
How it all started, right?
All this chaos.
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 architects need to be aware of.
Yeah, it's, you know, the thrive in chaos is really the place that the heroes love and where the heroes thrive.
You know, 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 until two in the morning and 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 when he's pulled away by his friend and brought to a concert.
with this orchestra conductor who's doing the concert and 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 conductor always asks is, you know, what are you playing?
Which is, you know, to the, you know, the violinist 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.
You're both bi-directional 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 in a problem talking appropriately and doing the right things?
Are you in tune?
Are you following the right standards, the right shared expectations, the right systems?
That's the analogy there.
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.
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 orchestra while you're playing, who you are playing with, like the team members, your dependencies, your stakeholders and all that?
Can you hear each other?
I think this is a very important question, I feel.
Because sometimes we just do our work, but we don't actually kind of like listen to each other, right?
Sometimes, especially 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 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 listened 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.
So another thing that I pick up from the book you mentioned that architect is actually empathy at scale.
So this is the site which I think did not get cover a lot in a lot of resources I read about software architecture.
So knowing how other people work, empathize with them, their situations, their problems, and all that, not always necessarily just focus on the system, the code, or the binaries.
So tell us why architects should also pick up this empathy at scale.
Well, you've heard this before, but there's three things.
There's technology, there's process, and there's people.
You need all three of those for our system to work.
Architects really have to...
the center of all three of those.
They have to know the technology.
They help create the processes or they're in 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.
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.
There are teams that have stopped talking to each other or service owners and 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 to 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 and to...
create the flow that works together.
The flow is the orchestra and working to create music instead of just noise.
And the flow for software architecture is creating a system that takes all the needs of everyone into account as the system is built and created.
Yeah, so I think I always remember whenever I have discussions with architects, we always argue about, you know, the best.
I don't know, like programming language, tech stack, frameworks, software architecture and things like that.
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?
But understand the concerns that people have, the fear, especially when we want to change something, right?
So definitely these aspects is kind of like probably under-trained for some architects because typically like what you said, right?
They are having hero mentality.
They want to dictate stuff and they want to come up with the best answers for other people to follow.
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 architects 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, um, tell us, tell us this difference of, you know, like being a teacher, being a mentor, as someone who dictates stuff.
Yeah.
So I, you know, in the, about the middle of the book, I'm not sure exactly where, what chapter number it is.
Um, Aaron and Anton in their mentor relationship, Anton has another friend who he introduces Aaron to, and that is, um, Marcus, who is.
and offensive coordinator for a football team.
And, you know, 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 I 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.
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 to 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 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 um tell them what to do yeah teaching others how to see i think that's a pretty good way of summarizing it right um so enable other people right um 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.
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, 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 were a successful architect.
That's really the key.
You want to make it so that decisions can be made, not make the decisions.
Right.
Well, I think that's quite an important point because people assume after a decision is made, then 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 these teaching aspects versus the dictating aspect, right?
So I think I really love that.
So one other part, typically 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 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 rock star 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?
Yeah.
And again, I think that 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 that's 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 the 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 that analogy.
You work with sand, not big rock.
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?
Staying away from the deep conversations is the first one.
Staying out of the deep conversations is...
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 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 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 developer role is a better role for you than an architect role.
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 principles of 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, 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 architects.
So I want to 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, 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.
It was actually intentional.
I had initially written several chapters actually on AI, and I decided just to strip them all out for a couple of main reasons.
One is the transition to architecture is really something that's been around for 30 years.
The architecture role has been around for 30 plus years.
AI is such a new thing and 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.
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 the age of AI.
So a software developer needs to grow in judgment 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...
architecture, which is a totally different thing altogether.
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.
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.
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.
It really is a human story, right?
It's a human.
The transition to architecture is a human story, not an AI story.
Yeah.
What I hear typically in the industry when people mention about, you know, the...
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 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 or 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?
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.
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 code base is what's happening.
So where 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 going to be the tool of software developers in the future.
And that's why that's going to 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 and what they're doing.
And that's the role of a software architect in this whole process is more of their, 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 going to 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.
Well, I like the framing of this, right?
So 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 AI-assisted code, 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 to see, right?
Teaching others how to see.
And then making, you know, this intervention, you know, making sure that'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.
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 advice stuff, right?
So how can an organization do this better?
Is this...
one part of 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?
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, 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.
And 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 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 it, 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 the 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 that 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.
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 science, right?
People call this also cognitive debt, intent debt, right?
So using the triple debt model that, you know, Margaret and Story 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.
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?
It's like the photo borrowing from the photo analogy, right?
You have the dark room where, you know, photos get produced.
In this case, it's dark factory, right?
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 automated and built the system for us.
This seems to be...
um, you know, in contrast to what you just mentioned, right?
So tell us about the danger of this trend.
First of all, I really think this trend as we're talking about is on the rise of the hype curve and it's, it's due for a big fall here coming very soon.
So, because I, it, and you're already starting to see some of this happen, right?
You're seeing, you know, vibe coded applications that, um, uh, can't go the next step because nobody understands how it works.
And it's too complex and too involved in a 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.
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 are not understandable.
Now, I'm not against vibe coding.
I think VibeCoding is 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 going to be long-term sustainable, and it's not the way that we're going to be seeing software develop 10 years from now.
If you're a new developer coming out that's just starting into the industry now, you're not going to be replaced by a darkroom.
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 going to be replaced by a darkroom.
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 cloud computing.
I was very, very intimately involved with cloud computing.
I was involved with the early days of creating cloud computing and working at AWS.
And we saw the same thing, or I saw the same thing.
Everyone said, Everything's going to be moving to the cloud and nothing's going to exist anywhere but in the cloud.
And oh, by the way, it's all going to be serverless.
And I had no idea the number of people who came to me at trade shows and they would introduce me and say, I love what you do.
I love what you're doing.
I want to tell you, we built our entire company using nothing but serverless code.
Aren't you proud of us?
And I say, no.
Did you use serverless for what it's intended for, but not everything, right?
And so I think the same thing is true here.
I think 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 going to figure out the best things.
Just like with cloud computing, we figured out 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, 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 going to 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 going to settle down to the point where AI is a truly useful tool for us, but isn't replacing everything we do.
Yeah.
Maybe if you can 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.
Oh, sure.
Yeah.
So the big thing that I talk about 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 chat bot 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 going to 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 for the parts of your application that are enhanced by non-determinism.
That's one of the things.
I think I could 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 going to 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 to use.
in your application for AI doesn't need Fable or Opus.
It works just fine with Haiku, right?
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 munch 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 episode will come out, but it'll be there in the history if it's not the most recent issue.
It'll be a...
It'll be one of them in the near past and you'll be able to see it.
But I read a lot about AI there and I write a lot about software architecture there, obviously.
And, and, uh, that's just one of the topics I'm, I've been working on recently.
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 with 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.
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.
Uh, if you can think of them just like an advice you want to give to the listeners before we close the conversation, uh, that would be great.
Sure.
I think you probably have heard all three of them so far in what I've been saying about the book, but, uh, you know, the first one is, you know, listen before you lead, you know, the, the conductor's most powerful tool is silence and to listen.
And that's just as critical to us as software architects.
The second one is to, 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 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, 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.
work yourself out of a job always.
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 that, again, it's a trend that many people are picking up.
So hopefully we still got junior software developers being able to transition.
to senior, to software architect, right, to engineering managers and all that.
So, yeah, hopefully the trend is not going to the wrong ways.
So, Lee, if people love this conversation, they want to reach out to you, ask you more questions, or, you know, by the book, is there a place where they can go online?
Sure.
I'll give you three places they can go.
First, if you're interested in the book, you can go to thesoftwareconductor.com.
The book is there and it's available on Amazon.
It's available in some tech bookstores.
And so you can get it at any of the places you would buy technical books.
And if you want to find out more about me and the things that I do, you can go to Lee Atchison.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 in my weekly writings.
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 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.
Thank you, Henry.
It was great to be here.