A Fundamental Shift: Change Management, Psychological Safety, and AI's Impact on Engineering Leadership with Dr. Adam Link
In this episode of "How Many CTOs Does It Take?" podcast, host Brad Hefta-Gaub is joined by Dr. Adam Link, former senior engineering manager at Coinbase, who shares his background leading global teams through highly technical transformations in fintech and crypto, including major infrastructure migrations. They discuss whether different kinds of change require different leadership approaches, emphasizing that change management is fundamentally about people. They discuss how fear makes change harder, so leaders must create psychological safety by providing "air cover" and managing messaging up and down. Adam notes that good managers must handle hard conversations like layoffs and performance issues with empathy while recognizing these outcomes aren't always personal decisions. He offers advice for engineers moving into management, including a tongue-in-cheek analogy that managers "test in production," and describes a challenging EC2-to-Kubernetes migration where success required strong technical credibility, hands-on help, and attention to team psychology. Adam and Brad compare blameless vs egoless retrospectives, discuss leaders defending engineers behind the scenes, and highlight the need for real remediation like error budgets or vendor changes. The conversation closes on AI as a fundamental industry shift, debate over the loss of hand-crafted coding vs enduring need for problem understanding, concerns about the junior-to-senior pipeline if entry roles disappear, decision fatigue from AI agents, and optimism about smaller teams producing better products with fewer bugs.
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
- Dr. Adam Link: https://www.linkedin.com/in/adamlink/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCTOs #Podcast #CTOs #CTOPodcast #ChiefTechnologyOfficer #Technology #Engineering #SoftwareDevelopment #SoftwareEngineering #TechLeadership #EngineeringLeadership #EngineeringCulture #TechDebates #AIRevolution #EngineeringCulture #ChangeManagement #LeadershipSkills #AIAssistedProgramming #AI #FinTech #Crypto #
Guest
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.
Brad: All right. Welcome,
everybody,
to another episode of the How Many CTOs Does It Take podcast?
My name is Brad Hefta-Gaub, and our regular co-host Scott Porad is not here today,
but we have a very interesting guest with us today,
Dr.
Adam Link.
I'm looking forward to talking to him about lots of interesting topics.
Adam,
why don't you introduce yourself and maybe let the audience know a little bit about how you got here.
Adam: Yeah, certainly.
Like I said, Dr.
Adam Link.
The doctorate, there's actually a doctorate in computer science, not medicine,
but computer science.
So this is one of the few venues where I definitely get to use the doctor abbreviation because I earned it.
Yeah,
no,
so I was a senior engineering manager at Coinbase and,
you know, worked at Coinbase for a number of years.
I've actually since transitioned out of the technology industry very recently.
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
Brad: Yeah.
Adam: over a decade in tech and about eight years of that actually in the crypto space so when it comes to you know
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
Brad: Yeah.
Adam: have to talk about ai at some point but uh yeah you know i i
Brad: We didn't even get five minutes in and we're already talking about AI.
Adam: well of course of course you know it's a technology podcast and the zeitgeist is ai
Brad: When you talked about change management and crypto,
I thought you were trying to make a.
to make a joke there about change and being
Adam: Oh,
Brad: fintech
Adam: yeah.
Brad: i love
Adam: Yep. No,
that would have been a much better joke.
Unfortunately,
it is Friday afternoon. So my collection of dad jokes went up with this morning's standups.
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
You already mentioned the notion of like large technology changes.
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.
Downsizing, right sizing, however you want to say it to spin it for the audience you're trying to spin it for.
And then we also have like sort of like kind of process change and culture change.
I'm just kind of curious,
Adam, when you think about like the challenges that we face as engineering leaders,
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?
Adam: Yeah, I definitely think as engineering leaders,
our job is people.
Right.
If you like tech and you only like tech, you stay an individual contributor,
right?
In most companies, at least those that I think are forward thinking enough in technology,
they recognize that people management is a separate skill,
right?
Not every really good engineer wants to be a manager of people.
And so it is a separate and complementary skill that you have to have.
And so really, at the end of the day, I do think change management with people.
is pretty much a skill that you can get good at,
but the nuance comes in the culture of the individual company that you're working in.
Right.
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.
If engineers are fail or failure adverse,
they're scared to fail,
whether it be technically or process wise or in a promotion or something like that,
there's a lot of fear around a change that just makes the change substantially.
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
Brad: Yeah.
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
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
Brad: Yeah,
it's interesting.
I think that like what I hear you saying, if I can play it back,
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,
they can begin to process the change and not be in a reactive sort of fearful state.
And then I think what I hear you saying that a big part of like creating that safety within the team is.
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
Adam: Yes.
Brad: the team so they're not the ones getting rained on or whatever is coming out of the sky on them
Adam: Yes.
My team has often had that nickname for me, the blank umbrella.
umbrella.
Brad: Yeah.
Adam: That's my job, right?
It's my job is just to make sure that
You know, they have a space
Brad: But, you know, it's interesting,
too, you say that and not to get too far afield from the change management conversation,
obviously another challenge that we face as, you know, leaders in companies that are naturally,
you know, working their way in capitalism is that we have an accountability to the enterprise,
to the stakeholders of the enterprise, be that our customers or our shareholders or kind of the community at large.
And that sometimes means like managing through change that will be difficult.
And sometimes, you know, hard for some team members.
Adam: Yes, that is very true.
And I do think one of the hallmarks of being a good manager is your ability to go through those tough conversations with people,
you know, whether it be a riff,
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.
Yeah,
change management.
It impacts people, it impacts lives.
Right.
And that is one of the things that I've actually had to go through many times, right?
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.
Sorry about that.
Brad: All right.
Adam: You know, it's just business,
right?
Which is almost never true.
Right. It's it's deeply personal,
at least the way that I practice.
Right.
I think it's deeply personal.
You know, you are impacting somebody's ability maybe to make the mortgage that month, you know, or send their kids to school.
And it's important to separate kind of your personal responsibility in that change from the organizational responsibility.
Right.
I think it's important to remember as a manager, being empathetic towards, you know,
your team going through those tough conversations, like, yeah, you're impacting somebody's life.
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.
Brad: Yeah, totally.
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.
That led to this conversation,
unless,
you know, you're the CEO,
in which case it might be your decision. Right. But even then,
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.
Don't take that lightly.
But at the same time, recognize that as much as you may be feeling like the bad guy,
it's not you personally all
Brad: yeah
Adam: the time.
Brad: it's the system yeah
Adam: Yep. And that's got me through some of those tough conversations.
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
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
And then more of the team suffers.
Right.
And so that's that's kind of one thing I try to hold on to.
It's interesting.
It is, you know, to your point about like as an engineer,
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.
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
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?
Adam: Yeah, so I'll take a very engineering-focused response
Brad: Sure.
Adam: because,
yeah, I think behind every engineering manager is a coder who just wants to get back to being heads down and building again.
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?
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
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.
I have no idea what's going to happen. And so the best I can do is test in production and manage accordingly.
Right. And so that means, you know, when you're talking to engineers sometimes like, oh, tell them, look,
give me a bug report every now and then.
you know look if i'm not doing something right it's just a bug report right
Brad: Right.
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
right
Brad: Now,
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
Brad: you
Adam: got a bug
Brad: got technical debt,
technical debt in your management operating system.
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
And just like there's risks of testing in fraud,
there's risks in management,
right? Like sometimes you take down the production server and
Brad: Yeah.
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.
That's taking down production,
right?
Brad: Yep.
Adam: If you can wrap your head around kind of that equivalency,
you as an engineer get to have an idea of what it is to be a manager before ever being there.
Right. And you can get a sense of like, I'm not the type of person who would ever test in production.
That is just not a thing I'm going to do.
Okay,
then maybe management isn't for you,
right?
Brad: I think that's an interesting analogy.
I definitely haven't ever thought of it that way,
but I can see where you're going,
where it's like, you know, you have more chance of a reaction and of course your wisdom,
your experience is going to help you have a less likelihood of.
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
Adam: They are.
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
Particularly challenging change management experience you had and do you have any tips for how you handled that?
Adam: Yeah, so one of the things that, so my background is in infrastructure,
as an infrastructure engineer,
most of the stuff I end up doing is infrastructure lifecycle management.
And so at a certain point in an infrastructure's life cycle, you have to deprecate infrastructure.
And ever since we've gone into the cloud,
this has accelerated beyond just deprecating a physical server to now,
well, you've got major or minor version releases that change and all that fun stuff.
And so as you do migrations in the cloud,
it's a never-ending cycle of migrations and infrastructure.
You're always moving from system A to system B.
One of the most challenging migrations I think we did was in actually conjunction with
Brad: Microsoft.
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
It's all container-based,
it's all pods,
it's all orchestrated, right?
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.
But lifting and shifting an entire company's compute layer onto an orchestration layer is a massive effort.
Brad: Yeah, totally.
Adam: Yeah,
that was about 18 months of work to do that.
Brad: Sure.
And I think I can imagine like, you know, as I ponder something like that,
like.
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,
well, EC2 is good enough we got this far,
you know, we know why I need to learn this whole new system,
you know, it's it's
Kubernetes is just like, you know, a bunch of fluff. It's syntactic sugar.
You know, I don't really need that.
We know our architecture now.
Those types of reactions I can imagine would be pretty common.
Adam: Yes, they're very common,
right?
So as an infrastructure manager,
I go into teams and these are teams that are producing product,
right? They are in the direct line of revenue.
And so you come and you say, okay,
look,
so your Q3 plan.
I know you're trying to launch a new feature.
I know you're trying to capture market share.
While you do that.
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,
and I need you to get comfortable enough with Kubernetes that you can do basic operations to deploy your service.
And this,
you know, it's a poor engineer sitting there with a giant backlog of tickets going,
you want me to do what now?
Brad: Yeah.
Adam: You're fundamentally shifting my entire service.
You know, it's not a fun conversation to have.
um especially when you know they're getting pressure from the revenue side of the business to ship product right
Brad: Yeah.
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
right all this other operational stuff but as a software engineer you're like cool it still runs i
Brad: Yeah.
Adam: just need to ship a product
Brad: Yeah,
totally.
I think that like,
okay, so that's a great example of a major like change management. And I think that like, you know, kind of
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
handle that behavioral and psychological impact.
Adam: Yeah, so this is actually something we had to learn maybe about three and a half, four years ago now,
as we were actually doing this migration.
So the two teams that really involved infrastructure,
one of them was actually the compute team.
So their job was the technical implementation of Kubernetes,
right?
They basically built the Kubernetes platform.
And so it was great to have a very strong technical team.
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
they could explain exactly this is a good idea.
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.
And so what we basically came with was a kind of an offer you couldn't refuse.
And we found this worked very well with overloaded engineers.
We would come to you and say,
okay, we need you to change your entire compute layer.
Here's the technical reason why, right? Here's the technical people you can talk to.
But we're also going to come.
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,
right?
And so it was something we had to get really good at because you basically have to understand the service,
you have to understand blast radius,
you have to understand how it calls downstream and upstream.
But once you have an engineer that can do that and write that first draft,
even if it's not perfect,
you've at least put forward a foot now as an infrastructure engineer.
to say, I tried my best to be a service and infrastructure engineer.
I tried my best to help you as far as I could.
And what we found with a lot of engineers, by taking that first initiative and at least giving them a draft full request,
even if it wasn't perfect,
you give them something that they can react to.
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
The hardest thing before AI for us was
crafting code, right?
And so now you can review code instead of craft it.
And that's a lot easier for humans to read code and point out the inefficiencies, right?
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,
that really allowed us to get these product engineers on board.
And then we basically tackled the biggest products we could first.
So everyone after that would say,
well, my product is super important.
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
Brad: Right.
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
No matter what happens, someone else is going to be there to help,
right?
So when an incident happens,
you hop on and you're the service expert.
But you're not the compute expert.
You're not the
Yeah.
migration expert,
right? You got a team of people to help you.
Yeah.
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.
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
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
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,
then I imagine that's.
Those are significantly different environments to do large scale change management in.
Yes.
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,
right?
Like we all have our production went down because I merged dumb change story,
right?
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.
but it also really makes you empathetic in situations like this and gives you a clear head because
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
Yeah
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
in fact it was my pr years ago right and
Yeah.
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
Right.
Yeah.
If this PR broke it, there's no reason another PR couldn't have broke it just the same.
So you want to fix the underlying problem.
Yeah.
Those are the cultures you aim for as an engineer because you're not getting fired for taking down prod.
If anything,
you're getting a gold star for finally becoming an engineer.
Yeah,
totally,
totally.
It's funny.
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.
I actually have no I don't use the term blame us retro anymore.
I've.
I've switched to using the term egoless retro instead.
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,
blameless retro.
And one of the things that they unfortunately did was in the retrospectives, they essentially would redact all names.
Okay.
Or they would basically bristle if there was ever a TikTok or a timeline that said, you know, Adam checked in the pull request,
it got reviewed by Brad,
it got put,
they would be like,
wait, wait, do we need to put Adam's name on there? How do we put Brad's name on there?
And I had to basically say,
well, look, okay,
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.
We don't do blame.
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,
if we if we remove the facts from the retrospective, we lose our ability to actually think critically about,
oh,
well, what do we need to do to improve?
Like, we fixed it. Great.
Like once we get it fixed,
right,
like no finger pointing,
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.
And it was really interesting because that notion of saying,
hold on a second,
no one's getting fired over this.
No one's getting no one's going to get.
blamed for this.
But we do need to be able to have a clear, accurate articulation of what actually happened.
And in this organization that I was confronted with this, they were really skeptical of that.
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
That, you know, so try to kind of.
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
Yep.
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
It's like conversion from EC2 to EKS,
you know, well, that was our strategic decision,
you know, I own that as the VP that said we're doing that.
And yep, that had the falling downstream,
you know, consequences.
Anyway,
that's my quick pitch for why I don't like to use the term blameless. I try to use egoist instead.
I like it. And I think, you know, at least in the way that I've seen retro's done.
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
Your name's on the PR,
right?
It's called get blame,
right?
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
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
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
Yeah, I mean, at a minimum,
somebody else did a code review.
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
and they try to fire somebody then you got to go find a new company you
Yeah.
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
in a you know incident everyone's trying to blame somebody else instead of fixing the code
Yeah.
because you don't want to be the guy that merges the code fix right or everyone wants
Yeah,
to be exactly. the guy that merges the code fix
Yeah.
And you sort of, in some sense,
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,
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.
Like, I get that you're upset about that. I get that, you know, that costs us $100,000.
That's a problem.
And we agree,
that's a problem.
And we need to look at like,
what are the, like, you need to know that if we come down on an individual,
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.
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
You know, that's that's that's not that's not helpful.
Now,
that being said,
I also think that it's on us as engineering leaders to be like, take it seriously.
You know, there's a difference between saying like,
hey, don't blame that guy and don't fire that guy.
That's one thing. But then they say, look, it's not a big deal.
It happens all the time.
That's not an acceptable stance to take either.
Right.
Exactly. Yeah,
that's the business side of engineering leadership,
right?
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
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
Right.
Yeah, totally.
You know, and at the same time, if it is a massive issue,
right,
and you are the CTO and the buck stops with you,
then you got to have a remediation plan which involves I'm going to call the CFO and say,
here's the deal. We got to build in an error budget.
Yeah, this costs us money.
We now need to change our financial forecasting,
right,
because there needs to be a monetary side.
And I get it, right,
and maybe that means I can't hire headcount.
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
build in that actual error budget,
not
Yeah,
technically,
but doing it monetarily.
or whatever that might,
whatever the remediation might be, but the remediation has to be something. It has to be a change in process,
a change in technology.
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.
provider and that third-party authentication provider
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
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
C-suite level included getting the product owner to be like, oh, okay.
The new features I want you to add, those are less important than people being able to use the product at all.
They have to be able to log in before those new features are going to be useful.
Yeah, exactly.
We had something similar with a system that our finance team used for book reconciliation,
a small portion of their book closing process,
but very important to the company. And yeah, this vendor.
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
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
Yeah, totally.
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.
Let's see.
One of them is obviously like AI.
Like, it strikes me that this is probably one of the most fundamental shifts that the industry has seen in a long time.
You know, I've been around long enough to see the shift towards the Internet and then the shift towards mobile.
And so this is like an even bigger shift.
And one of the things that I've seen more and more,
there's this, I think, dichotomy of people that are embracing.
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
that Yeah,
the era of like the small batch artisanal crafted hand coded program is over.
Um,
I remember, so you mentioned the internet,
that was a little bit before that, that shift was as far as in work professionally, but I saw the mobile transition definitely happen.
And I remember sitting down and you could work for four or five hours and come up with just these elegant frameworks.
I did a lot of stuff in Python and JavaScript and just, you know, the ways of orchestrating classes and,
you know, just overloading methods and all this, like it was just.
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
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
and the craft is gone.
Hmm.
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.
It's
It's interesting.
actually I can spit out faster
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?
And I think that for sure, no one's typing curly brackets anymore.
Like if you're typing curly brackets,
you're getting behind,
you know, so stop doing that.
But I think that the craft.
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,
right?
Mm-hmm.
That's for sure what I think the teams that I see that are embracing AI,
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?
And they were really good at understanding how to like.
narrow the scope and describe the problem space.
Some of those that became engineering managers,
the best engineering managers that I know were good at the people stuff,
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.
And to me, all that is craft and that craft is not going away.
So that's my little bit of pushback. What do you think?
Yeah, so I agree with you on the parts that are not going.
Right.
I have found so I use AI extensively.
Like my GitHub year in review,
like you can see, you know, the PRs, right?
And like, you know, it lights up more green, the more PRs push.
It's like fairly black and then like AI happens and just like lights up green,
Yeah,
right?
totally.
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.
that's me personally right and
Yeah.
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
Yeah,
i found
sure.
times where my knowledge as a more senior engineer has been the thing that unblocks it right
Oh,
because you'll you'll
yeah.
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
Oh,
I
Yeah,
get it.
but isn't that but don't you see that? Does that feel like that that that's craft?
That's you bringing the craft to bear,
right?
We already did this with senior engineers.
We already kind of had to team up with junior engineers.
We had them kind of doing the over,
you know, not necessarily the people management part,
but they were expected to, you know, mentor. What was what was mentoring when mean anyway?
It's it's essentially that like.
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
Yeah.
Yeah.
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.
That's basically out the window now. AI handles all
You know, but yeah,
the higher level stuff, mentorship and architectural patterns and problem solving, that is definitely still there,
right?
Now,
I think AI is getting substantially better and I don't know where we're going to be in six months from now,
Brad: Yeah
Adam: right?
You know, it seems that literally every week there's something new,
like literally this week I just found out that you can take Claude and get a list of bullet points and drop it into.
into google slides and gemini will make you slides um
Yeah, yeah
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
you know and having created it and the hands-on learning that that part's gone
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
Brad: Yeah, there you go. Well, we're all going through this change, so we're all going to experience it, I guess, differently.
I'm trying to find a way.
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
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
being able to guide the agent properly and get those results and you know I don't know maybe that's just because
You know, I've been, you know, I still get my hands dirty. I'm still writing code.
I'm personally burning.
I just ran the numbers on this because Scott was asking me about it.
My cursor daily token uses is like 20 million tokens a day on average for the last,
you know, couple months.
So I'm cranking through a lot, producing a lot of code myself.
But for most of my career.
I've gotten a bunch of joy out of the craft of leading people to build things, right?
And, you know, you kind of said it yourself,
like.
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
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
Adam: Right.
Brad: let's take some take some pride in the yeah you got the business outcome
Adam: Yeah.
And I do think that that is something that I've seen younger engineers struggle with because typically,
you know.
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
Brad: Totally.
Adam: Right.
And so I feel like those skills are getting pushed down now to more junior engineers.
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.
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
Brad: totally.
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
on the leadership side right because now you got to explain well what's a good checkout experience what's
Brad: Yeah.
Adam: ux what's ui right all these other things come into that and
you know what is the value of another dollar to this business what does that unlock why do we care it's
Brad: Yeah.
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
Brad: Yeah,
that's fair.
That's fair. And also,
I think that you and I both are experienced enough that like knowing those architectural patterns,
knowing those, you know, knowing what good code looks like is something that.
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
That's a big problem too.
Adam: Yes,
I have seen that.
I have seen multiple companies no longer hiring junior engineers because AI can do that.
And I'm sitting here, I'm going,
you guys, we've got a pipeline problem.
Brad: Right,
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
Brad: time right.
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
amongst engineers is just decision fatigue i
Brad: Yeah.
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
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
Brad: Well,
Adam: a decision
Brad: it's funny.
Yeah,
totally,
man.
I think that's pretty insightful.
I think that, of course, the...
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,
right?
Like use something like spec kit or,
you know, some other std sort of oriented tool.
Well,
then you're spending all your time.
you know,
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.
Now, now you're spending your time like really, really writing things.
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,
that the spec has too many words in it.
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
thought you know are things that would have resulted in extra time writing it
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
I honestly like, you know, the product person is like, I dropped off a 50 page product spec.
I've done my job. It's going to ship next week. And as an engineer,
you're like, no,
no, man, this is like a year's worth of work.
You're just getting started.
Brad: Right. Right.
Exactly.
Yeah.
Well,
yeah,
there you go.
So this was enjoyable chatting about these complex issues,
Adam.
And tell me, how do you think we should summarize this for folks?
Adam: Yeah.
So I think we are seeing a change.
Seeing a change of the AI,
I think we're going through a fundamental industry shift.
I think a lot of folks are going to be learning management skills with agents instead of people.
So I think there's a whole realm of management skills that your average engineer doesn't have yet that they need.
I think business value.
is going to be the thing that defines a company that succeeds with their engineers from a company that doesn't.
If your engineers understand why they're building what they're building,
they understand the business impact.
I think you have a world where AI will accelerate your company.
But if you continue to keep engineers in the dark and isolate them from the customers,
I think you're going to end up in a world where code can get produced very quickly.
But your engineers have no idea what they're doing, right?
And I think AI is then going to accelerate you into a place that your product no longer does anything useful.
Brad: There you go.
Nailed it. Nailed the landing for sure.
Adam: Nice.
Brad: I love it. Well,
this is super fun conversation.
We'll include a link to your bio in the show notes.
Anything else? Parting words of wisdom to the audience?
Adam: I think we've got a bright future as an industry.
I know this year has been tough with a lot of layoffs,
but I see a world wherein we have smaller teams producing better products and fewer bugs.
Brad: Love
Adam: So I
Brad: it.
Adam: think there is a light at the end of the tunnel.
Brad: Love it. Awesome.
Well, thanks everybody for listening to another episode of the How Many CTOs to Stick podcast.
Thank you very much, Adam, for coming along.
This was a great conversation.
I really enjoyed it.
And hopefully everybody tunes in next week for another episode.
See you guys.
Adam: Check you later.
Brad: This episode of the How Many CTOs Does It Take podcast was produced and edited by Saffron Heptecal.
Our theme song was AI Generated by Brad.
Please follow us on all the social media platforms at How Many CTOs Pod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X, TikTok,
and Patreon,
or at our website at HowManyCTOSPod.com.
dot com and remember to rate review and subscribe on the podcast platform of your choice thanks for listening