Transcript: A Fundamental Shift: Change Management, Psychological Safety, and AI's Impact on Engineering Leadership with Dr. Adam Link
0:00 Adam One of the things that I found easiest to change management is when you have a culture of engineers who recognize that you're not really a true software engineer until you've taken down prop.
0:27 Brad All right. Welcome,
0:27 Brad everybody,
0:28 Brad to another episode of the How Many CTOs Does It Take podcast?
0:31 Brad My name is Brad Hefta-Gaub, and our regular co-host Scott Porad is not here today,
0:35 Brad but we have a very interesting guest with us today,
0:39 Brad Dr.
0:39 Brad Adam Link.
0:40 Brad I'm looking forward to talking to him about lots of interesting topics.
0:45 Brad Adam,
0:46 Brad why don't you introduce yourself and maybe let the audience know a little bit about how you got here.
0:50 Adam Yeah, certainly.
0:51 Adam Like I said, Dr.
0:52 Adam Adam Link.
0:53 Adam The doctorate, there's actually a doctorate in computer science, not medicine,
0:57 Adam but computer science.
0:59 Adam So this is one of the few venues where I definitely get to use the doctor abbreviation because I earned it.
1:06 Adam Yeah,
1:07 Adam no,
1:07 Adam so I was a senior engineering manager at Coinbase and,
1:10 Adam you know, worked at Coinbase for a number of years.
1:14 Adam I've actually since transitioned out of the technology industry very recently.
1:18 Adam you know have led teams across multiple continents have led massive transformational change inside of companies and you know those those changes are highly technical in nature you know things like lifting and shifting the entire computer platform lifting and shifting the entire computer architecture i did over a decade in tech well
1:38 Brad Yeah.
1:39 Adam over a decade in tech and about eight years of that actually in the crypto space so when it comes to you know
1:43 Adam you know massive amounts of change you know we saw over the last decade kind of crypto was the the hot new thing uh and then became institutionalized now of course it's ai um we
1:54 Brad Yeah.
1:54 Adam have to talk about ai at some point but uh yeah you know i i
1:57 Brad We didn't even get five minutes in and we're already talking about AI.
2:01 Adam well of course of course you know it's a technology podcast and the zeitgeist is ai
2:06 Brad When you talked about change management and crypto,
2:09 Brad I thought you were trying to make a.
2:10 Brad to make a joke there about change and being
2:13 Adam Oh,
2:13 Brad fintech
2:13 Adam yeah.
2:14 Brad i love
2:14 Adam Yep. No,
2:15 Adam that would have been a much better joke.
2:17 Adam Unfortunately,
2:18 Adam it is Friday afternoon. So my collection of dad jokes went up with this morning's standups.
2:24 Brad it love it well when i think about like um you know as a cto when i think about uh sort of like managing change management and change managing through change there's so many things that can come up obviously we've got
2:36 Brad You already mentioned the notion of like large technology changes.
2:40 Brad You also obviously are going to often go through organizational or management changes. Of course, there's a lot of like organizational, let's say, right sizing going on these days in our industry.
2:55 Brad Downsizing, right sizing, however you want to say it to spin it for the audience you're trying to spin it for.
3:02 Brad And then we also have like sort of like kind of process change and culture change.
3:07 Brad I'm just kind of curious,
3:08 Brad Adam, when you think about like the challenges that we face as engineering leaders,
3:13 Brad where do you think do you think there's commonality in change management or do you think that different types of change require different approaches?
3:22 Adam Yeah, I definitely think as engineering leaders,
3:26 Adam our job is people.
3:28 Adam Right.
3:29 Adam If you like tech and you only like tech, you stay an individual contributor,
3:33 Adam right?
3:33 Adam In most companies, at least those that I think are forward thinking enough in technology,
3:37 Adam they recognize that people management is a separate skill,
3:40 Adam right?
3:41 Adam Not every really good engineer wants to be a manager of people.
3:45 Adam And so it is a separate and complementary skill that you have to have.
3:49 Adam And so really, at the end of the day, I do think change management with people.
3:53 Adam is pretty much a skill that you can get good at,
3:56 Adam but the nuance comes in the culture of the individual company that you're working in.
4:02 Adam Right.
4:03 Adam One of the things that I found when it comes to change management is that the culture of failure inside the company is one of the most important things.
4:12 Adam If engineers are fail or failure adverse,
4:16 Adam they're scared to fail,
4:18 Adam whether it be technically or process wise or in a promotion or something like that,
4:23 Adam there's a lot of fear around a change that just makes the change substantially.
4:28 Adam actually harder because you have to actually get over the human fear before you even get to the technical good or bad or process good or bad and you know anything like that right and
4:38 Brad Yeah.
4:39 Adam so that is one of the things I found as manager that kind of works across the board is your ability to provide what I call air cover right which is basically you as a manager take the first hit for your team and then you know you can kind of massage the message as it goes through
4:54 Adam through you and so if you provide air cover to your engineers that also goes upwards that when your engineers you know make a mistake right you're able to massage that messaging going out to a VP or an exec level to explain why it's not the engineer's fault right and so that is something that we've had to do a lot change management it's just really massage you know messages when things go wrong right so you don't have a bunch of engineers suddenly feeling like they got thrown in the bus
5:18 Brad Yeah,
5:19 Brad it's interesting.
5:19 Brad I think that like what I hear you saying, if I can play it back,
5:22 Brad is that a big part of change management is creating a space of essentially psychological safety so that the people feel like they can even hear about the change,
5:32 Brad they can begin to process the change and not be in a reactive sort of fearful state.
5:38 Brad And then I think what I hear you saying that a big part of like creating that safety within the team is.
5:43 Brad just being able to kind of manage in both directions and sort of provide a air cover as you said i think i used to i think when i was early in my career i used to describe it as like being an umbrella you know uh for
5:57 Adam Yes.
5:57 Brad the team so they're not the ones getting rained on or whatever is coming out of the sky on them
6:03 Adam Yes.
6:03 Adam My team has often had that nickname for me, the blank umbrella.
6:08 Adam umbrella.
6:08 Brad Yeah.
6:08 Adam That's my job, right?
6:10 Adam It's my job is just to make sure that
6:13 Adam You know, they have a space
6:14 Brad But, you know, it's interesting,
6:15 Brad too, you say that and not to get too far afield from the change management conversation,
6:19 Brad obviously another challenge that we face as, you know, leaders in companies that are naturally,
6:26 Brad you know, working their way in capitalism is that we have an accountability to the enterprise,
6:30 Brad to the stakeholders of the enterprise, be that our customers or our shareholders or kind of the community at large.
6:38 Brad And that sometimes means like managing through change that will be difficult.
6:44 Brad And sometimes, you know, hard for some team members.
6:48 Adam Yes, that is very true.
6:50 Adam And I do think one of the hallmarks of being a good manager is your ability to go through those tough conversations with people,
6:57 Adam you know, whether it be a riff,
7:00 Adam you know, lay off a company right sizing, however you want to euphemistically spin it, you know, or just terminations, you know, negative performance reviews.
7:08 Adam Yeah,
7:09 Adam change management.
7:10 Adam It impacts people, it impacts lives.
7:13 Adam Right.
7:14 Adam And that is one of the things that I've actually had to go through many times, right?
7:20 Adam Like any good manager, you go through a change as part of change management and you find yourself on a call with an engineer and HR and you and you go, man, the rest of your Tuesday is going to be horrible.
7:29 Adam Sorry about that.
7:30 Brad All right.
7:31 Adam You know, it's just business,
7:32 Adam right?
7:33 Adam Which is almost never true.
7:35 Adam Right. It's it's deeply personal,
7:37 Adam at least the way that I practice.
7:39 Adam Right.
7:39 Adam I think it's deeply personal.
7:40 Adam You know, you are impacting somebody's ability maybe to make the mortgage that month, you know, or send their kids to school.
7:47 Adam And it's important to separate kind of your personal responsibility in that change from the organizational responsibility.
7:54 Adam Right.
7:55 Adam I think it's important to remember as a manager, being empathetic towards, you know,
8:00 Adam your team going through those tough conversations, like, yeah, you're impacting somebody's life.
8:04 Adam But at the same time, you also have to recognize that your manager would have the same conversation with you in a heartbeat if the company told him to.
8:10 Brad Yeah, totally.
8:12 Adam And so it's like, you know, you've got to do your job, you've got to be empathetic, but also recognize that it's not your decision.
8:19 Adam That led to this conversation,
8:21 Adam unless,
8:22 Adam you know, you're the CEO,
8:23 Adam in which case it might be your decision. Right. But even then,
8:25 Adam you know, there's market forces at work that you may or may not have control over. And so, you know, it's just it's one of those things like, yeah, impact somebody's life.
8:34 Adam Don't take that lightly.
8:37 Adam But at the same time, recognize that as much as you may be feeling like the bad guy,
8:41 Adam it's not you personally all
8:42 Brad yeah
8:43 Adam the time.
8:43 Brad it's the system yeah
8:44 Adam Yep. And that's got me through some of those tough conversations.
8:48 Brad totally totally the other thing about that is that you also have to kind of like typically i've been you know look i've been doing this for you know more than 35 years so it's like i've seen many termination or a you know
9:02 Brad risk or something like that and you know it's tough too but at the same time you also got to kind of one of the things that i try to hold on to as well we're trying to maximize the positive outcomes for as many people as we can right and unfortunately that means that some people might have a negative outcome but you know if we if we don't make those tough decisions
9:25 Brad And then more of the team suffers.
9:27 Brad Right.
9:28 Brad And so that's that's kind of one thing I try to hold on to.
9:31 Brad It's interesting.
9:32 Brad It is, you know, to your point about like as an engineer,
9:35 Brad if you don't really want to do the people side of things, then you sort of like kind of need to stay on that.
9:41 Brad i see route you know and these parts of it the sort of the challenging parts of dealing with the other humans you know those of us that a lot of us gravitates towards computer science because we like the you know kind of working with the machine and what have you seen in folks that like have made that jump into kind of the people management side of things what advice would you
10:08 Brad Would you give them about the things, the attributes that they probably would want to hold onto or to cultivate in themselves to be able to do that job well?
10:18 Adam Yeah, so I'll take a very engineering-focused response
10:21 Brad Sure.
10:21 Adam because,
10:23 Adam yeah, I think behind every engineering manager is a coder who just wants to get back to being heads down and building again.
10:29 Adam And so the way I've often told people who've asked me this is, you know, what's the difference between an engineering manager?
10:33 Adam manager and individual contributor um and my answer is kind of tongue-in-cheek you know what i'll say as engineering managers we test in production as as an engineer individual contributor you get to test in development you test in staging and then you push to production when you know there's very few of any bugs in your code you know how the code's going to work as an engineering manager i test in production i have no idea how you're going to respond to the sentence i'm about to tell you i have no idea if it's
10:59 Adam You know, if it's going to spin a whole downward spiral of culture problems or a bunch of rumors or impact your work or conversely, you know, give you a great new idea for a new product that leads to, you know, a new revenue source for the company.
11:14 Adam I have no idea what's going to happen. And so the best I can do is test in production and manage accordingly.
11:20 Adam Right. And so that means, you know, when you're talking to engineers sometimes like, oh, tell them, look,
11:25 Adam give me a bug report every now and then.
11:26 Adam you know look if i'm not doing something right it's just a bug report right
11:29 Brad Right.
11:30 Adam treat management like a system treat you know the team like a system and if you're dealing with a bunch of engineers you know nobody gets upset because you submit a bug report right no one says oh you're a bad programmer because there's a bug in your code right and so i try to take the same thing as a manager it's like if you keep that mindset of like just because something happens doesn't mean you're a bad manager it's just a bug in the system you
11:51 Adam right
11:51 Brad Now,
11:51 Adam well once you know about that bug if you don't do anything about it for a couple years right like well get now you're just a bad you know bad manager right you're a bad programmer you
12:00 Brad you
12:00 Adam got a bug
12:00 Brad got technical debt,
12:01 Brad technical debt in your management operating system.
12:04 Adam exactly right no but but it's also it makes it really easy when you put it like that to an engineer who's thinking of making the transition because you can start to understand kind of the mindset it takes
12:14 Adam And just like there's risks of testing in fraud,
12:17 Adam there's risks in management,
12:18 Adam right? Like sometimes you take down the production server and
12:20 Brad Yeah.
12:21 Adam that means, you know, you might have a mutiny on your hands. Your team really doesn't like what you say, right? People yell.
12:27 Adam That's taking down production,
12:29 Adam right?
12:30 Brad Yep.
12:30 Adam If you can wrap your head around kind of that equivalency,
12:33 Adam you as an engineer get to have an idea of what it is to be a manager before ever being there.
12:38 Adam Right. And you can get a sense of like, I'm not the type of person who would ever test in production.
12:43 Adam That is just not a thing I'm going to do.
12:44 Adam Okay,
12:45 Adam then maybe management isn't for you,
12:46 Adam right?
12:47 Brad I think that's an interesting analogy.
12:49 Brad I definitely haven't ever thought of it that way,
12:52 Brad but I can see where you're going,
12:53 Brad where it's like, you know, you have more chance of a reaction and of course your wisdom,
13:02 Brad your experience is going to help you have a less likelihood of.
13:06 Brad perturbating the system in a way that it's going to to create a problem uh but humans are you know a little bit more unpredictable let's say than than the code you write um so that's fair
13:18 Adam They are.
13:19 Brad do you think that like what's what are from your experience what are some examples of like the most complicated or difficult or what's a what's a a example of it
13:31 Brad Particularly challenging change management experience you had and do you have any tips for how you handled that?
13:37 Adam Yeah, so one of the things that, so my background is in infrastructure,
13:42 Adam as an infrastructure engineer,
13:43 Adam most of the stuff I end up doing is infrastructure lifecycle management.
13:48 Adam And so at a certain point in an infrastructure's life cycle, you have to deprecate infrastructure.
13:53 Adam And ever since we've gone into the cloud,
13:55 Adam this has accelerated beyond just deprecating a physical server to now,
13:59 Adam well, you've got major or minor version releases that change and all that fun stuff.
14:03 Adam And so as you do migrations in the cloud,
14:05 Adam it's a never-ending cycle of migrations and infrastructure.
14:08 Adam You're always moving from system A to system B.
14:11 Adam One of the most challenging migrations I think we did was in actually conjunction with
14:15 Brad Microsoft.
14:15 Adam in conjunction with a number of other infrastructure teams but we lifted and shifted the entire compute platform of a large fortune 500 company from ec2 which is just you know raw compute to eks which is kubernetes right so there's an orchestration layer in the middle and obviously you know you can run code on an individual computer but on kubernetes you are dockerizing everything it's all
14:40 Adam It's all container-based,
14:41 Adam it's all pods,
14:42 Adam it's all orchestrated, right?
14:43 Adam So you get a lot of benefits from a technical perspective of being able to shift workloads and not worrying about underlying technology and the actual underlying server.
14:51 Adam But lifting and shifting an entire company's compute layer onto an orchestration layer is a massive effort.
14:57 Brad Yeah, totally.
14:58 Adam Yeah,
14:59 Adam that was about 18 months of work to do that.
15:01 Brad Sure.
15:01 Brad And I think I can imagine like, you know, as I ponder something like that,
15:06 Brad like.
15:07 Brad A lot of the different aspects of the change management there are going to be you got to get buy in from so many people that are going to have, you know, kind of prebuilt expectations around the way it used to be right like,
15:19 Brad well, EC2 is good enough we got this far,
15:22 Brad you know, we know why I need to learn this whole new system,
15:26 Brad you know, it's it's
15:28 Brad Kubernetes is just like, you know, a bunch of fluff. It's syntactic sugar.
15:33 Brad You know, I don't really need that.
15:34 Brad We know our architecture now.
15:36 Brad Those types of reactions I can imagine would be pretty common.
15:41 Adam Yes, they're very common,
15:42 Adam right?
15:42 Adam So as an infrastructure manager,
15:45 Adam I go into teams and these are teams that are producing product,
15:48 Adam right? They are in the direct line of revenue.
15:51 Adam And so you come and you say, okay,
15:52 Adam look,
15:52 Adam so your Q3 plan.
15:54 Adam I know you're trying to launch a new feature.
15:56 Adam I know you're trying to capture market share.
15:57 Adam While you do that.
15:58 Adam We are shifting the entire compute layer underneath your feet, and now your make file doesn't work the way it used to. I need you to dockerize your make file. I need you to write a bunch of Helm charts,
16:08 Adam and I need you to get comfortable enough with Kubernetes that you can do basic operations to deploy your service.
16:14 Adam And this,
16:14 Adam you know, it's a poor engineer sitting there with a giant backlog of tickets going,
16:18 Adam you want me to do what now?
16:19 Brad Yeah.
16:19 Adam You're fundamentally shifting my entire service.
16:21 Adam You know, it's not a fun conversation to have.
16:23 Adam um especially when you know they're getting pressure from the revenue side of the business to ship product right
16:28 Brad Yeah.
16:29 Adam and here you are on the compute side uh you know saying hey well here's here's the cool new thing you're going to shift to now your application is going to run the same it's still going to have the same latency it's still going to respond with a 200 but you're going to do all this work and like okay now it allows us to scale it allows us to shift infrastructure allows us to be more resilient right
16:49 Adam right all this other operational stuff but as a software engineer you're like cool it still runs i
16:54 Brad Yeah.
16:54 Adam just need to ship a product
16:56 Brad Yeah,
16:56 Brad totally.
16:57 Brad I think that like,
16:58 Brad okay, so that's a great example of a major like change management. And I think that like, you know, kind of
17:06 Brad one of the things that you i think mentioned before we started recording is this idea that like well the technical like maybe i can convince you of the technical thing like this is technically the right answer but we overlook the kind of the psychological aspect of of of what that does for teams do you think that like do you have any particular uh suggestions on how you've been able to approach that to sort of
17:31 Brad handle that behavioral and psychological impact.
17:34 Adam Yeah, so this is actually something we had to learn maybe about three and a half, four years ago now,
17:38 Adam as we were actually doing this migration.
17:41 Adam So the two teams that really involved infrastructure,
17:44 Adam one of them was actually the compute team.
17:47 Adam So their job was the technical implementation of Kubernetes,
17:51 Adam right?
17:51 Adam They basically built the Kubernetes platform.
17:53 Adam And so it was great to have a very strong technical team.
17:56 Adam that we could lean on on the infrastructure side so like the first thing is you got to have the right people in the room who know their stuff right because there's nothing worse than bringing a massive change to an engineer and having them start poking holes in the technical implementation right because now it's like well now they don't trust you and they're overloaded and you know they don't trust the tech right so we had a very strong compute team that was able to basically explain the technical aspects incredibly well right like it doesn't matter if you're a principal level engineer they could
18:21 Adam they could explain exactly this is a good idea.
18:23 Adam And what my team basically did was the hands-on keyboard work for as much of the migrations we possibly could for these product teams.
18:31 Adam And so what we basically came with was a kind of an offer you couldn't refuse.
18:35 Adam And we found this worked very well with overloaded engineers.
18:39 Adam We would come to you and say,
18:40 Adam okay, we need you to change your entire compute layer.
18:42 Adam Here's the technical reason why, right? Here's the technical people you can talk to.
18:46 Adam But we're also going to come.
18:48 Adam with an engineer that's going to look at your service and help write the first draft of the code to make you shift over to this new compute layer,
18:57 Adam right?
18:58 Adam And so it was something we had to get really good at because you basically have to understand the service,
19:02 Adam you have to understand blast radius,
19:03 Adam you have to understand how it calls downstream and upstream.
19:06 Adam But once you have an engineer that can do that and write that first draft,
19:10 Adam even if it's not perfect,
19:11 Adam you've at least put forward a foot now as an infrastructure engineer.
19:15 Adam to say, I tried my best to be a service and infrastructure engineer.
19:20 Adam I tried my best to help you as far as I could.
19:23 Adam And what we found with a lot of engineers, by taking that first initiative and at least giving them a draft full request,
19:28 Adam even if it wasn't perfect,
19:29 Adam you give them something that they can react to.
19:32 Adam that allowed them to have that psychological safety of saying you know it's not my code right somebody else screwed it up if it goes down right and we on infrastructure we're fine with that we're used to taking down production it happens you get over it right um and so you know we were willing to you know put our our you know reputation in the line there and do our best that we could so you get that psychological safety to the product engineer you also give them the ability to react to something
19:57 Adam The hardest thing before AI for us was
19:59 Adam crafting code, right?
20:01 Adam And so now you can review code instead of craft it.
20:03 Adam And that's a lot easier for humans to read code and point out the inefficiencies, right?
20:07 Adam And so by putting that first foot forward and staffing my team appropriately so that we could actually go out and do that for the entire company,
20:15 Adam that really allowed us to get these product engineers on board.
20:18 Adam And then we basically tackled the biggest products we could first.
20:21 Adam So everyone after that would say,
20:23 Adam well, my product is super important.
20:24 Adam you know we can't we can't change we'd say oh really are you more important than you know the number one revenue product of the company because we shifted them and
20:32 Brad Right.
20:32 Adam it worked right and so now you've basically created this you know one-two punch like well you got to do it we'll do the work for you here's some psychological safety and if everything else breaks you get to say well it worked for the biggest product so i don't know what the heck happened here it's not my fault right so as a product engineer you're basically covered no matter
20:51 Adam No matter what happens, someone else is going to be there to help,
20:53 Adam right?
20:54 Adam So when an incident happens,
20:56 Adam you hop on and you're the service expert.
20:58 Adam But you're not the compute expert.
21:00 Adam You're not the
21:00 Adam Yeah.
21:00 Adam migration expert,
21:01 Adam right? You got a team of people to help you.
21:02 Adam Yeah.
21:03 Adam It's interesting. You were saying earlier about the idea that like how a culture handles failure makes, you know, is it has a big impact on this. And it does sound like this makes sense to me. I think that the times that I've been involved in complicated change management, it's always been harder in organizations that had more of a sort of.
21:23 Adam fear based culture and in those cultures that are I guess more growth minded as a culture or sort of like not not necessarily like risk takers but at least sort of more willing to sort of accept it like stuff
21:40 Adam you know like stuff goes wrong you know like watch a team watch a team how they handle an incident you know a data security incident or an outage incident like watch them how they perform in that and if they do it in a way that's like ego-less and you know like team team oriented and like hey this was an opportunity for us to learn something bad happened but that's okay we're going to fix it and we're going to learn from it
22:05 Adam From it and then that's going to give us an opportunity to do stuff better if that's their approach as opposed to, you know, everybody's kind of like pointing fingers,
22:12 Adam then I imagine that's.
22:15 Adam Those are significantly different environments to do large scale change management in.
22:19 Adam Yes.
22:20 Adam One of the things that I found easiest to do change management is when you have a culture of engineers who recognize that you're not really a true software engineer until you've taken down fraud,
22:30 Adam right?
22:31 Adam Like we all have our production went down because I merged dumb change story,
22:34 Adam right?
22:34 Adam And if you don't, like you got to get a story like that because that's, it's just the right, a rite of passage.
22:40 Adam but it also really makes you empathetic in situations like this and gives you a clear head because
22:45 Adam if you've done it before you know there's no reason why that pr that merged was the pr that brought down prod it could have been your pr it could have been a hiccup right a network card could have died on a server and you had a singleton running on that server right like stuff just happens it's
23:00 Adam Yeah
23:00 Adam just chance sometimes and if that's why you took down prod congrats right but in an incident then you've got enough senior engineers in there who recognize this it's not like i'm going to sit there and point fingers at you because it could have been my pr
23:11 Adam in fact it was my pr years ago right and
23:14 Adam Yeah.
23:14 Adam it's like look it happens whatever we're here it's passed it's shipped let's fix it and then you practice what's called a blameless retro and you go figure out what in the system broke
23:24 Adam Right.
23:24 Adam Yeah.
23:24 Adam If this PR broke it, there's no reason another PR couldn't have broke it just the same.
23:28 Adam So you want to fix the underlying problem.
23:30 Adam Yeah.
23:31 Adam Those are the cultures you aim for as an engineer because you're not getting fired for taking down prod.
23:35 Adam If anything,
23:36 Adam you're getting a gold star for finally becoming an engineer.
23:40 Adam Yeah,
23:40 Adam totally,
23:40 Adam totally.
23:41 Adam It's funny.
23:42 Adam You said blame us retro and it's I'll tell a little tiny change management story of something I had to work through once.
23:48 Adam I actually have no I don't use the term blame us retro anymore.
23:50 Adam I've.
23:50 Adam I've switched to using the term egoless retro instead.
23:53 Adam And the reason I've made that switch, and I explain it to people ahead of time, is that I worked in an organization where everybody was very adamant, like blameless retro,
24:01 Adam blameless retro.
24:02 Adam And one of the things that they unfortunately did was in the retrospectives, they essentially would redact all names.
24:10 Adam Okay.
24:10 Adam Or they would basically bristle if there was ever a TikTok or a timeline that said, you know, Adam checked in the pull request,
24:18 Adam it got reviewed by Brad,
24:20 Adam it got put,
24:21 Adam they would be like,
24:22 Adam wait, wait, do we need to put Adam's name on there? How do we put Brad's name on there?
24:25 Adam And I had to basically say,
24:27 Adam well, look, okay,
24:27 Adam first of all, we don't want to blame Adam and we don't want to blame Brad. Like, like, like you said, it's like, it's, you know, it's going to happen to any of us all the time, you know, so don't.
24:35 Adam We don't do blame.
24:37 Adam But if we completely eliminate like the factual information about what change made, you know, what what change at what time happened and then what was the downstream consequences of that,
24:48 Adam if we if we remove the facts from the retrospective, we lose our ability to actually think critically about,
24:57 Adam oh,
24:58 Adam well, what do we need to do to improve?
25:00 Adam Like, we fixed it. Great.
25:02 Adam Like once we get it fixed,
25:03 Adam right,
25:03 Adam like no finger pointing,
25:04 Adam we're not finger pointing at any of this, but we still need to understand what actually happened so that we can have a meaningful root cause analysis and a meaningful set of improvement steps.
25:16 Adam And it was really interesting because that notion of saying,
25:21 Adam hold on a second,
25:22 Adam no one's getting fired over this.
25:24 Adam No one's getting no one's going to get.
25:26 Adam blamed for this.
25:28 Adam But we do need to be able to have a clear, accurate articulation of what actually happened.
25:37 Adam And in this organization that I was confronted with this, they were really skeptical of that.
25:44 Adam and skeptical of the idea of like including that level of detail and to your point there's a little bit of a at least in my experience what I had to do in that particular case was a little bit of a lead with like the technical reasoning like okay let's just talk about the technical reason why we're why we need to change the way we're doing this and hopefully believe me when I say no one's getting fired over this like
26:10 Adam That, you know, so try to kind of.
26:13 Adam demonstrate that a little bit and i think that i was actually you know i've been fortunate enough to be able to say you know to have made mistakes myself to be able to say like look you know here's an example of a very clean retrospective that has my name on it i did the thing that caused the thing you know and
26:31 Adam Yep.
26:32 Adam that's and and maybe you know maybe in leadership you know like you're the vp and like yeah we're going to do this like
26:38 Adam It's like conversion from EC2 to EKS,
26:41 Adam you know, well, that was our strategic decision,
26:44 Adam you know, I own that as the VP that said we're doing that.
26:47 Adam And yep, that had the falling downstream,
26:50 Adam you know, consequences.
26:52 Adam Anyway,
26:53 Adam that's my quick pitch for why I don't like to use the term blameless. I try to use egoist instead.
26:58 Adam I like it. And I think, you know, at least in the way that I've seen retro's done.
27:03 Adam in under under the blameless term but you know you do put names right because it's important to document what happened right and you know at least with prs if you put well this pr changed it well look your name's all over the pr
27:15 Adam Your name's on the PR,
27:16 Adam right?
27:17 Adam It's called get blame,
27:19 Adam right?
27:19 Adam exactly yeah get blame who did this i mean i can find it out real fast um but to your point about no one's getting fired for this that's one of the things where as a
27:29 Adam leader you have that ability to really shape what happens behind the scenes in performance reviews in promotion panels right and I've actually I've gone to the mat before for certain team members when you know a code change that brought about an incident was brought up in a performance review and I basically said like you you can't you can't talk about that as if it was their fault right you can say their code was bad right that's
27:55 Adam okay but you can't say that they caused an incident right like we we truly have to be blameless here so you can't hold that incident against them
28:03 Adam Yeah, I mean, at a minimum,
28:04 Adam somebody else did a code review.
28:05 Adam exactly yep right yeah it takes two right but yeah you know as a leader you really do have to you know defend that in the culture truly to say that no one's getting fired for this and again this is the way that i practice management is you know you got to practice what you preach and if you say no one's getting fired because of this
28:22 Adam and they try to fire somebody then you got to go find a new company you
28:24 Adam Yeah.
28:25 Adam know as a manager if you're not going to uphold that and you truly believe that then you as a manager owe it to your team and you know your own integrity to go find somewhere else right and you got to be willing to take that line with folks that don't understand engineering culture to say you know you do this i walk and you got to protect that team to protect that safe space otherwise you ended up in a world where
28:47 Adam in a you know incident everyone's trying to blame somebody else instead of fixing the code
28:50 Adam Yeah.
28:51 Adam because you don't want to be the guy that merges the code fix right or everyone wants
28:53 Adam Yeah,
28:54 Adam to be exactly. the guy that merges the code fix
28:55 Adam Yeah.
28:56 Adam And you sort of, in some sense,
28:58 Adam you sort of introed that as well, where it's like the job of a manager is kind of both managing in both directions. And I think that's a good example of managing up,
29:07 Adam you know, where you've kind of got to say, look, okay, I understand you're really hot that the production system came down like.
29:12 Adam Like, I get that you're upset about that. I get that, you know, that costs us $100,000.
29:17 Adam That's a problem.
29:18 Adam And we agree,
29:19 Adam that's a problem.
29:20 Adam And we need to look at like,
29:22 Adam what are the, like, you need to know that if we come down on an individual,
29:27 Adam we're actually going to create an environment that doesn't allow us to do the other business objectives that you want. Like you want us to be moving fast and, and, and keeping up with our competitors or.
29:37 Adam or surpassing our competitors and you also want us to do that in a way that's like safe and reliable and predictable and so all those things require that psychological safety so if you you know if you react negatively to an incident then
29:53 Adam You know, that's that's that's not that's not helpful.
29:56 Adam Now,
29:57 Adam that being said,
29:58 Adam I also think that it's on us as engineering leaders to be like, take it seriously.
30:03 Adam You know, there's a difference between saying like,
30:05 Adam hey, don't blame that guy and don't fire that guy.
30:08 Adam That's one thing. But then they say, look, it's not a big deal.
30:11 Adam It happens all the time.
30:12 Adam That's not an acceptable stance to take either.
30:14 Adam Right.
30:15 Adam Exactly. Yeah,
30:15 Adam that's the business side of engineering leadership,
30:18 Adam right?
30:18 Adam where you got to say i get it that was a really big whoops and this is at least the way i've seen upper management uh c-suite level uh work well in a company is when you can shield your team and also take the blame yourself right there's a certain level where taking the blame for something minor doesn't impact you at all right you know like yeah we went down i'll take the blame for that
30:43 Adam that you know it's a minor credibility you know minor credibility hit to me but it's not a career right like you're the right guy to take that
30:50 Adam Right.
30:50 Adam Yeah, totally.
30:51 Adam You know, and at the same time, if it is a massive issue,
30:55 Adam right,
30:56 Adam and you are the CTO and the buck stops with you,
30:58 Adam then you got to have a remediation plan which involves I'm going to call the CFO and say,
31:03 Adam here's the deal. We got to build in an error budget.
31:05 Adam Yeah, this costs us money.
31:06 Adam We now need to change our financial forecasting,
31:09 Adam right,
31:09 Adam because there needs to be a monetary side.
31:12 Adam And I get it, right,
31:14 Adam and maybe that means I can't hire headcount.
31:15 Adam right maybe that means that we can't you know do a vendor upgrade i get there's got to be consequences because money isn't unlimited right but then you also owe it to the company to
31:25 Adam build in that actual error budget,
31:27 Adam not
31:27 Adam Yeah,
31:27 Adam technically,
31:28 Adam but doing it monetarily.
31:28 Adam or whatever that might,
31:30 Adam whatever the remediation might be, but the remediation has to be something. It has to be a change in process,
31:36 Adam a change in technology.
31:37 Adam You know, I was working at this, actually, Scott and I worked together at this health tech company several years back, and one of the most common production incidents that they would have is they had a third party authentication provider.
31:52 Adam provider and that third-party authentication provider
31:56 Adam kept having outages and so nothing was wrong with our software but the third-party authentication provider would go out and then nobody could log in and that was a you know it happened like multiple times and it was like oh my god we have another incident report that the root cause analysis is third-party authentication provider goes down right and the remediation couldn't just be not our fault like it wasn't us it was our our vendor right like like
32:23 Adam that's not a viable remediation right so you know after it happened you know more than once it was like hey how exposed are we here we need to come up with a plan that we can address this and ultimately that plan involved yeah we're going to have to like rip it out and replace it with something more reliable and that was not a free thing you know and so having you know that was a good example where having a conversation at the at the sort of like
32:47 Adam C-suite level included getting the product owner to be like, oh, okay.
32:53 Adam The new features I want you to add, those are less important than people being able to use the product at all.
33:00 Adam They have to be able to log in before those new features are going to be useful.
33:04 Adam Yeah, exactly.
33:05 Adam We had something similar with a system that our finance team used for book reconciliation,
33:11 Adam a small portion of their book closing process,
33:15 Adam but very important to the company. And yeah, this vendor.
33:18 Adam oh my gosh they just had issue after issue with data processing huge etl pipeline that would go sideways and you know take 24 hours to rerun yeah it was the first time it was like okay this is bad second time it was like is this going to become a pattern third time it was who else are you talking to in the industry it's like well we've already started those conversations you know it's good to have that you know kind of fool me once fool me twice by the third time i'm having conversation
33:44 Adam in conversation everybody else i'm yep we are actively searching for a new vendor right like because that that is the right answer at that point
33:51 Adam Yeah, totally.
33:52 Adam You know, there's two different things that we've talked about or kind of touched on in this conversation that I'm intrigued by and I'm curious to get your take on it.
34:00 Adam Let's see.
34:01 Adam One of them is obviously like AI.
34:04 Adam Like, it strikes me that this is probably one of the most fundamental shifts that the industry has seen in a long time.
34:13 Adam You know, I've been around long enough to see the shift towards the Internet and then the shift towards mobile.
34:18 Adam And so this is like an even bigger shift.
34:22 Adam And one of the things that I've seen more and more,
34:26 Adam there's this, I think, dichotomy of people that are embracing.
34:30 Adam the tooling and those that are resisting it and this feels like a classic change management problem and a classic leadership problem so I'm just kind of curious what's your what's your what's your take on
34:44 Adam that Yeah,
34:44 Adam the era of like the small batch artisanal crafted hand coded program is over.
34:53 Adam Um,
34:54 Adam I remember, so you mentioned the internet,
34:56 Adam that was a little bit before that, that shift was as far as in work professionally, but I saw the mobile transition definitely happen.
35:02 Adam And I remember sitting down and you could work for four or five hours and come up with just these elegant frameworks.
35:09 Adam I did a lot of stuff in Python and JavaScript and just, you know, the ways of orchestrating classes and,
35:15 Adam you know, just overloading methods and all this, like it was just.
35:19 Adam like a symphony style like you know right like you just you just get to sit and like wax poetic as you create and like the creative energy flows out of you and you know you leave for the day feeling really just fulfilled and um and now with ai it's like all i do is i type into a black screen and ai comes back with words and i read the words and i type it in again and then it comes back and i swear at it and i say do this differently and then it comes back and then i review the code and i go what did you just write here this is
35:46 Adam it's garbage and then i merge it right because it works right and we've gone from this like you know small batch handcrafted gorgeous program to like all that matters is the ui i click the button i log in i move on to the feature the feature works cool ship it right it's an assembly line
36:02 Adam and the craft is gone.
36:05 Adam Hmm.
36:06 Adam And I do think that that is the future, unfortunately, right? I don't think that we're going to get points for doing handcrafted code.
36:16 Adam It's
36:16 Adam It's interesting.
36:17 Adam actually I can spit out faster
36:18 Adam I it's so funny you said that so first of all, I I'm going to push back a little bit. So the pushback is what is the craft of being a software engineer?
36:28 Adam And I think that for sure, no one's typing curly brackets anymore.
36:33 Adam Like if you're typing curly brackets,
36:34 Adam you're getting behind,
36:36 Adam you know, so stop doing that.
36:39 Adam But I think that the craft.
36:41 Adam The craft of being a software engineer was always understanding the problem space and understanding the solutions that could solve that problem and being able to identify a good solution versus a poor solution,
36:58 Adam right?
37:00 Adam Mm-hmm.
37:01 Adam That's for sure what I think the teams that I see that are embracing AI,
37:05 Adam that's the strongest engineers were already the ones that were really good at reading other people's code because they knew what good code looked like, right?
37:15 Adam And they were really good at understanding how to like.
37:19 Adam narrow the scope and describe the problem space.
37:22 Adam Some of those that became engineering managers,
37:25 Adam the best engineering managers that I know were good at the people stuff,
37:30 Adam but they kept their technical strengths really strong and they understood how to describe business problems and how to read a plan and believe it and then how to read the code and verify that it met the plan.
37:44 Adam And to me, all that is craft and that craft is not going away.
37:48 Adam So that's my little bit of pushback. What do you think?
37:50 Adam Yeah, so I agree with you on the parts that are not going.
37:56 Adam Right.
37:58 Adam I have found so I use AI extensively.
38:01 Adam Like my GitHub year in review,
38:04 Adam like you can see, you know, the PRs, right?
38:06 Adam And like, you know, it lights up more green, the more PRs push.
38:09 Adam It's like fairly black and then like AI happens and just like lights up green,
38:14 Adam Yeah,
38:14 Adam right?
38:15 Adam totally.
38:15 Adam And as AI has gotten better, like it's gotten greener and greener. Like I can push probably 20 to 30 PRs a day just me.
38:23 Adam that's me personally right and
38:25 Adam Yeah.
38:25 Adam it's just like you know and some of that's just like fast agile iteration and stuff like that too but it's just the speed at which you can come up with the feature test it push it merge it right like i can do so many more of those what i found in ai though is ai operates as a really good mid-level engineer
38:42 Adam Yeah,
38:42 Adam i found
38:42 Adam sure.
38:42 Adam times where my knowledge as a more senior engineer has been the thing that unblocks it right
38:48 Adam Oh,
38:48 Adam because you'll you'll
38:48 Adam yeah.
38:49 Adam notice it going down a certain path and you'll be like what i want you to use is this architectural pattern and it'll be like oh yeah you're totally right of course i'm totally right ai you always think i'm totally right right but it's like that that like little shift of like the word you're looking for is this framework right like this architectural pattern all of a sudden it's like
39:07 Adam Oh,
39:07 Adam I
39:08 Adam Yeah,
39:08 Adam get it.
39:08 Adam but isn't that but don't you see that? Does that feel like that that that's craft?
39:13 Adam That's you bringing the craft to bear,
39:15 Adam right?
39:16 Adam We already did this with senior engineers.
39:17 Adam We already kind of had to team up with junior engineers.
39:20 Adam We had them kind of doing the over,
39:22 Adam you know, not necessarily the people management part,
39:24 Adam but they were expected to, you know, mentor. What was what was mentoring when mean anyway?
39:30 Adam It's it's essentially that like.
39:32 Adam uh that's a dark that's a that's a dead end don't go down that road try this that you know the framework you're looking for is this the words you're looking for is this like yeah there you go that's that's your craft man that's that's that's obviously what you'd be good at
39:45 Adam Yeah.
39:46 Adam Yeah.
39:47 Adam And so I, you know, I think for me, for me, part of singing code was just the fun of writing the code and seeing stuff compile and, you know, like the little things like that. And that's.
39:57 Adam That's basically out the window now. AI handles all
39:59 Adam You know, but yeah,
40:01 Adam the higher level stuff, mentorship and architectural patterns and problem solving, that is definitely still there,
40:08 Adam right?
40:09 Adam Now,
40:10 Adam I think AI is getting substantially better and I don't know where we're going to be in six months from now,
40:14 Brad Yeah
40:14 Adam right?
40:16 Adam You know, it seems that literally every week there's something new,
40:19 Adam like literally this week I just found out that you can take Claude and get a list of bullet points and drop it into.
40:26 Adam into google slides and gemini will make you slides um
40:29 Adam Yeah, yeah
40:30 Adam that are like gorgeous right like i literally just saw it this week and i was like i did not know that last week last week i was making powerpoint presentations this week i just made three powerpoint decks using cloud and gemini right um so i don't know where we're going to be in two weeks but um i think that some of the craft of being a software engineer will still be there but certainly the writing code at least for me you know creating the architectural patterns really understanding
40:53 Adam you know and having created it and the hands-on learning that that part's gone
40:57 Adam and I'm a little sad about but as a business-minded person who wants to get stuff out of my software like oh I love the fact that AI can write me an entire new you know system in an afternoon and that would have taken me two weeks right like I love the result
41:15 Brad Yeah, there you go. Well, we're all going through this change, so we're all going to experience it, I guess, differently.
41:21 Brad I'm trying to find a way.
41:23 Brad with the engineers that i work with the teams that i work with i work with a bunch of teams that are just absolutely embracing ai and you know they're you know to your point they're like you know easily every single engineer on the team is producing you know clocks is a bad measurement but let's say 3 000 lines of real business value every day you know and just like like you said just like that github chart has just gone from
41:49 Brad light green to solid green every single day you know it's just massive acceleration and but I do hear this like oh I feel like the joy is you know leaving it and or it feels soulless or I feel like I've I've lost touch with the the craft and I want to try to help folks see that well there's a ton of value in being able
42:15 Brad being able to guide the agent properly and get those results and you know I don't know maybe that's just because
42:27 Brad You know, I've been, you know, I still get my hands dirty. I'm still writing code.
42:31 Brad I'm personally burning.
42:33 Brad I just ran the numbers on this because Scott was asking me about it.
42:36 Brad My cursor daily token uses is like 20 million tokens a day on average for the last,
42:42 Brad you know, couple months.
42:44 Brad So I'm cranking through a lot, producing a lot of code myself.
42:49 Brad But for most of my career.
42:53 Brad I've gotten a bunch of joy out of the craft of leading people to build things, right?
43:02 Brad And, you know, you kind of said it yourself,
43:06 Brad like.
43:07 Brad take the take the accountability like if something goes wrong take the blame like hey i was a leader i was a leader that caused the thing that that was here when the thing happened like i'm accountable for that you know um and you i think you ought to be able to take some pride in
43:24 Brad being the leader that helped lead the thing to get built too and so maybe that's the way we shift our thinking of instead of sort of having such affinity for the the typing of the curly brackets and the and the tabs and the enters right like let's
43:39 Adam Right.
43:40 Brad let's take some take some pride in the yeah you got the business outcome
43:44 Adam Yeah.
43:45 Adam And I do think that that is something that I've seen younger engineers struggle with because typically,
43:50 Adam you know.
43:50 Adam coming fresh out of school with the CS degree like you got a head for CS but not a head for business yet and I feel like you know a lot of more junior engineers grow and see the business value and it's almost one of the hallmarks of being a more senior engineer is being able to connect feature requests with business value
44:08 Brad Totally.
44:08 Adam Right.
44:09 Adam And so I feel like those skills are getting pushed down now to more junior engineers.
44:15 Adam So I think the challenge as a leader then is you now have to communicate the business value further down the chain into your team.
44:23 Adam right because it used to be just shut up and make the button you know change color on hover and now it's like well what does the button go in why does the button exist at all what's the modal part of you know what's this entire page because that's the scope that ai needs Yeah, right
44:36 Brad totally.
44:36 Adam button's going to change that's an easy thing right now it's like well what you're actually building is the checkout flow and how should a checkout flow work and explaining that now to a new grad is it's going to take a lot of additional coaching
44:49 Adam on the leadership side right because now you got to explain well what's a good checkout experience what's
44:52 Brad Yeah.
44:53 Adam ux what's ui right all these other things come into that and
44:56 Adam you know what is the value of another dollar to this business what does that unlock why do we care it's
45:01 Brad Yeah.
45:01 Adam no longer just change the button color it's like well now this is why we need another million bucks out of this checkout line right and so make it better
45:09 Brad Yeah,
45:10 Brad that's fair.
45:10 Brad That's fair. And also,
45:12 Brad I think that you and I both are experienced enough that like knowing those architectural patterns,
45:18 Brad knowing those, you know, knowing what good code looks like is something that.
45:22 Brad that it takes essentially you know the 10,000 hours right the 10,000 hours become an expert to understand to be able to do that so I do I mean definitely one of the things I I wonder about is how do you get your senior if you still need senior engineers to like guide the AI what do you do if you don't have junior engineers becoming senior engineers and getting those 10,000 hours like that's that's a bigger problem
45:46 Brad That's a big problem too.
45:48 Adam Yes,
45:49 Adam I have seen that.
45:51 Adam I have seen multiple companies no longer hiring junior engineers because AI can do that.
45:56 Adam And I'm sitting here, I'm going,
45:57 Adam you guys, we've got a pipeline problem.
45:59 Brad Right,
45:59 Adam right like if if you can't make a junior into a senior eventually all those senior engineers in about a decade they're gonna be 10 years older that's the funny thing about
46:07 Brad time right.
46:08 Adam right and all of a sudden you're gonna have less senior engineers if you never train up juniors and then what you know then what happens you know so it's that's an unsolved problem um and i am seeing that right now the other interesting thing you mentioned ai that i am seeing a lot more amongst
46:25 Adam amongst engineers is just decision fatigue i
46:28 Brad Yeah.
46:28 Adam have heard from so many more engineers now by the time friday rolls around they are dead and i'm still diagnosing exactly why that is um near as i can tell it's you got a bunch of engineers who are now making management level decisions who are not used to context switching like a manager can and i think they're just getting burned out by thursday end of day and so you get four days of work and friday's gone
46:51 Adam now i've seen that now the past three weeks or so right so again this is all changing very quickly um but that decision fatigue is especially affecting mid-level and more junior engineers i think more than i'm seeing it affects seniors it's just like yeah they just they can't make another decision for ai they're just like just code it just do it for me don't give me
47:10 Brad Well,
47:10 Adam a decision
47:10 Brad it's funny.
47:10 Brad Yeah,
47:11 Brad totally,
47:12 Brad man.
47:12 Brad I think that's pretty insightful.
47:15 Brad I think that, of course, the...
47:16 Brad The anecdote I've heard to kind of counteract that anecdote to counteract that is, oh, well, do a better job of specifying up front,
47:25 Brad right?
47:25 Brad Like use something like spec kit or,
47:27 Brad you know, some other std sort of oriented tool.
47:30 Brad Well,
47:31 Brad then you're spending all your time.
47:34 Brad you know,
47:34 Brad writing and reading these very verbose documents so that they're, so the AI doesn't have to guess or doesn't have to ask you decisions.
47:42 Brad Now, now you're spending your time like really, really writing things.
47:47 Brad And there's a fair amount of, I've seen many people pushing back on that, you know, people like I've, Scott and I were just talking about this the other day that product owners who like, oh,
47:58 Brad that the spec has too many words in it.
47:59 Brad and it's like well you know what that's actually the level of detail you should have been providing to the engineers all along yeah oh my god that's that's a lot of how many users wait there's 25 user stories here that seems overkill well okay let's look at those user stories are is there actually anything in there that is not what you wanted oh yeah oh it caught some edge cases that yes i want it to do that it's like well all those things that it caught
48:26 Brad thought you know are things that would have resulted in extra time writing it
48:31 Adam yes uh yeah i know it is it's like this marriage of waterfall and agile right like if you remember like some of the early waterfall systems like we have this gorgeous you know spec document user journeys data flow diagrams crow's foot notation to the database it's you know 50 to 100 pages you get it you're like cool what does this do as a software engineer you're like
48:52 Adam I honestly like, you know, the product person is like, I dropped off a 50 page product spec.
48:57 Adam I've done my job. It's going to ship next week. And as an engineer,
48:59 Adam you're like, no,
49:00 Adam no, man, this is like a year's worth of work.
49:02 Adam You're just getting started.
49:03 Brad Right. Right.
49:04 Brad Exactly.
49:04 Brad Yeah.
49:05 Brad Well,
49:06 Brad yeah,
49:06 Brad there you go.
49:07 Brad So this was enjoyable chatting about these complex issues,
49:11 Brad Adam.
49:12 Brad And tell me, how do you think we should summarize this for folks?
49:17 Adam Yeah.
49:18 Adam So I think we are seeing a change.
49:19 Adam Seeing a change of the AI,
49:19 Adam I think we're going through a fundamental industry shift.
49:22 Adam I think a lot of folks are going to be learning management skills with agents instead of people.
49:28 Adam So I think there's a whole realm of management skills that your average engineer doesn't have yet that they need.
49:33 Adam I think business value.
49:36 Adam is going to be the thing that defines a company that succeeds with their engineers from a company that doesn't.
49:42 Adam If your engineers understand why they're building what they're building,
49:45 Adam they understand the business impact.
49:46 Adam I think you have a world where AI will accelerate your company.
49:50 Adam But if you continue to keep engineers in the dark and isolate them from the customers,
49:55 Adam I think you're going to end up in a world where code can get produced very quickly.
50:00 Adam But your engineers have no idea what they're doing, right?
50:02 Adam And I think AI is then going to accelerate you into a place that your product no longer does anything useful.
50:07 Brad There you go.
50:08 Brad Nailed it. Nailed the landing for sure.
50:12 Adam Nice.
50:12 Brad I love it. Well,
50:13 Brad this is super fun conversation.
50:15 Brad We'll include a link to your bio in the show notes.
50:19 Brad Anything else? Parting words of wisdom to the audience?
50:23 Adam I think we've got a bright future as an industry.
50:27 Adam I know this year has been tough with a lot of layoffs,
50:29 Adam but I see a world wherein we have smaller teams producing better products and fewer bugs.
50:37 Brad Love
50:37 Adam So I
50:37 Brad it.
50:38 Adam think there is a light at the end of the tunnel.
50:39 Brad Love it. Awesome.
50:40 Brad Well, thanks everybody for listening to another episode of the How Many CTOs to Stick podcast.
50:45 Brad Thank you very much, Adam, for coming along.
50:47 Brad This was a great conversation.
50:48 Brad I really enjoyed it.
50:49 Brad And hopefully everybody tunes in next week for another episode.
50:53 Brad See you guys.
50:53 Adam Check you later.
50:54 Brad This episode of the How Many CTOs Does It Take podcast was produced and edited by Saffron Heptecal.
51:00 Brad Our theme song was AI Generated by Brad.
51:03 Brad Please follow us on all the social media platforms at How Many CTOs Pod.
51:09 Brad You can find us on YouTube,
51:11 Brad LinkedIn,
51:11 Brad Instagram,
51:12 Brad Facebook,
51:12 Brad Threads, X, TikTok,
51:14 Brad and Patreon,
51:15 Brad or at our website at HowManyCTOSPod.com.
51:18 Brad dot com and remember to rate review and subscribe on the podcast platform of your choice thanks for listening