From the Dress Code to the Bottom Line: A CTO Business Primer
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub discuss the interplay between tech and business. Starting with comments about their own scruffiness and stories of wearing hats to interviews and fancy restaurants, they delve into how CTOs can effectively bridge the gap between technical teams and business stakeholders. They run through a crash course on economics, explaining concepts like unit economics, customer acquisition cost (CAC), and lifetime value (LTV), explaining the importance of speaking the language that non-technical counterparts can grasp, and touch on the role of AI in reducing operational costs. The episode offers practical advice for aspiring CTOs and an invitation for listeners to request a class on finance specifically tailored for technology leaders.
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 #TechFashion #StartupLife #AIRevolution #BusinessGrowth #BusinessPrimer
Scott: Business is a game and the scorecard is the prop the P&L or it's also called the income statement
To this week's episode of How Many CTOs Does It Take?
My name is Scott Porad.
I'm here with my trusty co-host,
Brad: Brad Hefta-Gaub.
Scott: Brad, what's on your mind these days?
Brad: I don't know, man, but we look like a couple slobs, don't we?
Scott: Slobs.
Faces for radio.
That's what they say.
Brad: You know?
It's funny you say that, right?
Because I think that like,
I don't know, we shouldn't spend a whole 30 minutes talking about this, but there is this sort of like,
I feel like
Scott: Well,
Brad: I
Scott: if we're not, sorry,
let me interrupt you.
If we're not going to spend 30,
let's spend 45.
Brad: was going to say like,
what is your take on sort of like
how engineers engineers are there's like this classic sense of like a lot of engineers sort of being like not necessarily like it's a profession it's a white collar profession that you can basically show up wearing whatever right like how many times have you had you know engineers that showed up at the office wearing Birkenstocks and cargo shorts and stuff like that right but then as the CTO there's often these times when we gotta
We got to show up at the board meeting or we got to show up and we got to like put on our fancy clothes instead.
I don't know.
Maybe there's something.
Maybe there's something.
Are we being more authentic here by showing up at this podcast with our scruffy T-shirts and our unshaven faces?
Scott: Well, I've got three initial reactions to what you said.
The first is I'm always reminded of something I learned at one of my first jobs from a guy who had led business development.
He said,
nice clothes open doors.
Brad: There you go.
Scott: So there's one thing.
The second thing, I was early.
And I hit to the remote work thing early from
Brad: Oh yeah, so did I.
Scott: about 2007 to 2012,
I was part of a five years, I was part of a startup that was largely remote.
We had people all over the country. We even had a guy who lived in an RV.
Did you know that a feature of RV parks is Wi-Fi?
Brad: Yeah, that's pretty common.
Scott: So he and his wife or girlfriend,
I don't know, significant other,
they were just driving around the country. They go to a place, sometimes they'd stay for a month, sometimes they'd stay for two days.
Anyhow, so he's coming into the office one day.
Actually, it's not this guy. It was another guy that we hired.
So we, at this company,
three or four times a year,
we brought everybody to,
we did have an office and we brought everybody to the office for a week.
And we do this frequently to create connections in a variety of ways.
And the person we hired,
he actually sent me a message. He was like, hey, what's the dress code?
Brad: Right.
Scott: And this was over, at the time we weren't using Slack,
we were using a tool called Campfire, which was a Slack-like tool.
I don't know how Slack beat Campfire in the chat
Brad: Is
Scott: tools,
Brad: a campfire
Scott: but there's
Brad: a 37 signals add-on?
Scott: Basecamp.
I don't remember.
And I just wrote back to him,
just don't show up naked.
And that became sort of within that culture,
you know, things sometimes happen in a culture that catch on and that thing that caught on, which was like, just don't show up naked.
Brad: My wife and I just started watching this streaming show,
The Chair Company.
There's like this whole storyline where this guy's upset because his boss convinced him that everybody worked naked and he showed up at work naked.
Scott: No way.
Brad: It's a super absurd show.
It's like, anyway.
Scott: So here's the third thing.
I once, and this was about, let's say 2017.
I was working at a company we were hiring.
By the front in the lobby near the lobby there were some like small conference rooms that were used for interviews I was kind of the interview rooms So I come in one day and there's an engineering candidate in there and he's wearing a baseball cap And I really struggled with that.
I don't know if we hired him if we didn't hire him.
I have no recollection
Brad: Then you wouldn't hire me with my scruffy baseball cap.
Scott: But I just remember thinking like at an interview,
like I can understand people wear baseball caps to work. I don't ever wear a baseball cap to work,
but like people do.
That's kind of a fashion thing.
I'm okay with it.
It's not me.
But I just remember thinking like at an interview,
like.
Brad: Yeah.
Scott: I don't know when I was a kid like if we were in a hat like we came to sit down at the dinner table you had to take your hat off like
Brad: I got
Scott: you couldn't have a hat at the table at our house
Brad: oh man in my 20 in my 20s my wife and I my girlfriend at the time not my wife we were I think I'm pretty sure this was before we were married we um we were at some we were at some hotel lobby restaurant and eating dinner and or eating food or was like even like a brunch or something like that and I had a baseball cap on
And some customer walked up to me and just told me I had to take my hat off. I was being rude.
I was just like, how?
Scott: I'm a little bit from that school.
So anyway,
I just remember walking into the interview and I was so rattled because I was just like, what?
You can't wear a baseball cap in an interview?
Brad: Well, it's funny.
So like,
did you do you feel like was this a person that you ended up interviewing or did you did you know anything about whether they got hired or not?
Scott: No, yeah,
I was the interviewer.
Brad: Oh,
Scott: I was like,
Brad: it was literally a person you were interviewing.
Scott: yeah,
but like for the first.
few minutes of the interview i was just so rattled i was like how
Brad: Did
Scott: could you you i
Brad: hire them?
Scott: don't recall i have no recollection i
Brad: You just remember
Scott: have
Brad: the
Scott: no recollection
Brad: baseball cap.
Scott: if i heard them
I just remember the baseball cap and just being like shocked.
Like, you know, people would show up to interviews in t-shirt, like you talk about, you know, t-shirts and cargo shorts and everything.
And there'd be lots of times where I'd say, well, that's not how I dress for an interview,
but whatever.
This is the industry,
but the baseball cap thing,
man blew me away. Anyway, so that's what you're on your mind is fashion in the tech industry.
Brad: Well,
Scott: That's what you
Brad: I
Scott: want to go for
Brad: don't
Scott: today.
Brad: know if I want to talk about it the whole way,
but I think you like raised a couple.
Well, you know, there's a couple of things.
OK,
so how do we make this how do we make this relevant to the how many CTOs podcast?
OK,
so like
Scott: I'll tell
Brad: I.
Scott: you how to make it relevant.
Brad: OK,
tell me what your thoughts are,
because I feel like there's a few threads to pull on here.
Scott: I have received the following coaching,
which I also had to give to somebody yesterday.
It doesn't matter that you're right.
You're still pissing them off in the way you say it.
So
Brad: Delivery.
Scott: the container matters,
right?
Whether it's what you're saying, how you're saying it, what you're wearing,
these things do make a difference because whether we like it or not.
There are interpersonal relationships in the workplace.
And I remember when I was given that feedback,
I was like, but I'm right.
And the person who had given me the feedback was like,
I get it, but you're still pissing
Brad: Yeah,
Scott: them off.
Brad: yeah, totally.
Okay,
so hold on a second.
So hold on a second. So first of all, I love this framing here, right?
So as a technology leader,
as
you know c-level executive or vp depending on the scale of the company depending on the stage of the company you've got different constituents that you you bring your you've got different contexts that you're operating and we always talk about this as a cto like you're you're that bridge between the other stakeholders and the engineering team okay
Scott: Mm-hmm.
Brad: and um i'm going to offer a
hypothesis.
And that is that I think that effective CTOs know how to code switch between working
Scott: 100%
Brad: with their engineers and working with external non-technical stakeholders.
And part of that code switching might be depending on the context of the interaction.
changing your clothes right dressing up for the occasion but a big part of that code switching is you know the language we use and and the sort of informality that we might use versus formality we might use in one direction or the other
Scott: I 100% agree.
And I don't mean to brag.
That's not how my parents raised me.
But if you were to ask me.
Scott,
what is the number one attribute that led you to get to this level?
It would be a tie between two things.
One of them is...
project management,
just the ability to organize people and get something done because that got rewarded. You delivered things and people wanted you to deliver more.
But the other,
which is equally if not more important,
is the ability to explain technical concepts to non-technical people in ways that they'd understand so that they will support them.
And I don't know how I got that.
It just seemed to always be something I had a knack for.
which was to try and explain it i think it's because you know i use a lot of drawings i use a lot of analogies and sometimes the analogies don't work but you're always striving to find an analogy just this week i was just talking yesterday to our ceo she was trying to understand what's an mcp server and why do we need one i
Brad: Right.
Scott: thought we were i thought we had an api do we also need an mcp server like you know being able to explain that
so that she understood she's grateful and so she understood I think is a key part of this job and frankly it's a it's a skill to hone I mean I've definitely flopped at it a few times but you see those CTOs or engineering managers or whatever that get in there and the jargon with the whiteboard and their eyes gloss over and people were like I
Brad: Yeah
Scott: don't want to give you the money
Brad: Yeah, totally,
totally, totally.
And I think that like, I think you kind of articulated a few of the things that matter,
like the ability to.
you know maybe make analogies or to draw pictures or to I don't want to say simplify it because it's not about simplifying it's about translating it into the language that matters but I think that one skill that's important to have in order to be successful at that is
You need to have a business awareness as well.
So it's sort of like, you know, this is one thing I would say, you know, coaching to engineers that want to move up in management,
like being able to explain things to your non-technical stakeholders is critical.
And one way that you're going to get better at that is if you spend a lot of time trying to learn more about understanding about how businesses operate.
and what what what success looks like in business right because what success looks like in engineering is not directly related to what success looks like in business a great software company succeeds when or a great company that has a technical component succeeds when the engineers aren't just engineering but they're engineering with the end goal of making the business stronger and so you have to understand how to make the business stronger
Scott: A hundred percent. And I have some concrete advice for anybody listening
Brad: Yeah,
Scott: to this.
Brad: yeah
Scott: One,
the scorecard business is a game and the scorecard is the P&L, the income statement.
The profit and loss,
P&L is profit and loss or it's also called the income statement.
You don't have to go take accounting 101,
although I think it's, I took two years of accounting, but taking accounting or just going and learning,
learn how the income statement works. That is the scorecard.
100%.
Brad: Want to pray?
Scott: And learn how everything that your engineering team is doing is impacting something on that income statement.
And there are people at that company who want the numbers to go either up or down.
Are you growing with them or are you growing against them? So that's the first thing.
The second thing is go learn about unit economics.
In fact, that was a big unlock for me when I learned about unit economics and how it relates to our software businesses.
Brad: You want to say a little bit more about that? Let's say more about that.
Scott: A unit economics is what is the economics or the profitability of a given unit? And a unit could be an individual customer,
it could be a partner,
it could be if you are running a bunch of retail stores,
it could be each store location,
units change.
But you could think of it simply as what does it cost to acquire this unit?
And then what is the lifetime value in terms of profit of that unit? So I'll use an example from TaskRabbit where I'm working now is very simple. And then I'll also use an example of a startup I'm advising for, which is a brick and mortar,
which is a little bit different.
The unit at TaskRabbit is an individual consumer,
right?
And we spend money like on Google ads and things like that to acquire a customer.
We get some customers for free via word of mouth and
things like that but even when you do SEO you're spending money to develop your pages or whatever those those are all money you're spending to acquire customers and so if you take all the money you spent to acquire a customer and then you divide it by the number of new customers you got you get something called CAC CAC customer acquisition cost
which is just the average amount it costs you.
So now I'm giving a unit of economics
Brad: Yep
Scott: 101 here.
So, okay,
so you got your average cost of acquiring a customer,
and then you have their lifetime value.
So if they transact once with you, it's how much profit did you make on that transaction.
If they keep on coming back.
Over time, then, you know, the lifetime value grows.
So I don't know if these are the real numbers of TaskRabbit because I don't know off the top of my head,
but I'm just going to say it costs us $50 to acquire a customer.
On average, we make $25 a transaction.
Average customer transacts with us four times a year. And so a four-year LTV would be $400 over $25.
What would that be?
16 to 1?
That'd be amazing,
by That's the way.
Brad: a great CAC to LTV.
Scott: Crazy sauce.
I talked to an investor once. He said to me, look.
If you're three or four to one, I'll take your call.
I might listen.
You know, if you're five to one ratio,
I'm very,
very interested.
Brad: Yeah. Well,
Scott: If you're
Brad: and if you're if you're less than one over one, then you're not profitable.
Scott: losing money.
Brad: You're not profitable. You're you're like we're printing dollar bills and selling them for 80 cents a piece.
Scott: That's right.
That's right. I was in the startup once where we were we were printing we were selling dollar bills for 50 cents and we were growing really.
Really fast customers like that.
So, you know, your profit has to cover all your fixed costs, all your hosting,
all of your employees,
all of your rent,
all that stuff. So you have to have enough of a ratio there to kind of generate enough volume.
So that's your lifetime value to customer acquisition cost ratio is called.
the unit economics so that's for like a consumer internet site which i just told you i have a friend who's i advise her startup which is a
chain of local grocery stores she has five locations in the seattle area of small format grocery stores and in different neighborhoods and so her unit is a store it costs i don't remember the exact numbers roughly a million dollars to build out a store she breaks even basically within it she basically makes a million dollars a store a year she thinks the store will last her 10 years before she has to remodel it
So her unit economics are 10
Brad: Yep
Scott: to 1 or something like that.
And so there's another key piece there,
which is to know about in the unit economics world,
which is payback.
So LTV to CAC tells you your profitability,
then payback tells you your risk.
If you get your money back in a year,
that's very different than if you get it back in six months or if you get it back in 24 months because time has risk. So, again,
from my understanding, at least in the consumer Internet world.
12 under 12 months you know nobody has less than six months when I say nobody I mean think of it like six to 12 months is good over 12 months not not you know over 18 months nobody's going to invest in you
Brad: You
Scott: and so mean forth
Brad: as far
Scott: pay
Brad: as payback life, payback half?
Scott: back like payback this is too risky too much could change in that time
Brad: Well, so this is great. So I love it. So we went from punk rock sweatshirts and baseball caps to we just gave our budding CTO listeners a quick little mini lesson on lifetime value,
customer acquisition cost and unit economics.
And I think that I think those two things actually kind of tie in nicely because they're they're kind of speaking to this.
um various modalities that as engineering leaders if you really want to be a strong engineering leader not only do you have to be really good at writing code and managing people to write code but you also need to be able to understand when the essentially unique economics aren't working out
Now you need to understand, like,
well,
how do I respond as an engineering leader to help the business team find workable unit economics?
And
Scott: Mm-hmm.
Brad: this is, of course,
you know, I think one of the classic,
one of the first, one of the first lessons that most engineering leaders learn about.
in economics tends to be when they get the call from the business side of the house saying we are going to have a reduction in force and you now need to help identify how to restructure your engineering team to make this.
make our business work and
Scott: Yeah.
Brad: i mean there's a lot of understandable reactions to that but one of the one of the reactions that i think i see with less experienced engineering leaders is oh my god if you take away my people then we're already behind we already have too much to do we already are underwater i'm just going to be that much further underwater
And maybe something that we can try to kind of speak to here is like,
OK,
well,
it doesn't really matter if you get the software done if the union economics aren't working out or
Scott: Yeah, if you don't know what those projects,
if they're not either essentially increasing your CAC or decreasing your CAC.
Decreasing your CAC or increasing lifetime value or putting more units through the system
And more volume.
Brad: improving growth sure yeah
Scott: Right.
Essentially, each one of those units that goes through generates a little bit of profit.
That ultimately every or you're lowering your fixed costs. Those are essentially the four things you're doing.
Brad: lowering your fixed cost also has a direct improvement to the total lifetime value right like if you know that if you know that essentially like a customer is as loyal as they are they they definitely interact with you four times
a year for four years and that's pretty given anything you can do to lower the cost of goods of
Scott: Mm
Brad: that
Scott: -hmm.
Brad: interaction is also improving the the capture from the lifetime value a
Scott: Yeah.
Brad: lot of times lifetime value is listed as the top as the top line so it's more like
Lifetime top top line revenue finance
Scott: Maybe we should teach a special class finance for CTOs
Brad: I mean, there's a lot of I would I would I would suppose that there's probably a lot of demand for that,
especially how long it's been 21 minutes into this episode and it's time for the ding ding ding ding ding talk about AI.
Right.
Scott: Yeah.
Brad: Like I would say that AI is, you know, as you know, I'm bullish on on the use of AI. And one of the ways to use AI is to lower your fixed cost of your of your energy.
Scott: in
Brad: Mm-hmm.
Scott: its ability to generate more software to drive the economic engine of your technology company.
Brad: Mm-hmm.
Yeah.
Either lower the cost or grow faster.
That's right.
So I think there's something important that we kind of brushed over earlier.
It's a little sad,
but it's just a fact of life.
is for software engineers software leaders that work in the commercial software world like i do and you do you talked about we have to translate languages from our language to the business language and unfortunately we have to operate i'm going to make this very us and them we have to operate in their world
They don't often come and operate in our world, right?
Scott: Right
Brad: All the business people want us to understand the finances and want us to reduce the costs, so on and so forth.
But I never, you know, I never have the CFO coming over and talking to the cloud infrastructure team about how to configure the network,
right?
So like it is just,
there's a little bit of asymmetry there.
And some people resist it. Some people really try to spend a lot of time teaching business folks all the ins and outs of the technology.
But the truth is, whoever you are, like you and I, Brad, but whoever you are out there listening,
you've got decades of experience doing this. You're never going to be able to teach someone.
You can teach them at a high level.
But there is some amount that you have to gloss over when teaching them.
And so we do have to go learn to play in their space.
Scott: Yeah, I mean, 100% agree with that statement. And I guess it's interesting.
I'm pondering when was there ever a time? Well,
okay,
the times in my past lives where I have
used, you know, done my best to inform engineering concepts or engineering challenges to my business partners.
Brad: Mm-hmm.
Scott: I can only think of times that I did that where
It was a fundamental question that mattered about the business,
right?
Like we want to go take on this new initiative.
Okay.
At that point, I want to go take on this new initiative.
It may be the case that like having a conversation about the cost structure of taking on that new initiative,
the challenges of it,
the complexity of it, the overall like some of the engineering details about what it would take to take on that new venture.
That might be a time when you need to explain like,
oh, you're asking us to, you know, kind of joking about this, like bend the laws of physics there,
right?
Like, well, that's like a, that's going to be a technical conversation that matters to the business owners so that they can understand like,
oh, yes,
we could do that. Like we could, I don't know.
Can you make your whole system?
run on you know one-tenth the power consumption and you know uh 10 times faster okay well if it's an old you know um riddled with tech debt you know legacy system then it may be technically possible to get it to run 10 times faster on one-tenth the the compute resource like that
Brad: Mm-hmm.
Scott: actually may be a practical thing to do but
It's probably going to be a very expensive project to lots of engineering hours effort to do it.
Brad: Mm
Scott: And
Brad: -hmm.
Scott: that's the one type of scenario where I can picture myself trying to.
engage with the business owners to help them understand the technical thing that they're asking for and
Brad: Mm-hmm.
Scott: that might require some explaining technical but I only am able to do that conversation if I'm already playing in their space of understanding why they're asking for the business and then being able to map my engineering awareness onto business terms that make sense to them right this is how many people it's going to take to do this this is how long it would take
would take to do that right and therefore this is how much it's going to cost us if we take this on and I guess that's my way of saying like I can't think of that many times when it's been beneficial for me to spend a lot of time trying to explain engineering stuff to a business if they ask I'll certainly want to give them as much detail as they're interested in knowing
But they really own,
I think they rightfully only care about it insofar as it affects the business,
the P&L.
Brad: Yeah, although I would simply add I've observed that many times when I explain a technical concept effectively, people are really appreciative.
And I think it's because there's this big, important and expensive thing in their company that's kind of a mystery to them.
And
Scott: Yeah.
Brad: so it feels really good to like understand what you're talking about,
right?
Scott: I agree with that.
Brad: Because so many times I think that things are explained in a way that they don't understand.
but also so they just kind of nod and say yeah yeah yeah and that makes them feel really held hostage isn't the right word but like i am i am really
Scott: out
Brad: at the yeah
Scott: of control okay
Brad: out of control i'm really out of control but i have to trust this person and they're just saying stuff to me that like they're talking about this thing called kubernetes and containers and how it's all going to be better and blah blah blah like i have no idea what they're talking about
Scott: so first of all i i that i 100 agree with i i think that there's
a ton of value to be had in building trust between yourself as the engineering leader and your your business counterparts like building that trust i think is 100 required and you build that trust a couple different ways and one of the ways that you can build that trust is by by saying like hey i'd be happy to explain this um would you like to learn more about this would you you know would it help you
if i explained this you know to you and i agree with you that uh many you know like i that that that little those little micro conversations happen all the time almost always around like wait why aren't you done with this yet or why do you think it's going to take two months to do that or you know why has the you know data engineering team why are they why did why do they seem to take so long to respond
on to new uh bi analysis questions you
Brad: Mm
Scott: know or
Brad: -hmm.
Scott: or why do you guys keep having you know uh customer complaints about bugginess of xyz uh feature right like taking the time to say oh yeah let me let's let's walk through that let's walk through why those particular challenges exist so that i agree with i just want to like i i have also seen like really strong engine
engineers who are who are practicing and growing learning the the business side of things right or if they're resistant to learning the business side of things and they think that they can kind of like build that trust by just engineering explaining like you don't understand how hard this is let me explain how hard this is like you're not gonna you're not that's not gonna get you where you want to get to
Brad: No, because they just want the outcome.
Scott: Well, not just that they want the outcome,
but just saying like you it's really hard, you know, let me tell you how hard it is like that does like what you said earlier that just sort of like increases the sense of of I don't understand what you're saying to me. Right.
But if you pivot that language to be like,
hey, let's let's talk a little bit about like, you know, show them that you understand their pain point as well. Show them.
Show your
Brad: Mm-hmm.
Scott: business counterparts that you understand the reason they're asking for it sooner or the reason they're asking for it cheaper or the reason they're asking for it to be more reliable. Show them that you understand that.
Make sure you get the business needs and then use your understanding of the business needs to speak to the technical challenges you're facing.
Brad: Yeah, I think that's right.
And if you can, I find sometimes helpful when I'm trying to explain a technical thing to start with kind of a business impact.
Let me give an example of what I mean. A minute ago, I talked about trying to explain why we need to containerize things and use Kubernetes.
Just imagine,
Brad,
you're the CFO.
Brad, look,
at the end of the day.
This is just a more flexible and more efficient way to manage our infrastructure,
which in theory should allow us to have a lower hosting cost with AWS,
therefore our cost to serve will be lower.
Can I tell you exactly how much?
right at this moment i mean maybe if we modeled it out i could but like i'm just telling you conceptually it's just a more efficient and more flexible way which allows us to do things more efficiently that's why we're doing it and so then you can get into what a container is and how they work and all this crazy stuff but at least they're anchored and understanding like oh they're trying to do something to make my business more efficient
Scott: What's interesting is that's a great explanation for.
If the team has decided to modernize using Kubernetes,
that's a great explanation, and I think that's at least the start of the conversation with your non-technical business stakeholder.
It's funny,
I recently had to explain this exact choice to a...
you know, the product owner, not as technical business owner.
And I had two cards up my sleeve. The first one was that, like, hey,
this actually allows us to, you know, instead of dedicating specific resource types in AWS,
actually it's more fluid and it allows things to scale more easily.
And we can shuffle things around without essentially like, you know, spinning up the more expensive versions of AWS components.
And so it'll make us cheaper to run the infrastructure that we're doing.
And also that business was going through a phase where they were like standing up additional tenants for customers.
And this had the advantage that like,
oh,
this makes it super easy for us to stand up new tenants for other customers.
Like that's what it's really good at doing, you know. So that was kind of a double whammy of like two
Brad: Mm
Scott: business
Brad: -hmm.
Scott: needs that mattered that this particular technical choice happened to.
you know facilitate but
But again,
like just saying like hey,
it's it's Kubernetes. It's way better.
It's it's the latest and greatest technology It'll make everything easier like
Brad: Yeah,
Scott: that's
Brad: as soon as you start talking about Helm charts,
they're like, what?
Okay,
I think this is a great spot to end it for today.
Scott: There you go.
We solved the world's problem.
You are allowed to wear a sweatshirt or a scruffy baseball cap if you're good at explaining to your non-technical stakeholders in terms that matter to them, which is business,
P&L, CAC,
total lifetime value and unit economics.
Brad: That's right.
And if you are interested.
in a class on finance for CTOs, I don't know, reach out to Brad or I mean, we'll put something like that together.
Scott: Yeah,
that sounds like a good time.
Brad: All right.
Smash rate and review, everybody.
Scott: Smash that subscribe button,
rate and review.
Brad: We got to say it, otherwise we're not even really doing a podcast.
Scott: Oh yeah,
exactly.
If you don't say smash that subscribe button,
are you really doing a podcast?
Brad: I don't even know.
Scott: All right. Nice talking to you, Scott.
Brad: Bye,
Scott: Until
Brad: Brad.
Scott: next week.
This episode of How Many CTOs Does It Take Podcast was edited by Safran Epigow.
Our theme song was AI Generated by Brad.
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.