Predictions and Reflections: One Year Anniversary of the How Many CTOs Does It Take? Podcast
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCTOs #Podcast #CTOs #CTOPodcast #ChiefTechnologyOfficer #Technology #Engineering #SoftwareDevelopment #SoftwareEngineering #TechLeadership #EngineeringLeadership #EngineeringCulture #TechDebates #PodcastBirthday #OneYearAnniversary #PodcastAnniversary #AI #AIAssistedProgramming #AIProgramming #BallofMud #AICoding
Scott: We will find a way to fit this into the patterns we already have,
even though we think it's flipping everything up right now.
Brad: Welcome, everybody,
to another episode of the How Many CTOs Does It Take podcast.
My name is Brad Hefta-Gaub, and my trusty co-host is,
Scott: Scott Porad.
How are you, my trusty co
Brad: -host? I am doing fantastic.
How are you doing?
Scott: I'm doing good as well.
We have an occasion to celebrate.
Brad: I was going to say,
did you know, did you know what today,
the day that we're recording this podcast,
is?
Scott: is our birthday,
Brad: It's our birthday.
Scott: our podcast birthday.
Brad: Our podcast birthday was exactly a year ago today on
Scott: Happy February birthday to us.
Brad: 18th, 2025 that we released the first episode of this little shindig we call a podcast.
Scott: Yeah.
It's been fun.
Brad: It's been fun, hasn't it?
Scott: Yeah, I guess so.
What's happened in the last year?
Brad: What so much has happened in the last year,
hasn't it?
Scott: I don't know. It hasn't been a lot. I can only think of one thing that's happened in the last year.
Brad: Everything that's happened.
Scott: Well, let's just recap it.
We interviewed some people.
Brad: Yes.
Scott: Because we had some vexing questions of engineering management.
Brad: Yes.
Like the ball of mud.
Scott: I came into this podcast,
that was the most pressing thing on my mind was, what do we do about some of these problems like tech debt and balls, things like that.
Brad: Yeah.
Scott: And to be truthful, what I learned is I don't think anybody knows.
Brad: Nobody knows how to solve that problem.
Scott: I mean, we didn't interview everybody.
Brad: Yeah.
Scott: But we interviewed some smart people and talked to some smart people and it seems like I guess there's only one answer,
which is just you put your head down and go to work and just refactor this stuff.
There's no real secret to it.
Brad: Yeah,
I think that like that's that's what I feel like I I kind of take away from all the conversations we had in that regard is it's like lots of people have advice on how not to get to the ball of mud.
Scott: Yeah.
Brad: Right.
It's there's nobody that has any advice on what to do.
What to do if you unfortunately already have the ball of mud.
Scott: Yeah.
Now,
you know that I'm in the business right now of trying to untangle a ball of mud.
Brad: Yeah.
Scott: And I have observed maybe that there is a role or a function that we don't have in our industry that we need.
Brad: Tell me more.
Scott: I'll just call it product manager.
I'm not sure it's really product manager.
So, you know, if you have a bunch of features you want to add to your product,
you have product managers who go out there and interview the customers and the stakeholders and try to figure out.
how to build it and work with designers and collaborate with engineers and ultimately in theory it ends up in a spec and an engineer goes and builds it right when you want to say refactor a system because it's you know doesn't work well or brittle or whatever that whole part that important work of like okay what exactly are the problems what are the possible solutions let's consider them etc etc the engineers just kind of do it
or the engineering managers or whomever people just kind of do it but
Brad: Yeah.
Scott: it's takes time and energy and we might be better at unwinding these balls of mud if we had people who specialize in that
Brad: Yeah.
Scott: I suppose it could be architects type architect types,
right?
But there's also, you know, product managers bring with them sort of a, at least in our industry, sort of a project management skill set also to
Brad: Yeah.
Scott: sort of shepherd something along.
And that's not something that often our engineering architect types of.
Brad: I'm getting two strong reactions from what you're saying here.
Scott: Tingly?
You're getting tingly?
Brad: Yeah, I'm getting some tingling. So the first one is.
One is we just had one of our one of our posts that are on our social media literally today just kind of went a little viral and it was this post where you and I was from a couple episodes ago where we were talking about interviewing for engineers in the age of AI and
Scott: Yeah.
Brad: and the clip was basically kind of you and I talking about how like really being able to untangle vague business problems and then.
You know, kind of demonstrating your ability as an engineer to to to understand a vague business problem and then turn it into actionable steps.
That Yeah. was kind of what you and I were talking about in that clip.
And there was a it went viral with a bunch of a couple of different people basically kind of reacting with,
well,
my my product managers can't even do that. They can't even untangle vague business problems,
you
Scott: Yeah.
Brad: know, and so I'm just getting this.
this tingling feeling about you kind of talking about like how there's this gap there that like kind of really being good at understanding business problems and being able to kind of like capture them and in my own like fractional CTO experience like I run into this all the time right like I you know got multiple clients that I've either you know engaged with or talked to where their problems are almost always like
Oh, I have a, you know, the founder visionary CEO that's like, I have a vision for what I want, but then they struggle at kind of like putting it down on paper.
And then if you can't put it down on paper in some form that then can be digested by engineers,
then of course what the engineers are going to build is you're not going to be happy with it.
You know, you're going to be dissatisfied.
And so like, I think there's a real, that's, that's a real thing.
Scott: I want to go into that, but I want to clarify something I said,
which is to me, it's actually more on the things that don't have a business or they have business impact.
Let me give a concrete example.
This is the best one I can think of at the moment. We are currently refactoring our authentication system.
Brad: Yep.
Scott: classic company that's 15 years old we have a homegrown authentication system now there are off-the-shelf services we can use and we're going to switch right and so to get from a to b there are a number of steps you got to go through to get there we have four different customer types at TaskRabbit so we have to think about each of their use cases and we have to build it with the new system we have to migrate people over so on and so forth
but when we're done nothing will really be different than what we have now right
Brad: Yep. Yep.
Scott: to the user that should be it'll appear a little bit different because it's it's gonna but like conceptually like it's still
Brad: In fact, if it acts different,
it almost is a problem.
Scott: That's right.
Brad: Yeah,
Scott: That's
Brad: you probably
Scott: right.
Brad: broke something if it acts different.
Scott: Yeah,
it's still going to be, you know, username,
password,
text message with a code kind of situation, right?
So, but underneath the covers, there's going to be, it's going to be more flexible.
So, and then what I was observing today,
I was looking at this plan and I noticed some features creeped in there.
We want to add social login,
we want to add this and that.
But the main point is forget the stuff that creeped in there.
Just going and saying, well, wait a second, what is all the stuff that our auth system does now? What are the requirements for figuring that out and then making the plan forward and then breaking that into milestones and deliverables? That's real work and
Brad: Yeah.
Scott: it's a soft skill.
It requires some technical skill,
but it also requires the skill of really being able to.
project manage and to some degree product manage so
Brad: I will say the second tingly feeling that I had that I mentioned I had multiple is this is I remember we could our producer can find the you know and link to the episode where we talked about this but I remember us having this conversation where one of the things I said to you was I think that the challenge of the ball of mud is so many people don't know all the functionality that's in the ball of mud.
and and
Scott: Yes, that's
Brad: so like that's one of the reasons we're all afraid to sort of refactor is we're afraid that we're going to miss out on something that we didn't realize was a feature that was in there and and
Scott: right.
Brad: potentially there are a bunch of features that are in there that literally nobody uses and don't matter anymore but you're just you kind of get this paralysis where you don't know or you don't have you don't know if people are using it or worse you don't even know that it
know that it exists since you're just afraid of the stuff the unknown that is in there that's 10 years old that how could you nobody remembers it but somebody's surely using it
Scott: To add on to that, here's a way that we do ourselves a disservice.
As engineers,
we say, oh, authentication sucks.
Brad: Right.
Scott: it's terrible to work with okay what sucks about it oh it's just it's it's garbage okay um what specifically about it is garbage well it doesn't follow any standards oh okay now we're now we're cooking with gas right so i think we do ourselves a disservice of engineers of not being
actually descriptive of the real problems right and what i've observed is often when you get to the real problems when you get from it sucks to it's not standards-based then you can get into oh now we can solve this right now we know we can get to a solution for this because we can oh we need a standards-based thing okay let's let's go do that uh
Brad: Yeah,
totally.
Scott: i want to go back to what you're saying about that thing that went viral i played
So the first time yesterday was something that GitHub has published called spec kit.
Brad: Yeah.
Scott: It's
Brad: Yeah.
Scott: labeled spec kit.
Brad: Yeah, it's one of the SDD things out there,
the software or spec driven development things out there.
Scott: Yep.
Brad: Spec is
Scott: It's
Brad: one of one.
Scott: one of the SDD things out there.
Brad: Yeah.
Scott: Essentially, if I was to interpret what it's doing, it
Brad: Hold
Scott: is
Brad: on a second. Wait a second. I just want to make sure we're clear.
We're 15 minutes into the conversation and
Scott: Yeah.
Brad: we're about to start talking about.
Scott: The second theme from this year.
The second theme from this year for me, Brad,
I think you were ahead of me on this, as I would say a year ago,
February,
whatever,
a year ago,
I was still in the, say I was interesting,
let's see what it does.
i don't know my it's unclear how much of an impact it's going to have maybe
Brad: Yeah.
Scott: we'll have some i mean it'll definitely make a difference but
Brad: Yeah.
Scott: like how much and i think i have come to now february later oh boy not sure we're gonna have i'm not sure this industry is going to be here it'll be here but like i'm not sure what it's going to look like in five years like this is this is
I'm going to use two words kind of with a slash crazy cool.
Yeah.
it's wild what's happening out there right now that's where i've come to yeah
Brad: But you know what's interesting is we had remember like in one of our early episodes, we had Michael Natkin on and what he basically described and he had a blog post that he he wrote that kind of went like this was like more than a year ago.
He had this blog post that kind of went a little viral about how he was using prompting and what he was doing was was now is what people call STD, but he didn't call it that.
right but he basically had you know he had this template of like hey i'm building this i'm building the following thing here's the things create for me a task list in the task list make sure that you have clear acceptance criteria for each task and so this was a set of these were essentially he had figured this out i don't think he was unique in this but he'd kind of figured out this model of like overly prescript make make sure that before the agents try to write any code at all
at all, they're really focused on the high quality spec of what success looks like and what the acceptance criteria are.
Scott: Well,
it goes right back to that comment that you were saying on that post.
Even the product managers don't do this.
Brad: Yeah.
Scott: But when the robots are not there in the room with you or on Slack with you and can't ask you, what did you mean by this or use their judgment to say, oh, I think I knew what he meant by.
date picker whatever
Brad: Yeah, exactly.
Scott: um i'll just grab this date picker library you have to be very specific
Brad: Yeah.
Well,
it's interesting,
too.
I've seen a couple of posts recently.
So one,
STD is obviously the big trend lately.
And what I think is interesting is like as we look back on the year,
I think that the themes around how do you use AI effectively and the speed with which.
The teams that are using it effectively are starting to get results is very much driving around this notion of call it SDD or call it like plan mode or call it like, you know, clear.
clear outcome-based instructions to the agent.
That's really what this is about.
Scott: Mm
Brad: And,
Scott: -hmm.
Brad: you know, as I have said, I'm a big believer in, you know, like I think the challenges of the teams that are going to struggle with AI or the ones that are going to succeed with AI are really going to be the ones that have,
the ones that succeed are going to be the ones that have infrastructure that would allow human developers.
to write 3000 lines of new code every day, right?
Scott: Mm
Brad: Like, and if
Scott: hmm.
Brad: you, if you can't handle a human developer writing,
you know, 10,
300 line pull requests a day, then you're not going to be able to handle what true agentic programming is capable of doing.
Scott: Yeah,
we're going to see another fork in the road, too, though.
I'm seeing it already,
which is the work that our team is doing where it's essentially greenfield, just tremendous AI productivity.
Brad: Yeah.
Scott: And then the work that's the brownfield work where they're having to go into the existing system.
We haven't got there yet.
One of our similar people right now are working on trying to create the context and rules for our existing environment. Can we...
extract from the existing system what these things are but that's going to be a real k-shape also to
Brad: Yeah.
Scott: use your expression which is company it's it's actually in that i wonder if it's going to change this dynamic so i've been asked so many times in my career when things take too long would it be better to start from scratch
And
Brad: I
Scott: the answer
Brad: think
Scott: is
Brad: the
Scott: always no.
Brad: answer that answer up till now has been no, the answer going forward may become yes.
So
Scott: Maybe
Brad: yeah,
Scott: tell me yes.
Brad: so so again,
like if we look back on the last year of this podcast,
like
all of the technical debt um human systems problems like we talk a lot about that and then we've talked about it in the context of this radical transformation with ai yeah
Scott: Yeah,
I would say the thing that has finally become clear to me in the last year is it is going to completely transform this industry.
Now, here's something interesting.
You know, I've worked in a bunch of startups,
Brad,
and I've worked every and I've always worked in startups.
I'm not in a startup right now, but I've mostly worked in startups my career.
And usually when you're doing a startup type of thing,
it's something which is new. Right.
I was early working on gig economy.
I was early working on social media,
user-generated content.
I was early in e-commerce,
all those kinds of things.
And at the time you're doing it, you think it's very novel.
But what happens over time, and I've seen this happen over and over again,
is each of these things starts to get fit into an existing pattern.
Right.
And it turns out, oh, they're not all that we thought they were special,
but it turns out they're not all that different from a bunch of other things that happened before. Right.
Brad: Yeah.
Scott: I mean, a gig economy marketplace, it's still a marketplace. It's still essentially like commerce on one end and fulfillment on the other end. Right.
Brad: Yep.
Scott: User generated content, social media. It's basically just an advertising business. You're selling impressions and engagement and things like that. Right. And so.
The thought that comes to my mind lately is we think our industry is being transformed.
But is it really?
Or are we going to look back and find a way to fit this into all the
Brad: Right.
Scott: patterns and practices?
Maybe this is what you were touching on a minute ago with the 3000s lines of code.
Are we going to say, no, it's not that different. We just need to fit it into all the things organically learned as an industry.
I mean, that's what,
here's what I'm going to get at.
Okay,
we're talking about the year in review.
I'm going to talk about the year ahead for a second.
Here's what we're going to learn over the next year.
This is my prediction.
It predicts the show.
My prediction is in a year from now,
it will make a big difference, but we will learn it's still going to fit into our industry,
right?
All the things that we've organically learned over the last 75 years.
not you and me 75 years but as an industry 75 years this isn't something different it's just the next version of it and it's probably a good frame for people to be thinking about it you've been talking you talked about it in terms of the engineer who wrote 3 000 lines of code or i think were we talking about
ALDC recently.
Brad: Oh, we haven't talked about that yet.
Scott: We haven't talked about that yet. We talked about that on our future podcast.
Brad: Yeah, we're going to talk about that on a future podcast.
We'll have to hold off on that.
Yeah.
Scott: tease teaser for everybody prediction this year there will be a thing called ALDC out there in the world so my point is we will find a way to fit this into the patterns we already have even though we think it's flipping everything up right now
Brad: Yeah, totally. And you know what's interesting is so I literally just got forwarded a new YouTube video for I don't know if you ever watch Nate Jones.
He's a actually Seattle guy and he does like AI news and kind of like the latest in AI coding and his his podcast from today that came out just today was his video was about like the five levels of using a AI in coding.
you know and he kind of and he kind of talks about like the notion of like level one is just like you know fancy autocomplete right and you know and then level two is much more like you're kind of giving more
you know almost like full tasks and letting it write some code level three is treating it like a junior engineer and you're kind of managing it uh level four kind of goes up from that um but then level and so i think that like where i'm seeing like and basically this guy's making the case that like
Most developers aren't getting past level two, right?
The teams that are seeing high,
high performance,
they're more at level three.
But there's very few, there's just a couple firms out there that are operating at what he describes level five,
which is lights out software development factory,
where the humans are only giving specifications and.
verifying results and they're
Scott: Mm
Brad: not
Scott: -hmm.
Brad: writing the code and they're not reviewing the code and they're not and and you know they're they and those that that notion of that lights out software factory that works only if the owners of the factory you know the directors of the factory have a clear understanding of what a software factory looks like
Scott: Mm-hmm.
Brad: And so to your point,
like, I think you're right.
I think that what we'll see is this is kind of what I've been talking about this K-shaped economy,
like the people that really understand how to make a software factory will be able to have a software factory that is lights out, operated by robots and a handful of a handful,
very small number,
you know, less than three, three or less.
managers,
but it will work only in the context that those three managers really do understand what it means to have a software factory.
And had they had a thousand human beings working for them, they would have to solve the problems of how do you have a software factory with a thousand engineers writing code 24-7 around the clock.
Scott: First of all, I love that expression lights out software factory.
That's cool.
Okay,
so here's a question I have about that.
If you had a thousand humans
There would be some sort of enterprise architecture design function which said, okay, you're going to work on this piece of the system and you're going to work on this piece of the system. And here's how all the pieces of the system are going to work together to contribute to this whole overall thing.
In the Lights Out software factory,
does that function exist or do we just let the robots figure out the whole thing?
Brad: That's a great question.
And I haven't watched the whole video yet because I was watching it right before you started this call.
Scott: Okay, I'm going to propose the answer to that.
Brad: Yeah,
I would love to hear what you think the answer to that question is.
Scott: If you want a ball of mud,
then you let the robots do it.
Think of it. If you have a thousand engineers and no overall architecture and just said.
So here's your code base,
go build this thing.
You'd end up with a ball of mud.
And if you said, okay, well, we're going to build some sort of distributed service oriented kind of thing.
And okay,
you 20 agents over here, I want you to go build this piece and you're going to talk to these other parts.
Here's how you're going to communicate to these other parts. And so there does need to be some layer on top now.
It might still be a human instructing an AI to design that layer.
Brad: Yeah,
Scott: But I think there is going to be layer or layers atop those thousand robots so that you don't end up with a giant ball of mud.
Brad: I think I agree with half of what you're saying and disagree with the other half.
So
Scott: Okay.
Brad: the part that I agree with is that if you don't have a clear architecture.
then you're gonna end up with a ball of mud like i that that feels like
very i feel like it'd be hard for anybody to argue with that point right you and i kind of played around with kind of dabbling around that when we a couple episodes ago we talked about the question of like does it matter if it's a ball of mud if the agents are able to write the code and understand it does it matter right and i kind of said well it still definitely matters because the humans need to read it right so i'm now taking the stance that well if if level five
If lights out software factory doesn't have humans reading the code anymore,
then,
okay,
does the ball of mud matter?
I think the ball of mud still matters.
I think you cannot,
you don't want a ball of mud. If your factory is producing ball of mud,
I think that's a bad thing.
So I agree with that statement. You need architecture to not have a ball of mud.
The part that I maybe disagree with you is, or and maybe you maybe you won't argue with me too much on this because you did hint at maybe the architecture architecture is is developed by the AI with the guidance of the of the humans.
Scott: Yeah.
Brad: And so I think that that's what.
I think the answer is the answer here is that you need to make sure your specification truly encompasses everything that matters for your software to come out the other end to match your business needs.
And so a good example of this would be if you fail to include in your specification the scale and the latency and the,
you know.
If you don't say scale and latency in your specification,
then the AI will not bother to make it scalable with low latency.
Scott: Right.
Brad: Right.
And,
you know, and by the way, as we kind of look back on the year in review,
right,
we had a great conversation with Greg Conklin where he was talking about like his experiences at large scale companies and how if he had it all to do over again, like what were the things that he would want to make sure.
Want to make sure he did in the early,
early days of a venture.
And one of those things that he called out on was make sure you're really clear with your engineering team, whether it's the robots or the humans, make sure you're really clear about what your non-negotiables are.
And he gave the example of like,
I think this was when he was at.
Groupon or something like that where you know kind of they they they had some kind of a performance they were dealing with some performance problem and like the the senior architects were like well wait a second if if I'd known that like latency was a hard requirement I would never have designed it this way
Scott: Right, right.
Brad: Right?
I didn't know that was one of the requirements,
you know?
Scott: Well,
I think what I take from that is there is always a design function and an implementation function,
right?
And often that happens in the same brain.
But as you get more and more coders, there are human coders or robot coders working on it.
You still have to have both of those functions. And I think where you end up with the ball of mud is largely when you don't have a design function or when your design function is weak.
Brad: Or if you're, I agree with that, and I would add to that a variant of your design function is weak is it's underspecified, right?
And if it's underspecified, then that means the engineer has to fill in the underspecified components.
And if that is a human engineer filling in the underspecified components,
then maybe they're going to make pattern choices that result in a ball of mud. If it's a...
robot that's filling in the underspecified components we we get to blame it for hallucinating when in fact it was just filling in the underspecified components yeah
Scott: I've hallucinated before too.
Okay,
Brad: that's
Scott: so you're actually giving me, I just had an insight that I never quite had before.
And maybe that's because I'm not that bright, but you talked about how, you know, balls of mud come when things are underspecified.
And another reason balls of mud come is when there is time pressure for engineers and they choose to take anti-patterns in order to get it done.
In a world where effectively the time to produce code becomes zero or something approaching
Brad: Because
Scott: it,
Brad: we have a lights out software factory.
Scott: yeah,
there is a project happening at our work right now, which I have not validated this yet,
but an engineer using Spectrum and development.
says he did a thing that was scheduled to take four months in three days and
Brad: Yeah.
Scott: he was about to hand it off to some other people and he was like he said i'm not going to do that actually i'm going to it only took three days i'm going to start over and go sit down and pair with those people we can all do it together because
Brad: Yeah.
Scott: three days is basically it's going to take us six days now it's still whatever
Brad: Totally.
Scott: 15
Brad: I
Scott: weeks
Brad: think that's
Scott: faster
Brad: the... By
Scott: than we thought
Brad: the way.
Kudos to that. That sounds like a fantastic idea.
Like,
Scott: Yeah.
Brad: I mean, the benefit of not just shipping the three days, but then using that as the pair programming learning experience for the people that would have tried to do it in four months.
Scott: Yep.
Brad: Man,
that's gold.
Scott: And I believe he spent two of those three days getting the spec right,
Brad: Of course.
Scott: interacting,
using spec kit,
interacting with it to define that.
So my point is, if the cost of code becomes basically zero,
if suddenly the anti-pattern of I was being pushed to get this done faster, so I hacked it together,
and now I've got, say,
dependencies between two parts of my system.
systems that shouldn't exist any longer,
that goes away.
Brad: Yeah.
Scott: That's kind of interesting.
When we think about tech debt and balls of mud,
one potentially something we get from AI is one of the biggest problems we face as an engineering industry goes away.
the pressure and there's still gonna be impatience and people want to get stuff done faster i'm sure three days wasn't fast enough for the stakeholder but the fact is if it's three days or four days it's so much faster than it was
Brad: I'm seeing this over and over and over again with the teams that I work with. I have like visionary founder type people that are like,
I want and they invent a thing.
Right.
Scott: Mm
Brad: Like I need the following.
And like the I mean, Scott,
you and I have talked like so many times we've talked about this challenge of the estimate.
Right.
And it's like
Scott: -hmm.
Brad: the golden triangle. Right. Like quality,
cost,
you know, features.
Right. And I am now seeing that the ideators cannot keep up with the ability for.
a well-trained engineer using AI to implement their ideas.
I have this, like all the teams I'm working with, they are cranking out functionality that the ideators thought would be like hard, right?
Scott: Yeah.
Brad: And that maybe even a year ago would have taken the team a sprint to do something.
Now it's one developer is doing that same level of effort.
in a day and they can get 10 of the one developer can now get 10 of those scale things done.
you know uh in in a sprint where it used to be the whole team would take a sprint to do it and you know it's funny you yeah and you and it's funny again like harkening back to previous episodes right i remember the time where you and i talked about this where it's like if you just get more and more efficient then if you know if you're using story points to measure like you know you get more and more story points done it's just like well
isn't it really just a case that the story points kind of scale to be bigger and bigger concepts like it's a it's a it's like a gas it's going to fill to it's going to fill the space allotted to it like the faster we can build stuff the more stuff people are going to demand that we build yeah
Scott: This reminds me of kind of an old story, but I'll cut to the chase and then I'll tell a story.
The estimate for everything is going to be two weeks.
Okay.
So long time ago, my first engineering manager job,
I worked on the front end of a website.
I worked on drugstore.com, which ultimately became Walgreens.com.
People were always coming to me asking me for stuff.
And after I did this job for a while, this is my first engineering manager job, but after I did it for a while, I think I just started always giving the answer two weeks because
Brad: Ha, ha, ha, ha.
Scott: people wouldn't come with a spec or anything.
They'd just be like, how long will it take to do this?
do this thing and I'll be like I don't know two weeks and then finally I give an answer two weeks to a woman who was a good work friend at the time I haven't talked to her in a long time Julie Johnston she says hey every time I come in here and ask you for something you say two weeks I think you're bullshitting me and I said look Julie nothing takes a day and nothing around here really ever takes more than a month
So if you're going to come in here with a sentence or a paragraph of what you want,
two weeks is a good enough answer for you, right?
Like it's close enough. It might take us three days. It might take us 17 days.
I don't know.
Two weeks is good enough. And so we're approaching this world where everything's going to be two weeks. Literally,
it's going to be less than two weeks. It's going to be one week.
Brad: well yeah okay i have two two uh riffs
Scott: One day.
Brad: two riffs off that first first riff is i remember
When I was first an engineering manager,
I had a mentor of mine pull me aside and he goes,
whenever a developer gives you an estimate,
if
Scott: Mm-hmm.
Brad: that estimate includes the phoneme two,
then it's a bullshit estimate. And I'm like, what do you mean? He goes,
yeah, two weeks,
two days,
I'll have it to you tomorrow.
I'll be done today.
They're all bullshit.
Scott: That's good.
That's good.
Brad: well the other thing that's funny is that that i have noticed that some of the ai tools um you know like uh plan mode with cursor or plan mode with anti-gravity will will sometimes the plan mode includes like if you give it a big enough thing it'll
Scott: It'll give you an estimate.
Brad: give you estimates and it's so ridiculous because the estimates literally will say things like oh phase one is one to two days and it's like i click the fucking build button
And it's done in an hour,
so it's like its estimates are so off base,
you know.
Scott: It's true.
It would be nice if it estimated how long this would ordinarily take.
So, well, this comes back to the SDD thing for a second, which is if the cost of developing the software is zero,
the pressure is on the spec.
Brad: All the pressure should be on the spec.
Scott: You know, then this begs a question,
which is if you've got this role in your organization called product manager whose job is to specify the thing that the engineer builds,
like how is that going to work? Are they just going to sit with the STD bot and clarify their spec that way? Do they need the engineer even involved?
Or like, what's going to happen there?
Brad: I don't know if you and I talked about this already,
but I feel like one of the sort of like memes that I'm starting to hear more and more of is essentially all these jobs start to morph into a job that is very close to being like a product manager,
right?
Scott: Yes.
Brad: So product, like a product manager using a high quality,
you know.
software lights out software factory methodology is indistinguishable from an engineer using a lights out software factory methodology
Scott: That's fair.
One of the engineering managers at our company, Tom Osowski,
who I think maybe you've talked to before,
that's what he's been playing with.
He took essentially,
you know, we use a system called augment,
which is like cursor to cursor.
He plugged it into Jira.
He plugged it into Confluence. He plugged it into Google Drive and a bunch of other stuff,
you know, non-technical system,
GitHub,
of course, with our code.
And he's been marveling at like, what does this mean for the job lines,
for the lines that we have, the roles and responsibilities, because now I can go, he did something interesting. He said, look,
find our company goals for this year.
and tell
Brad: Yeah,
Scott: me the
Brad: yeah
Scott: top five tickets that my team should be working on right and I don't know if the answer was exactly right it was close enough and
Then that's pretty interesting if the AI can do the prioritization for you
Brad: I think, yeah,
for sure.
And like, how many times do you think you could sit down with like a visionary product CEO type person where, you know, you'd have those conversations around like,
oh, what do we trade off for this new feature that you just came up with that you want to build?
And it's like,
hey,
dude, you got to prioritize this stuff.
Like you need to someone needs to prioritize this stuff.
Well, guess what?
The AI probably is actually better at prioritizing a gigantic bucket of tasks than the average human is because the human doesn't have the patience, right?
Like every time you ever go to a triage or prioritization meeting,
right?
Like everybody burns out in the first, you know, 20 minutes of that because humans struggle at such a hard, it's so hard for humans to like look at giant lists of things and to think rationally.
about how to prioritize them.
Scott: Well, yes.
And I mean, you just.
triggered me a little bit, not really triggered me, but I am trying to
Brad: This is one of the most triggering things that a CTO can remember and think about is how many times they've been in prioritization meetings where the product owners or the CEO visionary is just unable to prioritize.
Everything's the top priority.
Scott: Well, yeah, it's interesting.
I would say the trigger is actually two ways.
The immediate reaction was,
I'm actually doing this bit of work right now to try and convey some priorities for this big project we're working on and just expressing it in a succinct way so that people can digest it. But also.
um with enough details that it's meaningful to them i don't think i found the answer yet but it's very difficult right because um we have about probably eight or ten work streams on this project and each work stream is a roadmap of its own with a year you know a year-long roadmap on each work stream and um how you end up with this huge huge thing if you do it in a gantt chart it's massive and it's just very confusing
But here's the other place.
This is very cynical.
And if the other people who I work with at TaskRabbit are listening,
I'm just I'm making this up for entertainment purposes.
I want them to know that when I used to get very worked up about those prioritization conversations earlier in my career.
And now I do not at all.
because i view it as like this is great you guys can sit here and discuss how many prior ones and prior zeros you want but the fact is we only have so much capacity and
Brad: Yep.
Scott: notwithstanding the ai conversation that we might be growing our capacity we've only got so much capacity so you can debate this till the cows come home but at a certain point
So there's the next project up and you're going to have to pick what it is.
Brad: Yep.
Scott: And so maybe I'm cynical,
but I've just found that trying to trying to getting emotionally invested in that prioritization conversation is not ever proven successful to me because,
like you said, people have a hard time with it.
Now,
I enjoy and happy to contribute to it on like a let's think about strategically,
where do we want to be investing in all those things.
But mentally,
I sort of treat it more like a Kanban board,
which is like this is great that you want to do all this stuff. But at a certain point, some team or some project is going to finish and then we're going to choose the next one to start working on.
And that's the best we can do.
Brad: Yeah.
Scott: And that's I guess that's my advice to all the CTOs out there is like, don't get too worked up because the reality of this comes back to sort of what Zuckerberg says about code wins arguments.
It's not exactly the same spirit of it. But at the end of the day, someone's just going to.
It's going to start coding and that's the point at which you have to decide the next P1.
Brad: I had a I had a early,
early in my career,
I had a when I was first an engineering manager, I had a mentor that effectively said something like that to me and it was he was a business owner.
So it was it was good to hear this from a business owner. It wasn't like he was an engineer that was like saying this,
but he basically was like,
Brad,
like just don't worry about it. The engineers work for you.
like they're
Scott: The whole
Brad: gonna follow
Scott: session.
Brad: you you know they're gonna follow you so you know help out collaborate but don't get so worked up about you know this or that
Scott: Well, I think the thing you said about, I want to harp on that word collaborate for a second. I do think it's important to have a plan over time.
I personally,
I believe that a Gantt chart is the best way to express that plan.
And I think that's actually really important. And I think it's important to recognize you can change that plan at any time you want.
There's a cost of changing it. And if you're doing.
if you've broken down your projects into small deliverables the cost gets smaller and smaller
so I don't think there are people who want to go the extreme other way and say well we're just going to do Kanban we're just going to pull the next ticket off the board no I think you have to have a plan businesses need to know what to expect is coming right
Brad: Yep, but for sure.
Scott: I've never been in a place where we haven't tried to plan more than we could actually do
And I used to get really wound up about that.
Brad: Well,
Scott: So,
Brad: and I also think
Scott: yeah.
Brad: that you and I, you and I have both spent a lot of time in startups and one of the challenges of a startup is that you don't know what you don't know. Right. And so you don't want to get too, you don't want to plan too far in the future because your strategic priorities are going to change.
Scott: I mean, you can't.
All right. I'm at a more mature company now and we can plan for the future because there's stability.
But when you're earlier, it's just like you don't even know what's happening next week.
And you have to build it and grow it. You start out, hey,
we're doing a one-week sprint, and you build your capability.
Well, look, we've gone way, way off of a year in review and off predictions.
You got a final prediction for the coming year?
Brad: Let's see,
prediction for the coming year.
I've said it already.
I'll say it again.
Scott: we're going to see more and more more and more of a K-shaped economy that's
Brad: Yeah.
Scott: what I think we're going to see I think we're going to see the halves the halves are going to crush it and they're going to just really perform and the have-nots are going to fall further and further behind yes
Brad: And so the interesting question for the coming year will be, if you're starting a company,
it's easy to be a half.
The question is if you're, well,
Scott: Well,
Brad: let's
Scott: yeah,
Brad: not call it a company,
if you're starting a software project,
Scott: I think it's easy to be have if you've got the right engineering mindset.
Brad: oh,
of course, of course,
but there's no impediments to be,
well,
there's, you know, there's not a lot of impediments, but I think the interesting question in the year ahead will be if you're an existing project or company,
whatever,
how do you become a half?
Scott: How do you get into the top half that K?
Brad: Yeah.
Scott: I think we're going to see I think we're going to see organizations that have good,
strong engineering methodologies.
They're going to find ways to jump up to that top half of the K and and they're going to become the halves.
So even if you got legacy code base,
I think we're going to see I am
Brad: very Yeah.
Scott: bullish. I am very bullish on the software agents are going to get better and better at looking at legacy code because they spent all their time looking.
I'm looking at legacy code.
Brad: Yeah,
that has to be the piece. I was looking at something similar to spec kit called Agent OS,
and it has a feature in there.
I can't remember what it's called,
but where it's trying design specifically for this problem.
We're going to try to look at your code and try to reverse engineer rules and context from what you have.
that's a real problem and it's actually interesting because it's a real problem with the big company staff and so it'll be interesting to see if the Googles and Facebooks of the world come out with some tooling to help us with that because they've got balls of mud too right
Scott: Yeah, for sure.
For sure.
Brad: Um,
so it'll be interesting to see if they start to come out with some tooling to help us with that because we need it very badly.
Scott: So there you go. You helped me come up with a refined prediction.
One,
I've been saying it in K-shaped economy,
but my other prediction is you're going to see some breakout legacy companies with large legacy code bases that have provable demonstrable top of the K performance gains.
Brad: Yeah.
All right.
Scott: So there you go.
Brad: That's it. Year one has been fun,
Brad.
Scott: It's been a super fun year. I'm so glad we started doing this. I love getting together with you every week and talking and picking your brain and learning from your wisdom and just sharing this time.
It's been so much fun.
Brad: I feel 100% the same way.
And I'm excited because we have informally and we've not said this to anybody, to the 39 people who are listening,
we've not said this.
We've kind of made it a mission for ourselves to bring on more guests this year.
this year and
Scott: Yeah.
Brad: I am looking forward to that as well to seeing we brought on some guests last year but we weren't really systematic about it when we thought about it and now we've got our production staff so
Scott: Our producer has been just cranking out the guest invites.
Brad: I'm looking forward to meeting some folks this
Scott: Yeah,
Brad: year do
Scott: it's going to be fun.
All right, everybody,
remember to rate,
review,
and subscribe.
Brad: you think anybody does that
Scott: I mean, at least five people did.
Brad: All right.
Thank you, Brad.
I'll talk to you next week.
Scott: All right. Talk to you next week. Bye.
This episode of How Many CTOs Does It Take Podcast was edited by Saffron Epigal.
Our theme song was AI Generated by Brad.
Please follow us on all the social media platforms at at howmanyctospod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon,
or at our website at howmanyctospod.com.
And remember to rate,
review,
and subscribe on the podcast platform of your choice.
Thanks for listening.