1 00:00:00,064 --> 00:00:02,986 The people who get promoted out of software development are the 2 00:00:02,989 --> 00:00:05,534 heroes of software development. They do their job because 3 00:00:05,542 --> 00:00:08,041 they're great at writing code. They're the ones that everyone 4 00:00:08,041 --> 00:00:10,080 turns to when something doesn't work quite right. 5 00:00:10,122 --> 00:00:12,190 So let's promote them. Let's turn them into managers or 6 00:00:12,190 --> 00:00:13,315 let's turn them into architects. 7 00:00:13,315 --> 00:00:16,226 And that's the way people turn into software architects, is 8 00:00:16,226 --> 00:00:18,887 from this hero mentality. Today's guest is Lee Atchison, 9 00:00:18,887 --> 00:00:21,845 author of The Software Conductor and early AWS cloud 10 00:00:21,845 --> 00:00:24,745 veteran, on how developers can become great software 11 00:00:24,745 --> 00:00:26,327 architects. How do you actually let go 12 00:00:26,335 --> 00:00:28,673 writing code, knowing about the system inside out and all that? 13 00:00:28,704 --> 00:00:30,534 The architect role is a very different role though. 14 00:00:30,717 --> 00:00:33,489 You don't accomplish anything as a software architect. 15 00:00:33,661 --> 00:00:36,044 An orchestra conductor is the only person in the orchestra 16 00:00:36,044 --> 00:00:38,640 who doesn't make a sound. Yet without them, there's no 17 00:00:38,640 --> 00:00:39,944 music. A good software architect 18 00:00:39,952 --> 00:00:42,629 doesn't write a line of code, doesn't make all the decisions. 19 00:00:42,663 --> 00:00:45,209 The good architects make sure that good decisions get made 20 00:00:45,209 --> 00:00:47,905 within the organization. And that's how you scale an 21 00:00:47,905 --> 00:00:50,042 organization. When you go into a room where a 22 00:00:50,042 --> 00:00:52,013 decision's being made, the question you should ask yourself 23 00:00:52,013 --> 00:00:54,448 as an architect is, can that same decision be made next time 24 00:00:54,448 --> 00:00:56,828 without you in the room? And if the answer is no, you 25 00:00:56,836 --> 00:00:58,691 didn't teach, you decided. These architects also have to 26 00:00:58,691 --> 00:01:00,714 deal with AI. Your book actually very little 27 00:01:00,722 --> 00:01:03,171 I see touching about AI. The architecture role has been 28 00:01:03,171 --> 00:01:05,839 around for 30 plus years. And AI is such a new thing. 29 00:01:06,300 --> 00:01:08,276 The things you need to learn to become an architect have 30 00:01:08,276 --> 00:01:11,338 nothing to do with AI. AI is driving a need for more 31 00:01:11,338 --> 00:01:13,428 judgment within all of the development roles. 32 00:01:13,481 --> 00:01:15,699 Judgment's becoming more important than anything else. 33 00:01:15,859 --> 00:01:17,446 Notice I didn't say architecture. 34 00:01:17,564 --> 00:01:20,182 I didn't say management. I didn't say principal level 35 00:01:20,182 --> 00:01:21,805 engineer. I said judgment and judgment's 36 00:01:21,805 --> 00:01:23,812 at all levels. The software architect's role 37 00:01:23,820 --> 00:01:26,695 in this is to help engineers understand the importance of 38 00:01:26,703 --> 00:01:44,897 judgment in what they're doing. Hey, quick pause. 39 00:01:45,077 --> 00:01:46,937 My goal with Tech Lead Journal is simple. 40 00:01:47,447 --> 00:01:50,207 Learn from the best in tech so we can all grow together. 41 00:01:50,447 --> 00:01:53,747 If this resonates with you, hit subscribe to follow the 42 00:01:53,747 --> 00:01:55,721 channel. It's the biggest way for you to 43 00:01:55,721 --> 00:01:58,292 support the show and help us keep bringing great guests and 44 00:01:58,292 --> 00:02:00,587 insights to you. Thanks for being here, and 45 00:02:00,587 --> 00:02:03,417 let's get back to it. Hello, everyone. 46 00:02:03,417 --> 00:02:06,357 Welcome to another episode of the Tech Lead Journal podcast. 47 00:02:06,357 --> 00:02:08,866 Today, I have with me Lee Atchison. 48 00:02:09,317 --> 00:02:11,797 He's someone who is very active in software architecture. 49 00:02:11,827 --> 00:02:14,497 He has done a lot of, you know, big distributed systems. 50 00:02:15,127 --> 00:02:18,671 And today we are going to talk about a book that I think is 51 00:02:18,671 --> 00:02:21,667 quite rare, available in the industry out there. 52 00:02:22,237 --> 00:02:24,227 The title is called The Software Conductor. 53 00:02:24,927 --> 00:02:27,587 So this book is basically telling us, you know, a 54 00:02:27,587 --> 00:02:31,191 journey about someone who is a hands-on developer turning 55 00:02:31,191 --> 00:02:36,282 into a software architect. So for those of you who are also 56 00:02:36,282 --> 00:02:39,045 interested in going through the same journey from, you know, 57 00:02:39,045 --> 00:02:40,915 maybe a hands-on software developer into software 58 00:02:40,915 --> 00:02:44,397 architect, I hope you can learn a lot from Lee, how we can 59 00:02:44,397 --> 00:02:47,247 transition in a much better way. So welcome to the show, Lee. 60 00:02:47,982 --> 00:02:49,542 Thank you, Henry. It's great to be here. 61 00:02:49,542 --> 00:02:53,042 I really appreciate you bringing me onto your show. 62 00:02:54,134 --> 00:02:56,366 Right. So maybe first of all, let's 63 00:02:56,366 --> 00:02:59,059 start by, you know, asking you why did you come up with this 64 00:02:59,059 --> 00:03:01,290 book, right? Because I think, again, this is 65 00:03:01,290 --> 00:03:04,827 quite a rare topic, that people pick up in the industry, 66 00:03:04,827 --> 00:03:07,734 especially now given the AI craze that is happening. 67 00:03:07,734 --> 00:03:10,664 So maybe tell us the story behind why you wrote this book. 68 00:03:11,053 --> 00:03:13,921 Sure. So actually, I wrote the book 69 00:03:13,921 --> 00:03:17,832 three times. Yeah, I started with what I 70 00:03:17,832 --> 00:03:21,071 called the tome, the big, thick architecture book that 71 00:03:21,071 --> 00:03:23,363 everyone writes, you know. And it's like, it's not my 72 00:03:23,371 --> 00:03:25,817 first book I've written. I've written for O'Reilly Media 73 00:03:25,817 --> 00:03:28,813 and other companies before. But this one was for another 74 00:03:28,821 --> 00:03:31,588 publisher that really wanted the big, thick architecture book 75 00:03:31,596 --> 00:03:33,523 about how to become an architect. 76 00:03:33,523 --> 00:03:35,203 And so I started writing that for them. 77 00:03:35,653 --> 00:03:39,063 We were… I was almost done. They were happy with the book. 78 00:03:39,483 --> 00:03:43,423 I absolutely was not. I didn't like it, what I wrote. 79 00:03:43,773 --> 00:03:46,328 What I found was it was all technically correct and 80 00:03:46,328 --> 00:03:47,613 everything. Everything was great in it. 81 00:03:47,983 --> 00:03:50,013 But I found the book was lifeless. 82 00:03:50,033 --> 00:03:53,785 It didn't really have a soul to it that I could feel proud 83 00:03:53,785 --> 00:03:56,253 about. And I didn't know why. 84 00:03:56,293 --> 00:04:00,287 So I decided to… You know, I broke the connection with the 85 00:04:00,287 --> 00:04:03,143 publisher, I canceled the contract, and we went our 86 00:04:03,143 --> 00:04:05,623 separate ways, and everyone was fine with that. 87 00:04:05,653 --> 00:04:08,654 But I tried rewriting it, thinking that maybe that's 88 00:04:08,654 --> 00:04:11,253 what it took, but it didn't do anything. 89 00:04:11,253 --> 00:04:16,622 It didn't solve the problem. What I realized was that I was 90 00:04:16,622 --> 00:04:21,038 teaching architecture the way that I used to lead it when I 91 00:04:21,038 --> 00:04:24,971 wasn't successful at leading it. And that is by, you know, from 92 00:04:24,971 --> 00:04:28,371 the front of the room with diagrams, telling people what to 93 00:04:28,371 --> 00:04:30,512 do. And that's not the way you do 94 00:04:30,512 --> 00:04:32,535 architecture. That's not the way you, that's, 95 00:04:32,535 --> 00:04:35,233 you're supposed to be when you're a software architect. 96 00:04:35,563 --> 00:04:37,573 But that's the way the book was feeling. 97 00:04:37,723 --> 00:04:41,661 And so I was, you know, the dictator of the page is the 98 00:04:41,661 --> 00:04:45,617 phrase I used at the time. And it was like, you know, I was 99 00:04:45,617 --> 00:04:48,579 dictating what to do, but I wasn't giving guidance on what 100 00:04:48,579 --> 00:04:52,186 and why you wanted to do that, or how to actually make that 101 00:04:52,186 --> 00:04:54,451 happen. So I knew I had to do something 102 00:04:54,451 --> 00:04:56,296 different. I didn't quite know what yet, 103 00:04:56,296 --> 00:04:58,123 but I knew I had to do something different. 104 00:04:58,673 --> 00:05:02,889 But then I remember way, way back, very early in my career, 105 00:05:02,889 --> 00:05:06,967 I read a book called The One Minute Manager, which was, I 106 00:05:06,967 --> 00:05:10,941 read it when I first took on the f- my first employees working 107 00:05:10,941 --> 00:05:13,853 for me, and I took on people management responsibilities, and 108 00:05:13,853 --> 00:05:17,453 I wanted to be the perfect manager, the great manager. 109 00:05:17,453 --> 00:05:22,305 And so I read this book, and, you know, what it was, was it 110 00:05:22,305 --> 00:05:25,858 was a management book that taught me management by not 111 00:05:25,858 --> 00:05:29,483 being a management book, okay? You know, it was a story. 112 00:05:29,613 --> 00:05:33,627 And what-- It was a story about how, you know, the path, a 113 00:05:33,627 --> 00:05:36,431 journey of someone becoming a manager and the lessons they 114 00:05:36,431 --> 00:05:39,467 learned along the way. And that's when it clicked to me 115 00:05:39,467 --> 00:05:42,197 that that's really what I needed to write for the software 116 00:05:42,197 --> 00:05:45,525 architecture journey. And that's when I shifted gears 117 00:05:45,525 --> 00:05:49,487 entirely, and this, you know, 500-page tome turned into a 118 00:05:49,487 --> 00:05:53,075 100-page story. And I wrote a, I wrote it in a 119 00:05:53,083 --> 00:05:57,633 story form, and the story form is what I ended up publishing. 120 00:05:57,653 --> 00:06:01,752 And think it tells the story that really needs to be told, 121 00:06:01,752 --> 00:06:04,043 which isn't how to do architecture. 122 00:06:04,123 --> 00:06:05,703 There's a lot of books that do that. 123 00:06:06,353 --> 00:06:10,141 But it tells you what being an architect, how that's 124 00:06:10,141 --> 00:06:14,053 different from being a developer, and how to make the 125 00:06:14,053 --> 00:06:15,979 transition. And there's a lot of stumbling 126 00:06:15,987 --> 00:06:19,417 blocks there, and it talks about how to make that happen, and it 127 00:06:19,417 --> 00:06:21,073 teaches that story along the way. 128 00:06:22,401 --> 00:06:26,227 Yeah, very interesting story. You had to rewrite this book 129 00:06:26,227 --> 00:06:29,651 three times, just because you didn't feel right, right? 130 00:06:29,821 --> 00:06:32,921 So I think many people in the industry still think architect 131 00:06:32,951 --> 00:06:35,785 works kind of like the way you describe it in the beginning, 132 00:06:35,785 --> 00:06:37,816 right? So they came with, I don't 133 00:06:37,824 --> 00:06:41,421 know, like, the ultimate answer. They knew everything, and they 134 00:06:41,429 --> 00:06:46,449 dictated people on what to do. So I think I still see these 135 00:06:46,457 --> 00:06:49,495 kind of behavior still in the industry, I think, typically, 136 00:06:49,495 --> 00:06:52,271 right? So why the approach actually 137 00:06:54,991 --> 00:06:57,041 doesn't work, right? So maybe from your experience, 138 00:06:57,049 --> 00:06:59,691 because you said it was the style that didn't work for you. 139 00:06:59,691 --> 00:07:04,771 But why, you know, something that people need to be aware of? 140 00:07:05,900 --> 00:07:09,480 Yeah, so I think what happens a lot of times, and this is 141 00:07:09,480 --> 00:07:14,690 certainly what happened with me, is the people who get promoted 142 00:07:14,690 --> 00:07:19,257 out of software development are the heroes of software 143 00:07:19,257 --> 00:07:21,435 development. You know, they're … they do 144 00:07:21,443 --> 00:07:24,300 their job because, you know, they're great at writing code. 145 00:07:24,300 --> 00:07:27,136 They write the best code. They go off and they do all the 146 00:07:27,136 --> 00:07:29,750 things they're supposed to do, and they're the ones that 147 00:07:29,750 --> 00:07:32,390 everyone turns to when something doesn't work quite 148 00:07:32,390 --> 00:07:34,890 right or they wanna learn how something works. 149 00:07:35,800 --> 00:07:37,250 You know, they're the ones that people turn to. 150 00:07:37,260 --> 00:07:39,920 They're the heroes of the development organization. 151 00:07:40,190 --> 00:07:42,475 So let's promote them. Let's turn them into managers, 152 00:07:42,475 --> 00:07:44,110 or let's turn them into architects. 153 00:07:44,110 --> 00:07:48,506 And that's the way people turn into software architects, is 154 00:07:48,506 --> 00:07:54,030 from this hero mentality. Well, the hero mentality is a 155 00:07:54,038 --> 00:07:57,563 self-centered mentality where you're asked to do something, 156 00:07:57,563 --> 00:08:00,302 you do it, and you move on to do something else. 157 00:08:00,342 --> 00:08:03,542 And that's all it is. And the architect role is a 158 00:08:03,550 --> 00:08:07,448 very different role, though. You don't accomplish anything 159 00:08:07,456 --> 00:08:12,838 as a software architect. You accomplish through other 160 00:08:12,838 --> 00:08:16,294 people. And that's where the story comes 161 00:08:16,294 --> 00:08:19,572 from, where … You know, the story I use throughout … what 162 00:08:19,572 --> 00:08:22,196 the story is about, I should give you a little bit of 163 00:08:22,196 --> 00:08:24,246 background what the story is trying to talk about in the 164 00:08:24,246 --> 00:08:29,811 book, is it's a story of Aaron who meets someone who ends up 165 00:08:29,811 --> 00:08:33,326 being his mentor. His name is Anton, and he's an 166 00:08:33,326 --> 00:08:36,429 orchestra conductor. And a very different career 167 00:08:36,429 --> 00:08:40,128 path, very different direction, but he learns how to 168 00:08:40,128 --> 00:08:45,982 become a software architect by talking to Anton, who's the 169 00:08:45,982 --> 00:08:48,992 orchestra conductor. And there's a real strong 170 00:08:48,992 --> 00:08:52,744 parallel, and it's a parallel that I use a lot in my 171 00:08:52,744 --> 00:08:54,952 communication with people about software architecture. 172 00:08:54,952 --> 00:08:58,970 But there's a very strong parallel between the being a 173 00:08:58,970 --> 00:09:01,222 orchestra conductor and being a software architect. 174 00:09:01,692 --> 00:09:05,342 Because an orchestra conductor is the only person of the 175 00:09:05,342 --> 00:09:09,802 orchestra who doesn't make a sound, yet without them, there's 176 00:09:09,802 --> 00:09:13,976 no music. And the same thing's true in 177 00:09:13,976 --> 00:09:16,178 software architecture. A good software architect 178 00:09:16,178 --> 00:09:19,878 doesn't write a line of code, doesn't do anything, doesn't, 179 00:09:19,878 --> 00:09:22,902 isn't a, isn't hero-developing code at all. 180 00:09:23,382 --> 00:09:26,975 They're helping others to accomplish their goals and to 181 00:09:26,975 --> 00:09:30,012 create the systems and the processes and the flow. 182 00:09:30,262 --> 00:09:32,252 The flow is one of the words I use in the book. 183 00:09:32,522 --> 00:09:36,712 The flow between the different pieces to create a whole that 184 00:09:36,712 --> 00:09:38,872 becomes the system that's being built. 185 00:09:39,242 --> 00:09:43,497 And that's the difference. You- what you do as a software 186 00:09:43,505 --> 00:09:47,442 architect day-to-day is very different than what you do as a 187 00:09:47,442 --> 00:09:49,677 developer. Just like the conductor's role 188 00:09:49,685 --> 00:09:53,532 is very different than the lead, you know, violinist. 189 00:09:55,392 --> 00:09:58,857 Their role is very different, and you don't do the same 190 00:09:58,857 --> 00:10:02,418 sorts of things. Yeah, hence the title of your 191 00:10:02,418 --> 00:10:04,062 book, right? The Software Conductor. 192 00:10:04,962 --> 00:10:07,502 I actually like reading your book because I initially 193 00:10:07,502 --> 00:10:10,652 thought it would be, you know, like more prescriptive, a lot 194 00:10:10,652 --> 00:10:12,682 of, you know, all these theoretical thing. 195 00:10:12,692 --> 00:10:15,424 But the moment, you know, you brought up about the story, 196 00:10:15,424 --> 00:10:18,192 there's a lot of parallel actually that I think readers 197 00:10:18,192 --> 00:10:21,105 can learn from there. And it's a very light reading as 198 00:10:21,105 --> 00:10:23,807 well. So, and I like the w- what the 199 00:10:23,815 --> 00:10:25,222 phrase that you mentioned, right? 200 00:10:25,392 --> 00:10:28,482 As a conductor, right, he's the only person who didn't make 201 00:10:28,482 --> 00:10:30,842 the sound. Maybe just the moves, you 202 00:10:30,850 --> 00:10:34,220 know, this coordination thing. But there will be no music if, 203 00:10:34,220 --> 00:10:35,972 you know, he doesn't do his work right. 204 00:10:36,232 --> 00:10:38,752 So I think we can see a lot in software development teams, 205 00:10:38,752 --> 00:10:41,234 right? An effective architect probably 206 00:10:41,234 --> 00:10:44,588 shouldn't be the one who is writing the most code, you know, 207 00:10:44,588 --> 00:10:47,002 building all these, you know, frameworks and all that, right? 208 00:10:47,042 --> 00:10:49,812 But orchestrating people to work more effectively. 209 00:10:49,812 --> 00:10:53,894 So I really love that. So maybe before we go into 210 00:10:53,894 --> 00:10:56,242 your book, right? So currently you are helping 211 00:10:56,250 --> 00:10:59,312 people as well in terms of doing software architecture, right? 212 00:10:59,352 --> 00:11:02,622 So sometimes doing fractional software architect and all that. 213 00:11:03,022 --> 00:11:06,292 So I rarely hear about fractional software architect. 214 00:11:06,402 --> 00:11:09,252 Maybe share a little bit more about this role, right? 215 00:11:09,357 --> 00:11:10,792 Sure. What exactly do you do? 216 00:11:10,792 --> 00:11:15,366 Because if you are doing conductor as a full-time 217 00:11:15,366 --> 00:11:18,282 software architect, what does the fractional do actually? 218 00:11:18,721 --> 00:11:21,473 Yeah, it's a good question. It's, and I'll be completely 219 00:11:21,473 --> 00:11:24,249 honest, you know, the term fractional chief architect, it 220 00:11:24,249 --> 00:11:28,923 reads well on LinkedIn, but in practice, really what I do is I 221 00:11:28,923 --> 00:11:32,269 go and I help the organizations with their software 222 00:11:32,269 --> 00:11:35,117 architecture issues. So I'll help maybe, you know, 223 00:11:35,117 --> 00:11:39,001 lead someone become a software architect or help an 224 00:11:39,001 --> 00:11:42,113 organization decide which direction they should be headed 225 00:11:42,113 --> 00:11:45,375 or where they're doing things right or where they do- should 226 00:11:45,375 --> 00:11:49,169 be working differently. And a lot of that comes from my 227 00:11:49,169 --> 00:11:51,650 historical background, my background with Amazon in 228 00:11:51,650 --> 00:11:53,981 particular, and my focus on cloud computing. 229 00:11:53,981 --> 00:11:56,991 I have a lot of knowledge about a lot of the early days of the 230 00:11:56,991 --> 00:11:59,711 cloud and how things work and how to build cloud systems. 231 00:12:00,381 --> 00:12:03,943 And a lot of my consulting work as architecture is to bring in 232 00:12:03,943 --> 00:12:06,598 that expertise to help an organization that maybe hasn't 233 00:12:06,598 --> 00:12:09,993 made a cloud migration yet and I help them figure out how to do 234 00:12:09,993 --> 00:12:13,656 that. So yeah, I think the, a real 235 00:12:13,656 --> 00:12:17,817 true chief architect isn't something you can do 236 00:12:17,817 --> 00:12:21,161 fractionally from external. It's something that's part of 237 00:12:21,169 --> 00:12:23,771 the organization and needs to be part of the organization. 238 00:12:23,841 --> 00:12:28,161 But, what I do is I help those people make their jobs 239 00:12:28,161 --> 00:12:30,098 successful. Right. 240 00:12:30,448 --> 00:12:33,665 Thanks for sharing that. Yeah, so I think another key 241 00:12:33,673 --> 00:12:36,932 parallel I would say, right. So for software developers who 242 00:12:36,932 --> 00:12:40,280 want to move on in their career, right, like being 243 00:12:40,280 --> 00:12:43,070 promoted and all that, typically there are two paths, 244 00:12:43,070 --> 00:12:45,471 right? Being the IC, right, maybe staff 245 00:12:45,471 --> 00:12:47,560 software engineer, principal software engineer and all that. 246 00:12:47,810 --> 00:12:50,190 And the other one is engineering management, right? 247 00:12:50,410 --> 00:12:52,965 Which is more like leading people, manage people and all 248 00:12:52,965 --> 00:12:55,576 that. Where do you see, you know, 249 00:12:55,584 --> 00:12:58,926 like software architect resides? Is it more on the individual 250 00:12:58,926 --> 00:13:01,164 contributor side? Is it more on the engineering 251 00:13:01,164 --> 00:13:03,506 management side? Because from reading your book, 252 00:13:03,506 --> 00:13:07,401 I can see there are still these two paths that architect 253 00:13:07,401 --> 00:13:10,670 is dealing with. So tell us where does, you know, 254 00:13:10,670 --> 00:13:12,310 software architect typically work in? 255 00:13:12,711 --> 00:13:16,475 Well, there's a lot of parallel between software architect and 256 00:13:16,475 --> 00:13:20,376 the dev manager role. You know, they typically both 257 00:13:20,376 --> 00:13:23,187 come from an individual contributor, and they move up 258 00:13:23,187 --> 00:13:27,609 usually as a result of being promoted, perhaps for the wrong 259 00:13:27,609 --> 00:13:29,421 reasons. Like I say, the hero developer 260 00:13:29,429 --> 00:13:33,837 moving into one of those roles. And they also share one other 261 00:13:33,845 --> 00:13:37,965 commonality, and that is almost every new manager I know and new 262 00:13:37,965 --> 00:13:41,349 software architect I know has the worst feeling about their 263 00:13:41,349 --> 00:13:44,041 job the first year. Because they don't know what 264 00:13:44,041 --> 00:13:46,889 they're supposed to be doing, and they don't know how they're 265 00:13:46,889 --> 00:13:49,909 judged. And how they're judged and how 266 00:13:49,909 --> 00:13:52,436 they're, what's considered successful is radically 267 00:13:52,436 --> 00:13:55,201 different than what they were doing before. 268 00:13:56,371 --> 00:13:59,331 But that's kind of where the similarity ends. 269 00:13:59,371 --> 00:14:01,983 And then there's some meaningful difference between those two, 270 00:14:01,983 --> 00:14:05,111 the management role and the software architect role. 271 00:14:05,691 --> 00:14:09,791 And that is the management role gets authority, right? 272 00:14:09,801 --> 00:14:12,431 You know, they have an org chart, they have direct reports, 273 00:14:12,431 --> 00:14:16,761 they have a structural title. The architect gets none of that. 274 00:14:16,781 --> 00:14:19,957 You know, they have to lead teams just like the manager 275 00:14:19,957 --> 00:14:22,561 does, but they lead teams that they don't manage. 276 00:14:22,601 --> 00:14:25,621 They lead teams that they are not organizationally in 277 00:14:25,621 --> 00:14:28,607 control of. So they have to lead by 278 00:14:28,607 --> 00:14:31,058 influence. And every time they go into a 279 00:14:31,058 --> 00:14:34,721 room, they have to prove their ability to lead over and over 280 00:14:34,721 --> 00:14:38,401 and over again because it's not granted to them by the 281 00:14:38,401 --> 00:14:43,581 organization, it's granted only by their actions and how they, 282 00:14:43,581 --> 00:14:49,011 and what they do. And so the manager's unit of 283 00:14:49,011 --> 00:14:51,841 work is people, careers, things like that. 284 00:14:52,461 --> 00:14:56,961 But an architect's systems and decisions, yet they have to work 285 00:14:56,961 --> 00:15:00,095 with those systems and decisions not directly, but through 286 00:15:00,095 --> 00:15:03,951 other people. So in some aspects, the 287 00:15:03,951 --> 00:15:08,916 architect role is harder, but it's just, it, I don't think 288 00:15:08,916 --> 00:15:10,641 really it's harder. I think it's just different. 289 00:15:10,761 --> 00:15:13,251 And quite frankly, it's a very different role. 290 00:15:13,281 --> 00:15:16,709 I've done both. I learned very early in my 291 00:15:16,709 --> 00:15:18,781 career that I was a good architect. 292 00:15:19,041 --> 00:15:22,073 I wasn't a good manager. I hate managing large 293 00:15:22,081 --> 00:15:24,846 quantities of people. I've managed large groups of 294 00:15:24,846 --> 00:15:27,999 people before, and, you know, I don't wanna deal with those 295 00:15:27,999 --> 00:15:30,186 issues. I'm glad to have mana- a 296 00:15:30,194 --> 00:15:33,846 manager do that for me. I'd rather deal with the 297 00:15:33,846 --> 00:15:37,631 systems, de- work with people, but deal with the systems. 298 00:15:37,961 --> 00:15:40,391 And so that's what worked for me. 299 00:15:40,671 --> 00:15:44,466 Other people are different. Other people like the people 300 00:15:44,466 --> 00:15:47,171 aspects. But they're similar. 301 00:15:47,171 --> 00:15:51,913 They're parallel steps maybe, if you will, up the management, 302 00:15:51,913 --> 00:15:55,051 up the organizational food chain, if you will. 303 00:15:55,061 --> 00:16:01,791 But they're very different, as far as the skills and the sorts 304 00:16:02,911 --> 00:16:06,651 of mindset that it takes to become each of those two 305 00:16:06,651 --> 00:16:09,003 different roles. Yeah. 306 00:16:09,563 --> 00:16:12,523 Leading with influence, I think it's always hard, right? 307 00:16:12,523 --> 00:16:15,473 So it's easier when you have the authority, definitely, right? 308 00:16:16,033 --> 00:16:17,673 So which brings me to the question, right? 309 00:16:17,673 --> 00:16:21,710 Because if you have to lead with influence, isn't that you 310 00:16:21,710 --> 00:16:24,675 should, you know, have the skillset, I mean, like, or the 311 00:16:24,675 --> 00:16:27,509 perspectives from other people that you seem to know many 312 00:16:27,509 --> 00:16:29,733 things, right? And you're the smart guy. 313 00:16:29,923 --> 00:16:32,553 You have dealt with a lot of things in the past as well. 314 00:16:32,893 --> 00:16:36,833 Like is that the true way of leading with influence? 315 00:16:36,943 --> 00:16:40,029 Or, you know, is there a way where you actually don't need 316 00:16:40,029 --> 00:16:43,285 to know everything, but somehow you can lead with influence 317 00:16:43,285 --> 00:16:45,786 more effectively? Well, the-- you can't be 318 00:16:45,786 --> 00:16:48,375 successful if you have the mindset that you have to know 319 00:16:48,375 --> 00:16:50,897 everything. And so you shouldn't have that 320 00:16:50,897 --> 00:16:52,981 mindset. You don't know everything, and 321 00:16:52,989 --> 00:16:56,001 you, you shouldn't act like you know everything either. 322 00:16:56,011 --> 00:17:00,309 And the real thing that, the thing that you do as the 323 00:17:00,309 --> 00:17:04,441 architect isn't to know everything, but to know how 324 00:17:04,441 --> 00:17:10,224 everything works overall, and let the depth of what is needed 325 00:17:10,224 --> 00:17:14,630 come from the individuals. And so you need to know that 326 00:17:14,630 --> 00:17:17,949 these areas work well with these people doing these sorts 327 00:17:17,949 --> 00:17:20,260 of problems and working. The-- and the problems they're 328 00:17:20,268 --> 00:17:22,790 running into are gonna be the sorts of things that this group 329 00:17:22,790 --> 00:17:24,835 over here can solve for them and work with them. 330 00:17:25,105 --> 00:17:27,191 And then make the connections and make sure they're talking, 331 00:17:27,191 --> 00:17:30,277 and make sure all the right pieces work together 332 00:17:30,285 --> 00:17:33,079 correctly, both as an organization and people talking, 333 00:17:33,079 --> 00:17:36,339 but also as a system and an application talking within 334 00:17:36,339 --> 00:17:40,389 itself. And so, you very much have a 335 00:17:40,389 --> 00:17:43,275 breadth-first approach when you're an architect. 336 00:17:43,795 --> 00:17:47,285 You have to know a little bit about a lot of topics. 337 00:17:47,285 --> 00:17:51,041 You have to know a little bit about everything going on within 338 00:17:51,041 --> 00:17:53,545 the organization, but you don't know the depth. 339 00:17:53,895 --> 00:17:55,185 You don't need to know the depth. 340 00:17:55,235 --> 00:18:00,785 And in fact, you fail if you rely on your depth, because you 341 00:18:00,785 --> 00:18:04,845 shouldn't have all the answers. You should garnish the answers 342 00:18:04,845 --> 00:18:08,005 out of the individuals within the organization. 343 00:18:09,214 --> 00:18:11,634 Yeah, so I think it's always the hardest thing, right? 344 00:18:11,644 --> 00:18:14,808 Especially if you were promoted because you are the hero, 345 00:18:14,808 --> 00:18:16,099 right? So-called the rockstar 346 00:18:16,107 --> 00:18:20,194 developer, right, in the past. I think it's always difficult 347 00:18:20,202 --> 00:18:24,941 to go to this mode, right? Simply because, if you like 348 00:18:24,941 --> 00:18:27,604 being hands-on, right, it's always the first thing that you 349 00:18:27,604 --> 00:18:30,144 have to let go, right? So tell us maybe from your 350 00:18:30,144 --> 00:18:31,854 experience, how do you actually let go? 351 00:18:32,154 --> 00:18:34,774 How do you actually let go writing code, knowing about the 352 00:18:34,784 --> 00:18:39,268 system inside out and all that? So I think the biggest thing is, 353 00:18:39,268 --> 00:18:42,886 you know, if you know the… There's four real ways that you 354 00:18:42,886 --> 00:18:46,857 can fail as an architect, and they all come back from this 355 00:18:46,857 --> 00:18:50,354 hero mode, right? You know, the first one is to 356 00:18:50,354 --> 00:18:52,046 think that you have to have all the answers. 357 00:18:52,066 --> 00:18:53,506 We talked about that briefly a little bit. 358 00:18:53,546 --> 00:18:57,990 But good ideas aren't yours, they're the ones that you get 359 00:18:57,990 --> 00:19:01,378 out of other people. And so if you… You don't want 360 00:19:01,386 --> 00:19:05,291 to have all the answers, but you want to have ability to get the 361 00:19:05,291 --> 00:19:07,296 good answers out of other people. 362 00:19:08,566 --> 00:19:13,305 And what's important about that is that become- makes you an 363 00:19:13,305 --> 00:19:16,015 enabler of decisions within the organization. 364 00:19:16,055 --> 00:19:18,725 A good architect doesn't make all the decisions. 365 00:19:18,745 --> 00:19:22,565 A good architect makes sure that good decisions get made within 366 00:19:22,565 --> 00:19:26,735 the organization, and that's how you scale an organization. 367 00:19:26,745 --> 00:19:29,531 I mean you can't scale an organization if all the 368 00:19:29,531 --> 00:19:31,645 decisions have to come through a central point. 369 00:19:31,675 --> 00:19:35,285 You scale an organization by making sure that decisions can 370 00:19:35,285 --> 00:19:38,991 flow outwards. And that also is a way to 371 00:19:38,991 --> 00:19:41,010 spread knowledge. You can't scale an organization 372 00:19:41,010 --> 00:19:43,895 if all the knowledge is centralized in one person, as 373 00:19:43,895 --> 00:19:47,245 well as the fact that that is risky for the organization to 374 00:19:47,255 --> 00:19:49,675 have all knowledge in a single person. 375 00:19:50,085 --> 00:19:52,951 And if you're, if a single person's making all the 376 00:19:52,951 --> 00:19:55,895 decisions, all the knowledge is within that one person's mind. 377 00:19:56,255 --> 00:19:59,601 But if, again, if you successfully make it so that 378 00:19:59,601 --> 00:20:02,743 the rest of the organization makes the decisions, that means 379 00:20:02,743 --> 00:20:05,229 the knowledge and the experience it takes to make 380 00:20:05,229 --> 00:20:08,021 those decisions is also distributed, and that helps 381 00:20:08,021 --> 00:20:10,175 make the organization grow as well. 382 00:20:10,815 --> 00:20:15,855 And it also helps make sure that you're doing, you know, the 383 00:20:15,855 --> 00:20:18,901 last part of the architect role, which is really important, and 384 00:20:18,901 --> 00:20:21,025 that is growing your own successor, right? 385 00:20:21,565 --> 00:20:24,329 You don't want to… Everyone should always be growing their 386 00:20:24,329 --> 00:20:26,035 successor in whatever job they're doing. 387 00:20:26,605 --> 00:20:28,647 But that's also true with a software architect, and that's 388 00:20:28,647 --> 00:20:31,065 something that a lot of software architects don't do. 389 00:20:31,335 --> 00:20:34,105 By making all the decisions, you're not growing a successor. 390 00:20:34,105 --> 00:20:37,838 But by allowing others to make the decisions and to grow 391 00:20:37,838 --> 00:20:40,589 their knowledge of how the system works, you're building in 392 00:20:40,589 --> 00:20:42,565 your own succession plan as you go along. 393 00:20:43,847 --> 00:20:46,195 Wow. I really like, all these, 394 00:20:46,203 --> 00:20:48,947 so-called failure modes, right, that you mentioned, right? 395 00:20:48,947 --> 00:20:52,227 So I think they shouldn't know everything, right? 396 00:20:52,247 --> 00:20:54,497 They should not make all the decisions. 397 00:20:54,797 --> 00:20:57,830 They should not hold all the knowledge and information, 398 00:20:57,830 --> 00:21:00,163 right? And they should not be always 399 00:21:00,163 --> 00:21:02,951 the one there, right? So you have to grow your 400 00:21:02,951 --> 00:21:05,431 successor as well. So I think that's really 401 00:21:05,431 --> 00:21:07,672 beautiful. So maybe let's dive deeper 402 00:21:07,680 --> 00:21:10,706 into the book, right? So I think I like the first few 403 00:21:10,706 --> 00:21:12,919 chapters. This is like also the Phoenix 404 00:21:12,927 --> 00:21:15,817 Project and all those, those kind of book, right, where you 405 00:21:15,817 --> 00:21:17,447 tell the gloomy story first, right? 406 00:21:17,457 --> 00:21:19,587 How it all started, right? All this chaos. 407 00:21:19,610 --> 00:21:20,397 Yeah. Yeah. 408 00:21:20,707 --> 00:21:23,767 So I like to pick up from, you know, like the story behind 409 00:21:23,767 --> 00:21:25,457 the first few chapters of your book, right? 410 00:21:25,477 --> 00:21:28,597 You're basically advising architect to actually figure 411 00:21:28,597 --> 00:21:32,031 out potential imbalance that they can observe within the 412 00:21:32,031 --> 00:21:35,229 system, within the team members and all that before it actually 413 00:21:35,229 --> 00:21:36,937 breaks. Because typically in the 414 00:21:36,937 --> 00:21:39,565 industry, many software architects work by, you know, 415 00:21:39,565 --> 00:21:41,721 chaos, right? When something breaks already, 416 00:21:41,721 --> 00:21:44,647 they get pulled in to fix the issues. 417 00:21:44,897 --> 00:21:47,139 But actually you mentioned that software architects needs to 418 00:21:47,139 --> 00:21:49,659 observe, right? Like a conductor, observe, see 419 00:21:49,667 --> 00:21:52,527 where potentially things might break before it actually breaks. 420 00:21:52,527 --> 00:21:56,805 So tell us why this importance is something that architect need 421 00:21:56,805 --> 00:22:00,866 to be aware of. Yeah, it's, you know, the thrive 422 00:22:00,866 --> 00:22:05,801 in chaos is really the place that the heroes love and where 423 00:22:05,801 --> 00:22:09,355 the heroes thrive. You know what the story in the 424 00:22:09,355 --> 00:22:13,248 book I talk about is Aaron, who's the hero developer that 425 00:22:13,248 --> 00:22:17,188 becomes architect. He's the one that when the 426 00:22:17,188 --> 00:22:20,270 system breaks, everyone gets into Slack and asks him, "What's 427 00:22:20,270 --> 00:22:20,966 wrong? What's wrong?" 428 00:22:20,966 --> 00:22:24,080 And his first instinct is always to sit down at a computer, 429 00:22:24,088 --> 00:22:26,312 find the problem, fix it, and move on. 430 00:22:26,332 --> 00:22:29,702 And that causes him to always be working till 2:00 in the 431 00:22:29,702 --> 00:22:32,110 morning and, you know, all of those sorts of normal hero 432 00:22:32,118 --> 00:22:34,706 things that you have to go through, and he's just gotten 433 00:22:34,706 --> 00:22:37,787 tired of that. And that's where he's, that's 434 00:22:37,787 --> 00:22:41,992 when he's pulled away by his friend who, and brought to a 435 00:22:41,992 --> 00:22:45,505 concert with this orchestra conductor who's doing the 436 00:22:45,505 --> 00:22:50,383 concert and where he's at, where he loves what this person is 437 00:22:50,383 --> 00:22:52,555 doing. And he meets the conductor, and 438 00:22:52,555 --> 00:22:56,564 the conductor tells him, the conductor's name is Anton, and 439 00:22:56,564 --> 00:23:03,583 he tells Aaron that he always asks his orchestra members five 440 00:23:03,583 --> 00:23:07,380 questions. And the same five questions, 441 00:23:07,380 --> 00:23:10,610 adjusted appropriately, are great questions for the 442 00:23:10,610 --> 00:23:14,382 architect to be asking for the organization to get out of the 443 00:23:14,382 --> 00:23:18,172 hero mode. You know, the five questions the 444 00:23:18,172 --> 00:23:22,595 the conductor always asks is, you know, "What are you 445 00:23:22,595 --> 00:23:24,982 playing?" Which is, you know, to his, to 446 00:23:24,982 --> 00:23:27,871 the, to the, you know, the violinists and the oboe 447 00:23:27,871 --> 00:23:29,840 players, et cetera. What are you playing? 448 00:23:30,120 --> 00:23:32,388 And that's really the same thing as the architect saying, 449 00:23:32,388 --> 00:23:34,842 "What's your purpose? What are you trying to 450 00:23:34,850 --> 00:23:36,840 accomplish? Who are you playing with?" 451 00:23:36,980 --> 00:23:39,843 That's really your dependencies, your both bidirectional 452 00:23:39,843 --> 00:23:42,400 dependencies, who you depend on, who depends on you. 453 00:23:43,490 --> 00:23:47,286 "Can you hear each other?" That's really about 454 00:23:47,286 --> 00:23:49,306 communicating. Are the individual parts of the 455 00:23:49,306 --> 00:23:52,296 organization that need to be working on a problem talking 456 00:23:52,296 --> 00:23:54,480 appropriately and doing the right things? 457 00:23:55,640 --> 00:23:58,340 "Are you in tune?" You know, are you following 458 00:23:58,340 --> 00:24:01,424 the right standards, the right shared expectations, the right 459 00:24:01,424 --> 00:24:03,770 systems? That's the analogy there. 460 00:24:04,590 --> 00:24:07,847 And one that's maybe not the perfect match is, "Do you know 461 00:24:07,847 --> 00:24:10,594 when to stop?" And that is, you know, what, do 462 00:24:10,594 --> 00:24:13,810 you know when to give up and have somebody else take over 463 00:24:13,810 --> 00:24:16,070 from where you were? What are your constraints? 464 00:24:16,520 --> 00:24:19,350 Where does your part end and somebody else's part begins? 465 00:24:19,950 --> 00:24:24,845 And architecture really is useful when it stops 466 00:24:24,845 --> 00:24:28,815 pretending to be mystical. I mean, you know, people think 467 00:24:28,815 --> 00:24:31,295 of architecture as a mystical concept, and it's really best 468 00:24:31,295 --> 00:24:34,848 when you can come down and say, "No, it's really the same 469 00:24:34,848 --> 00:24:38,925 as this." And if you make this work, it 470 00:24:38,925 --> 00:24:41,439 really is nothing mystical about it anymore. 471 00:24:42,720 --> 00:24:44,950 So yeah, I like the five questions you mentioned, right? 472 00:24:44,950 --> 00:24:47,990 So first, do you know what is your purpose, right? 473 00:24:48,000 --> 00:24:51,218 Like what are you playing in the whole, you know, orchestra, 474 00:24:51,218 --> 00:24:52,930 right? What you're playing, who you 475 00:24:52,930 --> 00:24:55,960 are, you know, playing with, you know, like the team members, 476 00:24:55,960 --> 00:24:58,840 your dependencies, right, your stakeholders and all that. 477 00:24:59,520 --> 00:25:02,642 Can you hear each other? I think this is a very important 478 00:25:02,642 --> 00:25:05,714 question, I feel, 'cause sometimes we just do our work, 479 00:25:05,714 --> 00:25:08,699 but we don't actually kind of like listen to each other, 480 00:25:08,699 --> 00:25:10,338 right? Sometimes especially with, when 481 00:25:10,338 --> 00:25:13,110 you work with third parties, right, dependencies and all 482 00:25:13,110 --> 00:25:14,440 that, you just focus on your own. 483 00:25:14,900 --> 00:25:16,950 And then are you in tune? This is also another thing. 484 00:25:17,780 --> 00:25:20,524 I feel it's important, right, because sometimes you just do 485 00:25:20,524 --> 00:25:23,510 the thing, but you may not be in tune with others, right? 486 00:25:23,510 --> 00:25:26,858 Maybe from architecture, be it, you know, the integration side 487 00:25:26,858 --> 00:25:30,640 or be it the API spec or be it even like how you collaborate 488 00:25:30,640 --> 00:25:32,730 with each other, right? So I think that's important. 489 00:25:33,130 --> 00:25:35,580 And yeah, the last one, know when to stop, right? 490 00:25:35,620 --> 00:25:38,556 Know when probably, you know, there are constraints, maybe 491 00:25:38,556 --> 00:25:42,230 there are danger signs, and how to loop in other people to help. 492 00:25:42,260 --> 00:25:44,160 I think this is also very important. 493 00:25:44,530 --> 00:25:47,700 So I really like this question. I think everyone who listen can 494 00:25:47,700 --> 00:25:50,864 really ask this as well, maybe, as part of your role, 495 00:25:50,864 --> 00:25:53,600 right, or maybe just as a reflection within your 496 00:25:53,600 --> 00:25:56,211 software team, right? So I think this is always a 497 00:25:56,211 --> 00:25:59,346 good thing to reflect. So another thing that I pick up 498 00:25:59,346 --> 00:26:02,951 from the book, you mentioned that architect is actually 499 00:26:02,951 --> 00:26:06,897 empathy at scale. So this is the side which I 500 00:26:06,897 --> 00:26:11,340 think did not get covered a lot in a lot of resources I read 501 00:26:11,340 --> 00:26:14,912 about software architecture. So knowing how, you know, other 502 00:26:14,912 --> 00:26:17,784 people work, right, empathize with them, their situations, 503 00:26:17,784 --> 00:26:20,540 their problems and all that, not always necessarily just 504 00:26:20,540 --> 00:26:23,908 focus on, you know, the system, the code, right, or the 505 00:26:23,908 --> 00:26:26,626 binaries, right? So tell us why architects should 506 00:26:26,626 --> 00:26:29,080 also pick up this empathy at scale. 507 00:26:29,979 --> 00:26:33,049 Well, you know, you've heard this before, but, you know, 508 00:26:33,049 --> 00:26:34,918 there's three things. There's technology, there's 509 00:26:34,926 --> 00:26:37,663 process, and there's people. You need all three of those 510 00:26:37,663 --> 00:26:40,629 for a system to work. Architects really at the 511 00:26:40,637 --> 00:26:43,651 center of all three of those. They have to know the 512 00:26:43,651 --> 00:26:45,819 technology. They help create the processes, 513 00:26:45,819 --> 00:26:49,160 or they're at the center of the processes, but they can't do 514 00:26:49,160 --> 00:26:51,259 any of that on their own. They have to do it with people. 515 00:26:51,269 --> 00:26:54,259 So they're really at the middle of that people part, and that's 516 00:26:54,259 --> 00:26:56,499 where the empathy comes from. You know what? 517 00:26:56,639 --> 00:27:02,349 Most failures in the system are, they're not really bugs, 518 00:27:02,349 --> 00:27:06,899 they're connections that have gone awry or have gone quiet. 519 00:27:07,109 --> 00:27:11,417 So there are teams that have stopped talking to each other, 520 00:27:11,417 --> 00:27:14,589 or service owners that no longer talk to each other, or 521 00:27:14,589 --> 00:27:18,504 services that, you know, that aren't, are no longer in sync 522 00:27:18,512 --> 00:27:22,885 and no longer working correctly. So the code problems that exist 523 00:27:22,885 --> 00:27:26,569 that create the bugs, that create the problems are the 524 00:27:26,569 --> 00:27:29,730 symptom, but the connection between the people is really the 525 00:27:29,730 --> 00:27:32,470 cause of that. So, you know, in practice, what 526 00:27:32,470 --> 00:27:35,599 architects really have to do is they have to, you know, 527 00:27:35,599 --> 00:27:39,745 listen for the human concern inside, you know, a technical 528 00:27:39,745 --> 00:27:41,694 objection. If someone has a technical 529 00:27:41,694 --> 00:27:44,449 objection, what is the real reason behind that objection? 530 00:27:44,509 --> 00:27:50,401 Is it really a technical issue, or is there an emotional or a 531 00:27:50,401 --> 00:27:52,949 human reason behind it? Not necessarily emotional, but 532 00:27:52,949 --> 00:27:57,664 a human reason behind it. Pushback from people is rarely 533 00:27:57,664 --> 00:28:01,823 about a legitimate design decision, and it's usually more 534 00:28:01,823 --> 00:28:07,884 about, you know, fear of a change or fear of a loss, or 535 00:28:07,884 --> 00:28:11,125 fear of doing something that… you know, it's around fear, 536 00:28:11,125 --> 00:28:13,123 right? It's around fear of not getting 537 00:28:13,123 --> 00:28:15,069 what makes sense for them to do. 538 00:28:15,339 --> 00:28:21,571 So stop telling people what to build and start asking them, 539 00:28:21,571 --> 00:28:25,737 "What do you need to build?" Or, "What do you need to 540 00:28:25,745 --> 00:28:29,419 accomplish what you want to do?" And then your job then is to 541 00:28:29,419 --> 00:28:32,689 fulfill those needs with all the other teams then to create 542 00:28:32,689 --> 00:28:35,169 the flow that works off, works together. 543 00:28:35,249 --> 00:28:38,893 The flow is the orchestra and working to create music 544 00:28:38,893 --> 00:28:43,023 instead of just noise. And the flow for a software 545 00:28:43,023 --> 00:28:46,929 architecture is creating the system that takes all the needs 546 00:28:46,929 --> 00:28:50,889 of everyone's into account as the system is built and created. 547 00:28:52,028 --> 00:28:56,120 Yeah, so I think, I always remember whenever I have 548 00:28:56,120 --> 00:28:58,672 discussions with architect, we always argue about, you know, 549 00:28:58,672 --> 00:29:01,414 the best, you know, I don't know, like programming language, 550 00:29:01,414 --> 00:29:03,926 tech stack, frameworks, you know, software architecture and 551 00:29:03,926 --> 00:29:06,836 things like that, right? But what you're saying is 552 00:29:06,844 --> 00:29:09,894 actually architects should be able to kind of like pick the 553 00:29:09,894 --> 00:29:11,508 cue from the human aspects, right? 554 00:29:11,738 --> 00:29:14,238 Not necessarily just the best ideas win, right? 555 00:29:14,238 --> 00:29:16,976 So, but understand the concerns that people have, you know, the 556 00:29:16,976 --> 00:29:19,998 fear, especially when we wanna change something, right? 557 00:29:20,268 --> 00:29:23,508 So definitely these aspects is kind of like probably 558 00:29:23,508 --> 00:29:26,435 undertrained for some architects because typically like what 559 00:29:26,443 --> 00:29:29,780 you said, right, they are having hero mentality, they wanna 560 00:29:29,780 --> 00:29:32,615 dictate stuff, and they wanna come up with the best answers 561 00:29:32,615 --> 00:29:36,443 for other people to follow. So empathy, I think it's 562 00:29:36,443 --> 00:29:39,328 something that architects need to be aware of. 563 00:29:39,818 --> 00:29:42,438 Which leads me to the next question, which is kind of 564 00:29:42,438 --> 00:29:44,955 like a bit interrelated, right? So you mentioned that architect 565 00:29:44,955 --> 00:29:48,102 should be a mentor, right? Teaching people how to do stuff, 566 00:29:48,102 --> 00:29:50,530 right, instead of being the dictator, right? 567 00:29:50,590 --> 00:29:53,030 Instructing people to do it this way, right? 568 00:29:53,330 --> 00:29:57,020 So tell us this difference of, you know, like being a 569 00:29:57,020 --> 00:30:00,250 teacher, being a mentor versus someone who dictates stuff. 570 00:30:01,548 --> 00:30:05,772 Yeah, so I, you know, in about the middle of the book, I'm 571 00:30:05,772 --> 00:30:10,806 not sure exactly where, what chapter number it is, Aaron and 572 00:30:10,806 --> 00:30:14,834 Anton in their mentor relationship, Anton has another 573 00:30:14,834 --> 00:30:22,241 friend who he introduces Aaron to, and that is, Marcus, who is 574 00:30:22,241 --> 00:30:25,158 an offensive coordinator for a football team. 575 00:30:25,408 --> 00:30:28,828 And, you know, and Aaron, you know, loves this because he 576 00:30:28,828 --> 00:30:30,398 loves football, right, and everything. 577 00:30:30,908 --> 00:30:36,060 And he… Marcus asks Aaron, "What do you think my job is?" 578 00:30:36,060 --> 00:30:38,948 And Aaron says, "Well, you design all the plays for the 579 00:30:38,948 --> 00:30:39,848 team, right?" You know. 580 00:30:40,758 --> 00:30:45,904 And Marcus says, "No, designing plays is only about 20% of my 581 00:30:45,904 --> 00:30:49,352 job. The other 80% is teaching people 582 00:30:49,352 --> 00:30:54,218 how to see." And that was really the driver 583 00:30:54,218 --> 00:30:59,002 behind this mentoring aspect, is he saw his job not at coming 584 00:30:59,002 --> 00:31:02,584 up with the plays, but to figuring out what is keeping 585 00:31:02,592 --> 00:31:05,478 other people from being able to do the plays that they need to 586 00:31:05,478 --> 00:31:08,233 be able to do. How, what's keeping them from 587 00:31:08,241 --> 00:31:12,246 fulfilling their role within the constraints of the football 588 00:31:12,246 --> 00:31:16,094 team? And, you know, you can't lead a 589 00:31:16,094 --> 00:31:19,478 team when you're trying to catch the ball, right? 590 00:31:19,488 --> 00:31:24,022 So if you're still trying to design the play, if you're 591 00:31:24,022 --> 00:31:28,192 still trying be the person that catches the ball, you can't be 592 00:31:28,192 --> 00:31:33,096 the one that figures out who should be where, and why when a 593 00:31:33,096 --> 00:31:37,826 play fails, it's because, you know, so and so wasn't able to 594 00:31:37,826 --> 00:31:40,298 fulfill their role. Well, why weren't they able to? 595 00:31:40,298 --> 00:31:43,038 And what happened? And what can you do to make that 596 00:31:43,038 --> 00:31:46,878 better? And so a mentor really is all 597 00:31:46,886 --> 00:31:49,996 about helping individuals overcome their obstacles versus 598 00:31:49,996 --> 00:31:53,118 telling them what they need to do. 599 00:31:53,608 --> 00:31:55,728 You know, there's all sorts of people who can tell them what to 600 00:31:55,728 --> 00:31:57,428 do, who can teach them what to do. 601 00:31:57,768 --> 00:32:00,602 Their job is to help them overcome the obstacles from 602 00:32:00,602 --> 00:32:02,808 being able to accomplish what their job is. 603 00:32:03,358 --> 00:32:06,008 That's part of the biggest change there, right? 604 00:32:06,008 --> 00:32:12,276 You know, they're a teacher, not a dictator, but they're also a 605 00:32:12,276 --> 00:32:15,788 obstacle remover, not a dictator, right? 606 00:32:15,798 --> 00:32:19,003 They're the ones that help them figure out how to learn, how 607 00:32:19,003 --> 00:32:24,438 to do what they need to do, not actually tell them what to do. 608 00:32:25,502 --> 00:32:27,152 Yeah, teaching others how to see. 609 00:32:27,212 --> 00:32:29,952 I think that's a pretty good way of summarizing it, right? 610 00:32:30,842 --> 00:32:34,432 So enable other people, right, to make decisions, right? 611 00:32:34,432 --> 00:32:36,529 Coming back to what you mentioned in the beginning, 612 00:32:36,529 --> 00:32:38,844 right? So making sure that people can 613 00:32:38,844 --> 00:32:40,922 make good decisions by themselves, right? 614 00:32:41,972 --> 00:32:44,362 And such that the decision can flow, right? 615 00:32:44,362 --> 00:32:47,499 It's not like always coming to you as a bottleneck at the end 616 00:32:47,499 --> 00:32:49,873 of the day. And as an architect there's 617 00:32:49,881 --> 00:32:53,133 actually a good test of this, by the way, if I could get this in. 618 00:32:53,133 --> 00:32:57,137 And that is, you know, if you-- when you go into a room where 619 00:32:57,137 --> 00:33:00,933 a decision's being made, the question you should ask yourself 620 00:33:00,933 --> 00:33:05,291 as an architect is, can that same decision be made next time 621 00:33:05,291 --> 00:33:10,007 without you in the room? And if the answer is no, you 622 00:33:10,015 --> 00:33:13,358 didn't teach, you decided. If the answer is yes, you've 623 00:33:13,358 --> 00:33:15,283 taught, and you are a successful architect. 624 00:33:15,733 --> 00:33:20,985 That's really the key. You wanna make it so that 625 00:33:20,985 --> 00:33:23,033 decisions can be made, not make the decisions. 626 00:33:24,334 --> 00:33:26,868 Right. Wow, I think it's, that's quite 627 00:33:26,868 --> 00:33:29,270 important point because people assume after decision is made, 628 00:33:29,270 --> 00:33:31,698 then yeah, just move on and do the thing, right? 629 00:33:31,898 --> 00:33:36,174 But yeah, I actually think that if you can explain the 630 00:33:36,174 --> 00:33:39,983 rationale and spread the reason why, right, and let others 631 00:33:39,991 --> 00:33:43,232 also make the same decisions probably next time, I think 632 00:33:43,232 --> 00:33:46,222 that's a very good effective way of measuring whether you 633 00:33:46,222 --> 00:33:49,222 have done all this teaching aspect versus the dictating 634 00:33:49,222 --> 00:33:51,468 aspect, right? So I think really love that. 635 00:33:52,748 --> 00:33:55,872 So one other part typically a software architect does the 636 00:33:55,872 --> 00:33:59,368 role is actually to be pulled in so many different directions, 637 00:33:59,368 --> 00:34:02,873 so many different systems, fixing fires here, you know, 638 00:34:02,873 --> 00:34:04,838 dealing with other problems somewhere. 639 00:34:05,208 --> 00:34:07,348 And there's a lot of context switching. 640 00:34:07,578 --> 00:34:10,108 There's a lot of things that us software architects need to 641 00:34:10,108 --> 00:34:12,219 know how. And when you talk about the 642 00:34:12,219 --> 00:34:14,755 empathy as well, there's a lot of people aspects that software 643 00:34:14,755 --> 00:34:17,447 architects need to deal with. Maybe, you know, working with 644 00:34:17,447 --> 00:34:19,888 the rockstar developers, maybe working with tough stakeholders 645 00:34:19,888 --> 00:34:22,716 and things like that. Is there any advice here that 646 00:34:22,716 --> 00:34:25,728 you can give architect as well such that, you know, they can 647 00:34:25,728 --> 00:34:28,618 manage this context switching and, you know, the dynamics, the 648 00:34:28,628 --> 00:34:31,228 complexity that they have to deal with? 649 00:34:32,288 --> 00:34:35,614 Yeah, and again, I think the, the biggest thing is to 650 00:34:35,614 --> 00:34:39,338 understand your responsibility as the architect is not depth, 651 00:34:39,338 --> 00:34:43,330 it's breadth. And so, you know, you need to 652 00:34:43,330 --> 00:34:46,835 depend on your experts to have the depth of knowledge as 653 00:34:46,844 --> 00:34:50,520 needed to solve a given problem. But you need to know enough 654 00:34:50,520 --> 00:34:53,606 about it in order to find how the decisions they're making 655 00:34:53,606 --> 00:34:56,888 impacts the rest of the project or the rest of the 656 00:34:56,888 --> 00:34:58,578 system or rest of the organization. 657 00:34:58,968 --> 00:35:01,438 And so you need to know enough to be able to do that. 658 00:35:01,458 --> 00:35:04,309 And so you can go to the other groups and say, "Hey, this is 659 00:35:04,309 --> 00:35:06,994 what's going on here. How does that impact you?" 660 00:35:06,994 --> 00:35:10,033 You're still asking questions, you're still letting them make 661 00:35:10,033 --> 00:35:13,278 decisions, but you're the ones that are one that's fostering 662 00:35:13,278 --> 00:35:16,875 the flow between them to create that knowledge and make that 663 00:35:16,875 --> 00:35:20,625 knowledge work. So the real important things 664 00:35:20,625 --> 00:35:25,278 here is, you know, as a developer, you focus. 665 00:35:25,338 --> 00:35:29,752 You focus on a thing. But as the architect, you need 666 00:35:29,752 --> 00:35:33,763 to do a lot more context switching with a lot more 667 00:35:33,763 --> 00:35:37,403 smaller granular pieces. You work with sand, not big 668 00:35:37,403 --> 00:35:40,328 rocks, using the, you know, the, using that analogy. 669 00:35:40,398 --> 00:35:42,148 You work with sand, not big rocks. 670 00:35:42,168 --> 00:35:45,270 So you need to be able to flow the sand through the system 671 00:35:45,270 --> 00:35:48,428 versus understanding how a big rock works. 672 00:35:48,818 --> 00:35:52,758 And that's really the biggest thing to do. 673 00:35:52,788 --> 00:35:59,446 How do you make that happen? You know, staying away from the 674 00:35:59,446 --> 00:36:01,540 deep conversations is the first one. 675 00:36:01,860 --> 00:36:05,070 Staying out of the deep conversations is, you know, is 676 00:36:05,070 --> 00:36:09,400 the most critical piece. Asking more questions than 677 00:36:09,400 --> 00:36:12,140 statements. You'll find as an architect, you 678 00:36:12,140 --> 00:36:14,627 should be asking more questions than you're making 679 00:36:14,627 --> 00:36:16,899 statements. If you're not make- asking more 680 00:36:16,899 --> 00:36:19,644 questions than statements, you're not understanding how 681 00:36:19,644 --> 00:36:24,468 your organization works. And then I guess the rest of it 682 00:36:24,468 --> 00:36:29,923 is also part of the mindset and the, of what it is to be an 683 00:36:29,923 --> 00:36:32,474 architect. Because an architect is someone 684 00:36:32,474 --> 00:36:36,374 that can't sit down and focus for long periods of time. 685 00:36:36,374 --> 00:36:40,248 They have to be able to context switch and flip back and forth 686 00:36:40,248 --> 00:36:42,992 from different areas and different topics, and be able to 687 00:36:42,992 --> 00:36:45,384 make a cohesive whole out of all of that. 688 00:36:45,664 --> 00:36:48,974 And so you have to be able to do a fast context switch in order 689 00:36:48,974 --> 00:36:52,256 to be a successful architect. And frankly, if you can't, then 690 00:36:52,256 --> 00:36:55,620 maybe a senior arc- a senior developer role is a better role 691 00:36:55,620 --> 00:36:58,784 for you than an architect role. Yeah. 692 00:36:58,924 --> 00:37:00,634 I can see now a clear distinction, right? 693 00:37:00,634 --> 00:37:05,022 So if you like being hands-on doing deep focus work, right, 694 00:37:05,022 --> 00:37:08,384 and know the details and all that, probably like something 695 00:37:08,392 --> 00:37:10,898 like principal software engineer, you know, like being a 696 00:37:10,898 --> 00:37:13,504 real IC is something that is more appropriate for you. 697 00:37:14,064 --> 00:37:17,418 Although I think there are a lot of, how should I say, a 698 00:37:17,418 --> 00:37:19,521 perspective change that must happen in the industry because 699 00:37:19,529 --> 00:37:22,289 again, like I can see in the industry, people think architect 700 00:37:22,289 --> 00:37:25,941 is the ultimate person who makes a lot of decisions and, 701 00:37:25,941 --> 00:37:28,698 you know, like orchestrating others, dictating others to do 702 00:37:28,698 --> 00:37:30,529 stuff. So I think hopefully the 703 00:37:30,529 --> 00:37:32,842 perception can change as well, especially with the appearance 704 00:37:32,842 --> 00:37:36,108 of your book right? So yeah, hopefully that people 705 00:37:36,116 --> 00:37:39,288 can become better architect. So I wanna touch on, you know, 706 00:37:39,296 --> 00:37:42,314 the big elephant in the room, definitely, right, the AI thing. 707 00:37:43,004 --> 00:37:47,464 So for a resource that come quite recently, your book 708 00:37:47,464 --> 00:37:51,390 actually very little I see, touching about AI Yep. 709 00:37:51,494 --> 00:37:53,464 Which I think these days architects also have to deal 710 00:37:53,464 --> 00:37:56,475 with AI, I guess, right? So tell us the reason why you 711 00:37:56,475 --> 00:37:58,574 didn't involve AI at all in the book. 712 00:37:59,318 --> 00:38:03,418 It was actually intentional. I had initially written several 713 00:38:05,458 --> 00:38:09,290 chapters actually on AI and I decided just to strip them all 714 00:38:09,290 --> 00:38:11,468 out because, you know, for a couple of main reasons. 715 00:38:11,478 --> 00:38:17,333 One is, you know, the transition to architecture is really 716 00:38:17,333 --> 00:38:20,328 something that's been around for 30 years, right? 717 00:38:20,368 --> 00:38:24,398 The architecture role has been around for 30, 30+ years. years 718 00:38:24,398 --> 00:38:29,998 And AI is such a new thing in that the things you need to 719 00:38:29,998 --> 00:38:33,308 learn to become an architect have nothing to do with AI. 720 00:38:34,218 --> 00:38:39,662 AI is a symptom of why people are looking to move to become 721 00:38:39,662 --> 00:38:43,360 an architect, or moving to become more of a principal 722 00:38:43,368 --> 00:38:45,456 engineer, moving into management, moving into 723 00:38:45,456 --> 00:38:48,458 whatever, because they're afraid of their traditional 724 00:38:48,458 --> 00:38:50,318 software developer roles going away. 725 00:38:50,338 --> 00:38:53,358 It's a symptom, but it's not the role. 726 00:38:54,390 --> 00:38:59,908 Well, my view on AI is AI is driving a need for more 727 00:38:59,908 --> 00:39:02,466 judgment within all of the development roles. 728 00:39:03,205 --> 00:39:05,906 Judgment's becoming more important than anything else 729 00:39:05,906 --> 00:39:10,230 in, in the age of AI. So a software developer needs to 730 00:39:10,230 --> 00:39:13,898 grow in judgment in order to-- in their ability to make 731 00:39:13,898 --> 00:39:17,236 judgment calls in order to be a better software developer. 732 00:39:17,606 --> 00:39:21,760 That's critically important. But that's nothing to do with 733 00:39:21,760 --> 00:39:25,542 the transition to architect which is a totally different 734 00:39:25,542 --> 00:39:29,461 thing altogether. That hasn't been, that whole 735 00:39:29,461 --> 00:39:33,594 process hasn't been affected by AI, and really isn't affected 736 00:39:33,594 --> 00:39:37,096 by AI because it's a different process that goes on there. 737 00:39:37,106 --> 00:39:42,982 So now, I use AI in the subtitle of the book because it's 738 00:39:42,982 --> 00:39:46,796 what's driving the urgency for the need for this book, right? 739 00:39:46,796 --> 00:39:49,856 Because people want to know what's next in their career, 740 00:39:49,856 --> 00:39:52,776 and this is one avenue that's next in their career. 741 00:39:52,776 --> 00:39:54,566 And they want to know that because of AI. 742 00:39:55,316 --> 00:39:59,066 But really nothing about the transition is AI-specific. 743 00:40:00,066 --> 00:40:03,506 So I intentionally left AI out of the narrative. 744 00:40:05,053 --> 00:40:08,833 Right. so yeah, for people who are wondering, when you read 745 00:40:08,833 --> 00:40:12,356 about this book, why no AI part in this software architecture 746 00:40:12,356 --> 00:40:14,688 transition? So I think you get the answer 747 00:40:14,688 --> 00:40:17,646 there. But it really is a human story, 748 00:40:17,646 --> 00:40:19,915 right? It's a human s- the transition 749 00:40:19,923 --> 00:40:23,795 to architecture is a human story, not a, not an AI story. 750 00:40:24,695 --> 00:40:26,782 Yeah. What I hear typically in the 751 00:40:26,782 --> 00:40:29,762 industry when people mention about, you know, the impact of 752 00:40:29,762 --> 00:40:32,865 AI to the jobs, right? Many people say that software 753 00:40:32,873 --> 00:40:35,725 engineers, just like what you mentioned, right, so they need 754 00:40:35,725 --> 00:40:38,375 to make a lot of judgment, judgment calls. 755 00:40:38,605 --> 00:40:41,175 And people associate this with, you know, every software 756 00:40:41,175 --> 00:40:44,363 developers now has to turn into something like a tech lead or 757 00:40:44,363 --> 00:40:46,865 software architect. So it's like everyone starts as 758 00:40:46,865 --> 00:40:48,505 a software architect as a tech lead. 759 00:40:48,675 --> 00:40:52,589 So tell us your view on this. Is this the right framing of, 760 00:40:52,589 --> 00:40:55,185 you know, our new role as a software developer? 761 00:40:56,025 --> 00:41:00,975 So I've written recently about a report that came out of 762 00:41:00,975 --> 00:41:04,551 GitClear just recently, and they've actually done a couple 763 00:41:04,551 --> 00:41:06,405 of different AI-related reports recently. 764 00:41:06,405 --> 00:41:10,460 And, but this most recent one, what they've discovered by 765 00:41:10,460 --> 00:41:15,639 examining GitHub repos that are public is that refactoring, in 766 00:41:15,639 --> 00:41:21,015 the age of AI, refactoring code is down 70%. 767 00:41:23,165 --> 00:41:27,615 Cross-file connectivity, is down 35%. 768 00:41:28,825 --> 00:41:33,455 Legacy code maintenance is down almost 75%. 769 00:41:33,455 --> 00:41:39,425 And code duplication and masking of errors is up significantly. 770 00:41:39,915 --> 00:41:43,045 What this really is showing, this is the effect of AI slop 771 00:41:43,045 --> 00:41:46,565 in our s- in our code base, is what's happening. 772 00:41:47,195 --> 00:41:52,886 So where, you know, AI isn't replacing what developers are 773 00:41:52,886 --> 00:41:55,037 doing. They're replacing… They're 774 00:41:55,037 --> 00:41:57,335 enhancing what developers are already doing. 775 00:41:57,355 --> 00:42:03,575 So the best developers who write great code can use AI to write 776 00:42:03,645 --> 00:42:05,835 more and more and more great code. 777 00:42:06,315 --> 00:42:10,518 While early developers or lesser developers or the newer 778 00:42:10,518 --> 00:42:13,409 developers or the less experienced developers, when 779 00:42:13,409 --> 00:42:18,472 they use AI, they write poor quality code in general, and 780 00:42:18,480 --> 00:42:22,523 they write more of it using AI. And that's what's happening 781 00:42:22,523 --> 00:42:26,623 here, is that AI is enhancing the amount of code that's 782 00:42:26,623 --> 00:42:30,072 produced, but it's not enhancing the quality of code 783 00:42:30,072 --> 00:42:34,474 produced unless it is being done by people who can create the 784 00:42:34,474 --> 00:42:37,360 quality of code. That's why judgment, I mentioned 785 00:42:37,360 --> 00:42:41,892 judgment earlier, that's why judgment is gonna be the tool of 786 00:42:41,892 --> 00:42:44,245 software developers in the future. 787 00:42:44,405 --> 00:42:47,335 And that's why that's gonna be really what's important here. 788 00:42:47,675 --> 00:42:50,255 Notice I didn't say architecture. 789 00:42:50,555 --> 00:42:54,585 Notice I didn't say management. Notice I didn't say principal 790 00:42:54,585 --> 00:42:57,145 level engineer. I said judgment, and 791 00:42:57,153 --> 00:43:00,439 judgment's at all levels. So it's really important, you 792 00:43:00,439 --> 00:43:04,083 know, we start teaching this more with, and we start… And 793 00:43:04,083 --> 00:43:07,722 actually what, the software architect's role in this is to 794 00:43:07,722 --> 00:43:11,219 help engineers understand the importance of judgment in what 795 00:43:11,219 --> 00:43:14,127 they're doing, and that's the role of a software architect 796 00:43:14,135 --> 00:43:17,290 in this whole process, is more of their mentoring role, if you 797 00:43:17,290 --> 00:43:19,860 will. But that's really the solution 798 00:43:19,860 --> 00:43:22,924 to this issue. It's not to up-level engineers 799 00:43:22,924 --> 00:43:26,415 and say, "All engineers now are gonna be senior level 800 00:43:26,415 --> 00:43:28,155 engineers, or tech leads, or whatever." 801 00:43:28,155 --> 00:43:31,353 We have the need for all the roles within the organization 802 00:43:31,353 --> 00:43:35,584 that we had before. We still have those needs in the 803 00:43:35,584 --> 00:43:39,489 future organization, but we have a higher need for judgment 804 00:43:39,489 --> 00:43:44,297 in all those roles because AI is going to assist us, but not 805 00:43:44,297 --> 00:43:48,909 solve all of our problems. Wow, I like your framing of 806 00:43:48,909 --> 00:43:51,303 this, right? So yeah, people have to learn 807 00:43:51,303 --> 00:43:53,503 how to make a good judgment, right? 808 00:43:53,623 --> 00:43:57,193 Learn how to notice things when it goes sideways, right? 809 00:43:57,193 --> 00:43:59,330 So for example, coming back to earlier discussion, right, a 810 00:43:59,330 --> 00:44:01,776 good architect will actually figure out the imbalance that 811 00:44:01,776 --> 00:44:04,591 is happening, right? Maybe the risk of, you know, 812 00:44:04,591 --> 00:44:07,873 AI-assisted code, you know, churning out more code, but not 813 00:44:07,873 --> 00:44:12,112 with a good quality, right? So all these aspects definitely, 814 00:44:12,112 --> 00:44:15,737 maybe need people to actually learn the patterns, right? 815 00:44:16,157 --> 00:44:18,547 Like again, like teaching how, how to see, right? 816 00:44:18,547 --> 00:44:21,777 Teaching others how to see. And then making, you know, 817 00:44:21,785 --> 00:44:24,937 this intervention, you know, making sure there's a guardrail 818 00:44:24,937 --> 00:44:27,521 policy in place, right? And ultimately making good 819 00:44:27,521 --> 00:44:30,318 judgment, right, such that your, you know, I don't know, 820 00:44:30,318 --> 00:44:33,027 your architecture, your code quality is still kind of like 821 00:44:33,027 --> 00:44:36,602 in a good state. So mentioning about judgment, 822 00:44:36,610 --> 00:44:40,634 you know, people associate also a lot with, you know, 823 00:44:40,634 --> 00:44:42,429 guardrails. You know, policy, governance 824 00:44:42,437 --> 00:44:45,827 on when using AI, right? Because it's so much easy to 825 00:44:45,827 --> 00:44:48,949 produce code these days, but if you don't have good judgment, 826 00:44:48,949 --> 00:44:52,802 good quality of, you know, governance and all that, right, 827 00:44:52,802 --> 00:44:56,962 people will still, you know, I don't know, like follow the 828 00:44:56,962 --> 00:45:01,643 way AI advise stuff, right? So how can an organization do 829 00:45:01,643 --> 00:45:04,519 this better? Is this one part of a 830 00:45:04,519 --> 00:45:07,457 architecture, sorry, one part of architect's role as well to 831 00:45:07,457 --> 00:45:10,102 actually come up with the policy and governance or is this 832 00:45:10,102 --> 00:45:13,652 something that someone else, kind of like have to make 833 00:45:13,652 --> 00:45:16,275 decision? So it's a good question. 834 00:45:16,275 --> 00:45:20,075 I think, you know, the architect's role is to help 835 00:45:20,075 --> 00:45:24,227 create the environment where the guardrails are built and 836 00:45:24,227 --> 00:45:26,623 created correctly. They're not the ones who come 837 00:45:26,631 --> 00:45:29,245 up with the governance, they're the ones that help create them. 838 00:45:29,625 --> 00:45:33,625 And really, the right guardrails aren't really policy 839 00:45:33,625 --> 00:45:37,117 documents, right? The right guardrails are the 840 00:45:37,117 --> 00:45:41,286 right process that allows developers to create what they 841 00:45:41,286 --> 00:45:44,655 need to create and to be proud of what they create. 842 00:45:44,685 --> 00:45:50,955 You know, they, the developers need to still be responsible for 843 00:45:50,955 --> 00:45:53,965 everything they produce, whether AI wrote it or they wrote it. 844 00:45:54,405 --> 00:45:58,245 And so their own self-guardrails become really the first line 845 00:45:58,245 --> 00:46:01,450 of defense to make that happen. I don't think we're seeing 846 00:46:01,450 --> 00:46:03,275 enough of that yet. I don't think we're seeing 847 00:46:03,283 --> 00:46:05,975 enough focus on that yet. I think we're seeing developers 848 00:46:05,975 --> 00:46:09,363 realize that, "Hey, I can do, I can write 10x more code 849 00:46:09,363 --> 00:46:11,379 because I don't have to pay attention to it as much anymore. 850 00:46:11,379 --> 00:46:14,069 I can do all these things and look at, I acted like 10 851 00:46:14,069 --> 00:46:14,925 engineers. Isn't this great?" 852 00:46:15,295 --> 00:46:17,395 That's not the right role for them. 853 00:46:17,395 --> 00:46:22,353 Their role for them is to use AI to help alleviate the things 854 00:46:22,353 --> 00:46:28,405 that slow them down and to make it harder for them to write 855 00:46:28,405 --> 00:46:32,472 code, but not remove the responsibility for the code they 856 00:46:32,472 --> 00:46:34,499 develop. You know, when I was… You know, 857 00:46:34,499 --> 00:46:37,623 I do a lot of writing of code on my own simply because, you 858 00:46:37,623 --> 00:46:40,379 know, I don't get to do it professionally as much anymore, 859 00:46:40,379 --> 00:46:42,815 but I still love to code, so I write a lot on my own. 860 00:46:43,715 --> 00:46:49,984 But what I find is that, you know, I used to spend a lot of 861 00:46:49,984 --> 00:46:53,651 my time writing code, with dealing with bottlenecks in 862 00:46:53,651 --> 00:46:57,385 the code writing process itself. You know, what API parameters 863 00:46:57,393 --> 00:47:01,132 are needed for so and so, and how does this loop variable 864 00:47:01,132 --> 00:47:02,935 work. You know, all those sorts of 865 00:47:02,935 --> 00:47:06,229 little things that you, that take up 90% of your brain and 866 00:47:06,229 --> 00:47:09,033 90% of your actions. Well, all that goes away with 867 00:47:09,033 --> 00:47:11,565 AI. AI can do all of that for you. 868 00:47:11,565 --> 00:47:14,345 You know, just build this API for me, fine, no problem. 869 00:47:14,875 --> 00:47:17,585 But that doesn't change your job. 870 00:47:17,705 --> 00:47:20,429 Your job is still to make sure that the code that gets 871 00:47:20,429 --> 00:47:23,576 created is the code you want to get created, and is the right 872 00:47:23,576 --> 00:47:26,771 code and the right shape and the right size and everything's 873 00:47:26,771 --> 00:47:30,011 correct. What AIs really should be doing 874 00:47:30,011 --> 00:47:34,851 for you is removing the obstacles for you to do what you 875 00:47:34,851 --> 00:47:38,715 really want to be doing, which is developing a good system. 876 00:47:39,944 --> 00:47:42,068 Yeah. So I think it's a very 877 00:47:42,076 --> 00:47:44,884 important reminder, right? So because people think now with 878 00:47:44,884 --> 00:47:48,446 AI they can just produce a lot more code, a lot more output, 879 00:47:48,446 --> 00:47:50,720 right? But slowly the responsibility 880 00:47:50,728 --> 00:47:53,689 of understanding the system, understanding how the code gets 881 00:47:53,689 --> 00:47:57,122 produced is something that is kind of like starting to get 882 00:47:57,122 --> 00:47:59,688 eroded, right? People will start… I think I 883 00:47:59,688 --> 00:48:03,320 keep hearing as well, like in the conversations or in some 884 00:48:03,320 --> 00:48:06,972 posts that people say, oh, Claude says this, or maybe, I 885 00:48:06,972 --> 00:48:10,380 don't know, AI suggests me that, or I don't know how it got 886 00:48:10,380 --> 00:48:11,784 produced in the first place, right? 887 00:48:11,984 --> 00:48:13,534 So all these are kind of like signs, right? 888 00:48:14,124 --> 00:48:17,754 People call this also cognitive debt, intent debt, right? 889 00:48:17,754 --> 00:48:21,274 So, using the triple debt model that, you know, Margaret-Ann 890 00:48:21,274 --> 00:48:23,294 Storey came out, recently as well. 891 00:48:23,454 --> 00:48:26,042 So I think definitely there's a lot of risk of using AI not in 892 00:48:26,042 --> 00:48:28,502 the right way. I like the way that you 893 00:48:28,502 --> 00:48:31,338 mentioned that it should not remove the responsibility of 894 00:48:31,338 --> 00:48:35,324 developer in deciding, right, the right size of the code, the 895 00:48:35,324 --> 00:48:37,854 right shape of the code, right, the right quality of the 896 00:48:37,854 --> 00:48:39,944 code. So definitely, it's something, 897 00:48:39,944 --> 00:48:43,994 very important. So talking about, you know, 898 00:48:43,994 --> 00:48:47,638 removing responsibility, I've seen some trends in the industry 899 00:48:47,638 --> 00:48:50,476 where people, their ultimate aim is actually to create this 900 00:48:50,476 --> 00:48:53,094 thing called, I don't know, like dark factory thing, right? 901 00:48:53,094 --> 00:48:57,934 Just like the photo, borrowing from a photo analogy, right? 902 00:48:57,934 --> 00:49:01,074 You have the dark room where, you know, photos get produced. 903 00:49:01,244 --> 00:49:03,994 In this case it's dark factory, like you have a dark room where 904 00:49:04,034 --> 00:49:05,844 code gets produced somehow by AI. 905 00:49:06,734 --> 00:49:10,074 So a lot of things are turning into this trend now. 906 00:49:10,074 --> 00:49:13,029 Like people want to reduce number of developers and have 907 00:49:13,029 --> 00:49:16,604 AI fully automate it and build the system for us. 908 00:49:17,154 --> 00:49:20,730 This seems to be, you know, in contrast to what you just 909 00:49:20,730 --> 00:49:23,620 mentioned, right? So tell us about the danger of 910 00:49:23,620 --> 00:49:26,684 this trend. First of all, I really think 911 00:49:26,684 --> 00:49:30,368 this trend, as we're talking about, is on the rise of the 912 00:49:30,368 --> 00:49:35,100 hype curve, and it's due for a big fall here coming very soon. 913 00:49:35,110 --> 00:49:37,780 So because I… W- it… And I, and you're already starting to 914 00:49:37,780 --> 00:49:41,784 see some of this happen, right? You're seeing, you know, 915 00:49:41,792 --> 00:49:47,745 vibe-coded applications that can't go the next step because 916 00:49:47,753 --> 00:49:52,204 nobody understands how it works. And it's too complex and too 917 00:49:52,204 --> 00:49:56,261 involved, and the bug rate becomes too convoluted for 918 00:49:56,261 --> 00:49:58,570 anyone to really understand what's going on, so you have 919 00:49:58,570 --> 00:50:01,170 to throw it away and start over again, you know. 920 00:50:01,170 --> 00:50:05,998 And that's what you get when you build a system that's not 921 00:50:05,998 --> 00:50:08,586 understandable. And that's what vibe coding does 922 00:50:08,586 --> 00:50:11,942 for you, is it builds systems that is not, that are not 923 00:50:11,942 --> 00:50:14,900 understandable. Now I'm not against vibe coding. 924 00:50:15,360 --> 00:50:18,642 I think vibe coding's great for prototyping, for trying new 925 00:50:18,642 --> 00:50:21,802 ideas, and to say, "Hey, what if we wanted something like this? 926 00:50:21,802 --> 00:50:24,505 Build it up, test it out. Everything's great." 927 00:50:24,505 --> 00:50:28,334 And it's also great for maybe creating the initial foundations 928 00:50:28,334 --> 00:50:32,686 of an application. But it's not great as a way of 929 00:50:32,686 --> 00:50:35,460 replacing the developer. And so these dark rooms we're 930 00:50:35,468 --> 00:50:38,706 talking about here aren't the way the software should be 931 00:50:38,706 --> 00:50:42,090 created, nor will it be created in the future. 932 00:50:42,090 --> 00:50:45,668 I think the whole concept of this dark room is a trend 933 00:50:45,668 --> 00:50:48,865 that's going to disappear. It's not gonna be long-term 934 00:50:48,873 --> 00:50:52,340 sustainable, and it's not the way that we're gonna be seeing 935 00:50:52,340 --> 00:50:54,240 software developed, you know, 10 years from now. 936 00:50:54,940 --> 00:50:58,836 If you're a new developer coming out, you know, that's just 937 00:50:58,836 --> 00:51:01,726 starting into the industry now, you're not gonna be replaced 938 00:51:01,726 --> 00:51:05,060 by a dark room. You might be replaced by 939 00:51:05,060 --> 00:51:08,743 engineers who can make better use of AI than you, and that's 940 00:51:08,743 --> 00:51:10,260 something you should be aware of. 941 00:51:10,280 --> 00:51:14,810 You should make good use of AI in your job, but you're not 942 00:51:14,810 --> 00:51:16,350 gonna be replaced by a dark room. 943 00:51:16,380 --> 00:51:18,350 That is just not the way it's going to be. 944 00:51:19,150 --> 00:51:22,483 But hype is hype, and that's what we're seeing the hype 945 00:51:22,483 --> 00:51:26,410 with right now. I see this very similar to the 946 00:51:26,418 --> 00:51:29,565 hype with the cloud computing. You know, I was very, very 947 00:51:29,565 --> 00:51:30,860 intimately involved with cloud computing. 948 00:51:30,860 --> 00:51:33,730 I was involved with the early days of creating cloud computing 949 00:51:33,730 --> 00:51:38,000 and when working at AWS. And we saw the same thing, or 950 00:51:38,000 --> 00:51:40,435 I saw the same thing. You know, everyone said, 951 00:51:40,443 --> 00:51:43,675 "Everything's gonna be moving to the cloud, and nothing's gonna 952 00:51:43,683 --> 00:51:47,709 exist anywhere but in the cloud. And oh, by the way, it's all 953 00:51:47,709 --> 00:51:50,440 gonna be serverless." And I… You have no idea the 954 00:51:50,440 --> 00:51:53,820 number of people who came to me at trade shows and s- and, 955 00:51:53,820 --> 00:51:56,560 you know, they would, you know, introduce me and say, "Oh, I 956 00:51:56,560 --> 00:51:58,200 love what you do. I love what you're doing. 957 00:51:58,360 --> 00:52:01,978 Hey, I wanna tell you, we built our entire company using 958 00:52:01,978 --> 00:52:05,540 nothing but serverless code. Aren't you proud of us?" 959 00:52:05,540 --> 00:52:10,330 And then I say, no. Did you use serverless for 960 00:52:10,338 --> 00:52:13,750 what it's intended for, but not everything, right, you know. 961 00:52:13,750 --> 00:52:15,980 And so I think the same thing's true here. 962 00:52:16,000 --> 00:52:19,933 I think, you know, AI is great at helping you build 963 00:52:19,933 --> 00:52:23,744 applications, and AI is the best thing to happen to software 964 00:52:23,744 --> 00:52:27,233 development ever. It's also the worst thing to 965 00:52:27,233 --> 00:52:28,908 happen to software development ever. 966 00:52:29,278 --> 00:52:33,084 And I think we're, as we sort out the worst things from the 967 00:52:33,084 --> 00:52:34,908 best things, we're gonna figure out the best things. 968 00:52:34,908 --> 00:52:37,295 Just like with cloud computing, we figured out, you know, the 969 00:52:37,295 --> 00:52:39,813 cloud native model and what works in the cloud and what 970 00:52:39,813 --> 00:52:43,308 doesn't work in the cloud. That same thing is going to 971 00:52:43,308 --> 00:52:46,904 happen here with AI. In fact, I'm, I, One of my 972 00:52:46,904 --> 00:52:50,068 articles that's going to go live, I think on Tuesday, is 973 00:52:50,088 --> 00:52:53,128 about AI native and how it compares to cloud native, and 974 00:52:53,128 --> 00:52:56,478 the move towards an AI native world, and what does that mean. 975 00:52:57,118 --> 00:53:00,300 And what you're gonna find is it looks very different than the 976 00:53:00,300 --> 00:53:03,318 hype you're seeing now. Just like the cloud looked 977 00:53:03,326 --> 00:53:06,598 very different than the cloud hype was when it first started. 978 00:53:06,938 --> 00:53:12,328 So don't be distressed by the world of hype of AI right now. 979 00:53:12,668 --> 00:53:15,348 It's going to settle down, and when it settles down, it's gonna 980 00:53:15,348 --> 00:53:19,318 settle down to the point where AI is a truly useful tool for 981 00:53:19,318 --> 00:53:21,548 us, but isn't replacing everything we do. 982 00:53:23,432 --> 00:53:25,670 Yeah. Maybe if you can get, give us a 983 00:53:25,670 --> 00:53:27,882 glimpse, because by the time this episode gets released, I'm 984 00:53:27,882 --> 00:53:29,962 sure your article has been published as well. 985 00:53:29,962 --> 00:53:33,724 So tell us some important aspects of being an AI-native 986 00:53:33,724 --> 00:53:36,928 team or organization. Oh, sure, yeah. 987 00:53:37,068 --> 00:53:41,063 So the, you know, the big thing that I talk about with in the 988 00:53:41,063 --> 00:53:44,515 article is about the AI-focused applications and how you build 989 00:53:44,515 --> 00:53:47,664 an application that's AI-native. And the fallacy that people are 990 00:53:47,664 --> 00:53:51,606 running into now is they say, "Well, let me add a chatbot and 991 00:53:51,606 --> 00:53:55,477 maybe one or two of my processes I'll replace with an 992 00:53:55,477 --> 00:53:58,028 AI agent, and everything… now I'm an AI app. 993 00:53:58,028 --> 00:54:00,716 And, you know, look, I'm AI-centric now, right?" 994 00:54:00,716 --> 00:54:06,417 Well, AI-native is more about things like looking at what AI 995 00:54:06,417 --> 00:54:11,371 is good at and using, you know, structuring your application 996 00:54:11,371 --> 00:54:14,855 to take advantage of those things, but not everything. 997 00:54:14,895 --> 00:54:18,685 You know, for instance, AI is non-deterministic. 998 00:54:19,465 --> 00:54:22,293 Most applications and most application development models 999 00:54:22,293 --> 00:54:26,125 right now are very deterministic, but can take 1000 00:54:26,133 --> 00:54:29,175 advantage of non-deterministic aspects for various parts of 1001 00:54:29,175 --> 00:54:30,675 what they're trying to accomplish. 1002 00:54:31,035 --> 00:54:34,541 Well, if you can feather out what parts of your application 1003 00:54:34,541 --> 00:54:37,379 are enhanced by non-deterministic and use AI 1004 00:54:37,379 --> 00:54:42,925 there, and keep the parts that aren't out of that and keep them 1005 00:54:42,925 --> 00:54:45,035 deterministic, you're gonna be better off. 1006 00:54:45,795 --> 00:54:49,345 So understanding the deterministic versus 1007 00:54:49,345 --> 00:54:53,055 non-deterministic aspect is a great part of that. 1008 00:54:53,835 --> 00:54:57,795 You see now, what people are doing now though, is they're 1009 00:54:57,795 --> 00:55:00,875 doing things like how do we make AI more deterministic? 1010 00:55:01,255 --> 00:55:05,617 And that's not the right model. The AI native model is to 1011 00:55:05,617 --> 00:55:09,423 leverage the non-determinism to… for the parts of your 1012 00:55:09,423 --> 00:55:11,595 application that are enhanced by non-determinism. 1013 00:55:11,935 --> 00:55:14,804 That's one of the things. I think I come up with four 1014 00:55:14,804 --> 00:55:16,465 things. I don't remember what they all 1015 00:55:16,465 --> 00:55:19,031 are offhand in the article, in this article, but that was one 1016 00:55:19,031 --> 00:55:21,965 of the big ones. And, you know, another one is 1017 00:55:21,965 --> 00:55:24,285 sizing. I think a lot of things you see 1018 00:55:24,285 --> 00:55:27,498 nowadays is a lot of companies that are just adding AI to their 1019 00:55:27,498 --> 00:55:30,625 application say, "Okay, I'm gonna add a chat box, and I want 1020 00:55:30,625 --> 00:55:34,155 it to be smart, so I'll use the biggest model I can find, and 1021 00:55:34,155 --> 00:55:38,434 I'll use that for everything." Well, the vast majority of what 1022 00:55:38,434 --> 00:55:44,267 you need your, to use your, in your application for AI doesn't 1023 00:55:44,267 --> 00:55:49,169 need Fable or Opus. It works just fine with Haiku, 1024 00:55:49,169 --> 00:55:51,863 you right? You know, you don't need the 1025 00:55:51,871 --> 00:55:55,285 power of a super strong model. You need just some 1026 00:55:55,285 --> 00:55:57,945 non-deterministic help in building things and making 1027 00:55:57,945 --> 00:56:00,435 things work and to, and to munge things. 1028 00:56:00,965 --> 00:56:06,585 And so, another aspect of an AI native application is to 1029 00:56:06,585 --> 00:56:09,857 understand the size and cost of model that's appropriate for 1030 00:56:09,857 --> 00:56:13,065 the type of job you're trying to do, and then apply it in the 1031 00:56:13,073 --> 00:56:14,565 right place and at the right time. 1032 00:56:14,625 --> 00:56:21,782 So that's another aspect of it. The article will be on, in my 1033 00:56:21,782 --> 00:56:23,405 newsletter at softwarearchitectureinsights.com. 1034 00:56:23,455 --> 00:56:26,075 Hopefully you can put a link to that in the show notes. 1035 00:56:26,495 --> 00:56:29,750 And it'll be there. I'm not sure when this ar- when 1036 00:56:29,750 --> 00:56:33,507 this episode will come out, but it'll be there in the history if 1037 00:56:33,507 --> 00:56:35,355 it's not the most recent issue. 1038 00:56:35,475 --> 00:56:38,667 It'll be be one of them in the, in near past and you'll be 1039 00:56:38,667 --> 00:56:41,624 able to see it. But I write a lot about AI 1040 00:56:41,624 --> 00:56:44,442 there, and I write a lot about software architecture there, 1041 00:56:44,442 --> 00:56:47,202 obviously. And that's just one of the 1042 00:56:47,202 --> 00:56:49,225 topics I'm, I've been working on recently. 1043 00:56:50,365 --> 00:56:51,821 Nice. Yeah, we'll definitely put 1044 00:56:51,821 --> 00:56:54,001 that in show notes. I was laughing when you 1045 00:56:54,001 --> 00:56:56,847 mentioned like, people are trying hard to make AI more 1046 00:56:56,847 --> 00:56:59,095 deterministic. I guess that's kind of like the 1047 00:56:59,095 --> 00:57:00,615 wrong trend that people are doing, I guess. 1048 00:57:00,655 --> 00:57:03,685 Especially if they really still rely on the LLM, right? 1049 00:57:03,995 --> 00:57:07,160 So the technology, the fundamentals behind all this, 1050 00:57:07,160 --> 00:57:09,785 you know, AI model that we see in the industry. 1051 00:57:10,025 --> 00:57:13,035 Because the LLM itself works probabilistically, right? 1052 00:57:13,495 --> 00:57:16,694 So that means non-deterministic. So I think that's a very good 1053 00:57:16,702 --> 00:57:19,155 call-out that, I think we still have to remember, right? 1054 00:57:19,185 --> 00:57:23,391 Remind ourselves, even though AI seems to be more like smarter, 1055 00:57:23,391 --> 00:57:26,626 more powerful, seems to be able to do a lot of things, don't 1056 00:57:26,626 --> 00:57:29,553 forget like all the things that they produce are actually 1057 00:57:29,553 --> 00:57:32,150 non-deterministic. And sometimes when you write 1058 00:57:32,150 --> 00:57:35,839 software, you want to be more deterministic rather than 1059 00:57:35,839 --> 00:57:39,641 non-deterministic. And I think AI is the best thing 1060 00:57:39,641 --> 00:57:42,341 that happens to software development, but it could also 1061 00:57:42,341 --> 00:57:44,435 be the worst thing. So I think that's another one 1062 00:57:44,435 --> 00:57:46,809 that I really like. So it's like a double-edged 1063 00:57:46,809 --> 00:57:49,825 sword. Pick the side that you prefer, 1064 00:57:49,833 --> 00:57:52,689 I think, right, to summarize. Yeah. 1065 00:57:52,999 --> 00:57:54,729 So Lee, thank you so much for this conversation. 1066 00:57:54,749 --> 00:57:57,697 I think many people hopefully learn a lot about how to 1067 00:57:57,697 --> 00:57:59,709 transition to becoming a good software architect, right? 1068 00:57:59,729 --> 00:58:03,252 Remember, it's the orchestra rather than the dictator. so 1069 00:58:03,252 --> 00:58:05,371 before I let you go, I have one last question that I would 1070 00:58:05,371 --> 00:58:07,313 like to ask you. I call this the three 1071 00:58:07,321 --> 00:58:09,882 technical leadership wisdom. if you can think of them just 1072 00:58:09,890 --> 00:58:12,799 like an advice you wanna give to the listeners before we close 1073 00:58:12,799 --> 00:58:14,799 the conversation, that would be great. 1074 00:58:15,809 --> 00:58:18,201 Sure. I think you, you probably have 1075 00:58:18,201 --> 00:58:21,379 heard all three of them so far in what I've been saying about 1076 00:58:21,379 --> 00:58:23,726 the book. But, you know, the first one is, 1077 00:58:23,726 --> 00:58:25,289 you know, listen before you lead. 1078 00:58:25,299 --> 00:58:29,945 You know, the conductor's most powerful tool is silence to 1079 00:58:29,945 --> 00:58:33,029 listen. And that's just as critical to 1080 00:58:33,029 --> 00:58:37,605 us as software architects. The second one is to judge… When 1081 00:58:37,605 --> 00:58:41,345 you look at your week that you've just completed, judge the 1082 00:58:41,345 --> 00:58:45,228 week by what your team shipped, not what you've 1083 00:58:45,228 --> 00:58:47,715 shipped. Because your- what you do is 1084 00:58:47,715 --> 00:58:51,493 less important than what your team does, and your value is 1085 00:58:51,493 --> 00:58:54,139 really to make your team more productive. 1086 00:58:54,249 --> 00:58:58,983 And to think that way is part of the process of moving out of 1087 00:58:58,983 --> 00:59:02,511 the hero mentality. And the third one, and this 1088 00:59:02,511 --> 00:59:04,959 applies to everybody, not just software architects, but work 1089 00:59:04,959 --> 00:59:06,879 yourself out of a job on purpose. 1090 00:59:07,209 --> 00:59:10,459 Your job, your p- your, one of your main jobs is to always 1091 00:59:10,459 --> 00:59:13,329 find your replacement and to train your replacement. 1092 00:59:14,049 --> 00:59:16,189 And we don't do enough of that as an industry. 1093 00:59:16,629 --> 00:59:19,759 And it will hurt you and your opportunities to move on. 1094 00:59:19,779 --> 00:59:23,516 I have seen so many people, in fact, it's happened to me, 1095 00:59:23,516 --> 00:59:27,283 where I couldn't move on to the next job because I was too 1096 00:59:27,283 --> 00:59:30,143 valuable in the job I was currently doing because nobody 1097 00:59:30,143 --> 00:59:33,585 else could do it. And that's my failing, not 1098 00:59:33,585 --> 00:59:37,223 anybody else's. So work yourself out of a job, 1099 00:59:37,223 --> 00:59:39,286 always. Right. 1100 00:59:39,886 --> 00:59:43,584 So one thing that people are trying to do is to use AI more 1101 00:59:43,584 --> 00:59:46,311 to replace themselves. But there's a lot of worry 1102 00:59:46,311 --> 00:59:49,056 about, you know, junior developers who need to step up 1103 00:59:49,056 --> 00:59:50,536 and become the successor. Yeah. 1104 00:59:51,366 --> 00:59:54,798 So yeah, I think the, again, it's a trend that many people 1105 00:59:54,798 --> 00:59:58,140 are picking up. So hopefully we still ha- got 1106 00:59:58,148 --> 01:00:02,064 junior software developer being able to transition to senior to 1107 01:00:02,064 --> 01:00:04,598 software architect, right, to engineering managers and all 1108 01:00:04,598 --> 01:00:06,741 that. So yeah, hopefully the, the 1109 01:00:06,741 --> 01:00:09,766 trend is not going to the wrong ways. 1110 01:00:10,236 --> 01:00:13,296 So Lee, if people love this conversation, they wanna reach 1111 01:00:13,296 --> 01:00:16,452 out to you, ask you more questions, or, you know, buy the 1112 01:00:16,452 --> 01:00:18,656 book, is there a place where they can go online? 1113 01:00:19,254 --> 01:00:20,939 Sure. I'll give you three, three 1114 01:00:20,939 --> 01:00:22,799 places they can go. First, if you're interested in 1115 01:00:22,799 --> 01:00:28,792 the book, you can go to thesoftwareconductor.com and the 1116 01:00:28,792 --> 01:00:31,794 book is there, and it's available on Amazon. 1117 01:00:31,794 --> 01:00:34,124 It's available in some tech bookstores. 1118 01:00:35,314 --> 01:00:39,084 And so you can get it any place that you would buy technical 1119 01:00:39,084 --> 01:00:42,076 books. And if you wanna find out more 1120 01:00:42,084 --> 01:00:45,376 about me and the things that I do, you can go to 1121 01:00:45,376 --> 01:00:48,262 leeatchison.com. And if you want to read my 1122 01:00:48,262 --> 01:00:50,944 writing and my articles and subscribe to my newsletter, 1123 01:00:52,264 --> 01:00:56,074 softwarearchitectureinsights.com is where I do all of my weekly 1124 01:00:57,064 --> 01:00:58,924 newsletter and my weekly writings. 1125 01:01:00,234 --> 01:01:03,331 Yeah. And I would like to also call 1126 01:01:03,339 --> 01:01:06,289 out that Lee has written quite a number of books, right? 1127 01:01:06,989 --> 01:01:09,400 Not just, you know, like being a software architect, but the, 1128 01:01:09,400 --> 01:01:11,519 like the usual architecture stuff as well. 1129 01:01:12,049 --> 01:01:13,779 So make sure you check them out as well. 1130 01:01:14,039 --> 01:01:16,359 So Lee, thank you so much for being in the show. 1131 01:01:16,399 --> 01:01:19,424 I learned a lot personally. So hopefully other people can 1132 01:01:19,432 --> 01:01:21,277 also learn from this conversation, so thank you for 1133 01:01:21,277 --> 01:01:22,960 that. Thank you, Henry. 1134 01:01:22,960 --> 01:01:23,760 It was great to be here.