CTO Therapy: The Risks and Rewards of Vendor Partnerships
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub delve into Scott's recent meeting with AWS. They discuss the concept of vendors supporting their clients, weighing potential benefits against risks like vendor lock-in and misaligned solutions. The conversation also touches on Scott's old blog 'The Luddite CTO.' They offer practical advice for engineering leaders on framing needs as problems to leverage vendor support effectively, rather than over-functioning or over-committing resources.
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 #VendorManagement #VendorPartnership #TechInsights #TechSolutions
Scott: Maybe I need to stop thinking about this like an engineer and start thinking about this like a customer.
Brad: Welcome, everybody,
to another episode of the How Many CTOs Does It Take podcast.
I'm Brad Hefta-Gaub,
and this is my co-host and
Scott: Scott Porad.
Brad: Scott.
Today,
what are we going to talk about today? You reached out to me and said you had a very interesting topic to talk about, and I would love to hear about it.
Scott: Well,
it's interesting because it's actually not an interesting topic.
In the sexy world of AI,
it is as dull as it comes.
Brad: Okay, let me hear about
Scott: At
Brad: it.
Scott: a high level, the topic is when you have a vendor who has the point of view that's supporting their customers within their own interests,
so they offer in different ways to support you,
how do you make the most of that?
That's the high level topic.
And then let me give the most specific example that's happened to me recently.
As listeners of this podcast know,
I am currently the CTO at a company called TaskRabbit, and we are primarily an AWS cloud platform customer.
We also use Google Cloud Platform for some things, but that's less of our workloads,
so to speak. And so we're a big enough client of.
AWS that we have an account manager,
that's the first part.
And the second part is they organized something for us that they call an EBC or an executive business conference where they invited us to Amazon myself and some people on my team to come to Amazon to their executive briefing center,
which is.
you know, basically a floor of one of their buildings in Seattle,
and to talk to us about the resources that are available at AWS to help us.
And what I learned, I learned a lot in that meeting, and I can give a little bit of an outline of what was discussed, but I think the most key thing I learned was AWS has a belief.
which is probably backed up with data, but they have a belief,
which is if we can help our customers,
then that will come back and help us.
And ultimately,
you know, they're thinking if we can help TaskRabbit grow,
then TaskRabbit will need more compute and we'll sell them more compute,
et cetera.
Or if we can help them solve a problem,
maybe they'll buy one of the other services that we offer on our platform.
In reading between the lines, I got the impression.
that the people in the room,
their personal annual performance reviews are based on
did their client meaning password did their client grow not did their client buy more stuff but actually did their client succeed right whatever whatever the client was telling you they had a problem with did they succeed at solving that so we came in they asked us to come in um we brought a group of one two three four about five people um
And we started by just telling, you know, opening the kimono, so to speak, telling them about the challenges we're facing.
And for us, that's a lot of, you know, decomposing the monolith kind of challenges.
That was one part of the meeting. Another part of the meeting really was not about engineering.
We talked about partnership with Amazon Marketplace, a potential partnership with Amazon Marketplace. I mean,
Brad: Yeah Sure
Scott: it wasn't a.
that was more of us saying hey we'd love to partner with you and
Brad: Right.
Scott: and they brought a person into the room who was like well okay i'm we'll talk to you about that but that i don't that's not going it might go somewhere but i'm not revealing anything that's a secret of course everybody wants to partner with amazon and then the third part of the day was really talking about ai on their platform and i will say and this is a little bit critical that was actually the least impressive part of the day you
Day to me.
Well, actually, the least impressive part of the day to me, there was an hour where the person from professional services came in and I wish I could have recorded that hour because it was a word salad of acronyms and industry
Brad: Yeah,
Scott: bingo
Brad: jargon.
Scott: jargon that's jargon.
And I was just like,
if it wasn't me in this room listening to this person,
this could literally just be.
NXKCD.
So,
um...
Brad: So I have a couple questions about this.
And maybe I'm just trying to frame it to see if this is kind of what went down is what I imagine what went down.
I guess this is more of a statement than a question,
but I think that like this notion of working with a vendor who's motivated to make sure their customers are succeeding while using their software,
like that's I hope that that's how most all vendors think,
right? Like I think that like we as software,
B2B businesses,
B2B businesses should.
should be thinking along the lines of the more that my customer is happy with using my software,
then the more loyal they'll be.
They'll maybe use more of it. They'll maybe, you know, increase their volume,
but they'll be more sticky with us as their particular business vendor, right?
So I feel like...
I feel like I've seen this sort of play before,
not just from huge vendors,
but even, you know, obviously when you're a small startup, you're doing this like crazy. If you're a B2B startup,
you're trying everything you can to make sure that like the people that purchase your software are successful with it because that's your
Scott: Yeah,
I would say this had a slightly different tone.
It wasn't, are you being successful with?
Our software,
it was what are the challenges that you are having in your business right now and how can we help you?
Brad: Yeah,
Scott: Could we help you solve them?
And that might end up with you using more AWS services and it might not,
but we are here.
We have a bunch of resources here and we just want to be helpful.
They're practically begging us. In fact, I walked out of the room thinking after like eight hours of being in this room, I walked out of the room thinking to myself,
pity isn't the right word, but I was thinking, oh my God,
we have to find a way to
Brad: to let
Scott: let
Brad: them
Scott: them help help us.
Brad: us.
Scott: I mean,
they'll be so crestfallen if they don't get to help us.
Brad: Yeah. And I sort of feel like there were there were definitely times at many of the vendors,
I mean, excuse me, at the companies I've been at over my career where, you know, the big player like the Microsoft or the Amazon or the Apple or something like that is just trying to get you to use their software,
you know, or the, you know, and so there and it makes sense that it's not just a.
how can we help you use our software but it's like how can we make sure you're being as successful as possible your business is successful as possible because we look good but I think that what you're speaking to here is this idea that it was clear that these people's you know like their quarterly objectives or annual objectives their review is going to be predicated on the success of your business and that's that's like I think that's pretty cool I agree with you it's not
It takes a pretty sophisticated vendor to be able to get to that stage where they can have those kinds of incentives for their employees.
They're clearly in a cash flow positive world and they're doing everything they can to kind of like buttress their lead or to kind of keep the customers happy.
So I feel like I have seen this before and it tends to be those like large long term, very steady players who are still aggressively fighting other big players in the space.
to keep market share and to maintain,
you know, loyal customers.
Scott: And what I walked, that's exactly right.
And what I walked away with was thinking.
How would I make the most of this?
Brad: Yeah, totally.
Yeah,
because a lot of times it's like how many times have I been brought into a meeting like that where it was like the the biz dev team at,
you know, mega corp was just trying to do more business with,
you know, my my little startup.
And it was like we're brought in as the, you know, the engineering leader,
you know, CTO or VP of engineering. And it's less like.
It's like, please find something that we can do to keep the business development people like happy.
It kind of that can that can definitely turn into a solution looking for a problem,
right?
Scott: That's right.
Well,
certainly there was a solution looking for a problem in this sense.
You know, they probably put up on the screen,
so to speak.
50 different things they could help us with.
Brad: Right.
Scott: I mean, AWS is such a vast landscape.
Brad: It's huge.
Scott: We can do this, we can do this, we can help with this, we help other partners with this.
So one of the things I walked out thinking was,
well,
we have to get clear on what's important to us. They'll help us with anything we want help with.
And they'll help us with things we don't want help with too.
So we need to get clear on what we want help with.
But I think the other thing I thought,
and you just touched on it, was this.
Yes.
When you said, hey,
I go into a biz dev meeting as a small startup,
there's this like mismatch of like our size and scale and how we're thinking about things and their size and scale.
Brad: Yeah.
Scott: And, you know, we are not Nike or.
I don't know, whole foods, I guess Amazon owns whole foods, but like I was just looking around my space here to see brands that I recognize were not Apple,
right?
And so the kind of solution that Apple would want, like, okay, one of our challenges right now is our sort of commerce and payment system.
We're having to work on that.
Well,
the commerce and payment system for a Nike or an Apple or a whole foods is entirely different.
than one for,
I think it's entirely different than one for a task rabbit.
And so sometimes I get afraid that they're kind of bringing,
I'm going to call it big company solutions when I want small to medium sized company solutions.
Brad: Sure, totally.
Scott: And so I think that.
That makes me a little, I just talked to you about some of the things,
but now we're going to do a little therapy,
Brad.
I'm going to talk about some of the things that always makes me think how do I get the most out of this. I think I'm afraid that I'm going to be fed solutions that are not the appropriate scale for my world.
I'm afraid that I'm going to get.
direction and advice and opinions about what to do when I've already got a lot of stuff to do and I need actually help getting it done.
Brad: Yep.
Don't bring me ideas. Bring me hands to get the ideas done.
Scott: Sure.
I'm afraid that I'm going to get solutions like if I'm afraid that I'm going to get level four solutions and what I mean by that is if I'm just operating like I'm just trying to get the basics right.
and and they're bringing me stuff that's like they're playing above the rim which is cool like the stuff they're doing that was some of the stuff i saw with ai there like neat stuff but i'm like yeah man i'm just here still working with engineers to like get used to using you know ai and their ide and
Brad: Right.
Scott: we're not we're not yet to where we have a fleet of agents which is you know so
I worry about you getting those level four solutions that are just like two where it's not there yet.
Right.
Brad: Yep.
Scott: And so I think about how to, you know, how to tap into what we need. And I guess it all comes back to what do we need? And maybe we don't even know what we need.
Brad: Yeah, totally.
Yeah.
Well,
you know, it's interesting.
I, you know, as you as you describe this, I'm thinking about, you know, I I've seen this recently. There's a.
groups that I'm working with where they want to be SOC 2 compliant and so then they were working with a vendor that's an up-and-coming vendor that's that's just like kind of really knocking it out of the park on SOC 2 compliance this company called Vanta and basically what they do is they wire up into all your systems and they kind of do automated automated audits and sort of like
guide you in a wizard-like way through what do you need to do to further your your security posture or your SOC2 posture and it's like you and I last time you and I worked at a company together where we we had like major compliance um regime around SOC2 and HIPAA and stuff like that and it was a you know it was like
just a ridiculous number of hours of energy and time that were put in by that organization and and vanta claims to kind of like automate all that away you know just glue right into your dashboards and it's like the company looking at this is super small like it's very very tiny team and i was just like man like this feels like yeah it's like my grandfather used to say something like i can't afford to save 200 on a refrigerator
Right.
And so it's like sometimes you can't afford the help that they're offering because
Scott: Right.
Brad: because it actually gives you it puts more more on your plate than if you just don't do the thing.
Right.
The help is the help.
Yes,
they're helping.
But even helping me, I still have to do more work.
Scott: Yes, you have to.
That's another fear,
right?
I have to.
I can't just say come help if there's not someone on our side to actually engage with them.
unless they're going to do it all on their own and it never seems like they're going to do it all on their own
Brad: Yeah, and, you know, it's interesting because,
you know, I don't think I'm telling any tales out of school, but Vanta works with a couple different vendors that are like essentially SOC 2 auditors. And one of their claims to fame is that they are able to kind of work with these firms that actually are really motivated to come in and do the work for you. Now you have to pay for it. But.
You know, that is an opportunity.
It seems very similar to like the best case scenario where it's like, I don't have the time and energy to do this. But if I have the money to pay for it and that vendor comes with a perspective of we're going to give this to you cheap or we're really good at doing working with people at your scale or our whole point is to make you successful. But if you're successful,
then you're going to keep coming back to us for business.
Yeah, I'd like to think that those things exist and there's no such, you know, the adage there's no such thing as a free lunch.
Well,
maybe there are such things as a very well-priced value lunch that actually
Scott: Yeah.
Brad: fill you up and, you know, are nutritious and also don't cost you too much.
Scott: Yeah.
You know, something was said in the last few minutes that made me, that provoked a thought,
which is.
Maybe I need to stop thinking about this like an engineer and start thinking about this like a customer.
Brad: totally yes throw it back and say show you know show me what you got like yeah I'm your customer you do the thing for me okay
Scott: Well,
I actually meant it a little bit different.
I meant it from the perspective of like.
I'm sitting here stretching my mind thinking, how do I tap into this? What do I want them to help me with and so on and so forth, as opposed to just expressing,
here is my need.
My need is.
My cost of maintenance for my cloud infrastructure is too high.
I have two full-time people who all they do is keep our cloud infrastructure running.
And as a CTO,
I want it to be one person or less so that I can free up that resource to go do something else.
Can you help me solve that problem? So
Brad: Yeah, that's
Scott: maybe
Brad: great.
Scott: the way to frame this is in the language of a user story.
as opposed to saying like where my mind is initially going as an engineer like well i wanted to come in here and like redo our networking so that we can blah blah blah and like and that's even a bunch of work for me that or me and my team have to think of right as
Brad: Yeah.
Scott: opposed to just saying
As a company,
we want to be multi-region for disaster recovery.
And right now, because of our networking,
we can't, and we want you to fix that for us.
Brad: Yeah,
I mean, that's that's a little example of maybe it's like, you know, when you're when you're presented with one of these.
So let's let's try to turn this into like advice for other CTOs or other up and coming engineering leaders.
Right.
Like one.
Do not be surprised if sometime in your career you're going to be approached by one of these large vendors with a team just like this and they're going to come in and they're going to basically say we're here to solve whatever problems you have.
Scott: Right.
Brad: And the first thing that's going to happen and you're going to get triggered and the first way you're going to get triggered is just like every time anybody comes to you as an engineering leader there they it's like they got to be asking for me to do something they're just they're they're asking for something that's going to cause my engineers to have to do work and the number one thing I have to do is like figure out how to allocate these precious resources of engineering minutes.
minutes you know so don't be surprised when you get approached by a big vendor like this and don't be surprised when you're triggered then
Scott: Right.
Brad: instead of being triggered instead of doing the thing that of course as an engineer you're so good at and which is what made you the engineering leader that you are to start to think about oh if I had that tool how would I use it instead of going down that road
Just say,
yeah, okay,
here's my problem.
Scott: Right.
Brad: Will you solve it?
Scott: I think that's right.
Brad: It's just that simple,
Scott.
Why didn't you come to that on your own? No, I'm just kidding,
but it is hard,
right?
Scott: Well,
it's because the roles are reversed.
We
Brad: Yeah.
Scott: are normally in the situation of people coming to us with a problem.
And so we're all oriented around.
solutions or sometimes they come with us to a solution and we say no no don't bring us solutions bring us problems
Brad: Good for you, it's your problem.
Scott: and so now the shoe is on the other foot or the glove is on the other foot or the hand is on the shoe or whatever people say and I have to rewire my brain to think about it in fact I have a message here
One of the people who was in this meeting thought it would be beneficial to have them come in and do some training to help upskill some of our team on some certain new things.
And that's the solution.
I want Amazon to come in and do some training for my people to upskill them on this when maybe the way we need to phrase that to Amazon is.
Our engineering team doesn't have enough experience with X and we want we believe we need more in order to accomplish Y.
Can you help us solve that problem and see what they come back with?
Brad: Yeah.
Scott: That's what I'm going to say to my team.
Brad: They might come back with,
hey,
we've got training programs. We'd be happy to bring you in on that.
They might come back with they might come back with maybe we can co-pilot with you, like maybe we can sit down and actually.
put somebody in sight on site with you and have them pair program with you even you know they might they might be able to bring all kinds of stuff to bear right
Scott: Tell them the problems we have and let them propose solutions and then we can decide if we want to take those solutions if they say yeah here we've got some links to some articles in our in tech net you remember Microsoft
Technet?
Brad: Yes.
Scott: Is that still around?
Brad: I don't know if it's still around,
but yes, that's exactly what I'm thinking about.
Yeah.
Well, happily, here's a solution to your problem.
We have this $2,000 product that's a bunch of CDs that you can install and read documentation.
Scott: Yeah,
and I would say to that, yeah, that's not really what we,
that isn't helpful because my engineers already have a subscription to TechNet.
I don't know, that's whatever.
But then that sort of puts us in a position of getting to decide if we think that would be helpful.
And that forces us to actually think about.
I feel like I'm having therapy with myself.
If you're building a great rubber duck breath,
it forces us to actually think about the outcomes we want.
Brad: Yeah.
Scott: How will we know? That's another part.
How would we know if we were successful with this thing we're asking you to do?
All of our engineers will know how to do X or our network will be such that we can open another region and it'll work whatever.
Brad: So, yes,
I, by the way, I think that you're pulling on exactly the right threads at this point, right?
Like really understand,
like, what do you want to accomplish?
Get really clear with yourself about like, what are your goals, right?
What are the actual problems you have as opposed to, you know, don't just have people bring you solutions if you don't know what the problems are.
So that's that,
that sounds great.
I want to, I want to ask you.
um what are the so so what are the downsides to kind of working with this vendor in this case so you you like the immediate downside the thing of like well we don't really know what we're doing or want so it's just going to be a waste of our time like that that feels like a kind of obvious downside what are some of the other potential downsides
Scott: Well,
of course, there's the risk that they would steer us towards solutions that cost money or that we don't need to be spending because it's in their interest.
There's the risk, as I mentioned,
that they steer us towards solutions that are not appropriately sized for our problem.
There's a risk that...
On our side, as we engage with them, we forget a little bit about what we're trying to accomplish and we start to get like whose parade are we marching in?
Brad: Yeah,
Scott: So we get a little diverted and all of a sudden we're heading down a rabbit hole.
There's a scope creep risk.
Oh,
you guys want us to fix your network? Well, you're going to really need to refactor your whole infrastructure,
Brad: yeah,
Scott: actually.
Brad: well I already told you that I told you my problem was the monolith
Oh, all we got to do is put if you just break this into a bunch of lambdas you'll be fine
Scott: Oh, actually,
that's a risk, too.
I don't know if our listeners know this.
I used to own the domain name.
the Luddite CTO because in I
Brad: why is it past tense you let it you let it expire what
Scott: had to let it go like I've had to let hundreds of other domain names go because I've thought of here's the thing I'm going to do and the first thing I do is I go buy the domain name and then after about five or seven years I say to myself am I really ever going to do this
Brad: was the luddite ccto going to be
Scott: It was going to be a blog back in the blog days. Remember what blogs were?
Brad: Yeah,
it
Scott: Can you believe there's kids who don't even know what blogs are?
Brad: goes kids these days newfangled
Scott: A blog was a newfangled thing for a while.
Brad: just
Scott: It went by the way of the CD.
Look,
I am not a CTO who is inclined to embrace the latest technologies about things.
Brad: for the sake of it
Scott: Just for the sake of it,
I am more comfortable being.
a step behind the cutting edge.
I want to embrace the most progressive cutting edge development software and development practices,
software engineering practices,
those things, but the technologies.
Let me, let's let somewhere out, let's let someone else prove this out and let's let the community decide, you know, when these technologies all start, there's always a bunch of them competing and then one of them ends up being a victor, right?
So let's let the community decide.
what the industry standard is going to be before we get on it and all of a sudden we're running angular and everyone else is on react but we've invested a bunch of this in the community figured out that react is the way to go right so i'm more comfortable with just a little bit behind the line and so a risk is you get put on some cutting edge thing that
they move you they encourage you to embrace the sort of cutting edge technology which maybe is overkill and doesn't necessarily end up being the industry standard what was the thing before Kubernetes I think it was called mesos or mesos you
Brad: Oh, I don't know.
Scott: know Kubernetes has kind of been you kind of become the industry standard right there were competitors right
Brad: Yep,
Scott: that's if
Brad: true.
Yeah.
Scott: you if you had your whole system remember chef
Brad: Yeah, chef.
Yeah.
Scott: Right.
Brad: Wow.
Scott: So remember Ansible?
Brad: Yeah.
Wow.
Yes.
Yeah.
Scott: So that's why I had to let ICTO is it was, you know, I was kind of blogging at the time I was speaking.
I used to do a lot more public speaking conferences,
that kind of stuff.
I'd like to do it again, actually, but it just died with the pandemic and then I just haven't got to it.
I wanted to talk for a little while about how like we're doing I felt like as people in consumer oriented internet companies we were doing ourselves a little bit of a disservice about embracing the latest technologies because it was as engineering teams we were getting distracted from what we were trying to do which was make the experience better for our customer because we were goofing around with
Yet another friend in framework.
Hamill, you remember Hamill?
Brad: Hamel. Jesus.
Okay,
so those all sound like legitimate risks, and they all kind of have a similar flavor to them, which they're effectively technology risks.
One of the things you didn't mention that I also think is a very real risk is,
especially when the vendor is a bigger vendor,
right,
is they go to school on you and they see what you're doing and you're just a little small fry and they're big and they decide to suck in what you're doing and take over.
Scott: Yes, and it's a great question.
I've actually had that experience.
I don't know if it's a risk with this vendor.
Brad: Maybe not in this particular scenario,
but if we're just looking at this generically for other CTOs or other VP engineering leaders who have this presented to them, this offer presented to them.
when
Scott: Gotcha.
Brad: you wear your business part of your c hat you know something you got to ask you got to ask the rest of your business team this
Scott: Yeah.
Brad: is a huge thing with the ai models the frontier models right now right like a whole bunch of um you know people that are building people that are building on top of the ai models are you know building mostly on um
you know on anthropic because anthropic's agreement is like we don't we will not be scraping any of your stuff to go build apps we are only building frontier models we are not we promise we will never build apps off of your what you're doing and open ai not so much like explicitly don't carve that out so
Scott: Mm-hmm.
Brad: you know that's a really that's a really good example of the same
Same dynamic, bigger vendor, smaller customer,
how much do you open the kimono to use your language?
Scott: Yeah,
there's some competitive risk. They learn your business and then they expand into your business. That's for sure a risk.
I don't think it's a risk in this case.
Frankly, they already do what we do.
So Amazon has a home services offering.
It's not as robust as in some ways it's more robust than TaskRabbit and in some ways it's not.
So that risk is already there.
Here's another risk.
The vendor lock-in risk.
Brad: Yeah, yeah,
I was about to say, that's what my Lambda joke was,
but you didn't get it.
Scott: Oh.
which
Brad: Like
Scott: is
Brad: lambdas
Scott: my guess so
Brad: are just like lambdas are a great example of like AWS lock-in.
I mean, you can sort of do lambdas and you certainly can do edge functions in the other clouds,
but it's like your code is barely reusable,
you know.
Scott: yeah i i am more i tend to not i tend to discount vendor lock-in risk because
Once you've gone a little ways,
like how you're working on still startup, how far along are you a year, year and a half?
Brad: Yeah.
Scott: Nine months.
Brad: Yeah, we're... It
Scott: How many months would it take you to switch to another cloud platform,
all your stuff?
Brad: would be an effort.
Scott: It'd be an effort,
right?
Brad: Yeah.
Scott: So I tend to think.
You know, the only reason to switch platforms,
what are the reasons to switch platforms?
They're offering you cheaper cost.
They've got some capabilities that maybe you want.
That could be some like sort of like political reasons,
like I don't want to do business with this vendor and I want to do business with this other vendor.
I don't know.
But I guess my feeling is like once any startup gets past more than a hot minute, you're kind of locked in from the economics of switching aren't worth it.
Brad: The number one reason that a small startup would want to be flexible and be able to work on any vendor would be the potential of an exit where the larger company decides to.
to acquire the startup and you it sucks if it's like you're on AWS and Microsoft comes knocking and says we'd like to acquire you right
Scott: Well, let's flip that around for a second. If you went all in and embrace the capabilities of the AWS platform in order to accelerate your business.
Like, it seems like the risk of lock-in,
the consequences of vendor lock-in are less than the benefits you could potentially get from, you know, taking full advantage of all the capabilities in the platform.
Brad: Yeah, I mean, maybe, but the one thing I'd say about that is.
I would say that all of the if we're just focused on cloud vendors right now right like they're pretty they're all pretty good they all pretty much have all the the same basic functionality to them they're different enough the flavors are different enough that you kind of can't you know it's it's pretty hard to code once and deploy everywhere although
you know with kubernetes and you could you know if you want to have your whole thing basically be you know open containers then you probably you can pretty much you can deploy those almost anywhere at this point but i i don't know i i it's funny i agree with your point about maybe uh vendor lock-ins overblown i kind of agree with that point and also
I don't really think there's that much benefit of like deeply embedding with a vendor resulting in much faster velocity than anything else, right?
Like it's not like one vendor is going to make you go way, way faster.
It's like whatever vendor you're on,
you're going to go as fast as your team's able to go.
Scott: Well, unless you're apprehensive about using any of the features and capabilities they offer because you're thinking,
well, maybe we'll want to switch vendors.
You talked about Lenovo a few minutes ago.
That might be a bad example.
Let's talk about, I don't even know what to call it anymore,
the databases that Amazon offers and the databases that Microsoft offers.
Brad: Sure.
Scott: Azure database and AWS database,
they've got different names now,
right?
Brad: Yeah.
Scott: You know.
i've worked with somebody in the not all that distant past that they were running their own database locally and i was like why are you doing that and they were like well you know just running it just running it on an ec2 instance we're just running a version of mongo on an ec2 instance i'm like why aren't you using document db oh we don't want to be locked into amazon in case we want to switch vendors we can just move this stuff over and i'm like yeah you're going to maintain a mongo database like that's not free and
In fact, it's complicated and
Brad: Yeah.
Scott: it just seems like you're preparing for this very small eventuality and
Brad: Yeah.
Scott: you're giving up a lot in order to get there.
Brad: Yeah, that's fair.
How do we tie this back into the when a vendor comes knocking to help you? What do you do?
Scott: May I ask you one other question about vendor lock-in before we do that?
Brad: Yeah.
Scott: Have you ever been locked into a vendor where it caused a problem?
Brad: I don't think so.
No,
Scott: I don't think so either.
I'm trying to think about that.
I can't think of a time where the fact that we used a given vendor presented us a problem where we wanted to change something.
Brad: yeah,
that's why I think you're it's fair that you're you're kind of challenging that like how big a deal is vendor lock in. Right.
But here's what I have seen. I have seen that when.
Your team is used to working with one, you know, shape of a vendor and then.
for whatever reason you're forced to use another vendor like a new person like like how much now that he's like when you're hiring people because you guys are based on aws if somebody comes in and they have no if you know they're like a developer or devopsy type person that has no experience on aws and they only have experience on you know gcp you're going to kind of be like how confident are you that you're going to be able to like transfer all your gcp skills to aws and
Scott: Right.
Brad: then
That's a little bit like to me the vendor lock-in that happens is people who only expose themselves to one vendor get really get only good at that.
And then they it's harder for them to go to an organization that is not using that vendor.
Scott: Well, some people pride themselves on that.
They get all the certifications. I'm a Microsoft certified solution expert or whatever.
I don't know if that program's around anymore, but like
Brad: Oh
Scott: they
Brad: yeah,
Scott: actually,
Brad: it is for sure.
Scott: you know, I'm sure Amazon has a similar program kind of thing.
They go the other way. They say, look, this is the thing I do. In fact, I have a cousin who is an independent software consulting firm and they.
and they um his firm does one they work on like one little piece of oracle like there's probably like three of these firms in the whole world and that's all they do if oracle ever shuts this thing down i guess they'll have to shut their firm down but like if you need i can't remember what it's called if you need some help with that thing
That's
Brad: Here's
Scott: what these guys do.
And he's just like, I mean, I don't know if he's a world's expert,
but it's just like, yeah, we've just decided to attach our horse to this wagon or attach our wagon to this horse.
And that's how we're going to roll, right?
Just like a SharePoint consultant or a WordPress consultant or whatever.
Brad: Yep,
Scott: okay got it. well you are trying to bring us back because i'm sure the 39 people by now we're probably down to like seven people who are on this podcast but seven of you for the seven of you who are left we were trying to get back to how do we take best advantage of these opportunities and the one thing i think we got to was hey think like a user and frame your needs don't try and design the solutions let the vendor
use their expertise to design the solutions for you and then you can decide if you want to take them
Brad: Yeah, I think that's an excellent piece of advice. I think another sort of corollary to that is don't over function,
right?
Like let the vendor, the vendor is claiming to come here and make your life easier.
you know set appropriate boundaries that don't over function and let the vendor do the work especially
Scott: Mm-hmm.
Let them
Brad: especially
Scott: do the work.
Brad: if they're like we do this we do this for free for you right then let them do it but don't don't get yourself sucked into um you doing the work
Scott: But I still think you have to have someone on your side to partner with them,
Brad: Oh, for sure.
Scott: at least one person.
Brad: Yeah,
for sure.
But I think that like, you know, again,
like I'm willing to say like,
have you ever had this happen before where you took advantage of them and it was a and it was a big win?
In other words, were you, you know.
Do we have success stories that we can look to?
Scott: Great question.
I'd have to think back about that.
I'm sure there are some.
I mean, I know, for instance,
recently we engaged with AWS. Our account manager hooked us up with some people. They did something called a well-architected review.
They basically just looked at our cloud infrastructure.
Essentially, I think they just gave us a report which said, you know, here's what you're doing right and here's what you're doing less right because
Brad: Yeah.
Scott: they have expertise in cloud infrastructures and,
you know, we have some expertise certainly.
So I think we thought that was successful, but then the next step is, but who's going to do this work or even more deeply.
Well,
it's this way for a reason.
That reason might be some weird dysfunctional, strange reason for our company,
but like it's a much deeper thing. It isn't just about redoing our cloud infrastructure.
We have to go redo a bunch of other stuff upstream in order to fix
Brad: Yeah,
Scott: that thing.
Brad: totally.
Scott: You have to think about success stories.
Do you have any success stories?
Brad: No,
honestly,
I don't think so.
I can't think of any.
I know that it's interesting.
I think my answer is going to be a hard no.
I have no success stories.
And maybe the reason for that is one,
the places where I could have used the most help from a bigger vendor,
that vendor ultimately decided to compete with us, right?
You know,
like back in the early days of real networks,
Microsoft was the 800 pound gorilla and they had, you know, customer success organizations and we interacted with them, but they very much decided to,
you know, no surprise that streaming audio and video needed to be a core component of the operating system.
So and so that was that was a fraught relationship.
I mean, so much so that there was,
you know, antitrust lawsuits and things like that, you
Scott: I
Brad: know.
Scott: was going to say, those lawyers get involved.
Brad: And so that would be an example where no success was had in the Microsoft offering to help.
And, you know, again,
like.
Yeah, the people on those orgs, the people in those teams, they certainly were as helpful as possible,
right?
They were motivated to be helpful,
but it doesn't mean that the, you know, sort of the general,
you know, winds of time are going to blow in that direction,
right?
Scott: Yeah.
Was that the same organization or a different part of the organization that caused that, you know, did that?
Was it the right hand not knowing what the left hand was doing?
Brad: Probably.
Scott: Yeah, I mean,
yeah,
that's what you I think that's what you would see in any of these large organizations like the team that's the customer success team there, they're they're a little bit further away from the strategic,
you know, it's not the customer success team that's going to come out and try to compete with you that's that's a totally it's a product, it's a product line or in in the other other half of the organization that's right it's actually competing with you.
Okay.
Well, let's leave it at that today,
Brad.
Yeah.
Be wary when the vendors come and knock in, but if it sounds legit,
then, you know, I
I'm going to tell you that this time around,
I'm really going to lean into it and I'm going to try to learn how to make it work.
think that sounds great.
I want to hear you.
You'll have to come back on the pod and tell us of your success.
I think if I can learn how to make it work,
it could be a real asset.
Totally.
Yeah.
Nice.
Well,
there you go.
How many CTOs does it take to work with a vendor who wants to make your life easier?
Maybe three or four.
Right.
Rate review,
smash that subscribe button,
and we'll see you all next week.
Right. Bye,
Brad.
Bye.
This episode of How Many CTOs Does It Take podcast was edited by Saffron 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.
Thanks for listening.