Software Misadventures - Engineer's guide to startup advising | Kelsey Hightower
Episode Date: April 2, 2024We’re super excited to have Kelsey back on the show! Our last conversation was around his incredible career journey - from working at McDonald’s after school to starting his own computer store, to... hacking on python infrastructure with the core developers, to meeting Satya Nadella for an interview. In part one of this conversation, we dive deep into Kelsey’s experiences and expertise as a startup advisor: How to break into advising when you don’t have a lot of connections How to influence without authority Passive vs. active advising How to add value as an advisor Setting boundaries and expectations Much more  Segments: [0:01:53] Being a "junior retiree" [0:11:00] How Kelsey got started with startup advising. [0:17:43] How to avoid mismatches in advisory engagements? [0:27:23] How to influence without authority as an advisor? [0:32:58] How to establish boundaries as an advisor. [0:38:29] Actions engineers can take today to prepare themselves for future startup advising roles. [0:42:55] How to manage the balance between advising and your primary job. [0:44:32] How to cultivate perspectives beyond engineering.  Show Notes: Kelsey on twitter: https://twitter.com/kelseyhightower Our previous conversation with Kelsey about retiring as Distinguished Engineer from Google at 42: https://softwaremisadventures.com/p/kelsey-hightower-on-retiring-as-distinguished-057  Stay in touch: 👋 Make Ronak’s day by leaving us a review and let us know who we should talk to next! hello@softwaremisadventures.com
Transcript
Discussion (0)
and a lot of times your initial advisory work will come from a person you used to work with,
right? So one on the team, they jump out there and they start their own company. So what do you do
when you start your own company? You start looking for people you used to work with, right? And they
say, hey man, I'm going to work on a new social media company. You're like, hmm, that sounds like
you're going to go out of business soon. I am not quitting my job to come work on a social media company.
Like where I am, I can't take this risk with you. And so then there's this opportunity typically
like, well, could you advise us? And that's where you got to ask that question. Do you want a
consultant where you want me to set up the database and design all the tables? Or do you want an
advisor to really talk about the type of data you're collecting?
Do you plan to sell this data to third parties?
How should the API be represented?
PII information, those kind of things.
Then it becomes a very low effort for you in terms of balancing that work with your day job.
Welcome to the Software Misadventures podcast.
We are your hosts, Ronak and Guan.
As engineers, we are interested in not just the technologies, but the people and the stories behind them.
So on this show, we try to scratch our own edge by sitting down with engineers, founders, and investors
to chat about their path, lessons they have learned, and of course, the misadventures along the way.
Hi everyone, it's Guan here. Kelsey is back. So last year, we got to chat with Kelsey about
his career journey after he announced that he was retiring from Google. Like that conversation,
this one has two parts. In this first part, we dive deep into his experiences advising startups,
the frameworks that he's developed, funny
stories along the way, and how we can get started doing it ourselves. Without further
ado, let's get into the conversation.
Kelsey, super excited to have you back with us today. Thank you so much for joining again.
Happy to be back.
So how's retirement treating you, by the way? It's been a few months now.
I'm a junior retiree, so I don't know.
It's been less than a year.
And so when you retire, you kind of have, for me, I knew I wasn't going to do anything.
And so when I left corporate America, you know, aka Google, I knew what I didn't want to do.
I didn't want to do corporate emails.
I don't want to do quarterly planning.
I don't want to do those things.
And so what's left from my career is the speaking engagements, right? So I still,
I think I've probably done at least 15 speaking engagements since leaving Google. So that continues. Startup advisory. I know that's something we're going to get into on this
particular podcast, but also just my wife retired at the same time. And so we're done with the alarm clocks.
Don't need them anymore. I try not to have any meeting scheduled before 10 a.m. That way I can
just wake up naturally, a lot more walks, and it's just resetting. So spend more time talking to
family members on the phone. There's no need to rush because, you know, you have a lot more time
to do those things. We're getting together like how we want to travel but it's really just like reclaiming your time back and then just trying
to explore who you are minus the work profile and so i'm still trying to figure it out haven't
mastered it but i do have a lot more time on my hands which is great this might be a bit
inappropriate but like how's your relationship with your wife has changed
now that you guys have a lot more time? I've been married 18 years and my wife had her own career.
She worked at the district level for our school district. She's an executive director there. She
built her own career. She's seen a lot. She has a fantastic network of educators, people inside and outside the community. And she
also sits on some nonprofit boards. So she works on big systemic issues. So she has her own North
Stars. And I have my own North Stars. And I think as long as you have that, we know how to be
separate. We have our own busy schedules. So we appreciate that time together. So around the house, I like to clean.
I like to do the dishes.
I like to fold the clothes.
I like to sweep and vacuum.
So some of those activities,
there's really no tension around,
I prefer to do them.
I like the towels folded a certain way.
And I think for us, we all have our strengths.
And look, you've been married that long.
You know how to play off of each other, right? You know how to pick up the slack in one area
versus another. I do travel from time to time. She travels from time to time. And so I think as
long as you allow each other to be independent, have your own friend groups, your own networks,
I think that just, you need time apart. Some people have no time apart right you just got to look
across the room that person is still there go somewhere or you may just want to go to Walmart
and this person will like hey can I come with you it's like I just want to go to Walmart by myself
uh luckily for us we don't really have that it's, you know, we've really done a good job over the last 20 years establishing our own identities, our own career paths.
So when we do have time to watch Netflix together, that's a bonus, right?
So you appreciate that time.
So I think that's for us.
And again, she's not doing zero either, right?
She has boards she's on, the social causes that she works on.
I think it's one of these things where you got to have a
plan for your life. And I think the challenging thing, most people have delayed even thinking
about what life is outside of work. And so when work goes away, they're just like, what do I do
now? So luckily for us, we were well prepared going into this. I empathize with some of the relationship aspects you mentioned I
think I'll have to maybe cut out the parts where you sell like cleaning for
my wife because I don't let me let's do a sidebar on what cleaning means to me
okay some people look at cleaning is purely a chore and they try to avoid as
much as possible so if you have money, hire someone
to clean your house for you. If you don't have money, some people do this weird thing. The person
that's the least busiest, at least in their mind, they should do the bulk of the cleaning. You have
just different views on it. My views about cleaning is that it is a privilege to have the
things you have. It's a privilege to have dishes. It's a privilege to have a place to live.
It's a privilege to have a car.
And so when you wake up and you clean with patience,
you get to appreciate the things you have.
The refrigerator door isn't broken.
So when you wipe it down, it just gets to be clean.
It's just like when you take a shower, you brush your teeth.
Some people don't have all their teeth, right?
And so when you brush your teeth,
it's kind of like a moment of appreciation. I'm taking care of the things I own. And so the
other thing about clean, when I have the time to clean, that means everything else is in order.
I don't have any emergencies. I don't have somewhere else I need to be. I don't, some people
would argue there's a better use of your time. But to me, it's like, look, you spend all your time
acquiring all of this stuff.
Where do you find time to appreciate it?
And so for me, cleaning is
also that. And it's the thing, again,
maybe it's my psychology of it all,
but having the time
to just be calm,
clean, and look, if you've ever
walked into a clean house, whether it's
yours or someone else's, you notice it. As soon as ever walked into a clean house whether it's yours or someone else's you
notice it as soon as you walk into a clean space it feels refreshing like when you go out of town
and you get a nice hotel the first thing you notice when you walk in is how clean it is
if you ever got a hotel room that wasn't clean you immediately i can't stay here
right everything is off right i expect it to be. So I take the same attitude to my home
and I don't mind doing the cleaning. So that is my philosophy around cleaning. And it's the same
philosophy I had when I was writing code. I want the variable names to be a certain way. I want the
code to line up in a certain way. I want the comments to fit the style guide. And so it's just
one of these things that if you carry this attitude to all the tasks
that you do then that philosophy carries too so that's what i mean by clean it's not just
i like doing dishes because no one else likes it's like no i like the fact that i have these
things and i can show appreciation well that's so insightful because for the longest time so
i'm like super messy around the house but i would like to think that my code organization you know
is quite a bit
better and then for the longest time people are just very surprised it's like you know i look
around you know your shit is everywhere and now i'm realizing yeah i think i took those for granted
and didn't really like find it in me to actually appreciate yeah that's that's really well said
thanks yeah uh so last time you were chatting, you mentioned you were rebuilding your fireplace, I think, or at least you had already built your fireplace.
That was a new thing that you were learning.
Is there something that you're learning these days?
Yeah, I mean, again, I kind of appreciate the skills that you are necessary for the physical world.
When you're in the software world, right, software adventures, right, you think about software being a tool that can solve any problem
we can imagine. And it's largely true because a lot of these things in the digital realm,
it's like we just have this make-believe world with the ones and zeros, rule supreme.
In the real world, not so much, right? There are physical things like the way the water runs
through your house, right? Maybe software can
decide when hot water mixes with the cold, but there are still physical pipes, there's drywalls,
there's insulation, there's electricity, there's wires, there's standards around that stuff.
So I continue to kind of increase my knowledge around those things. Like, hey, how does
things work? The winter just came, right? So, you know, a couple months ago, we pretty much had below freezing temperatures and one of my pipes frozen.
This is a brand new house.
I'm like, oh, no, how can there be any issues in a brand new home?
And it turns out the pipe was frozen.
But before, I was willing to believe that because there's nothing you can do with that, right?
Maybe you can go try to warm it up, but depending on where the pipe is, you just have to wait. So number one, you realize
how valuable hot water is when you don't have it for two days. Number two, the first thing I did
as like this kind of engineer mind was what? I went to YouTube and said, hey, how do I troubleshoot
my water heater? I went outside. I have all my electrical testing tools, I'm testing circuit boards, checking filters,
looking at water levels.
I even did the whole back pressure thing
where you hook up the cold water line to the hot water line
and you try to flush the system
to make sure there's no air locks.
And then you go down this rabbit hole of like
all the physics to how water actually works, right?
So I went through this whole thing
and I realized like
none of that's the problem. And I just waited two days, the temperature rose to 35 degrees,
stayed that way for 10 hours. And then I just kept testing the water and the hot water came on.
And I was super excited, like, hey, put your hand right there. It's like, what? Like,
you see the temperature? That's hot water.
And so it's one of those things where these simple systems is what we all kind of rely on and take for granted every day.
And so just learning, look, I feel great.
Now I understand how that thing works, where the filters are, how it all flows together.
Now I understand how to winterize my home to make sure that I'm not suffering from frozen pipes in the future. So paying attention to the details
I live in Toronto and I've heard about sometimes having frozen pipes in the winter hasn't happened to us yet
But I've heard that one should be careful about this if that happens. I might send you an email
Asking for I'm gonna, get a blanket and wait.
Good advice, good advice.
So shifting gears a little bit, like you mentioned, you've been continuing a few things since Google,
one of those being startup advising. And we spoke about startup advising a little bit in the last time we talked.
And you shared a lot of details with us, which have been super helpful.
We wanted to rewind the clock a little bit
and actually talk about how did it first start
and how did you get into it?
The thing about startups is,
even if you worked at a startup, right,
you go, a lot of people take a discount on their salary
and you're promised equity in return.
Yeah.
All right.
And look, most startups don't make it.
When I say most, we're talking high 90 percentage don't make it.
So that equity is kind of like losing lottery tickets.
You don't even have to scratch them off.
They're just dead paper.
And so you do it anyway.
You believe in the mission.
And if it works, everyone gets a, hopefully a decent reward. If there's a great outcome for everyone. And so when you're an advisor, you believe in the mission, and if it works, everyone gets a hopefully a decent reward
if there's a great outcome for everyone. And so when you're an advisor, you don't work there,
right? So, you know, you have passive advising, some people will go get an advisor, let's say,
you know, you're building a system to improve 911 response times. And so if you're a startup doing
that, you would probably want to go get a chief of police to be on your advisory board, board. And they will give you some feedback about how you would sell to police departments and so forth.
Some people just need a figurehead.
If I just get the right person's name attached to my startup and we launch the website, everyone will recognize this person's name.
Even though we don't have a product, even though we don't have any customers, if we get the right name there, we'll get some buzz and people will join a waiting list for a product that doesn't exist. And then there's
another form of advisory, and that's the kind of advisory that I like to partake in. And maybe
there's other forms as well. I really like to be active. And so when I think about all the roles
that I had towards the end of my career, where you can make an impact by reviewing the product,
the go-to-market strategy, user empathy, the whole design, the whole feel.
And so for those startups, you know, for example, there's one startup I'm working with called Q Labs.
They're behind the Qlang configuration management or configuration language tool.
Very smart team, right?
You have ex-Google engineer Marcel used to work on the Go team for a long time.
He started the project based on all of his experience working on
Borg and all the configuration challenges at Google.
You have a guy named Pauly
there. He kind of runs a lot of
the business operations side.
And you have a guy named Dominique there. So those three
combined equal the stewards
behind the QLAN community.
And the hardest thing
of any open source, got all
the GitHub stars.
You have the big companies using your stuff, right?
This is good.
And so at that point, you've managed to figure out how to give away software for free.
Yeah.
Right?
And surprisingly, that's also hard.
Like even giving away software for free is hard.
Yes, it is. And so we spend a lot of effort doing that.
And then once a company gets to that curve, what does someone like me add value?
You say, hey, listen, you have to learn how to sell software.
What will people be willing to pay for?
Even if you're just 100% engineer, you have no sales team, you have no marketing team,
you have to learn how to sell that software.
So if you take any standard open source project, what's the number one thing you can sell before
you have a differentiated product? Probably service and support. No one likes it because
it's not product-led growth, but it is the actual reality. So if you've never done that before,
an advisor can come in and say, listen, to support some of the features your biggest enterprise customers are asking for, you can draw that up in a support agreement that lasts about a year.
That's enough to onboard the project, train the employees, and then stand behind it with an SLA.
And just knowing that kind of motion, at least on the sales side, that just comes from experience.
Then on the product side,
you look at what they're building, right?
Everyone's focused on the cool technology.
It's better than this other project.
But an advisor with experience comes in and says,
listen, people are currently using tool X, Y, and Z.
You cannot bring in this new project
thinking that they're just going to whole swell switch
from what they're currently using to the new thing. That doesn't work. So then what is the
advice you give there? Well, number one, what is the actual tangible strategy, right? And sometimes
that strategy is going to be in the form of docs. If you are using tool A, here's what our tool can
do for you. We have this overlap. Here's how we're
different. And here's how you have to use both until we get all the features to make the other
one obsolete. And then the decision making as a team, do we go in this market area or do we back
out and reverse course based on feedback? And so I'm really active. Sometimes I wear the product
manager hat. Sometimes I wear the sales rep hat. Sometimes I wear the sales rep hat.
Sometimes I'm just another engineer.
It's like, yo, why are you building your own packaging format?
You should just build this on top of OCI images,
push the standard repositories, and add your own media type.
And it's just wherever you can be helpful.
So that's my approach to startup advisory.
And the other thing I learned is I will never work for free, meaning I will never do startup advisory for purely equity.
We already talked about how high 90% of it will turn out to be nothing.
And so I don't want to be someone's figurehead to be on their website in promise for equity.
So I always charge a monthly retainer fee.
And the reason why that's important,
I think about it as dividends, right?
Because the impact you will have as an advisor,
if you're any good,
will probably be had in the first three
to six months of your advisory, right?
Hey, I think we should take this approach.
And look, any startup with good velocity,
they're going to take that advice
and turn it into something,
right? A new product change, a new website thing. Maybe there's going to be a webinar announcing the new feature set. And then the benefit will sometimes be rapid and immediate. And then at
that point, maybe you can do it one or two more times within that year. But at that moment,
your vested equity is rolled into that impact. And at that moment, your vested equity is rolled into that impact.
And at that moment, hopefully you're going to get something in return. So those dividends
kind of keep me honest, keeps them honest. And if that price is too high, it's my way of saying no
by saying yes. Yes, I can be an advisor, but here are the terms. And some people say, well,
we can't afford that. So, hey, no
problem. And maybe there's just not enough value that I'm providing that makes that worth it.
Interesting. On that note, one of my questions was, yeah, like, when do you say no to startups?
Like, in addition to the money, like, how do you tell when there's a bad fit in terms of the
advisor relationship? If there's a domain where I don't think I can add value, I like to just be very transparent.
Like if you came and say, hey, Kelsey, our startup is about data and analytics.
I can't add alternative value there, right?
I know some fundamentals just from working at Google Cloud for so long.
I have great common go-to-market strategies that I can bring to the table.
Maybe you have a team like your product team and you want to help them develop process,
or maybe the founder needs a little bit of support because it can be lonely when you're
trying to run a company you don't have anyone to bounce ideas off of. But that is not my domain of
expertise. And so in those moments, I would say, listen, I don't know how I'm going to impact and
shape this product.
I do have methods that might be applicable, but this is not a perfect fit for me.
And you may not necessarily get your value.
Or if I think the company needs to be spun down.
And I've done this before where, you know, I was presented with, I mean, probably 5x the type of equity I would ever ask for.
Plus the willingness to do the whole monthly stipend thing. And I looked at him and said, this is a very generous offer. It benefits me in the short term, even if it doesn't pan out in the long term. But to be honest, all things considered,
if I were in charge, I would be trying to spin this thing down. Here are the headwinds that I
can't, I can't even imagine how you would get through them. And so the best advice I can give, in this case for free, is that I will be very careful about this.
And typically this is the result of a company trying it.
They're in year six.
The runway is low.
They don't really quite have the product market fit.
They may not have the velocity. Because a lot of times when you look at these things, you talk to the team and you say,
what's the chance that if you got great advice, whether it's from me or for a customer, that you can even act on it?
And when I know that you can't even act on it and you're just trying to repackage something and just go to market, I can't be that rapper.
I can't promise that two tweets will send
everyone your way because I don't tweet for money, right? I'm very authentic with my audience. So you
rarely see me tweet about a company that I'm advising. And if I ever do, I try to be very
transparent. Hey, I'm advising this company. And here's something that I'm excited about that I
actually use. So that's the tricky thing. And I think there's just something you do to keep your reputation high.
When you tell someone no around those boundaries,
you tend to respect people
who are willing to leave money on the table.
And so I'm very fortunate that I'm able to do that.
And also, I just try to make sure that
if I can't think of one or two customers
at the top of my mind
who would use this product,
then I'm just not convinced because I've seen too much over the years that if I
you if you show me the thing you're working on and we go through the
iterate through the vision and I can't think of one company that I authentically
think that this could help I'm very weary on on taking a long-term advisory
engagement in those in those terms interesting and for someone
that's new to advising maybe like do you recommend some kind of like trial period just to see
right like how they actually work with the uh like the founding team and things like that
yeah so i think for founders if you're a founder bringing people on for advisory i think the
founder's job is to really understand what
this person can do. Because really, one advisor is only one input, right? You don't even need to
listen to them and assume that they're going to always be right. Sometimes just having that
outsider's perspective just balances things out, right? Because if you're a founder, you don't
probably ready to have 10 people on your team. Maybe you want to just keep the three and
periodically bring in advisors who you think can help you with that stage in that chapter.
Right? So for example, you know, we are now thinking about running our platform on our own.
We are now thinking about, I might bring in someone to help advise us on what it means to
think about DevOps, maybe talk us out of moving to Kubernetes on our own infrastructure.
And I think that point in time
could just be a very temporary one-off engagement.
I think the other part is like,
hey, we want a partner that's going to help live
with the decisions we make.
And that's very different, right?
So it's like, hey, you said we should leave Heroku,
put everything on Kubernetes,
and start hiring one or two engineers.
Okay.
All right.
We're going to do that.
What should the job postings look like?
Can you reach out to your network and recommend some people where that's going to have a high success rate to make that happen?
Hey, we noticed that the bill is 4X what we were paying before.
This doesn't look like a great decision right now. And an advisor that can be around for
that long term, live with the mistakes, it's a really nice way, I think, to kind of rent
an expert's time without necessarily being able to compensate them for their full time.
Now, on the other side, let's just say, here's the thing. If you have no experience,
you're two years into your career, you have to be very careful what advisory means.
There's a difference between advisory and consulting.
Some companies will say, hey, you got two years of experience.
You know how to write front-end JavaScript better than our team does.
We would like to bring you on as an advisor slash consultant.
Could you build a front-end website for us?
That's just staff augmentation
at that point you're kind of like a independent contractor building websites for startups
i'm not saying there's anything wrong with it but that's very different than being able to
leverage your expertise and give advice so i've learned that kind of the hard way like hey i'm
not here to build or write any code for your team. I'm here to make sure that when you decide to build and write any code,
that we're pointing in the right direction
and we're making the best decision possible.
And I think that does require a bit of experience,
like hands-on experience, lessons learned.
Because when you talk to founders and you're collaborating,
they don't want to hear pie in the sky.
They would like to say, hey, you know,
when I was at CoreOS, we launched this product, we put too much behind it, and it was really a
feature. It was a feature part of a larger product. And we should have had a better strategy about
revenue expectations, how it sat alongside the rest of the portfolio, how are we going to
deprecate? You know, I've worked at companies where we have to deprecate a product.
People don't realize that when you launch a product, there's no guarantee it's going to be around forever.
And so how do you set expectations with the community that, hey, listen,
there's going to come a time that we have to deprecate this thing.
And the last thing we want to do is mislead our customers, our community
into this belief that we're going to maintain
the thing that is obsolete for another
10 years. So how do you craft
that email? How do you anticipate
what people are going to say about you on social media
and on Hacker News, right?
The first time someone jumps on Hacker News
is like, oh, I hate
this company.
They stopped supporting this tool that only three
people in the whole world use. I hope they fail miserably. And the last thing you want to do when
you see that, you don't want your CEO or any engineers on the team jumping on Hacker News
arguing with this person. No, that's not what you want to do. You got to listen to that, right? You
got to take the praise and the criticism equally. You have to look at that decision and know that was part of the decision
that we had to make. We approached this decision with empathy. And this is the type of response
that we expect. And you may want to reach out to that person in private and say, hey,
here's an alternative. We did think through how this would disrupt your workflow
and give people some outs or an
opportunity to step up and contribute. So those are the kind of things that I think is really
good to think about when you say, I would like to go out and start doing this advisory work,
understand where you can make impact, and then understand when it's no longer in either of you
all's interest to continue working together and spin that thing down. And this is why most of my
advisory agreements are just for one year, right?
If I'm still the right advisor for you after one year,
then we can renew the contract and talk about terms.
And look, I'm so happy that I think the majority
of companies I advise, we're in like year three
or year four, where you continuously show value,
your advice is helpful.
And in startup world, they measure results pretty quickly.
You know, after three to six months, you know, it's like, hey, man, none of your advice is
panning out.
It doesn't work out.
There's been scenarios where people bring you on as an advisor and they never meet with
you at all.
And this is why I have to have that cash component because there's a cost to that.
Right?
If you never reach out, you never schedule any meetings, I don't necessarily chase people
around to meet with them.
That's on them.
And so those are just not really good fits, but you don't learn that until you're kind
of already in, paperwork has been signed, and they just don't know how to utilize an
advisor's time well.
And so, you know, that's another trade-off you have to think about.
It's interesting you brought
up the um like advising versus consulting um one of the questions i had was um i feel like a common
thing with consulting right is that you're building on your own or like you tell the team like hey you
know we need to be doing this and the team is like ha ha ha like you know i do not give two rats about
what you just said um so for on the advisor side, obviously, there's a lot more respect, right, to advisors just because they have deep expertise in the in the area.
But have you come across situations where like you're like, hey, you guys should really do this?
And, you know, they don't really follow on that.
And how do you sort of address situations like that?
One thing I learned that Google, I was never a manager
of any teams there. I was there almost eight years. And to be really impactful across teams
that you don't manage, that you have no authority over, you have to earn that respect and that
influence. And so if you recommend that, hey, I think the Spanner team should add a Postgres interface
because that's going to allow adoption from a different part of the market
that prefers open source Postgres protocol,
but they like the benefits of what Spanner has underneath.
So how do you approach that?
You can't just walk into the product meeting or update someone's OKR.
That's not going to happen.
What you have to do is say, hey, one thing I used to do is look at people's goals that
they've defined for themselves.
Not goals that you throw on their board, but the goals they define for themselves.
So let's take something like Spanner.
Imagine a world, and this is just hypothetical.
We would like to increase adoption.
And so the thing you do is say, hey, well, what's the current adoption?
Well, there are some people who really just know what Cloud Spanner is all about.
They get the trade-offs that it's not going to have the full SQL dialect.
There's going to be some latency things to get that global consistency.
But they'll do it anyway.
They'll rewrite their code.
They'll use the proprietary drivers and libraries.
And they just are willing to make that trade-off.
And you say, okay, well, what's the penetration for that?
You look at the numbers, it looks good.
So then you say, hmm,
who would be an ideal customer base
for a product like that?
Well, there's lots of companies
that agree with the architecture.
That's why they're in the cloud.
But they don't agree with the protocol.
They just can't see themselves
departing from their ORMs,
their workflows, the ability to test locally,
the ability to leave if it came to that.
And so you say, well, here's the thing.
If you had a Postgres interface, what does that unlock?
And then you have to be paying attention to the market.
CockroachDB has a Postgres interface, right?
All of these new databases have
come out with a Postgres compatible interface. And then look, luckily for me, given that I have
a social media audience, I can go and say, man, if Spanner added a Postgres interface,
it would be the Gmail of databases. And then people show up. Real people say, that's exactly right. I love
everything about Spanner except the protocol. And then that becomes evidence. And so then when the
product team sees all of this playing out in real time, right? You've made a recommendation
after listening. You've aligned with their existing goals, not creating new ones. You've shown public support.
And they do it.
And they ship.
And then people start to use it.
And now people are like, hey, what else you got?
And so I take the same approach with the startups.
You got to look at where they are and then really try to say, hey, I have to live with these decisions along with the team.
And when you plead your case,
I'm pleading the case the same way, not just I think. It's like, I know with high conviction
based on these things. And a smart engineer will draw the line and do the math and say, you know
what? That actually makes sense. I can go verify that. And I've been impressed sometimes. I'll
meet some new startups. I don't know much about their product.
They'll explain it to me.
And I'll say something like, this is great, but I can imagine for enterprise adoption, they want X, Y, and Z.
And you just see the founders be like, oh, my God.
We just had a customer that said exactly the same thing.
So I really try to approach this stuff with pragmatism.
And usually the advice you give isn't re-architect the whole thing.
It's more like, all right, if we're here, we need to focus on just this.
And then I think we move the needle and it sets us up for the next big bet.
That's really well said.
Now, when it comes to startup advising, like, as you mentioned, you have a social media audience.
And I don't know the exact timeline, but you're Kelsey.
And when I say that, I'm sure our listeners know what that means.
So startups know who you are, what value you bring.
At some point, they would reach out to you and say, hey, Kelsey, we think you can help us with X, Y, and Z thing.
When it first happened to you, how were you able to differentiate that,
oh, this is a new thing that someone's asking me for, but it's not the contract thing, for example.
It's not even a job.
It's actually this other thing.
How did you go about recognizing that?
You have to set the boundaries, right?
Because there is a status quo for what this stuff is, right?
Some people say, hey, you have an audience.
We want to tap into it, let's sign an agreement, and then you tweet on our behalf, right?
Because they kind of, in their mind, they know what they want, typically.
Sometimes you were a founder of another company.
Having you picture inside the slide deck is really good when you're trying to raise capital.
So there's already kind of set expectations for what most people think about advisors.
Also, I would guess most advisors aren't very active.
Most advisors are not going to download the product, touch it, and then give feedback about the serialization method or what it's going to really take for developer adoption.
And so you don't really expect that from an advisor because maybe you're going to want to get that from your team, your engineers, or someone else.
And so what I've learned that I had to do was say, multiples, pricing, go-to-market, customer, integration work, various challenges and trade-offs, that's when they start to say, oh, we didn't know that that's the things that you had available.
So what you say is, listen, I am not going to ever use social media to try to point a light at your company.
That's not what we're going to do.
What we're going to do is the things that we work on together that are worthy of talking about, maybe at my discretion, I will use that particular lane.
So you almost have to tell them, hey, after listening to you all, here's where I think I
can help. I offer this perspective. And look, my agreements, you can counsel whenever you want.
You can counsel next month. And so if it doesn't align, if you're not seeing any value, then you just turn it off.
And I'm not worried about someone turning it off because I believe I can offer the value.
So I think that is the main thing.
So I think you have to define your boundaries.
Hey, whoa, we're not going to do the standard advisory thing where I'm just kind of a name on some slide deck.
Let's make sure we talk about where I can be impactful. And let's
make that the core of the engagement that we do with each other. So whether people know that I
advise your company or not, the impact should flow through to the thing that lands in the customer's
hands. That's the type of engagement that I'm in search of. So look, if someone knows that I'm
involved in it adds value bonus, but if I can't impact the product, what am I doing?
So for engineers, you mentioned a few things that you provide value in.
And it's not just engineering in this case.
It's like go-to-market, like you said, thinking about customers, integrations, and a bunch of other things.
We have a lot of engineers in our audience who might be listening to this and saying,
well, I have worked in, I who might be listening to this and saying,
well, I have worked in,
I'm just going to pick a random topic,
let's say databases.
I've been working with databases for two decades.
I understand and have deep expertise,
but they don't necessarily, let's say,
have an audience of sorts.
They don't necessarily,
they're not enough people in the startup community who necessarily know them.
But they want to put themselves out there to start eventually at some point be able to advise companies or be able to
do this as something from a financial standpoint or just as part of their career. What are the
things engineers could think about to better place themselves in a position where they can
eventually start doing this? I mean, what you are doing today is not an overnight thing.
It takes a lot of time, experience, and expertise.
But what can engineers think about
in terms of doing that eventually they get there?
Let's use the DBA example, right?
So your database administrator,
I mean, you even know how to write code.
You can construct all the SQL queries, store procedures.
You know the data model better than anyone in the company.
You can help the BI, business intelligence team,
we're reporting.
You can help the Java developers write the best queries
that's going to map well to the garbage collector of the JVM.
Like, this is just your core.
And so if you think about being a very senior dba you're also an
advisor right you look at the explain plan and say hey this is the worst query i've ever seen
in my life what are you doing with all these inner drawings the data you need is right here
and so you go into advisory mode and you say, listen, we can get way more performance if we add an index here and here.
Right. How you what are you doing with this data?
How do you plan to use this data? Not just how you want to store it, but how you plan to use it.
So you go into advisory mode. The business is like, listen, Oracle is about to come here and do an audit.
We're going to go from onlywing Oracle $200,000 to $2 trillion. How do we prepare
for this audit? And you as an advisor would say, listen, we have way too many provision dev
databases. There is no reason every team needs their own database. We can store some of these
tables co-located. We can do things with users and permissions. You become an advisor, but then
there's a part where you can get proactive.
You can analyze the business itself.
Just being a DBA.
Hey, our storage is growing at 5%.
But most of it is doing nothing.
No one's reading it.
And so you start to rethink, like, hey, what are we doing?
Should we offload it to cold storage?
Should we think about a different sharding strategy? There's so many things you can do from an advisory
standpoint. And then think about when emergencies hit, the database is down. You're going to be an
advisor. Everyone is panicking. No one knows what to do. This is a crisis. And so any DBA that can
communicate, say, hey, here's what's going on. That root cause analysis you put in place, the safeguards, the data is safe, right? We back up checkpoint every 10 minutes. Worst case,
we're going to lose nine minutes of data. And this is what we're going to do to get back on board.
So let's say you've been doing that throughout your career. You're learning that to be an
engineer is more than, you know, installing databases and creating tables and setting up foreign keys.
You know that to be a great DBA, you're managing the data for the entire business.
The system of record is the heartblood of the whole thing, and you advise all the people around you.
And so there might be a time where you start proposing things like, we should move to Postgres
for some of our use cases because we're overpaying to have this data here.
So then when a startup reaches out to you, and a lot of times your initial advisory work
will come from a person you used to work with, right?
So one on the team, they jump out there and they start their own company.
So what do you do when you start your own company?
You start looking for people you used to work with, right?
And they say, hey, man, I'm going to work on a new social media company.
You're like, hmm, that sounds like
you're going to go out of business soon.
I am not quitting my job
to come work on a social media company.
You're not doing that, right?
Like, I need this job.
I like this job.
I like where I am.
I can't take this risk with you.
And so then there's this opportunity.
Typically, it's like, well, could you advise us?
And that's where you got to ask that question. Do you want a consultant where you want me to set up the database and design all the tables? Or do you want an advisor to really talk about
the type of data you're collecting? Do you plan to sell this data to third parties?
How should the API be represented? PII information, those kind of things. Then it becomes a very low effort for you in terms of balancing that work with your day job.
Also, you need to be careful.
There are some agreements that you have with your current employer that may not allow you to be a DBA for a startup on the side.
But in exchange for that advice, you may say, hey, look, just give me equity.
You know, maybe give me half a point,
maybe 1% if I stick around for a whole year and make an impact on helping you get off the ground.
I'll leave an advisor about how to bring in the right DBA
when the time comes,
so that way we can think about the interview process
and so forth.
So I think that is the right way to think about it.
So that will probably be your first pull.
There'll be someone that knows you know tech stuff.
It could be a nonprofit. Hey, we would like you to be on our advisory board and help us bring the technology
focus. And look, when you're starting out, you may not be able to demand a fair amount of equity.
You may not be able to demand that monthly stipend. But if you're just starting up and
you seriously want to add this to your portfolio of skills, there are so many
nonprofits that could use a technical advisor.
Maybe they're doing something nice in your community, sheltering, foster kids, whatever
it is, and they need help making technology decisions.
Go over there and practice giving great advice and living with those decisions.
That's a really good idea, actually.
In this case,
when someone starts doing this, for instance, or at least initially when you started doing this,
how do you balance the amount of time you spend advising versus your full-time job? Because
that could also be demanding and you're like, well, it's becoming two jobs almost. So you have
to draw those boundaries too. Should it be part of an agreement or is something you just figured it out?
Yeah, so what I did systematically was say, listen, here is my advisory schedule.
These are the only hours I have.
And that gives you a chance to really think through family time, work time.
And so maybe while you have a full-time job, a lot of your advisory hours will happen on the weekends or before and after work. These days, now that I'm retired, I tend to have my advisory hours from 10 to 3, never Monday,
never Friday. And so, you just decide what your calendar is and that creates transparency.
So, then when you, you know, in all of my contracts, I say, hey, three hours, use it or lose it. And
especially if you start doing more than a handful of these, like if you only have
one or two, you know, it's a little easier.
But I would even recommend then get an advisory calendar where you use counterly or whatever
you want, and then just carve out set advisory time.
And the reason why I like doing this is that the onus is on them to find a slot that works
best for them.
Your availability is constantly communicated.
So let's say things get a little heavy at work.
You delete those advisory hours
just for that one day that week.
Hey, I can't do anything this Thursday.
Just delete it.
And when they go to book time,
they'll just see that there's no availability there.
So it just makes it much easier to manage all of this
and just the ultimate transparency.
And the other aspect of this
from an engineering standpoint,
so after spending enough time with engineering,
people learn enough about their core domain
and they develop the expertise.
You mentioned the other aspects,
like go-to-market and thinking about
what the customers would want.
And the other aspect is like,
well, if you're trying to sell a piece of software
to an enterprise company,
they are going to care about a whole lot of other things
that probably the startup team is not even thinking about what's a good way for engineers to
learn the skill set where they start developing this perspective beyond engineering here's the
thing if you're an engineer you have to at some point understand like if you're like a real
engineer like a person who built bridges real people get in their car and drive over the bridge.
If you build a bad bridge, people will be swimming.
That's not what a bridge is designed for.
It's not a diving board.
They're supposed to drive over the water.
And so when you think about engineering, it is a people-led discipline.
We're typically building these tools for actual people. So parts of me just have been doing it
long enough to know you're only doing this stuff for people. So when we say requirements,
there's going to be a person using the system. And so you should almost start with that anyway. And part of like, hey, someone assigns you
a Jira ticket and says, hey, we want to drop down on the website and populate it with this
information. You could just take that, go to your framework, add it, you know, maybe the pixels get
put in the right place and then ship it. But in my mind, I'm thinking of who's going to use this? Is it
accessible? What are our accessibility requirements? Does it work with a voiceover tool for people that
may be visually challenged? Like there's so many things that goes into that decision.
What countries will use it? Should we have localization enabled or not? Because then you
start thinking about the people. If it's only US, then maybe you're fine with no localization enabled or not? Because then you start thinking about the people. If it's only U.S., then maybe you're fine with no localization, English only.
But if it's something that's going to be seen by every country, you know, some countries, they don't like dates organized that way.
It confuses people.
And so as an engineer, you're always thinking about those things.
So how do you get practice?
Just go do a one-week rotation into support.
Just go over there.
Hey, I want to work on some tickets.
And when you work a support role, they need an answer right now. And so as an engineer,
when you get an issue, like, oh, we can code that up. It's like, bro, we're not waiting for a new
release. You need to fix this now. So that means you may have to do some hacks. You may have to do
some workarounds. We're going to have to fix it now.
We don't get to wait.
And I think that's going to create a lot of empathy about how people actually use your product.
For example, let's be very clear.
Suppose you ship a new weather API, right?
Hey, we have this best API.
You just call curl, you do a post, you get back some JSON.
And you're like, this is the best.
We're done and the customer comes and
says well the tool i use only understands xml that's it we everything we do is xml you'd be
like dude why are you doing xml use json right just create some proxy and convert it to like
dude we're not doing that i'm the customer i don't have time for all of that. I need you to support me.
So now you start thinking about integration.
Again, who are our customers?
Well, all of our customers,
they use this one enterprise software package
that only takes XML as input.
So you'll have empathy.
You'll start saying, okay,
we should probably take the application type
when the client comes in, and we can do JSON or XML, and we'll just serialize at the last mile.
So then when you're advising startups, you say, hey, who uses your thing?
And then they say these things and say, hey, have you thought about what the onboarding process is going to look like for them?
The customer shows up on day one.
They log in.
They get a token.
Where do they put the token?
This is interesting.
Most of our clients are using Java.
You don't have a Java SDK.
But these are the things that I think even where you work in your current job,
if you understand the full life cycle of your product and service, you can start learning
this stuff. So in real life, that means log out, get a fresh incognito tab on your browser,
and create a new account for the thing you work on. Look at the onboarding experience. Is it good?
Is it terrible? Once you logged in, how do you do stuff? The work that you do, what does it impact
that overall product thing? And once you kind of? The work that you do, what does it impact that overall product
thing? And once you kind of start to understand that, you start to really understand how to look
at the big picture and know that localized decisions typically have big impact on the
overall product. I would add two things there. Like one aspect, one thing which I've noticed is
I'm sure most or at least the big companies,
big tech companies specifically, you see this in senior engineers directly, where they're not just
thinking about what is your API going to look like, but they're also thinking about who's going
to consume your API and how exactly. So you see this user empathy kicking in in the design
decisions, which in many cases, the team building
the API is not thinking about. So I think that's one thing which at least I've noticed in many
people around me. And that is something people can learn from each other as well. The other aspect
that you mentioned about support, I mean, if you want to know where the stack sucks, go on call for
a week. And in some cases, it could be direct customer support where you have real customers paying you.
In other cases,
it could be your internal teams
using your product.
And you're right.
They don't care about the next release.
They want the fix right now.
So really good way to put yourself
in the shoes of the customers.
Hey, thank you so much for listening to the show you can subscribe wherever you get your podcasts
and learn more about us at software misadventures.com you can also write to us at hello
at software misadventures.com we would love to hear from you until next time take care