Measuring Technical Debt and Technical Investments
How Many CTOs Does It Take? Exploring Startups, Process, and Engineering Efficiency
In this episode, two CTOs tackle a wide range of topics, starting with the humorous notion of the number of CTOs needed to accomplish common tasks like naming a podcast or establishing coding standards.
They share insights into their professional lives, discussing the intricate dynamics of hiring family, the nuances of early startup life, and the importance of implementing processes from the get-go.
The conversation delves deep into engineering management strategies, from effective retrospectives and debt registers to the pivotal role of estimation accuracy as a proxy for team performance.
They also explore cutting-edge tools like GitHub Codespaces and methods to measure leverage within teams.
The discussion is rich with actionable insights for tech leaders and startup enthusiasts, emphasizing the balance between productive processes and agile development.
-
00:00 Introduction and Podcast Title Discussion
-
01:14 Hiring Family for Work
-
03:37 Stealth Startup Insights
-
04:31 Process and Team Dynamics
-
10:02 Breaking the Iron Triangle
-
15:54 Exploring GitHub Codespaces
-
21:05 The Challenge of Tech Debt
-
22:17 Creating a Debt Register
-
23:16 Project Retros and Estimating Costs
-
27:08 The Importance of Leverage
-
31:42 Measuring Engineering Efficiency
-
36:23 Closing Thoughts and Announcements
Scott: As an industry,
we still don't know a way to measure productivity.
Brad: When the girls all protect me,
sing the message to those who never tell,
to become themselves.
CEOs will share their stories untold.
How many CTOs does it take to figure out how to record a video call?
Scott: That's a great question.
I thought the very first thing we should discuss is what the title of this podcast would be, and I had no ideas, but maybe how many CTOs does it take to
Brad: I like that.
Scott: do?
Brad: I like that. How many CTOs does it take?
How many CTOs does it take to approve a coding standard?
Scott: Zero.
Brad: Hopefully.
Scott: I'm assuming there's a third-party coding standard out there that you could just code against.
So, okay, but if it wasn't how many CTOs does it take, which is a good, that's a clubhouse leader,
what would the other name be for it?
Brad: I thought it was ho-rad and be-rad.
Scott: Okay,
sure.
It could be that.
That's good.
Terrible.
We need a marketing.
We have a marketer we can reach out to.
Brad: Yeah, yeah, we got definitely like a social media influencer.
All right, welcome everybody.
My name is Brad Hefta-Gaub and this is my co-host Scott Borad and this is the How Many CTOs Does It Take podcast.
Scott: So what's happening at Stealth Startup?
Brad: Oh, it's great. It's the perfect time of a startup.
It's free product,
free customer,
free MVP.
So it's all it's like all blue ocean, just we're run, we're small team, we get to build stuff fast, we we don't have anybody complaining about it yet. Right.
But it's fun.
It's great.
It's it's it's really interesting.
I think that one of the things that
that I'm doing with this, which was a little bit of an experiment, but I'm really pleased with the results so far,
is
we're small right there's there's essentially like eight of us working on the product if i keep counting myself and then the other uh the founder who's our product guy so we're really small team and you can with a team that small you could totally get away with just like completely freewheeling it no process you know you every everybody could just be kind of just doing their own thing kind of thing
Um,
but instead we're, we've kind of got a fair amount of process,
right?
We're, we're, we're doing two week sprints. We,
um,
we do, uh,
like today,
you know, at one o'clock today,
we'll be doing our closing ceremonies for our current sprint that we're in.
We do really, I think really great, uh,
high quality retros where we kind of really, it's totally no ego,
no holds barred.
um what went well what went what didn't go well i'm super stoked about our dev stack we have this dev stack where it's like we're all using docker docker containers docker compose and like literally every single developer has can run the whole stack on their system on their on their local dev machine and as they're making changes to the full stack and when we do cicd we're basically when we deploy in github
we've got little aws instances for each of the developers that are like their little sandboxes so they can they can like work locally but when they make their pull request against any of the repos because we're like not a mono repo we're multiple repos um they can basically be like hey i got that feature up and running go check it out in you know scott in scott's stack you know so scott.dev.startup and um
anybody can go play with it and um and so the product the product guy can go play with it and give feedback or the qa guy that we have can jump in there and start basically doing early testing against it and um yeah it's pretty it's pretty cool i'm pretty stoked it's like i feel like it's it's way more process than i've ever had for a team this early and it's
And everyone, but we're still moving super fast and everyone seems to really be in the flow of it.
Scott: So I have so many questions for you, but the first one I'll ask is, well, if you don't need the process,
why do you think it's why is it happening?
Brad: I think that it, first of all, I think that teams that are this small can get away with very,
with no process.
Scott: Yeah.
Brad: can get away with it but it it but you're you're constantly accumulating a little bit of debt and
Scott: Yeah.
Brad: i think we have just enough process such that we're being much more intentional about whether or not we're accumulating debt
Scott: When you say debt, you meant tech debt or like process debt?
Brad: tech debt process i mean
Scott: Any
Brad: it could kind be all
Scott: of debt.
Brad: all the debt like um team dynamic debt
Right.
Scott: Mm-hmm.
Brad: Like great example of this is like we.
we implemented so like i said we're not a mono repo we have multiple repos it's like a multi-component stack and so we nominated a developer to be like the steward of each stack you know so every stack's got a steward and um or part of the stack has the steward and um yeah it was like the classic thing right like somebody puts up a poor request and it languishes and nobody does the code review and you know and and
And that's like a classic example that when you're 150 engineers,
right?
Scott: Mm
Brad: Like
Scott: hmm.
Brad: if that thing got built into your culture where you allowed that stuff to like languish, right?
You allowed to build the cultural norm that it's okay not to do code reviews or not to do, right?
But instead,
boom,
that comes up, that comes up in the retro and we're able to be like.
hey wait a second like we said we wanted to do code stewards and have code reviews and now but the code stewards are like not doing code reviews like
Scott: Yeah.
Brad: and then I get to play like the I get to kind of play devil's advocate go why are we even doing code reviews
let's not do like why are we sitting around slowing ourselves down waiting
Scott: Yeah.
Brad: for code reviews and everyone's like no we need to do them and i'm like okay then why aren't you doing them why aren't you and like you know and everyone kind of can have like a you know like a true i'm really proud of the team they're really not they've kind of gotten rid of their egos in this they're like they're like oh yeah that's that's screwed up like i should have you're right i was i failed to do my part
Part that we agreed we were going to do.
Scott: You're reminding me of the early days at Rover.
I mean, it was a similar kind of vibe.
Brad: Yeah.
Scott: And I think, I think we, I mean, you're essentially saying, hey, we're choosing to do the process.
And I think the team is choosing because they're professionals and they want to be excellent.
And it's helping them be better.
Brad: Totally.
Scott: I had a comment about something you said, then I had another question.
The comment had about like the no stress.
Brad: Oh.
Scott: I think it's actually,
I'm going to make this comment in two different ways.
The first is, I think the stress actually mostly comes from one specific place,
which is, I guess I'm going to combine the two ways.
It's when we're trying to break the iron triangle.
Fundamentally, I think all the stress comes from when we're trying to break the iron triangle.
Brad: 100%
Scott: And I actually have this hypothesis that the entire purpose of business
is to break the iron triangle.
Like when you break the iron triangle, you have found a competitive advantage,
which then the market catches up with you eventually and you don't have it anymore.
But fundamentally what the business is trying to do is figure out, can I offer something better for a lower cost?
Or can I offer something of the same quality that I make cheaper?
or higher quality that I make it the same whatever they're just fundamentally trying to break the iron triangle in order to get that so you get an advantage and
Brad: Totally agree.
Scott: at least in software like we're in the middle of the iron triangle we feel that squeeze right we are the triangle and so I guess what the thought I had about why you're not feeling stress is
for for whatever reasons I guess the phase you're in that you don't have
You don't you're not you're not burning down your runway far enough yet or you don't have sales goals that you've said you've hit or whatever it is. You're not quite yet feeling the
Brad: Yeah.
Scott: strain of the triangle closing in on you,
Brad: A
Scott: right?
Brad: hundred percent.
A hundred percent. A hundred percent. Yeah.
And that I,
yeah,
totally agree.
It's a, it's, it's the moment in time where it's still early enough.
That, you know, and we're, I think it is.
First of all, let me just say, I 100% agree with your assessment.
And it's a little bit of a red flag that I don't feel that stress.
Like, you know, being completely transparent,
like.
As a C-level executive at this startup,
I better,
I should be feeling some level of stress, like let's move faster. Let's, let's, you know, what,
what is the piece of the triangle that I need to be pressing on? Right.
Scott: Well,
Brad: Are we
Scott: I don't
Brad: moving?
Scott: know if I agree Are with
Brad: we
Scott: that.
Brad: not moving fast enough?
Are we not creating quality?
Why,
why don't we yet have the, you know, you know.
Why don't I feel this impending deadline of when are we putting this in front of a customer?
Scott: But I don't know if I agree with that because let's just say you had the right product, you had the right product market fit,
you had the right funding,
you had the right team, you had the right pieces in place.
Maybe you don't need to break the triangle in order for it to all work.
Like this is this
Brad: So
Scott: is one
Brad: wasn't
Scott: of the things
Brad: your point,
Scott: I'm
Brad: though, that capitalism definitionally is all about finding the.
The advantage that you somehow figured out that your competitor didn't figure out and that that advantage probably was one of the sides of the triangle getting
Scott: Okay,
Brad: pushed.
Scott: so that advantage might be on the quality side and a specific aspect of quality,
which is we have made a better mousetrap. We have made a better product,
Brad: Yeah.
Scott: right?
So it's not the dimensions of quality that people typically talk about, which is like.
you know,
is it well designed or well manufactured or whatever versus cheap?
You might have actually just said,
look,
we've made a better Apple watch and
We can work it's the market's going to adopt it just because it's a better quality item,
right?
And we don't have to try and build it for cheaper and we don't have to try and build it for faster.
We can just build it and the market will adopt it.
Right.
Brad: Yeah.
Scott: So that might be the case. And that would be ideal.
Right.
To me, I think one of the biggest strains is with these startups is that you're burning money.
And actually, and the truth is with these startups is.
It's actually not a business that works.
So, right,
this was a, when we were at 98.6,
the thing that I said this to a few people and it didn't win me any friends, which is like, you know, the possibility exists that this business won't work.
Right.
Brad: Right.
Scott: I mean, it's a great idea,
Brad: Well,
Scott: but it just
Brad: 90
Scott: cannot be
Brad: % of businesses don't work.
Scott: right.
And people are like, we have to do this. We got to do this. We got to make it work. I'm like, you know, there is one,
it might not be possible.
Brad: Right.
Scott: We have to accept that fact that it just.
Now, no one wants to just go back to their investors and be like, well, we tried and here's your money back because we couldn't really figure it out.
Brad: Right.
Scott: That's not the that's certainly don't typically win that way.
But I don't know, I feel like almost all the stress in my career has come from we're burning money.
We're trying to make something work that isn't working correctly,
that isn't working well enough. And so.
we're we're that we're burning too much money and we're not growing fast enough and those are not those are not intersecting at the right spot right
Brad: Right.
Scott: in the places where it has felt successful to me those were intersecting at the right spot right and I was like oh this is sweet who's working this is great and
Brad: Totally.
Scott: so um maybe you've just got one that works
Brad: Well, we like I said, we haven't released this to any customers yet,
Scott: Yeah.
Brad: so that's when the that's when the that's when the rubber is going to hit the road.
Scott: Okay.
And one more question for you.
Brad: Yeah.
Scott: Everybody's got their, you know, developer.startup, developer.dev.startup environment.
Did you look at GitHub Codespaces?
Brad: You know, we haven't been playing with GitHub. I haven't enabled that.
We are deployed in AWS.
Of course, GitHub Actions run the whole thing.
For the most part,
it.
You know, you know, the GitHub actions build the Docker containers and build everything and then launch it into a AWS domain.
So I have not played with code spaces. I thought codes,
I thought code spaces was more like an instance of an editor,
like it runs
Scott: Sort of.
Brad: like Visual Studio or
Scott: Either
Brad: something.
Scott: you're going to think it's stupid or it's going to blow your mind. And I'm excited for you to go look at it because you might come back.
I come back and just be totally geeked out on it. This is how I understand it.
It seems like Microsoft with GitHub has put together a trifecta, which is GitHub,
your repo,
and
Brad: Mm-hmm.
Scott: then VS Code.
Brad: Mm-hmm.
Scott: I guess you need to have containers in there as well.
And then code spaces. And basically, what code spaces does.
Code Spaces does have an online editor,
but it's the same as VS Code on your desktop.
Brad: Yep.
Scott: And basically,
you can run your containers locally.
Or you can run them in a quote unquote code space,
which is just a container in the cloud.
Brad: Yeah.
Scott: It's basically kind of what you're doing, but it's totally integrated and automated through VS code where you can just say,
OK,
here's my project. I just want to run these in containers.
They just run up there.
I think you can expose them to other people to look at, and you can edit them in your editor,
and it's got whatever sync mechanism is,
or it has to rebuild it, or it does whatever it does, right?
But I think they're trying to create this really elegant world where, as a developer,
you know, you go from repo to editor to...
Brad: Deploy.
Scott: to well this i don't think you deploy like a production version in code space it's just i think it here's one problem i think it solves which is i'm running an environment with x number of containers and to run them all on my local machine is just like we're having to get these developers machines with 64 gigs of ram now because they they need to work on one container but they need to be running 14 other containers
Brad: Yeah,
Scott: in
Brad: yeah, totally, totally.
Scott: order to like
Brad: Right,
Scott: so
Brad: exactly.
Scott: um
I think what this allows them to do is it solves that problem,
which is I don't need to have a huge local machine because the containers are all running.
okay now cloud um and now you need to have internet speedy internet probably um so it's kind of i think a similar solution and i think you could you know you can have multiple branches right this branch has this thing running in this branch and so and
Brad: so Yeah.
Scott: forth so i think it's kind of similar to what you've done you've just built your own and i think github is trying to just build it for us and
Brad: Yeah,
Scott: for sure just by the minute for whatever
Brad: yeah, of course. Exactly.
Well,
and I.
So I definitely want to check it out then. I'll chat with our DevOps-y, our full stack guy that is our most DevOps-y guy who's built all the GitHub actions. I'll ask him if he looked at it and see if there's value there.
We, you know, one of the other things, too,
that we have,
you know, I always, so part of the reason I'm proud of what we have and code spaces might be a good piece of this is I recall that.
At least at 98.6, one of the challenges that we faced there was that it was a very, you know, lots of small components were involved in the whole architecture and the developers who were like the front end focused developers couldn't really run.
the back end components when they needed to do development and so the only way they could kind of test their stuff was to deploy it into this dev space that was a shared dev space which had everybody else's partially implemented code in it and it was a it was a disaster and um i remember
Scott: Solutions and layers are like code spaces would solve that.
Brad: exactly
Exactly.
And we solved that problem early on, right?
Like
Scott: Yes.
Brad: when it was just two developers,
they were just doing deploys into a single hosted environment and it was like the two of them just didn't, you know, made sure not to step on each other.
I got there and had the third developer. I was like, wait a second, we need to solve this sooner rather than later.
This is a path to ruin.
Scott: Yeah. And well, then it becomes very expensive to fix later.
Brad: Oh,
Scott: So
Brad: yeah.
Scott: that's actually that's actually the world that I'm in now.
Right.
Brad: Yeah.
Scott: Is that.
I since the last time we talked I think so now I'm leading all of engineering for TaskRabbit so
Brad: Yeah.
All right.
Scott: it's about it's about a hundred and twenty engineers thank you to be careful what you wish for it and I was like a moth to a flame I was like you know what this is gonna be really hard and it's gonna be type two fun and why am I doing this I don't need to do it
I'm fortunate enough in life that I don't have to do it, but I couldn't stay away. I couldn't resist.
Brad: Built for punishment.
Scott: I just a masochist. Yeah, that's why we do it. So it's about 120 engineers plus another,
say,
30 or 40 kind of product people and designers and all that stuff.
Right.
And hacking on one single monolith.
And I've only been doing it now. This is the end of my fourth week.
I don't think there's a great development environment. Like all these things we're talking about aren't there.
It's a 14 year old company,
right?
Brad: Yeah.
Scott: And so the challenge they're facing is, well, it's just they're not tech debt bankrupt yet.
Like they're not like, hey, we just have to throw out this code.
It's not that kind of situation.
But the velocity of things are just really slow because it's just years of accumulated.
check debt and process debt and not having the tooling in place like you're talking about to make it easy things like that actually it reminded me of something that i want to see if i can get you to put something into your process there
Brad: Mm-hmm.
Scott: while you're young while you're just a handful of people I
Brad: Yeah.
Scott: want you to create a debt register you could do it in your retros where you somehow basically start while it's cheap while it's easy start accounting for the cost of that debt right so that you know right now everybody knows we have this big debt but you can't quantify it you can't quantify how much it's really slowing us down well we can do it I've done it before
It just takes a bunch of work to go through everything and like add it all up, right?
But you're at the beginning where you can start building that foundation now,
which What is every,
Brad: does that look like?
Scott: well,
I can tell you how
Brad: What
Scott: I did
Brad: are
Scott: it the before.
Brad: unit? I guess what are the units?
Scott: Let me tell you how I did it before.
Brad: Okay.
Scott: We did project retros. So after our project was over,
I sat down with the engineers and we went through.
Everything that had to be built,
kind of almost like a ticket level.
And I asked a few questions.
First of all, how easy or hard was this to build?
You know, you know, essentially,
like how much longer did it take if this took you for if this took you two days to build or a week to build or a month or whatever it was, how much longer did it take you because of the tech debt and stuff you had to deal with?
Brad: Okay,
Scott: Right.
Brad: so it's like you subjectively ask the engineer,
what's your estimate of the friction?
Scott: Friction.
Yeah.
And so and then I said, so Okay, well,
it took me a week and I
Can I, if this was just better written, I could have done it in three days.
And then if I didn't have to deal with this other thing over here.
And then I asked the question.
Um,
okay,
well,
how would we fix this other thing over here that was a problem?
And they would say, well,
if we did this other kind of thing, and I said, okay, cool.
How about estimate in a t-shirt size? How much work do you think it would take to fix that thing?
So now what I knew was I knew the cost of the tax.
Brad: Right.
Scott: Let's just use my example.
It was 40% cost.
I knew the amount.
I knew this and I knew a project to reduce that tax,
right?
Brad: Yep.
Scott: Let's say it was a large project.
I knew that to get rid of that 40% tax,
I could spend money to do this large project.
And so if you think about it in that financial model of tech debt,
I knew my interest payment,
which was the tax.
Brad: Yeah.
Scott: And I knew and I knew my principal,
Brad: Yeah.
Scott: which was the cost to fix it all.
And I had.
And with those two things together,
I had ROI.
Brad: Yeah.
Scott: I knew if I invested this, I would get this return,
right?
Now, I wouldn't get this return until I knew one other piece of information,
which was hard to know,
Brad: How
Scott: which
Brad: many other
Scott: is
Brad: projects will overlap on that same tax?
Scott: bingo.
Brad: Yeah.
Scott: But what I was able to do was I would get a lot of pressure from the finance and pressure isn't the right word.
Like the financial team would be like, they didn't understand why I wanted to invest in these things.
Why do you need engineers to do this? What's the ROI on it? How does it affect our revenue?
And I can go back and say,
look,
we did a bunch of project retros, you know, for the last six months we did a project retro and everything.
And on average,
40% of our effort goes to dealing with debt.
Brad: Yep.
Scott: So if I invest in some of these projects,
I'm going to bring that down and you're going to know you're not going to spend less money engineers because we're not going to just lay people off,
but you're going to be getting more for your engineering dollar.
Brad: I
Scott: So
Brad: love
Scott: that's
Brad: it.
Scott: how I did it. And the reason I said it was expensive to do is because we were kind of going in.
in retrospect figuring out what the debt was where
Brad: Yeah, yeah,
Scott: you're in this early stage where you're saying as you're creating the debts you can actually write them down and say hey we're making this choice we think it's adding this tax to it and this is what it would have really cost in order to avoid the tax and
Brad: cultural
Scott: so you can start to create that register and now i was doing it just for tech debt and you talked about process debt or whatever kinds of you could do debt it for all of them yeah you could do it for all of them
Brad: Yeah.
Scott: and just start from the foundation of we're building essentially a balance sheet here of what is principle and what is interest on these things doing
Brad: I love it.
That's a great idea.
Scott: it now now where I'm at with I want to start doing something similar that with TaskRabbit is every time they make a choice getting this added to a big list of debts we have
But I still think I need to get to what is the tax,
because the debts don't matter if you're not, as you said, if you're not touching that area of code ever again,
Brad: Right.
Scott: the debts don't matter.
Brad: So,
Scott: It's
Brad: exactly.
Scott: low interest debt,
right?
The interest is higher when you touch the different areas of code.
Brad: I'm going to plant a seed and we won't be able to do a deep dive on this,
but I want to plant a seed that I think is very related to the idea that you just talked about.
I like and I'm going to try to think about how to turn this into an investment model as well.
But one of the so here's the seed in the retrospective.
Pay just as close attention to the why did it go well?
as the why did it go like what could have gone better and
Scott: Mm hmm.
Brad: to really try to interrogate yeah but why did it go well like what specifically did we do differently that made this thing successful right
Scott: Yeah.
Brad: And this is something that I feel teams really struggle with because
Scott: Mm-hmm.
Brad: they want to just go,
yay,
we did so many stories. We got so much stuff done this sprint.
We got so much shit done.
Yay us.
But then to say, wait a second,
great,
love it.
Congratulations.
But why?
What was the choices we made that made this one successful?
And that comes from that comes from my experience in traveling in the mountains and traveling in avalanche terrain,
right, where you really want to interrogate all your all of the good things.
because did we make did we just luck out or did we actually make a decision that may and if we did make a decision
Scott: You can
Brad: then
Scott: repeat it.
Brad: we want to know it so we can repeat it yeah
Scott: You can repeat it. Yeah, it's a very very smart very smart
Brad: there might be a way to use your like
interest and principle way of looking at it, not just on the negative side of the balance sheet, but
Scott: Well,
Brad: on the positive
Scott: now you're getting
Brad: side.
Scott: now you're getting to the other side. Right.
So the opposite of interest is leverage.
Brad: Yeah.
Scott: Right.
Brad: Yeah,
Scott: And so you're saying, where did we get leverage here?
Where did we make it easier for us? Where did we get more work done with less effort,
not less work done with more effort?
Brad: exactly.
Scott: Right.
And so can you make a leverage?
I love this idea.
Can you make a leverage balance sheet also?
oh this is now we're cooking with gas this is interesting uh i'm constantly preaching about how what we have to do has to create leverage the thing i've been saying now this is the third potentially fourth company in a row i've been at where like my job has been to help a team perform at a higher level
Fundamentally, like if I was to boil it all down into like one saying,
it is the fastest way to get out of a hole is to stop digging.
And so, well,
Brad: And to call in somebody with a backhoe to lift
Scott: sure,
Brad: you out.
Scott: that's definitely one thing. But like everything,
things we do either create debt or create leverage.
Brad: Exactly.
Scott: And I love the fact that you're talking about assessing that side of it as well, because that's actually even more positive. That is something business leaders really want to hear about.
I did this thing, and now I can do something.
faster or you can do some faster or you can transact more orders or whatever you want to do with
Brad: And the fact that we attacked,
for example, with this very small team,
very early stages, the fact that we basically attacked how do we have our own personal dev stacks,
right?
How do we attack that early on?
Scott: Yeah.
Brad: That work,
that investment that we did has provided leverage every sprint since then.
Scott: But leverage and debt compound.
Brad: Yeah.
Scott: Look,
when we think about interest,
you can either be paying interest or you can be earning interest.
Brad: Exactly.
Scott: Right.
Brad: This is earning interest.
Scott: So and they both compound.
Brad: Yeah.
Scott: That's exactly right.
They both compound.
This is really sweet.
The big challenge I always have that we all have.
is conveying to the business leaders the value of these things.
Brad: Yeah.
Scott: That's the real challenge.
And really the fundamental challenge is,
I think, as an industry,
we still don't know a way to measure productivity.
Brad: Right.
That's the number one question, like number one question you ask any engineering manager or engineering leader that you're going to hire into your organization. Right.
Like is.
How do you know? How do you know if your team is actually performing at their best,
right?
You can't say task completion ratio.
They get 100% of their tasks done.
Is that because they sign up for like the minimal
Scott: Okay,
Brad: amount
Scott: well, now
Brad: of
Scott: this work? is very interesting.
This is very interesting because if I was literally just talking with another person this morning about this.
If I was to boil down the entirety of how an engineering team is performing into one proxy metric,
and this might be controversial,
Brad: lines of code clocks you're going to make the case for clocks
Scott: if I was to boil down all of engineering management.
To one thing, meaning how do I know if a team is performing well?
I would, and if you said, Scott,
you have to boil it down to one proxy metric and one proxy metric only.
I boil it down to estimation accuracy.
Brad: Yeah.
Scott: That's it.
Because there's all sorts of things in the value stream that have to.
be lined up in order to deliver an accurate estimate and if your software is unstable and you're having to deal with production fires all the time your estimations are off right because you're dealing with that kind of stuff so um i boil it down to that with one caveat i mean not a caveat but an asterisk at least the goal is not 100
I can give you 100%. It's easy.
We sandbag the estimates.
Brad: Exactly. I was going to say, anything you measure can be gamed.
Scott: That's right.
The goal is 80%. You want to be 80 plus.
And if you're at 100,
you're sandbagging, right?
You want to be at 80 plus. Now, look, there are, at least for the kinds of things I work on.
I did work on health care with you for a year,
but in general, I've never worked on things where there's a lot of life and death at stake.
Brad: Yeah.
Scott: I worked on pets for a while and there was, you know,
there were pets at stake for sure.
Very serious there.
But for most of what I've done in my career,
we we can get to 100 percent accurate by very detailed planning and specification and super.
all that stuff but we're not i'm not launching rockets or airplanes in the sky so i
Brad: Yeah,
Scott: need that so to me i said look we want to be between 80 and 90 that means we're not sandbagging we're striving a little bit that's enough of an area that the business can handle it if we said it takes a month and it's really going to take a month plus four days it's not going to crush us right
Brad: Or it shouldn't or it shouldn't crush us like the business also needs like if all sales forecasts were always within 80 percent, that would be a whole other.
Scott: Yeah, that's right.
So to me, like that's the foundation right there,
which if we had a crystal ball,
if we knew all the future,
we knew when the DDoS attack was going to happen, we knew when somebody was going to be sick, you know, we knew when.
you know the customer was going to call and be mad about something and had to randomize the team well then we could we don't have a crystal ball but so that's to me that's that's it and um i don't know how we got on this topic but that's i pretty
Brad: Oh,
Scott: much boiled
Brad: we're talking
Scott: all
Brad: about
Scott: team of engineering
Brad: efficiency.
Scott: team
Brad: I love it. I love
Scott: efficiency
Brad: it.
Scott: that's
Brad: All right.
Scott: it we're talking about measuring velocity that's the thing it's like we don't know how to do it but the best thing i've got is estimation accuracy
Brad: Not 100%.
If it's 100
Scott: % Yeah.
Brad: you're sandbagging.
Scott: Maybe the name of this podcast should be called 80%.
Brad: How many CTOs does it take to get to 80% accuracy?
That's a long podcast title.
Scott: Okay,
well, don't forget to like,
rate,
and subscribe.
Brad: Yeah,
Scott: We have to smash say that.
Brad: that subscribe button.
Yep.
Scott: Yep.
You can go to our Patreon page
Brad: Yes.
Scott: to sign up for bonus episodes.
Brad: Bonus episodes.
We're not quite sure what the bonus episodes – well, bonus episodes are – we do code challenges.
We do pair programming.
Scott: We could do that would be fun or we could do office hours we'll be doing a live podcast recording
Brad: Are
Scott: We're
Brad: we going to coming do
Scott: to
Brad: a we're coming to
Scott: next we'll be in Chicago,
Brad: We're
Scott: Illinois.
Brad: going to be in Chicago. Yes at the Symphony Hall
Scott: Yes. Oh,
Brad: All
Scott: we would
Brad: right,
Scott: fit if we can fill the Symphony Hall with a bunch of engineering management nerds, we will have
Brad: and
Scott: made
Brad: we will it'll
Scott: a big time.
Brad: definitely be big time
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.