Some reflections on running the podcast and Ronak has some eggciting news to share :)

Subscribe now

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

Oxide co-founders Bryan and Steve are back on the show to give an impromptu peek at the Oxide server rack and to chat about writing their own manufacturing software, overcoming false summits before shipping the first rack, the #1 reason startups fail and more. Don't miss the full-circle moment on their "meet cute" story from last time, shared at the end of the conversation :)

Subscribe now

Ronak & Guang’s Picks

#1 Make bad news actionable

When asked about how transparent one should be when delivering bad news to the team or investors,

Bryan: “So, you've got to love the bad news.

I've got good news and bad news. Everyone should want the bad news first. Like, give me the bad news. And we need to be in an organization, which includes our potential investors, on board with the idea that I want the bad news.

I want to know the bad news first. And you want to be able to give me enough context so that you don't induce panic in everybody all the time. But it's essential that we have the bad news and that you're transparent about it.”

Steve: “You've got to be transparent, but bring the bad news with one of two things: either a concrete ask of who you're bringing the bad news to, with some action you want them to take, or having already thought through mitigation options for the bad news. So, either come with a plan, like ‘here's the path we're going to be on, you don't need to take action,’ or ‘I need you to take action, and here's the action I need you to take.’ The worst possible thing you can do is just drop bad news on the table and say, ‘I don't know, we've got to figure it out.’”

#2 Put Me in Front of a Prospective Customer That We Have 0% Chance of Closing

Being curious is an essential skill, regardless of whether you're an engineer or in any other role. According to Steve, one practical way to develop this skill is to engage with customers directly.

Guang, who had attempted to do something similar early in his career while working at an enterprise SaaS company, recalled the pushback he received from management: "Don't put an engineer in front of the customer."

Steve: “If you find yourself in that same situation, there's an easy answer. Don't put me in front of a customer. Put me in front of a prospective customer that you think we have 0% chance of closing. Put me in front of someone that you think is a dead lead.

“I mean, if the person is non-responsive, it's kind of hard to get a conversation going. But who is someone we talked to that went with somebody else? I will tell you that an engineer has a much higher probability of getting a next conversation with that person than anyone in the sales organization.

“You've got credibility as an engineer. You can say, ‘Hey, I built the product. I'm reaching out because I would be deeply grateful if I could get any feedback about how you think about the problem space. We know that we're not going to be a fit for you, but it would be helpful to understand this.’

“You may have to reach out to four or five of these dead prospects to get one to agree to take a meeting, but oh man, you walk back with the information learned in that meeting and the CEO is like, ‘Where is he? We need him in the room right now so we can figure out what we did wrong in this case.’ You're going to get the other side of it. You're going to get why the customer didn't buy. And it may be product-related, or it may have nothing to do with the product. It may be something like, ‘Honestly, the rep didn't get back to me for seven days, and by the time they did, I was already down the path with this other person.’

“So, I would say that's an easy one because the sales organization thinks that lead is a 0% chance. So, why not? What's the harm? Nothing.”

Segments:

(00:00:00) The Oxide rack uncrating experience

(00:02:40) The office tour

(00:04:03) Challenges of shipping and unboxing hardware

(00:11:04) Hybrid hardware company?

(00:13:38) Custom designing a crate for the rack

(00:18:12) Optimizing for time to value

(00:20:43) Writing custom manufacturing software

(00:23:25) Taking ownership of the customer experience

(00:25:29) Buy vs build

(00:27:46) The false summits before shipping the first rack

(00:30:05) “Missing just enough context to be optimistic”

(00:33:07) The #1 reason startups fail

(00:38:49) Hiring the first sales role

(00:44:53) The dangers of “happy ears”

(00:47:18) The pitfalls of rushing to market

(00:51:03) The “third VP of sales” problem

(00:56:06) The value of a good sales leader

(01:00:07) Curiosity and empathy in sales

(01:03:41) Grooming sales skills as an engineer

(01:07:33) Learning from current customers

(01:09:13) Talk to prospective customers “that we have 0% chance of closing”

(01:11:25) Actionable bad news

(01:14:11) The role of GPUs in data centers

(01:18:50) Cloud repatriation

(01:24:23) Full circle to the “meet cute”

Show Notes:

• Our previous convo: https://softwaremisadventures.com/p/oxide-ditching-the-rules

• Bryan on Twitter: https://x.com/bcantrill

• Steve on Twitter: https://x.com/sdtuck

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

Known for co-creating Django and Datasette, as well as his thoughtful writing on LLMs, Simon Willison joins the show to chat about blogging as an accountability mechanism, how to build intuition with LLMs, building a startup with his partner on their honeymoon, and more.

Subscribe now

Ronak & Guang’s Picks

#1 Writing as an Accountability Mechanism

“My blog has been an accountability mechanism for me for a while now. Because I'm independent, I don't have an employer, so I started doing this thing I call week notes. Every two or three weeks, I post a blog entry saying, 'Here are the things I've worked on in the past couple of weeks.'

That means that when I'm thinking about what to do, occasionally I'll think, 'You know what, I haven't done anything I can write about yet.' So I should really invest in one of my open-source projects or do something so I've got something to show for it. And yeah, I love that. I think writing is thinking, and it's a great way of forcing you to structure your thinking. You know, if the best way to learn something is to try and explain it to somebody else.

So if you've got a blog, even my shortest little link blog things - where it's just a link and two sentences of text - I always try and put something valuable in there. Partly it's to prove that I read the thing I'm linking to, but also it's to add something extra from my perspective on it.

It might just be saying, 'This is related to something else.' For example, when I wrote about Claude's prompt caching, I linked back to Google Gemini, which has a similar feature. I could compare how Google Gemini pricing works and how Claude pricing works. That's a little bit of extra perspective that you won't get from Anthropic. They're not going to write about Google Gemini in their announcement of a feature. So it's that kind of thing - forcing you to engage with the material just a tiny bit more thoughtfully, so that you can try and say something interesting about it as well as linking to it.”

#2 LLMs aren’t actually easy to use

“The problem with LLMs is that they're actually really difficult to use, which is very unintuitive. Everyone assumes they're easy because it's a chatbot - you type things to it, and it responds. But to use them effectively, you need to build a really deep model of what they can and can't do.

For example, I would never ask an LLM to count all the instances of something in a paragraph, because I know they can't count. Which is totally non-obvious, right? It's a super sophisticated computer system. How can it not count? Computers are great at counting; that's what they've been doing since we invented them.

I know that if I have a question that a friend of mine could answer by reading a Wikipedia page, then I know the LLM will be able to answer that question. But if it's the kind of thing that the Wikipedia page probably won't cover, it's less likely that the LLM will be able to answer it. The challenge is that you really do have to put in the time. A friend of mine says that 10 hours is the minimum you need to spend with a GPT-4 model before it really starts to click - before you understand what these things are and how to use them. And I think that's what it takes to develop the level of expertise where I can look at a prompt and, 90 percent of the time, correctly predict whether it will work or not.”

Segments:

(00:00:00) The weird intern

(00:01:50) The early days of LLMs

(00:04:59) Blogging as an accountability mechanism

(00:09:24) The low-pressure approach to blogging

(00:11:47) GitHub issues as a system of records

(00:16:15) Temporal documentation and design docs

(00:18:19) GitHub issues for team collaboration

(00:21:53) Copy-paste as an API

(00:26:54) Observable notebooks

(00:28:50) pip install LLM

(00:32:26) The evolution of using LLMs daily

(00:34:47) Building intuition with LLMs

(00:43:24) Democratizing access to automation

(00:47:45) Alternative interfaces for language models

(00:53:39) Is prompt engineering really engineering?

(00:58:39) The frustrations of working with LLMs

(01:01:59) Structured data extraction with LLMs

(01:06:08) How Simon would go about building a LLM app

(01:09:49) LLMs making developers more ambitious

(01:13:32) Typical workflow with LLMs

(01:19:58) Vibes-based evaluation

(01:23:25) Staying up-to-date with LLMs

(01:27:49) The impact of LLMs on new programmers

(01:29:37) The rise of 'Goop' and the future of software development

(01:40:20) Being an independent developer

(01:42:26) Staying focused and accountable

(01:47:30) Building a startup with your partner on the honeymoon

(01:51:30) The responsibility of AI practitioners

(01:53:07) The hidden dangers of prompt injection

(01:53:44) “Artificial intelligence” is really “imitation intelligence”

Show Notes:

• Simon’s blog: https://simonwillison.net/

• Natalie’s post on them building a startup together: https://blog.natbat.net/post/61658401806/lanyrd-from-idea-to-exit

• Simon’s talk from DjangoCon: https://www.youtube.com/watch?v=GLkRK2rJGB0

• Simon on twitter: https://x.com/simonw

• Datasette: https://github.com/simonw/datasette

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

A Silicon Valley veteran and known for his writings like "The Death of the Junior Developer", Steve Yegge joins the show to chat about his "AI Midlife Crisis", the unique writing process he employs, and building the future of coding assistants.

Subscribe now

Ronak & Guang’s Picks

#1 Even Great Writing Can Take a Long Time to Get Recognized.

Steve's tech rants journey began as an early engineer at Amazon. Upon accumulating many posts there, he published them online after leaving for Google.

Instant success?

Nope. “Nothing happened for six months.”

“So actually, my biggest piece of advice to you is, if you're going to write something big, write it. But then don't expect anything to happen for a few months. It takes time for people to absorb.”

“Six months later, on the nose, all of a sudden, people started walking up to me at Google, going, ‘Yo, I read your blog.’ And I'm like, ‘Well, which one?’ And they'd name one. ‘Oh, okay, weird.’ And then somebody else the same day would be like, ‘I read your blog.’ And I'm like, ‘Yeah, which one?’ And they named a different one. And I'm like, ‘What's happening?’”

“Right. And it was that somebody had found them, and they made Hacker News, and people were reading all of them, all the old Amazon rants. So at that point, I guess I'll keep going.”

#2 The Key to Perseverance in Writing? Get Pissed.

Given that writing on the internet can feel like shouting into the void sometimes, we were curious about what kept Steve going during the many dry spells he's mentioned.

“What keeps me going is I eventually get pissed off enough about something. And I'm like, all right, I'm riled. And that's what I know: I'm going to write that. It's going to be good, right?”

“Because I'm heated, right? But I'm also kind of snarky. So then the jokes start flying, right? Because I've seen it. And so that's the formula, right? You think about it, you let it rattle around, you let it bake. And then at some point, you get yourself worked up until you're in LLM generation mode, and you whip the whole thing out at once.”

Segments:

(00:00:00) The AI Midlife Crisis

(00:04:53) The power of rants

(00:09:55) “You gotta be able to make yourself laugh”

(00:11:46) Steve's writing process

(00:14:10) “I published them… and nothing happened for six months”

(00:17:30) Key to perseverance in writing? Get pissed.

(00:23:24) Writing in one sitting

(00:29:05) The AI Midlife Crisis

(00:35:04) Management to IC

(00:38:35) The acceleration and evolution of programming

(00:41:43) Picking up new skills in a new domain

(00:43:40) The power of prompt engineering

(00:47:27) Secondary hashing

(00:50:47) The importance of context in coding assistants

(00:53:56) “The future of coding assistants is chat”

(00:57:15) The importance of platforms in coding assistants

(01:02:30) The nefarious T-word in AI

(01:06:32) The death of the junior developer and its consequences

(01:09:35) The future of code understanding and semantic indexing

(01:13:15) The power of context in AI platforms

(01:16:21) Surprising capabilities of LLMs

(01:21:04) Transferable skills in AI product development

(01:23:53) Mental health and the innovator's dilemma

Show Notes:

• The Death of the Junior Developer: https://sourcegraph.com/blog/the-death-of-the-junior-developer

• Steve’s blog rants:

  https://steve-yegge.blogspot.com/

• Steve’s medium posts:

  https://steve-yegge.medium.com/

• Sourcegraph’s blog: https://sourcegraph.com/blog

• Steve on twitter: https://x.com/steve_yegge

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

A veteran of early Twitter's fail whale wars, Dmitriy joins the show to chat about the time when 70% of the Hadoop cluster got accidentally deleted, the financial reality of writing a book, and how to navigate acquisitions.

Subscribe now

Ronak & Guang’s Picks

#1 What does your manager do when your team accidentally takes out the Hadoop cluster?

As he wrote the emails to update the company on the status, Dmitriy thought he was going to get fired. While it wasn’t him who deleted the cluster, he was managing and responsible for the team’s actions.

But instead, his boss told him, “#1, this happens, don't worry about it. I've got you. And #2, eventually this was going to happen. It doesn't feel like it right now, but it's going to be such a relief that this happened now and won't happen anymore in this company than if it had happened three or four years from now.”

#2 “Pressure makes diamonds”

Having joined Twitter early in 2010 to help build the data platform, Dmitriy found himself on an engineering team that was constantly putting out fires caused by explosive user growth. But it was also through these firefighting efforts that the team was able to build grit and camaraderie.

“Later, I heard people say that the joke was that I love hiring ex-Twitter people because, no matter how much everything is exploding, they just go, ‘Eh, I've seen worse,’ because things were really, really bad.”

“But also, sometimes the worst times are the best times.”

Segments:

(00:00:00) The infamous Hadoop outage

(00:02:36) War stories from Twitter's early days

(00:04:47) The fail whale era

(00:06:48) The Hadoop cluster shutdown

(00:12:20) “First restore the service then fix the problem. Not the other way around.”

(00:16:16) The importance of communication in incident management

(00:19:07) That time when the data center caught fire

(00:21:45) The "best email ever" at Twitter

(00:25:34) The importance of failing

(00:27:17) Distributed systems and error handling

(00:29:49) The missing README

(00:33:13) Agile and scrum

(00:38:44) The financial reality of writing a book

(00:43:23) Collaborative writing is like open-source coding

(00:44:41) Finding a publisher and the role of editors

(00:50:33) Defining the tone and voice of the book

(00:54:23) Acquisitions from an engineer's perspective

(00:56:00) Integrating acquired teams

(01:02:47) Technical due diligence

(01:04:31) The reality of system implementation

(01:06:11) Integration challenges and gotchas

Show Notes:

• Dmitriy Ryaboy on Twitter: https://x.com/squarecog

• The Missing README: https://www.amazon.com/Missing-README-Guide-Software-Engineer/dp/1718501838

• Chris Riccomini on how to write a technical book: https://cnr.sh/essays/how-to-write-a-technical-book

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

Known for hosting the CoRecursive podcast, which dives into the stories behind the code, Adam joins the show to chat about discovering that the great engineers he had looked up to are actually great communicators, his framework for building one of the best storytelling engineering podcasts, and the journey getting into DevRel.

Subscribe now

Ronak & Guang’s Picks

#1 The most well-known engineers don’t always write the best code, but instead, they excel at sharing their ideas

“I don't know why I wanted to be the best engineer. There were all these people that I looked up to at that time, like Joel Spolsky, and I wanted to be that great. But if you think about it, the reason we know about them is because they're actually great communicators, right? They're explaining problems to us.”

“I thought this guy had a blog because he was the most amazing engineer. But no, I know about the things he's done because he talks about them. All these people I looked up to, what they're actually good at is communicating. The person who wrote the book that I wanted to ask questions about, on how to do functional programming, it's not clear they were the best functional programmer in the world (hopefully, they were decent at it), but no, they had written a book. They had spent a lot of time communicating.”

“It can be super impactful if you can take something and explain it in a way that lets it crystallize in people's minds. And I don't know if I'm the best at it, but it feels very valuable and important.”

#2 To improve in a nascent domain, borrow knowledge from more mature, adjacent fields

Podcasting is a relatively new field with limited resources on how to produce high-quality episodes. Instead, Adam turned to radio journalism, which is a much more established field with a wealth of resources and a significant overlap in skills with podcasting. Specifically, Adam took classes offered by the Independent Association of Radio Journalists, and those paid huge dividends in elevating the quality of the podcast.

Chapters:

(00:00:00) Highlights

(00:04:23) The power of casual conversations

(00:07:08) Taking the leap into podcasting

(00:10:34) The hardest part of running a podcast

(00:14:03) Learning to follow up

(00:16:26) Storytelling in podcasting

(00:20:36) The evolution of CoRecursive

(00:21:19) What makes a good story?

(00:24:48) Finding the right guests

(00:30:26) Preparing for interviews

(00:32:07) Favorite part of making a podcast episode

(00:37:43) Learning from radio journalists

(00:39:47) Overcoming self-doubt

(00:44:27) Balancing passion projects with full-time work

(00:46:38) The power of vulnerability in storytelling

(00:53:29) Behind the scenes of developer relations

(01:00:38) the great engineers you know are actually great communicators

Show Notes:

• Adam on Twitter: https://x.com/adamgordonbell

• CoRecursive Podcast: https://corecursive.com/

• Automating follow-up emails: https://www.followupthen.com/

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

As the original architect and API design lead of Kubernetes, Brian joins the show to chat about why "APIs are forever", the keys to evangelizing impactful projects, and being an Uber Tech at Google, and more.

Subscribe now

Ronak & Guang’s Picks

#1 “API versioning *conceptually* exists”

While many aspects of software engineering are iterative, Brian makes the point that often you only have one shot to get things right when designing APIs.

“One thing that happens is you have to get stuff right in the beginning, or you can't change it because it's too expensive—that it's not worth it. It's kind of sad because it's like a wart on the side for all history, but the ecosystem of stuff that's been built, and everybody's configurations that are using the current API, is just too large for it to be worth changing.”

For a project as complex as Kubernetes, and as it evolved over the years to support huge clusters and broad use cases, it's no small feat that the architecture and APIs haven't significantly changed since the 1.0 release. And one big reason for this foresight in design comes from the lessons Brian learned building and running Borg and Omega at Google.

#2 The keys to evangelizing a project

Throughout his career, Brian has been consistently good at proposing and evangelizing new projects that have had a significant impact. Here are the keys to making it happen:

The environment matters: Unlike a company culture that's top-down driven, customer-focused, or revenue-driven, having a strong bottom-up engineering culture makes it easier to propose initiatives as an engineer.

Before working on Borg, Brian identified the subproblems, wrote documentation, and started an education program to evangelize moving all the C code at Google from single-threading to multi-threading.

Build trust and start with a prototype: “If you come in from the outside to the company or to the organization and you propose an idea, there's less trust in your judgment, then you have to make a much stronger case.

You have to find business metrics, and it may be very difficult to get concrete data, or you may need to do experiments first to get the data. So, there may be a chicken-and-egg scenario.”

Leading up to the creation of Kubernetes, the unified compute working group was formed at Google, which brought in folks from cloud and Borg to discuss “if one was going to build a cloud product like Borg, something Google could use, what would that look like?” After working on this for a few months, Brian presented the initial API design, and Brendan built a prototype for it that eventually led to the open-source proposal.

Be a good role model: “Everybody saw me writing all these sections of the user guide. I didn't get pushback from anybody asked to write a section—not even a single person. So, if you show people that you think it's important enough that you're going to spend your time on it, that seems to work.”

Segments:

(00:03:01) Internship with Mark Ewing

(00:07:10) “Mark and Brian's Excellent Environment” manual

(00:11:58) Poker on VT100 terminals

(00:14:46) Grad school and research

(00:17:23) The value of studying computer science

(00:21:07) Intuition and learning

(00:24:06) Reflecting on career patterns

(00:26:37) Hypergrowth and learning at Transmeta

(00:28:37) Debugging at the atomic level

(00:34:27) Evangelizing multithreading at Google

(00:39:56) The humble beginnings of Borg and Kubernetes

(00:47:10) The concept of inertia in system design

(00:50:07) The genesis of Kubernetes

(00:53:45) The open-source proposal

(00:57:25) The Unified Compute Working Group

(01:02:16) Designing the Kubernetes API

(01:05:03) AIP.dev and API design conventions

(01:08:02) The vision for a declarative model in Kubernetes

(01:17:25) Kubernetes as a DIY platform

(01:19:07) The evolution of Kubernetes

(01:21:40) The complexity of building a platform

(01:25:11) Style guides?

(01:28:23) Gotchas in Kubernetes workload APIs

(01:32:02) Understanding your thinking style

(01:35:37) Reflections on Kubernetes design choices

(01:44:08) The importance of getting it right the first time

(01:48:13) Designing for flexibility

(01:51:16) Collaboration and leadership

(01:52:21) The role of an Uber tech lead at Google

(01:56:33) “Giving away the Legos”

(02:02:29) Picking the right person to hand off

(02:06:41) Overcoming writer's block

Show Notes:

• API Design conventions: https://google.aip.dev/

• Brian’s blog: https://medium.com/@bgrant0607

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

From building a new kind of server to building a new kind of company, co-founders Bryan and Steve join the show to chat about their "meet cute" and the origin story of Oxide, their unconventional recruiting process, transparent and uniform salaries, and their solution to the "N+1 shithead problem".

Subscribe now

Ronak & Guang’s Picks

#1 Everyone at Oxide makes $201,227 USD

For a company with more than 50 people, this is pretty nuts.

Interesting follow-ups that we chat about:

• For roles that are traditionally paid less (i.e., Support), you can easily attract the best in class, but what about roles that are paid higher?

• Uniform compensation does away with levels; how do you track your performance when there are no levels?

• How does this change the recruiting process (no negotiations)?

#2 Asking every candidate the happiest and unhappiest moment in their career

Early in Oxide's interview process, candidates fill out a set of questions that include:

• What was the happiest moment in your career? and

• What was the unhappiest moment in your career?

Reflecting on the answers that Bryan has seen throughout the years, "all the unhappiest moments basically all rhyme with one another. All the unhappiest moments are basically [where] the people who were responsible for execution knew the right thing [that needed] to happen, and bad leadership, bad management was preventing it from happening."

On the other hand, "the happiest moments are way more interesting and can be way more difficult. For me, the happiest moments of my career are when the extraordinary team comes together to do something really special. Those happiest moments definitely vary for people, but they're very revealing when they talk about those happiest moments."

The cool part about these questions? Before the interview, as the interviewee, you get to see the interviewers' answers from when they interviewed 🤯.

Segments:

(00:03:03) Bryan and Steve's "meet cute"

(00:05:56) "the sun does not shine on me"

(00:12:19) the dagger that went into sun

(00:21:23) culture of exonerating yourself vs solving customer problems

(00:23:25) the shared "error in judgment" of joining joyent

(00:27:54) the origin story of joyent

(00:29:44) reporting to the (physical) chair

(00:31:26) the comically bad ceo candidate

(00:36:23) the enterprise software shift

(00:40:21) the importance of curiosity in sales

(00:48:30) filtering for curiosity in hiring

(00:52:26) oxide's unconventional hiring process

(01:04:01) bryan's worst hire

(01:05:21) the limitations of traditional hiring

(01:08:32) the value of written reflections

(01:10:28) "what were the happiest moments in your career?"

(01:21:16) misconceptions about sales and go-to-market

(01:22:03) trust and alignment in sales

(01:30:24) building connections across organizations

(01:34:23) how to do performance reviews when everyone's paid the same?

(01:40:00) the power of transparency in compensation

(01:50:14) validation through impact

(01:53:14) origins of on the metal

(01:55:45) transparency and open communication

(02:01:32) the importance of storytelling

(02:04:56) building a company differently

Show Notes:

• Bryan’s blog post on the transparent and uniform compensation model at Oxide: https://oxide.computer/blog/compensation-as-a-reflection-of-values

• On the Metal’s interview with Jeff Rothschild: https://share.transistor.fm/s/6fa1eaa4

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

From building the data platform and Parquet at Twitter to using AI to make biology easier to engineer at Ginkgo Bioworks, Dmitriy joins the show to chat about the early days of big data, the conversation that made him jump into SynBio, LLMs for proteins and more.

Subscribe now

Ronak & Guang’s Picks

#1 The value of a CS education in 2024

With recent articles proclaiming the end of junior devs (replaced by LLMs), Ronak and I find our friends asking the question of whether it's still worth it to study computer science in undergrad.

Dmitriy makes the argument for why he still remembers CS 170, a class he took almost 24 years ago: "These days, I barely write any code, but having a background in computer science is hugely valuable for my job as a VP or manager, right? Because, like, I need to understand what's going on. I need to understand how systems work together. In fact, organizations or systems. And if you understand distributed systems and how they interact, right, like with a little bit of transformation, you can start thinking about the organizations, how they direct, and how to build that system. So I think systematic thinking is still critical, and you're not going to get that from, like, ChatGPT, right?

Like, you can have ChatGPT do some routine work for you and incorporate that into a creative process. But the actual thinking about what needs to happen and why it needs to happen, right? You need to have your brain prepared to be able to do that. And to me, the CS curriculum is a really good one for that."

#2 AlphaFold2 was an “AlexNet” moment for Biology

"AlphaFold2 was a major moment for biology - it didn't solve protein folding, but it was a massive leap forward, like the AlexNet moment in the AI world, where the game changed, right? What was impossible before became fairly straightforward now, and you don't have to be an expert."

But just like AlexNet, showing the possibility of a solution doesn't mean solving the problem - "Immediately, it was like, well, yes, that problem is solved, but that's not actually the problem we care about. What we actually care about is designing a drug that's going to be expressed only in the liver and is going to pass all the phase three trials and whatnot, and not have any side effects or unpredictable side effects, et cetera. Can AlphaFold give me that? The answer is no, it can't. It tells you how the thing folds."

Segments:

(00:03:18) Data engineering roots

(00:05:40) Early influences at Lawrence Berkeley Lab

(00:09:46) Value of a "gentleman's education in computer science"

(00:14:34) The end of junior software engineers

(00:20:10) Deciding to go back to school

(00:21:36) Early experiments with distributed systems

(00:23:33) The early days of big data

(00:29:16) "The thing we used to call big data is now ai"

(00:31:02) The maturation of data engineering

(00:35:05) From consumer tech to biotech

(00:37:42) "The 21st century is the century of biology"

(00:40:54) The science of lab automation

(00:47:22) Software development in biotech vs. consumer tech

(00:50:34) Swes make more $$ than scientists?

(00:54:27) Llms for language is boring. Llms for proteins? that's cool

(01:02:52) Protein engineering 101

(01:06:01) Model explainability in biology

Show Notes:

• Tech and Bio slack community: https://www.bitsinbio.org/

• The Death of the Junior Developer: https://sourcegraph.com/blog/the-death-of-the-junior-developer

• Dmitriy on twitter: https://x.com/squarecog?lang=en

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

Having quit Google in 2018 to bootstrap indie software businesses, Michael is known for writing very transparently about the ups and downs of his journey. After recently selling his hardware business TinyPilot for $600K, Michael returns to the show to chat about the misconceptions about running an indie business, the hardest part of selling a company, and why “hardware is definitely out” for his next move 😂

Subscribe now

Ronak & Guang’s Picks

#1 The biggest misconception about running an indie software business

“is how great it is.”

“I met a guy at a meetup a couple of years ago, and he was like, ‘We've got a lot of users, they seem really enthusiastic, but like, we're just not making money, so I think I'm just going to give it up and like, go back to working for a big company.’”

“And the way he was talking, he sounded so grizzled and distraught that I was like, ‘Oh man, he seems like he's been at it for like five years or something, he's so burned out.’ And I was like, ‘How long have you been doing this?’”

“And he was like, ‘Three months.’"

😂😂😂

Needless to say, having built a product and gotten real users in only three months is actually way above average - it took Michael 2 years before building something that had traction.

As Michael points out, "there's this kind of Instagram effect where there's a heightened reality that people present online. And I meet people at meetups who want to start an indie business, and their expectations are so high for what it's going to be like. They hear these stories about people quitting their jobs. And six months later, they're making a hundred thousand dollars a month from some SaaS business."

#2 Value Created vs. Value Captured

Which kind of work would you pick?

• Work #1: You create $2M in value for the company and you're paid $400k.

• Work #2: You create $200k in value and keep all of it.

Michael makes the case for picking the latter: "Another big thing that I really like about being an indie founder is knowing that there's not this distinction between the value that you create and the value that you get to capture."

"That was a really frustrating part of working for Google - not so much the value, but feeling like the gap in incentives. Like, a lot of times the thing that was right for me at Google was not the thing that was right for my team or for the company. And I didn't like having to choose between, 'Do I do the right thing to help my teammates or do I do the right thing for my career?'"

Segments:

(00:04:22) The complexity of selling a hardware business

(00:08:49) Why "hardware is definitely out" for Michael's next venture

(00:11:57) The evolution of TinyPilot

(00:16:29) Inherent risks of a hardware business

(00:20:53) The most terrifying 10 minutes of 2023

(00:24:52) The pricing strategy

(00:31:48) Building the team

(00:35:32) Recognizing the limits of solo founders

(00:37:22) What and how to outsource?

(00:42:45) Tracking hours and managing expectations

(00:46:50) High-level math and profit projections

(00:52:17) Working with contract manufacturers

(00:54:12) How to know when to delegate?

(00:58:16) Misconceptions about running an indie business

(01:03:56) The importance of value capture

(01:09:26) Identity and purpose after selling a business

(01:13:40) How Michael arrived at the decision to sell the business

(01:17:53) The process of figuring out the price

(01:20:36) Negotiation and the final sale

(01:25:09) Why due diligence was so stressful

(01:30:09) The importance of buyer fit

(01:34:16) Michael's new course "Hit the Front Page of Hacker News"

(01:35:17) The power of "Show, don't tell"

(01:38:14) Sneak peek of the course

Show Notes:

• Michael’s blog post on the process of selling TinyPilot: https://mtlynch.io/i-sold-tinypilot/

• Michael’s excellent monthly retrospectives on building TinyPilot and beyond: https://mtlynch.io/retrospectives/

• Hit the front page of hacker news: https://mtlynch.io/notes/htfp-live/

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

Well-known for his insightful and meticulous write-ups on testing distributed systems, Kyle (aka Aphyr) joins the show to chat about the origins of Jepsen, how he built a business around testing distributed systems, his writing process, favorite databases, and more.

Subscribe now

Ronak & Guang’s Picks

#1 Key to being a better writer is to reduce filter

Like many, I want to write better and, more importantly, write more often, but have a hard time starting. Kyle's pro-tips: "This is obviously not great advice, but some people say get drunk; maybe have a gummy – the idea is to reduce your filter. You want to get yourself in a state, whether sober and just doing it emotionally or with your favorite whiskey in hand, of being able to just spew thoughts onto the page and then refine. Uh, but if you're struggling to get over the hump, I find that often the challenge is you're trying to get everything perfect upfront. And I like to think of writing as a tool for thinking, and nobody else is going to see your bad draft; you can always throw it away."

I'm gonna give this a try with a PBR next time 😏

#2 Finding a pricing model that works

Pricing is hard, especially for a consulting business where hourly-based pricing is too open-ended for the clients and project-based pricing is too risky for Overruns. Kyle puts it well - “In the software world, numbers are insane. Nobody knows what anything costs. Any figure you quote is going to be both 10X less and 100X more than two different clients are willing to pay”.

The issue Kyle ran into earlier on was that “I didn't anticipate that I would spend so much time doing lead acquisition and bookkeeping. And also that when you charge less and you do sort of piece work, such as 30 minutes here, two hours there, clients will want you to work for an hour here and then three hours next week and two hours next week. And it should all be on their schedule. And what you end up with is a work week that contains like 10 hours of actual work.” This led to Kyle significantly undervaluing his labor.

The solution? “Rather than offer an hour here an hour there, you engage me for a number of weeks and we can decide how many that is. You could say, 'Okay, next week is our last week.' That's great. Or you could say, 'I want to extend.' That's great. But you're buying a whole week of time. And then I can really sink my teeth into the problem, have all the context I need, and, ideally give you a good result.”

Segments:

(00:03:29) From Physics to Software Engineering

(00:07:47) The origins of Jepsen

(00:09:41) Turning Jepsen into a full-time venture

(00:13:14) Jepsen's testing philosophy

(00:16:30) The consulting journey

(00:19:16) Structuring a consultancy

(00:22:32) Setting boundaries

(00:24:32) Pricing misadventures

(00:29:17) Pros and cons of being an independent consultant

(00:32:08) Managing your time when working for yourself

(00:38:23) Best part of the job

(00:41:13) Early writing influences

(00:45:25) LLMs and AI-generated content

(00:48:17) “The period where you can trust what you read is actually very recent”

(00:51:33) How to become a better writer

(00:54:25) Developing a formal understanding of distributed systems

(00:59:30) Common faults in distributed systems

(01:01:17) The complexity of testing distributed systems

(01:07:32) Communicating criticism effectively

(01:10:26) Advice for distributed systems engineers

(01:13:46) “Anybody trying to sell you a distributed lock is selling you sawdust and lies”

(01:16:31) Failure mode documentation

(01:18:52) The pitfalls of containerization

(01:20:17) Lightning round - favorite databases

Show Notes:

• “Anybody who is trying to sell you a distributed lock is trying to sell you sawdust and Lies”: https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

• Kyle’s excellent write-ups on testing distributed systems: https://jepsen.io/analyses

• Kyle’s blog: https://aphyr.com/posts

• Training courses that Kyle runs: https://jepsen.io/services/training

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

From creating one of the Python’s most influential libraries to co-founding Voltron Data, Wes joins the show to chat about why the book cover of the pandas book doesn’t feature a panda, open source pitfalls to avoid, the pros and cons of hiring engineers at a non-profit, and more.

Subscribe now

Ronak & Guang’s Picks

#1 Open source historically has been a privileged activity.

It’s hard to contribute to open source outside of a full time job if you have small children to take care of, or if you’re doing a second job to make ends meet.

Wes makes an interesting point that “the early story of open source software and part of the reason that the open source world has significant inclusivity and diversity issues is indeed because open source development started out as a very privileged activity.”

And this is why Wes has advocating for creating more full-time jobs in open source and has pointed out recent progress in this - “what's great now is that startups and large companies have made open source an essential part of their strategy. Microsoft, from the Steve Ballmer days has transformed itself into being a very open source friendly company. And Guido van Rosum works at Microsoft on making CPython faster and and Microsoft has made enormous contributions to the open source world.”

#2 Set clear boundaries to avoid the consulting trap if you want to work on open source

According to Wes, “the consulting trap is where you have an open source project and you find consulting gigs where you work for a company that's using the open source project. And maybe they partly are paying you to fix bugs and customize the project for their needs.

But what can happen is that you end up spending a lot more time working on the company's internal software projects. You become more or less a software developer of that company and your work on the open source project can become incidental or something that you do on the side when ideally you would spend 50% of your time working on building things for the company and 50% of the time on the open source project or even more time on the open source project. But it's not uncommon to see the shift and it ended up being, 10, 20 percent of your time on the open source project and 80, 90 percent of your time building custom solutions for the client.”

The solution? set clear expectation in the contract or statement of work to guard your time.

Segments:

(00:02:50) Guang’s complaint about the pandas book cover

(00:04:38) Quarto and Open Access Publishing

(00:12:00) Convincing Wall Street to Open Source

(00:15:31) Publishing the first python package over Christmas

(00:18:01) Doubling Down on Building pandas

(00:23:23) Personal sacrifices for the sake of impact

(00:26:28) The Evolution of Open-Source

(00:29:19) “Open source development started out as a very privileged activity”

(00:32:40) The Consulting Trap

(00:35:17) The Startup Trap

(00:39:29) The Corporate User Trap

(00:44:21) Avoiding the Startup Trap

(00:46:54) Non-Profit vs. For-Profit

(00:48:09) The Challenges of Hiring Engineers in a Non-Profit Setting

(00:50:08) The Benefits of Remote Work for Open Source Development

(00:52:15) Balancing Open Source and Enterprise Interests

(00:57:25) New Funding Models for Open Source?

(01:00:01) Getting into VC

(01:06:19) The Future of Composable Data Systems

Show Notes:

• online edition of pandas book: https://wesmckinney.com/book/

• the new digital publishing tool that Wes recommends:

  https://quarto.org/

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

From creating Envoy to co-founding bitdrift to reimagine mobile observability, Matt joins the show to chat about being told to simply “write some proxy in Python” in the early days of building Envoy, early influences from building “shrink wrap” software at Microsoft, the process of spinning bitdrift out of Lyft, and much more.

Subscribe now

Ronak & Guang’s Picks

#1 Lessons from spinning bitdrift from Lyft

While it’s common to see either

• build a successful open-source project X at Big Co Y, leave, and build a company around X; or

• build a successful internal project X at Big Co Y, leave, and start a company that rebuilds X from scratch.

Matt and his co-founders accomplished something rare: they retained the IP as they exited bitdrift out of Lyft, got Lyft on board as an investor, and retained them as a customer. How? Through open and honest communication with the company as early as possible - a strategy that's more likely to succeed than you might think, given today's environment where companies are looking to cut spending on non-core projects.

#2 The trust you earn with the team go beyond your current job.

On paper, it seemed crazy for Lyft to have supported Matt in pursuing the development of Envoy when Lyft was a 300-person company with less than 80 engineers. But, as we learned from the conversation, one key component was that he had the support of the head of engineering at Lyft, who was Matt's manager at Twitter and knew well what Matt was capable of. Startups can be chaotic, so the trust you build with teammates can become a valuable currency, even when you leave that company.

Segments:

(00:03:10) Being a plumber on LinkedIn

(00:05:00) Early influences from building “shrink wrap” software at Microsoft

(00:10:44) Getting diverse work experiences

(00:16:36) Setting high standards for the team

(00:20:42) Lessons from failure of the first startup

(00:22:02) Building a successful open source project vs. running a startup

(00:25:25) Why not start a company around Envoy?

(00:29:54) Why not open source bitdrift?

(00:36:01) Mitigating the risk of big companies building in-house solutions

(00:38:16) Co-founding bitdrift to tackle mobile observability

(00:40:37) Applying lessons from the first startup failure

(00:44:14) Why mobile observability is so hard

(00:50:06) Open source vs source available

(00:53:33) The software licensing strugglebus

(00:58:03) How bitdrift was spinned out of Lyft

(01:03:36) Achieving work-life balance through leverage

(01:06:13) The early days of Envoy

(01:09:20) Impact driven development

(01:13:43) The crazy decision to build Envoy in retrospect

Show Notes:

• Matt’s blog posts on why mobile observability is a hard problem: https://mattklein123.dev/2024/04/24/no-one-talks-about-mobile-observability/

• The new company Matt is building:

  https://bitdrift.io/

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

From being a distinguished engineer at Sun Microsystems to co-founding Oxide Computer Company to build a new kind of server, Bryan joins the show to chat about being told that he’s on a suicide mission when starting Oxide, the moment he felt “I’m actually living HBO Silicon Valley”, lessons from Sun, and much more.

Subscribe now

Highlights

#1 Problems worthy of attack, prove their worth by fighting back.

When tackling a hard problem, it's easy to feel discouraged and want to give up. But remember that problems worthy of attack prove their worth by fighting back. It's when you're punched in the face and pushed down that you know you're onto something valuable.

The key is to celebrate small wins, even when they feel insignificant. Those little victories build up and give you the confidence to take on even bigger challenges. And when you're working with a team, the sense of accomplishment is amplified.

Don't be afraid to be vulnerable and admit when you're struggling. It's okay to feel terrified or unsure, but don't let that hold you back. As the saying goes: "Things take time." Grind, grind, grind, and eventually, you'll get that win.

#2 Using RFDs in the hiring process.

An unique step in Oxide’s hiring process are the Requests for Discussion (RFDs). These detailed documents give candidates a glimpse into the thought process and the level of complexity involved in the work.

By making many of their RFDs publicly available, they do not only showcase their expertise but also set expectations for potential hires. As Bryan puts it, "If you dig deep enough, you'll get to the limit of our own thinking." This transparency helps attract candidates who are up for the challenge and willing to put in the hard work required to excel.

Segments:

(00:02:24) The Origin of Bryan's Nom-de-Guerre: "Colonel of Data Corruption"

(00:04:02) What Debugging Performance Issues at Twitter in the Early Days Revealed About Silicon Valley

(00:13:37) Value of Formal Education and the Experience That Everyone Should Have

(00:16:02) Balancing Following One's Passion vs. Having Stability

(00:21:14) What Shaped Bryan's Sense of Integrity

(00:25:39) The Moments When Values Are Instilled

(00:30:25) The Dark Side of Tech

(00:35:12) "Economic Opportunities Attract Economic Opportunists"

(00:40:35) The Origins of Oxide Computers

(00:50:20) Building the A-Team

(00:52:18) "Compaq Was the Most Successful Startup"

(00:55:51) The Venture Capitalist's Dilemma

(01:03:04) Being Told "You're on a Suicide Mission"

(01:07:12) The Lifestyle of the "Lifestyle Business"

(01:09:30) The Harsh Reality of Raising Venture Capital

(01:13:12) The Challenges of Building Hardware

(01:16:36) Why You Should Think About Not Only Gross Margin but Net Margin

(01:19:14) Hardware and Software Co-Design

(01:22:06) The Frustrations of Infrastructure Deployment

(01:26:46) Finding the Right VCs

(01:28:16) "Oh My God, I'm Actually Living HBO Silicon Valley"

(01:33:12) Oxide's Principles and Lessons from Sun Microsystems

(01:39:51) Sun's Unspoken Values

(01:45:03) Sun's Legacy of Empowering Employees

(01:48:53) Sun's Missed Opportunities

(01:53:04) The Reason Why Sun Survived the Dot-Com Crash

(01:56:21) "God Bless the Early Adopters"

(01:57:39) A Tweet from Shopify's CEO

(02:01:24) The Hard Thing About Hard Things

(02:12:55) The Hardest Moment in Oxide's History

Show Notes:

• Oxide’s principles: https://oxide.computer/principles

• Requests for Discussion (RFDs):

  https://rfd.shared.oxide.computer/

• Toby’s tweet: https://x.com/tobi/status/1793798092212367669

• Bryan on twitter: https://x.com/bcantrill

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

From writing the first lines of Kafka over a Christmas break as a LinkedIn engineer to running a public company as the CEO of Confluent, Jay joins the show to chat about how he and his co-founders convinced investors to take a chance on their vision, what many engineers get wrong about communication, and why engineers can make great CEOs - even when coding is not in the job description. And much more.

Subscribe now

Highlights

#1 Do engineers make good CEOs?

Engineering is probably the least useful skill for becoming a CEO since you don’t need - nor want - the CEO to write a lot of code. But there are 2 attributes of an engineer that translate quite well into the CEO role:

The ability to learn new things, quickly

As an engineer, you're constantly learning new things, which builds the confidence in tackling unfamiliar subjects. This ability to learn and understand various aspects of the business is crucial for a CEO, who needs to oversee multiple functions and make informed decisions.

Systems thinking

As companies scale, they become complex systems that require a unique kind of thinking. Engineers, particularly those with experience in distributed systems, possess this skillset. They understand how to design and optimize systems, identifying areas of high coupling and optimizing feedback loops.

This system thinking is crucial in software engineering, and it's equally valuable in running a larger company. Engineers know how to peer inside a "module" (or department), get it in good shape, and measure its outputs. They can reason about inputs and investments, and make data-driven decisions.

#2 Many engineers communicate in a way that provokes the opposite of what they want to happen

As engineers, we often focus on conveying facts, but that's only half the battle. To truly communicate effectively, we need to consider our audience's perspective and tailor our message to drive the desired outcome.

Unfortunately, many engineers fall into the trap of communicating in a way that actually provokes the opposite reaction. The solution isn't to become overly cautious or vague, but to develop a deeper understanding of our audience and what will drive change. By focusing on the impact we want to have and honing our communication skills over time, we can become more effective leaders and change-makers.

Segments:

(00:01:16) The Shaved Head Bet

(00:04:07) Fundraising

(00:12:16) The Role of Technical Background in VCs

(00:15:48) The power of believing in the possibility of important changes

(00:18:29) The Journey to starting Confluent

(00:27:11) Kafka's Controversial Beginnings

(00:34:30) Effective Communication in Engineering

(00:44:20) The Early Days of Kafka

(00:48:31) The Power of Storytelling

(00:57:19) Early days of Confluent

(01:03:06) Do Engineers Make Good CEOs?

(01:07:59) A Typical Day in the Life of a CEO

(01:12:24) The Evolution of Data Streaming

Show Notes:

• “The log” blog post that solidified Jay and his co-founders’ conviction to found Confluent: https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

• Jay on twitter: https://x.com/jaykreps

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

Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

If you’ve worked on data problems, you probably have heard of Airflow and Superset, two powerful tools that have cemented their place in the data ecosystem. Building successful open source softwares is no easy feat, and even fewer engineers have done this back to back. In part 2 of the conversation, we talk about Max’s journey in open source.

Subscribe now

Highlights

#1 The most undervalued skill for software engineering: code orientation

When it comes to being a successful open source contributor, one crucial skill often goes undervalued: code orientation. This refers to the ability to find your way around a large, complex codebase, identifying where to make changes and how to decipher existing code.

Imagine joining a company like Facebook, where you're faced with massive mono-repos and thousands of microservices. Without code orientation, you'd be lost. Max likens this skill to being able to find your way around a new village or country, where patterns learned in one project can be transposed to others.

#2 What makes a good project to make your first OSS contribution?

When it comes to getting started with open-source projects, it's essential to pick a project that's right for you and a good beginner project is one that scratches your own itch. Instead of trying to find a "simple" project, focus on a library or tool you use daily that doesn't quite meet your needs.

Perhaps you've pip-installed a library that's missing a crucial feature or has a bug that's driving you crazy. That's the perfect opportunity to dive in, explore the code, and contribute to the project. This approach forces you to develop your code navigation skills, and you'll likely encounter like-minded individuals along the way.

#3 Good intentions, poor execution

When working with people who have good intentions but poor execution, it's essential to know when to cut your losses. If someone opens a large and ambitious project but fails to course-correct despite guidance, it may be time to redirect your attention to more promising collaborations.

Focus on contributors who demonstrate a willingness to learn and improve quickly. You can often identify these individuals from their first draft or review.

Segments:

(00:03:27) “Project-Community Fit” in Open Source

(00:08:31) Fostering Relationships in Open Source

(00:10:58) Dealing with Trolls

(00:13:40) Attributes of Good Open Source Contributors

(00:20:01) How to Get Started with Contributing

(00:27:58) Origin Stories of Airflow and Superset

(00:33:27) Biggest Surprise since Founding a VC-backed Company?

(00:38:47) Picking What to Work On

(00:41:46) Advice to Engineers for Building the Next Airflow/Superset?

(00:42:35) The 2 New Open Source Projects that Max is Starting

(00:52:10) Challenges of Being a Founder

(00:57:38) Open Sourcing Ideas

Show Notes:

• Part 1 of our conversation: https://softwaremisadventures.com/p/maxime-beauchemin-llm-ready

• Max on Linkedin: https://www.linkedin.com/in/maximebeauchemin/

• SQL All Stars: https://github.com/preset-io/allstars

• Governator: https://github.com/mistercrunch/governator

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

If you’ve worked on data problems, you probably have heard of Airflow and Superset, two powerful tools that have cemented their place in the data ecosystem. Building successful open source softwares is no easy feat, and even fewer engineers have done this back to back. In Part 1 of this conversation, we chat about how to adapt to the LLM-age as engineers.

Subscribe now

Highlights:

#1: Building a reflex for trying with AI first.

The AI revolution is fundamentally changing the way we live and work, comparable only to the impact of the internet. To thrive in this new era, it's essential to develop a "first reflex" to leverage AI in our daily workflows. This means trying to solve problems with AI assistance before attempting to do them on our own.

In practice, this means integrating AI tools, such as language models like Claude, into our daily tasks. Before starting a project, ask your AI assistant for help, and see if it can provide useful code snippets, input documentation, or even assist with writing emails or designing data models. By working with AI, you can create a feedback loop that streamlines your work and increases productivity. Don't try to do it alone – let AI be your first reflex.

#2: being a SQL monkey is probably not going to cut it anymore when AI is a better SQL monkey than we are

The data engineering landscape is on the cusp of a significant shift. With the advent of AI-powered tools, being a skilled SQL expert may no longer be enough. According to Max, founder of Apache Superset, AI is rapidly becoming a better "SQL monkey" than humans. While AI excels at writing SQL, it lacks essential skills like executive judgment, long-term memory, and business context.

As AI takes over routine SQL tasks, data engineers will need to adapt and focus on higher-level skills like providing context, understanding data models, and making strategic decisions.

#3: Promptimize: bringing Test Driven Development to Prompt Engineering

In the world of AI-generated data models, prompt engineering is crucial for achieving accurate results. However, measuring the quality of prompts and comparing their performance can be a daunting task. This is where Promptimize comes in - a toolkit designed to bring scientific rigor to prompt engineering.

With Promptimize, you can write test cases for your prompts, similar to unit testing frameworks, and measure their success rates against different AI models like GPT-3.5 Turbo or GPT-4. This allows you to identify strengths and weaknesses, compare performance, and optimize your prompts for better outcomes.

Segments:

[00:01:59] The Rise and Fall of the Data Engineer

[00:11:13] The Importance of Executive Skill in the Era of AI

[00:13:53] Developing the first reflex to use AI.

[00:17:47] What are LLMs good at?

[00:25:33] Text to SQL

[00:28:19] Promptimize

[00:32:16] Using tools LangChain

[00:35:02] Writing better prompts

Show Notes:

• Max on Linkedin: https://www.linkedin.com/in/maximebeauchemin/

• Rise of the Data Engineer: https://medium.com/free-code-camp/the-rise-of-the-data-engineer-91be18f1e603

• Downfall of the Data Engineer: https://maximebeauchemin.medium.com/the-downfall-of-the-data-engineer-5bfb701e5d6b

• Promptimize: https://github.com/preset-io/promptimize

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

Out of thousands of engineers at Uber, there’s only a handful of Distinguished Engineers and Joakim was one of them. In this conversation we chat about

• Why software engineering is a lot like a sausage factory.

• Considerations for leaving big tech for a startup.

• “How to beat the promo committee”.

• How can one effectively shape engineering culture?

• “Mentoring two people on the same team is a waste”.

• Much More.

Subscribe now

Segments:

[0:01:52] The “reverse sausage” architecture

[0:07:36] How to get people on board with the new deployment system?

[0:13:55] What does it mean to be a distinguished engineer?

[0:17:47] Under-appreciated soft skills?

[0:21:28] How to improve technical writing

[0:24:16] Do all senior engineers need to write and review code every day?

[0:30:19] How to search out where to contribute when your time is so constrained?

[0:43:10] How to maximize your impact as a mentor

[0:48:52] “How to beat the promo committee”

[0:52:56] Effective means to influence engineering culture?

[0:57:09] Capping the company at 150 employees

[1:03:33] Why join a startup instead of moving to another big tech company?

[1:11:14] What Joakim is working on now at Beyond Work

Show Notes:

• Joakim on leaving Uber to start Beyond Work: https://www.linkedin.com/pulse/why-i-left-uber-start-beyond-work-joakim-recht-o63of?trk=public_post_feed-article-content

• Read Joakim’s other excellent posts here: https://www.linkedin.com/in/recht/recent-activity/all/

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

We’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 two of this conversation, we dive deep into Kelsey’s experiences learning in public and writing “Kubernetes: Up and Running”:

• The biggest barrier to getting started with learning in public and a step-by-step guide to overcome it

• Cautionary tale of the “JavaScript sucks” guy

• Developing the skill of crafting good analogies

• The business and economics of writing a book

• Much more

Subscribe now

Segments:

[0:01:12] Writing and learning in public.

[0:10:58] Writing "Kubernetes: Up and Running."

[0:16:05] The business and economics of writing a book.

[0:21:27] Why your first book should not exceed 100 pages.

[0:23:36] What prevented Kelsey from giving up on the book.

[0:26:15] Being intentional about building an audience and the cautionary tale of the "JavaScript sucks" guy.

[0:36:44] Authenticity does not guarantee success.

[0:39:09] Developing the skill of crafting effective analogies.

[0:47:47] Advice for engineers to leverage their technical skills outside of the nine-to-five.

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:

**Kelsey:** [00:00:00] the first month you're like, man, I'm about to write a book. It's going to be crazy, Month number four. You like, man, I'm not finished, bro. Why do this? I can literally stop because I didn't tell anyone. and then you start to understand the value of a co author because when you're tired or too busy your co authors in there Writing, adding chapters, and then you can review.

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've learned, and of course, the misadventures along the way.

Hi everyone. It's Guan here. Last episode, it was all about startup advising. In this part two of the conversation, we get into Kelsey's [00:01:00] experiences about the what, why, and how of learning in public, as well as writing his book, Kubernetes Up and Running. Without further ado, let's get into the conversation.

**Ronak:** You've been learning in public. And I think as learning in public, you've done a few different things. Like used to be meetups, for example, at some point where you would go and talk about a new thing you learned with, let's say puppet. Um, That transformed to Kubernetes, that transformed to, you know, giving keynotes, for example, where it's still at least, and I might be off base here, but it seems like it's still part of just learning in public.

**Ronak:** It's an extension of that in a way. Um, many folks think about, well, I want to start blogging, posting on Twitter or giving conference talks. Um, but they don't exactly know where to start. Do you have any advice for people who want to do a little more of this, but just don't know where to start? They're like, I don't have anything interesting to talk about.

**Ronak:** Uh, but when you, [00:02:00] I'm sure others would think differently, but they themselves don't have an idea.

**Kelsey:** You know, I think the biggest barrier to getting started is people keep trying to compare themselves to people who've been doing it for 10, 20 years. Right? Some people say, Oh, I want to start a podcast, but I got to get Joe Rogan set up first. It's like, what are you doing? And so then it delays you, right?

**Kelsey:** Especially if we're talking about engineers here, they overthink everything. They start thinking about all the branches, you know, how it can end up, just overanalyzing some of these decisions. So if you think about what it means to learn in public, and we're just going to try to be hyper specific. You have a job, you work on back end engineer, you're using Node.

**Kelsey:** js, expresses your framework of choice, you build these APIs, this is what you do every day. One day you get an issue from support. music ends And it says, Hey, um, we're not returning Unicode. Customer names are coming out of the database and certain, [00:03:00] um, Unicode things are being stripped out and missing. So you don't know what's going on.

**Kelsey:** Maybe you're early in your career. You don't have any idea. You're not really thinking about Unicode versus ASCII. You're not thinking about any of this stuff because stuff was just working before. And so the ticket gets assigned to you. You go in the database and after some digging, you see UTF 8. You're like, what's UTF 8?

**Kelsey:** What does that have to do with anything? You look at your client libraries, you look at your JSON serialization tool, you look at NGINX and you notice that somewhere in the chain, one of them is just doing ASCII by default. So it's getting an array of bytes and it's interpreting them a different way.

**Kelsey:** And you're like, how is this possible? So maybe you go to stack overflow, you look at something. And then you learn the fundamentals, the fundamentals say data is just an array of bytes arranged in some way. That's what it is. A string just happens to be an agreed upon. Set of bytes with some terminator at the [00:04:00] end.

**Kelsey:** And the database interprets and stores those string of bytes as UTF 8. Your library gets streamed UTF 8. You parse the data as an array of bytes and your JSON parser treats it as ASCII for some weird reason. And what it generates back out to the client is in a different interpretation of those bytes.

**Kelsey:** So you fix it. You go to your library, you go to the parser. You say. Um, you know, text format is Unicode, right? And you check in the code, bug fixed, done, right? You've learned a lot, that's it. So what is learning in public? Learning in public could be as very simple as, hey, in the commit message, by default, the JSON parser we are using defaults to ASCII. This change uses UTF 8 by default, which matches. [00:05:00] All the databases we use in the company. This change changes just that one line, and updates other parts of our place because we think that's the right thing to do. And so that's your pull request. Now the person reviewing the pull request, which is a small audience by the way, gets to learn everything you went through because you're not just saying, fix JIRA ticket 278, you know, you look at the diff, it's just like, You know, text format equals UTF 8.

**Kelsey:** That doesn't teach anybody anything. Someone just said, I don't know, man, if that's what you needed to do to fix it. Merge.

**Ronak:** There's a whole lot of that, by the way. Yes.

**Kelsey:** Yeah, there's a lot of that. So learning in public is that patience to say, hold on, stop. It took me two days to learn all of this fundamentals. Let me put it in the issue. And now that it's in the issue, it's in public.

**Kelsey:** The co reviewer is going to see it. Uh, a lot of times when you're a developer, you usually put the JIRA ticket number in the commit message so that it can be linked and close the upstream [00:06:00] issue. Now support may be curious, like, how'd you fix it? And so when they click on the issue, it goes and they get to read this phenomenal commit message.

**Kelsey:** And when they have to explain to the customer or explain to other people in support what they're doing, it What's happening? They see this nice commit message. So now they learn. And then they say, you know what? We've had 200 of these type of issues in the last two years. Now that we finally see this commit message, we can finally explain the other 200 issues.

**Kelsey:** Now everybody knows what's going on. Now a lot more people know about bytes on disk and how they're interpreted by these different codes. And then one thing you could do is, this is where I think a lot of engineers get thrown off. That sounds very simple to people with experience, right? It's like, oh man, everyone knows that.

**Kelsey:** I'm embarrassed that I didn't know it. So I'm not going to tell anybody,

**Ronak:** Oh, yes.

**Kelsey:** right? But if you want to be transparent, you go to your local meetup. I didn't say KubeCon. [00:07:00] I didn't say the big national conference. I'm saying the local meetup where the same two people talk every day, right? It's like, dude, this guy giving a talk again.

**Kelsey:** So if you don't want to see that, that means you have to step up and give a talk. And so you take the situation we just talked about. So you did. The commit message. You've educated the JIRA ticket. And now you go to the meetup and say, Hey, look, I'm gonna give a very short talk. And as an engineer, that's been doing this for a little while. never thought about how data is represented in the database, in our apps, and when we return to clients. And so I'm just going to walk through an issue that I had to troubleshoot. And what I learned about Unicode versus ASCII and why it's important. So you go give that talk at a local meetup. It's like 13 people there. And those 13 people are like, I knew that, but I never explained it to anyone else before, and I never really thought about why it's still a problem. And it's a nice refresher for them. Then there's going to be a bunch of people that's [00:08:00] like, I work in ops and I never thought about any of this stuff. So they're educated.

**Kelsey:** And so that's just 13 people. So what happens then two years from now, one of those 13 people run into the exact same issue and they say, Hey, is it ASCII or Unicode? And they will remember the talk and I can go on and on about then tweeting about that talk or writing a blog post about that talk. So I think for you is don't don't skip out on things because you think it's too simple because remember we're talking to millions and millions of people worldwide.

**Kelsey:** Someone needs this reminder for someone. This is the first time that someone that. They can resonate with. It's talking to them. So that's how you start. Very tangible, very straightforward, very easy. You don't have to create a CFP and submit to some large conference. When the time comes from that, then you do it at that time.

**Guang:** Think it's super important, like the part you pointed out about being able to set [00:09:00] aside your ego, right? Not feeling embarrassed that when you're telling the story, I can like sharply imagine like my ex co worker, Ben, who's like amazing at this. One of the things that really jumped out to me is that, right, it's not that he's very smart, not just that he's very smart and he communicates super well, but he's, like, very humble.

**Guang:** And I think that also lends itself, right, to, like, empathy of, like, when I'm watching it, right, like, whatever he's presenting, it also makes me, like, oh, yeah, like, I can totally see Bing in his shoes, right? Like, he's telling the story in a way that, like, I can really relate to. And, yeah, there's many times where When he started out it was like very simple, right?

**Guang:** I'm like, oh, yeah, I sort of know like what's going on Yeah, i've seen this before but then, you know halfway through i'm like Oh, I didn't know like right like these are all the nuances that like go into it.

**Kelsey:** The stories are right in front of you. When you run into these things and you struggle with it, you power through and you solve it. That is the story. Don't try [00:10:00] to At a car chase, don't try to add an explosion and a helicopter. Like this is not, you know, everything doesn't have to be a Transformers movie, right?

**Kelsey:** So I think some people are like, Oh man, this is not exciting enough. Right? So you hear people say, what is the most interesting bug you worked on? They say, Oh man, I found a bug in the Intel CPU. It's like, dude, what? That's not normal, bro. That's that's, that's something else. Uh, don't tell all the stories.

**Ronak:** Yeah. Uh, the other thing which I would just say is that I think the added benefit of actually going that extra mile in the commit message or the meetup talk, or even a blog post is it ensures you fully understand the thing and whatever you've thought you understood, uh, or, or whatever you fixed wasn't just, or it just seemed to work coincidence.

**Ronak:** Uh, no, but it ensures that while you're explaining it to others, you really deeply understand. Okay. So going from. learning in public to educating others. [00:11:00] Um, you, you have written a few books. Uh, they'll say Kubernetes up and running is probably the one that at least I have read. Um, and. I saw that there were three editions of it.

**Ronak:** And in other cases, whenever I've heard about people talking about writing books, they just say, well, they wanted to write a book because it seemed cool, but then it was a whole lot of work. I remember asking, I think one of our friends, Manu who wrote a book and we asked him, what's your advice on other people writing a book and he's like, don't do it, it's too much work.

**Ronak:** Um, But you've written a book as well. So we're curious to know your thoughts. Uh, what was that experience like?

**Kelsey:** So Kubernetes comes out, I'm contributing, I'm working at CoreOS. And I'm a big fan of the O'Reilly book series because when I was learning new skills, I remember just finding an O'Reilly book and just reading it multiple times until I learned. And I felt like that was like one of the best ways of really improving, uh, you know, knowledge, especially if you were [00:12:00] already working, you know, just kind of fill in the gaps.

**Kelsey:** So I wanted my opportunity to create a book too. And so back in that time, I was the only author. Right? I went to Wikipedia, I looked up pods and found the killer whale, they travel in pods, blah, blah, blah. And so, I didn't know, but you don't normally get to tell O'Reilly or propose what your book cover is.

**Kelsey:** They pick an animal for you, right? There's a person who draws the animals, and that person may have drawn 20 animals that are waiting to become book covers. In this case, I'm like, hey, I don't, I don't know anything about that. I just, I would like this whale to be my cover. And they're like, fine. Um, so you put together a draft, uh, an outline of the things I wanted to cover.

**Kelsey:** And luckily for me, there are zero Kubernetes books at this time. So this will be the first one. So more than likely you have a great chance, but when you think about the book business, so there's, there's two things here. There's the, I just want to write a book to put my thoughts on paper. And I don't care if they [00:13:00] sell a single copy, right?

**Kelsey:** So you're just doing it for that reason. And. In that case, you know, the book was very successful in terms of putting these things on paper. I think I got to about a hundred and something pages of a 220 page book before I realized I needed some help. So co-authors, Brendan Burns, Joe Beta, right? Two of the multiple founders of Kubernetes really brought in.

**Kelsey:** So I started the book saying, look, I wanna make sure it was very hands-on. I wanna start with Docker fundamentals. A bit of storytelling. I want people to really learn. And actually type through this thing and really learn and how to do these things. Brendan brings in like the, why, why did we have pods?

**Kelsey:** Why did we do this? Why did we do that? Why do we make all these decisions? And Joe brought all that, that analytical stuff. Well, especially his experience working on things like Borg. So all three of us then put this combination together and then you get Kubernetes up and running. So a lot of people saw all three [00:14:00] of those styles blended together, right?

**Kelsey:** Cause we didn't, we didn't write individual chapters. It was more like, all right, Kelsey has the frame. Most of it's here. Brendan may go in and redo some things. Joe may go in and redo things, maybe make the examples a little clearer. So, and then you get the editors come in and they clean it up and make sure all the formatting matches the style of O'Reilly and then the book goes.

**Kelsey:** Now, before that process, the business side. Given that Kubernetes was so hot, the only thing in town, I remember, I won't mention the dollar amount, but you know, it was some people's medium income probably just for the first chapters being marketed through some download. You know, you see these things like, Hey, download the rough cut

**Ronak:** Yeah.

**Kelsey:** and a company will pay for exclusive access just so they can host that book is a bit of co marketing and so that's really good business when you can start to get.

**Kelsey:** Basically sponsors to, you know, put this thing out, drive demand for the book, a couple of sample chapters, [00:15:00] and then you just get early revenue from that. The book has been translated into Chinese, German, lots of dialects and languages. So, you know, every, every time they do that, they'll, usually they have to seek your permission, like, Hey, we're gonna let you all know, we're gonna translate this work.

**Kelsey:** Into a different language. And at that moment, you're no longer the author of that new language, but it's a derived work from your previous work. And so I'm done. Volume one, I am done with this thing. It does take a while. It took me like six to nine months to just get to the a hundred pages to realize that I need help to finish this thing.

**Kelsey:** Maybe it takes another three to six months to really get this thing wrapped up. And so there's a lot of work that goes into it. Number one, mainly because we're not professional writers. Now what I've learned is that trying to write perfect chapters out of the gate, that's not how you do it. You don't write code that way either.

**Kelsey:** Right? You do the first pass, then you clean it up. And for some reason, when it comes to writing, we all forget that there will be multiple [00:16:00] phases to get to where you want to be. So volume one is out now. Luckily for me, since I do speak at conferences and how this other kind of revenue stream book signings, I've definitely made more money on book signings than book royalties,

**Ronak:** Hmm,

**Kelsey:** right?

**Kelsey:** Because there's something about people wanting you to stand somewhere for two hours that you could sell 5, 000 books. And wouldn't make as much as I would make on a book signing. So that in person thing is, it's like a artist, like a concert. You may make more money on the concert than actually selling albums to all the people who showed up at the concert. So.

**Guang:** that work? Yeah, book

**Kelsey:** I'll give you an example. Different people have different prices, but I usually charge like keynote prices. My keynotes are 20, 000 to 30, 000 plus travel. Book signings are roughly the same for me. So if you put out a number like that, they order [00:17:00] the books, so you'll get some revenue from the book sales.

**Kelsey:** But remember, you got three co authors, two co authors, the publishers taking their cut. Like, you know, now look, I think my average check size, even to this day, might be 600 or 700. It was much bigger. Six years ago, seven years ago when the original edition published. So I am not complaining to continually getting royalties from this, you know, work that I did a long time ago, but a book signing, there's something about being in person. And so people come, they get to shake your hand. It's almost like a keynote. So you stand there, you may give a little talk to kick things off and now there's a book signing. So That's 20, 000, no shipping, no printing. You're just there signing books. Now different authors may not necessarily get to charge those same prices.

**Kelsey:** I'm not going to say it's the same for everyone, but there's a lot in an appearance fee. So some of the more popular artists may have an appearance fee where they show up at these book signings and it just drives people to the establishment. [00:18:00] Uh, maybe people pay to get in. So a lot of these conferences, people pay to get into these things.

**Kelsey:** Sponsors pay a lot of money for those booths. And why not drive traffic to a booth via a book signing? So that's just kind of how that works. But again, now you, as an author, you have to also be a business person. You see this in music as well. A lot of artists are not business people. They just make great music and then someone else deals with all the business.

**Kelsey:** So they're like, Oh, you don't make money doing music. I'm like, there's money in the music business, but it includes merchandise, concerts, uh, appearance fees, those kinds of things. So when I thought about like, Hey, when you write a book, you have to think about the whole package in terms of like, that book is a product, but you probably gonna have to do the other things around if you really want to maximize it.

**Kelsey:** The thing about a book though, when you sign with a publisher, it is not your book, it's their book and there's a royalty split. So when they decide that they want to do a volume two, then it gets a little [00:19:00] tricky because volume two may not be guaranteed to be written by you.

**Ronak:** Hmm.

**Kelsey:** Now your name stays on it because you know, most of the content was probably written by you and the other coauthors.

**Kelsey:** So maybe one coauthor wants to go off and do You know, second edition, they have the bandwidth to update the chapters. I think Brendan Burns kind of led the charge on volume two. Hey, let's update this thing. There's new data types in Kubernetes. We have services, ingress. Right. When I started writing the first book, there was no ingress.

**Kelsey:** So he came and added all of these things. And most of the time you just kind of keep the splits roughly the same, you know, brand is not hurting for money. Just want to see the second edition out. I may do some reviews, but he largely leads to charge volume three. Um, we added a new coauthor, uh, uh, latch in for Microsoft, right?

**Kelsey:** He worked at days for a while, worked on things like helm and he wanted to do a lots of updates. So we added. there. [00:20:00] And, you know, again, you have to negotiate your splits, right? And so I didn't have to do pretty much anything, but I still got my splits, but this is the book business, right? So it's not yours.

**Kelsey:** Now out of all of my experiences, all the book signings, all the value that that book has brought to the community, to me financially and all the coauthors, I think it was definitely something I'm glad I did. It's a good experience. But now that I understand the book business, my advice to anyone would be, Just write a hundred page book.

**Kelsey:** Stop. Don't, you don't need 200 pages. Maybe a book publisher needs 12 chapters or something like that. You probably need only a hundred pages. Just, if you think about the technical concepts we're trying to convey, Kubernetes was so big that I can't believe I even tried to cover all the concepts you would find in something like Kubernetes.

**Kelsey:** But if I was thinking about writing a book today, let's say I wanted to write a book today, I might say, How to write a modular monolith using Go, Very [00:21:00] straightforward. Like, you can write microservices, but here's my opinion why you shouldn't. Here's what that looks like. Here's how I would approach it with a Go codebase.

**Kelsey:** And, 100 pages. If that's not enough, you're talking too much. Get closer to what you're trying to say. 100 pages. Because you will finish 100 pages. You're not going to have enough space to say all the things you want. If you think about it, there's a famous book, the, uh, K& R, uh, who is it? Um, Kearney and Ritchie, Dennis Ritchie, you know, the inventors of C.

**Kelsey:** They wrote the C book. If you've never seen it, it's like a white book with a blue C on the top. That thing is a hundred pages. And for a long time, that was, they called it the C book. It is the book about C. Hey, here is C. It's a high level programming language. I remember them describing it this way. And they show you how to write, like, temperature apps, temperature conversions, you know, how to do all this stuff, how to compile, all these things, an appendix in the back.

**Kelsey:** Like, it had a whole appendix about what these words [00:22:00] mean. Like, that's, but the book is very concise. And so I think if you're going to do this as an engineer, do not torment yourself. Get very clear on the idea you want. And look, if you want to add more later, do a volume two. Dual Volume 3, these books have life cycles and they don't last as long as you think, but think about the whole business.

**Kelsey:** If you write a book today that's any value, think about the talks you'll give about the book. Think about, um, the things that you didn't get a chance to write about that you can then do an author series or a video about, but it's a business.

**Guang:** But you were, when you were writing, um, did you think about giving up at any point? Maybe after like the first hundred pages you were like, you know what, this is, uh,

**Kelsey:** Yeah, in the beginning, because once you start talking about all the formatting, like when you write for O'Reilly, they have a really good publishing system. So, It was Git based, largely like this kind of ASCII doc, kind of markdown blend type of thing. And so, you didn't have to worry too deeply about the [00:23:00] formatting, but you did have to kind of line things up.

**Kelsey:** But I had a lot of code snippets in the book. And so then you gotta like, where am I hosting the code? You can never take it down because it's in the book, the links. So we try to print as many code blocks, but there are some parts where you have to go download something from a URL and bring it in. So you're kind of stressed out about these things.

**Kelsey:** Um, and then, like I said, you know, the first month you're like, man, I'm about to write a book. It's going to be crazy, Month number four. You like, man, I'm not finished, bro. Why do this? I can literally stop because I didn't tell anyone. and then you start to understand the value of a co author because when you're tired or too busy your co authors in there Writing, adding chapters, and then you can review.

**Kelsey:** So I think for the first time, having a co author isn't terrible. A lot of people have shadow authors anyway, right? There's ghost writers that are doing a lot of these biographies where you see someone's name on

**Ronak:** yeah.

**Kelsey:** And, eh, [00:24:00] they're not really writing the whole thing, so it is a lot of work. But yeah, I do think you start to think about giving up, but luckily again, having Joe Beda, Brendan Burns, and the support of like O'Reilly, that is the value I think having a publisher.

**Kelsey:** Publishers do all these things like, I mean, they're so fast at writing when they do their past, they're correcting for tone, they're asking you really good questions and they make sure you actually ship something of quality. So I would say if you go to book publisher route, that is why Manning press, all of these people are really good to work with because they fill in the gaps and they they'll tell you.

**Kelsey:** Do not try to get this thing perfect, just write and then use the whole iteration step to do it. And as long as I had that, I kind of felt confident later on that it was going to get finished because there was finally a team behind it.

**Ronak:** In this case, when you propose the idea, do you have to kind of send a chapter or a draft?

**Kelsey:** Well, I had some trust, right? Because at that time, I was the chair of OSCON, which was the big O'Reilly open source conference. My name was kind [00:25:00] of out there publicly, you know, talks, you know, I kind of had a brand next to me. So, and it's kind of like anything, if someone that is like a known quantity, respect of the community, high profile, there's nothing better for A book publisher to have someone with the name, a brand, an audience, and an area of expertise that's unique in the marketplace.

**Kelsey:** And I was proposing a book where there was none that existed anywhere. You're going to get a lot of support from that, but let's say you don't really have some of these attributes, right? You don't have a good public profile. You haven't built that audience. You're kind of an unknown entity. Remember. The book publisher has to put a lot into this as well.

**Kelsey:** They got to pay people to edit book covers, printing press, the whole nine. So they have to be calculated about some of the risks that they're taking here. The other part of it, I think is, um, what are you writing about? Some people like, um, I want to write the 7, 000 book about Kafka. It's like, bro, listen. Is too [00:26:00] saturated for someone to really kind of organize around it because it's just the potential for us succeeding Is a little more challenging. So you got to be real careful about About how you approach that.

**Ronak:** So talking about building an audience for you, like as you were giving these talks, some of this became a little more organic, where organically people were interested in what you were saying, they started following you, and now you have a really big audience. Do you think engineers should think about being intentional about this?

**Ronak:** Well, like today they are amazing at what they do, but this is not something that like they don't put themselves out there for a lot of reasons. Uh, as we discussed earlier, I don't have anything interesting to say as one of them, but is this something that should, they should be intentional about?

**Kelsey:** I don't know if i've read it somewhere or heard it somewhere. It was um, I used to care what people thought Now I care even more All right, because the lie we tell ourselves is I don't care what people think about me. It's like you're lying Don't lie you care [00:27:00] Because I think now, so there's two things here.

**Kelsey:** I don't care if you think I'm successful or not, because I can't, that's subjective, right? And then I'll stress myself out way too more, too much trying to hit your definition of what success is. So I'm not in that game, but I do want to be a kind person. So if I get feedback from a person that I am not that, then I'm willing to make adjustments to be the person I want to be.

**Kelsey:** So I do account for that feedback loop. I'm not good at the intentionality around growing my audience. There are some people, they got spreadsheets. They know the number of followers they're getting, who's dropping off. I'm like, I don't, you know, I don't, I don't want to do that because I think once you start talking for the audience, this is where I think things can go wrong. I've seen people get on social media and you might do something like. JavaScript sucks, right? Maybe you're just frustrated that day. You know, you, you miss types because you're coming from a programming language that has [00:28:00] types that will help you. You know, you ship this thing, then JavaScript doing some undefined behavior.

**Kelsey:** It's like, how does anyone use damn JavaScript? And you go on Twitter and you said, JavaScript sucks. And it blows up. I'm talking about you get 10, 000 likes, 2 million. Retweets, reads, you know, it's crazy. And then you watch the news and on CNN and this week on tech, JavaScript sucks. And people are texting you.

**Kelsey:** It's like, Hey man, your tweet is blowing up. And you like, yo, I've never been this famous before in my life. You know what I'm tweeting tomorrow? Why it sucks. And so now you become the JavaScript sucks person and people will keep cheering. And cheering. And then one day you're going to wake up happy as hell, right?

**Kelsey:** You're happy, but you got to be mad today for Twitter because people want more of that negative energy. Because if you say, Hey guys, I'm happy [00:29:00] today. You know, I finally found why JavaScript is so flexible. I was trying to do something really hard. I take back what I said. Nah, no, no, no, no. You posted beyond team.

**Kelsey:** I hate JavaScript forever. You're a traitor. I am unfollowing you. I used to think that you were authentic, but now you said this. Nah, I don't follow this guy anymore. So now you're like, Oh, okay. I need to fix this. Right. I need to fix this. So you delete the other tweet and you say, I was just joking.

**Kelsey:** JavaScript sucks. Ha, what are we doing? So you don't want that because then you become a slave to the audience. What I've been trying to do is I don't even tweet as often as people think. There are days, multiple days. I don't say anything cause I don't anything to say. I'm too busy experiencing life.

**Kelsey:** There's a musician named Maxwell. He had a phenomenal album. He has songs like This Woman's Work, there's so many albums, he has this amazing album. And it took years between [00:30:00] that album, I think he won some awards, and the next album. People are like, what took so long? He said, because I had to live. You have to live and love if you're going to write love songs.

**Kelsey:** You can't just be writing back to back albums because some albums require lived experience in order to tell these new stories. And so for me, typically when I tweet is because I'm talking to someone. And I say something in the moment that I think is worthy of sharing with other people. Or maybe it's something I learned or I'm gonna go kick the tires on a new thing.

**Kelsey:** And now let me go and rephrase it, that whole learning in public thing. So I think when it comes to intentionality is you should be intentional about who you are online. If you want to be pretending, then you need to be intentional about who you're pretending to be. Because a lot of people online are pretending.

**Kelsey:** That they have everything figured out. So they only try to tweet smart stuff the whole time. So, okay, now you got to pretend to be the smartest [00:31:00] person all the time. It's not sustainable. I try to be just as authentic as possible and appreciate. That there's a part of this community that says Kelsey gets to be authentic and uses a normal voice.

**Kelsey:** He doesn't have to pretend with us. So some days I care about inflation getting out of control. Some days I care about rust versus go and i'm gonna try it and Put my notes out there for people to judge and tell me I don't know anything And so you just need to be very careful about what it means to put yourself out there like that I don't post my family if people have a note.

**Kelsey:** I don't my private life I try to keep roughly to myself because that's not what i'm trying to put out there and portray Uh, but I do think your voice is important So let's get to the other side of this equation when I got my first twitter. It was probably like 2012 I just became a full time engineer at puppet labs after working in the enterprise using puppet in production You And I'm sitting at this desk and then we're starting to do these little puppet conferences And people's like, hey, man You should probably get a twitter to tell [00:32:00] people where you're going to be or what issues you're working on That's like, ah, nah, man people who use social media.

**Kelsey:** They're just showing what shoes they're buying I don't want to be any of those things man. I'm not i'm okay And I was like, all right, let me create one And so I created a twitter account and i'm just kind of posting some of the stuff we're working on engineering like hey You know, did you know puppet can do this or?

**Kelsey:** You Man, I ran into this issue with the in it system and you know, I started just posting things and then, you know, you get your first 10 followers. You're like, man, it's over. Man, I might quit and just go full time. You think you want to go full time on Twitter. And I was like, nah, let me just keep using it to broadcast to the world what I'm working on when I'm, when I'm facing challenges of, but then your audience does start to grow and you have to pay attention to who's in the audience because then you'll get someone like, wow, this person follows me.

**Kelsey:** Hmm. Why? You know, what did they care about? But the thing that I've noticed is that your perception of who [00:33:00] you are outweighs your resume full stop the last 10 years, maybe the last 15 years of my career. No resume required. No, fill out this job application. Tell us about what you know, people like now we, I had a, I had an interview with Microsoft and an executive recruiter reached out to me, right?

**Kelsey:** It's a different process. You did not say fill out this job. No, no, no. The executive, um, recruiter says, Hey, listen, um, You know, we've been thinking about bringing on talent. All these things is very flattering because they know what they're doing. This is a very strategic hiring process. And I'm like, okay, do I have to give a resume?

**Kelsey:** Cause I don't have a resume. I didn't even have LinkedIn. Like I just created a LinkedIn again the other day because someone wanted me to review some founders for due diligence. And I'm like, man, I got to create a LinkedIn account. Ha. So now I have one, there's nothing there. So don't ask me to. Invitate to be connected.

**Guang:** Oh man. [00:34:00] Sorry. Sorry.

**Kelsey:** When, when they reached out, they're like, no, we know who you are. And when I, when I heard that I'm sitting there, like, wow, I've seen that from like, you know, other tech companies, you know, they, they kind of seen you in the community, especially when I went to go work at puppet, I was already contributing to the open source.

**Kelsey:** So it's like, you've already working with those people. So that whole work in public learning public, it creates this reputation. Especially when you start to get into things like solving hard problems or you're on a podcast and people get to hear you. And one thing I learned about when you operate in public, you're always interviewing. There's someone that's going to listen to one of your podcasts and be like, you know, there's some people like, man, I don't think Kelsey really knows this stuff. He just looks like a tech influencer that just knows how to copy paste, say the right things. But then when you hear the stories and you hear the nuance, he was like, nah, you're not talking about Unicode.

**Kelsey:** And byte arrays, unless you know, and then that becomes the new perception. Like, yeah, I don't [00:35:00] think Kelsey tech influencer, I think he might know what he's talking about because now there's evidence, right? Can Kelsey write code? Like you just go to GitHub. We were talking about the codes on the GitHub. And so I think when you start to build up this personal persona, that is your resume.

**Kelsey:** So back to your original question, should software engineers be intentional, like a hundred percent? You are, you're intentional about your code base. And you yourself have a public resume that should rival the paper resume.

**Guang:** The biggest takeaway from the last conversation was when you were like But yeah, you know, I got a bunch of things lined up. Thought about rescheduling the podcast, but I was like, you know, just do it. And now every time I kid you not, like, well, I'm like, ah, you know, it's on my calendar, but I said it like two weeks ago, I don't really want to do it.

**Guang:** Now I just have your voice just like pointing in my head, being just like, just do it. Um, and this time I think, cause you know, in the background, like we've been trying to grow this podcast as [00:36:00] well. And one thing that I think we're like kind of struggling with is trying to Kind of, you know, we want to tailor it towards like to the audience, right?

**Guang:** But at the same time, we also want to kind of keep true to like, will we actually care about like, you know, who we want to talk to? What do we want to talk about? And I think finding that balance is kind of tricky at times. Like if you look at the data sometimes, right? It's too few data points, right? So it's hard, but I think authenticity, uh, like you said, I think it's a huge takeaway of exactly like if we're You Like trying to pretend in order to cater to sort of what we think the audience cares about without actually caring about it Then we have to carry that on and yeah, that's bad news bears.

**Kelsey:** I mean, the truth is authenticity does not guarantee success.

**Guang:** And and that's everyone should be okay with that right like but

**Kelsey:** Yeah. I mean, if you can financially afford it, and I think that's the biggest challenge, because when you see someone that you know, as being in authentic, having success, like it could be a coworker that's [00:37:00] tweeting and you know, the code is terrible. You know, they're on a performance review plan. You know, they're not a good engineer.

**Kelsey:** You were on the review panel. You can't believe they hired this person. And while you over here working, solving issues, they're on Twitter, talking about the day in the life of a software engineer, and you're reading their tweets is like, this guy is about to get fired. Why are people liking any of this stuff?

**Kelsey:** Like, what the hell is this? How's this working? So you go on there and you say some actual authentic thing. And people are like, boo. Unfollow. This guy's talking about facts. And you're sitting here like, I don't understand this social media game. So authenticity isn't a guarantee of success, but boy, when you hit being authentic, it's sustainable because you don't have to pretend.

**Kelsey:** Right? And I think that's the thing. So look, you know, you're right, there is an audience, some audience draw their attention to certain things, but if you can give them something that you all actually believe in, then, [00:38:00] then the work becomes very easy to do, right? You're not like, Hey, who is the most, uh, controversial guest we can bring on to try to get more views?

**Kelsey:** Like you don't want to get into that game.

**Ronak:** Oh, no. I think that has been one of the filters we've had on the podcast is, um, We'll talk to people we are interested in talking to. We'll ask the questions we are curious about. Uh, and some of the friends I've asked at times, like, well, why don't you bring on so and so and it would be great to talk to that person.

**Ronak:** And I was like, well, we just don't know what to ask. And I don't have any questions for that person anymore. So I completely agree with you in terms of keeping it sustainable and part of being authentic.

**Kelsey:** And it may broaden out, you know, I think at some point, right. There is value in a person that I've heard interviews from thousands of times, but it's a different interview when they get interviewed by you, right? You may have a different set of questions they've never been asked before. So, but that just, that will come naturally.

**Ronak:** Yeah. Okay, coming back to what you said, uh, makes a lot of [00:39:00] sense now in terms of tweeting, for example, um, or even conference talks, I've seen.

**Ronak:** You have an incredible skill to very succinctly describe things. And I'll, I'll, I'll take an example from this conversation itself. you mentioned something about Spanner being the Gmail of databases. For example, if you have the Postgres driver, it's a really well set thing.

**Ronak:** Like if you say this to someone, it clicks, it clicks in terms of what you're trying to describe. Um, I, I recently saw a tweet from you, I think sometime in the last couple of weeks. Oh yeah, it was about perplex, perplexity and Google search for examples, like when Google searches, like the index on a book versus perplexities, like the cliff notes.

**Ronak:** Uh, but you got to trust cliff. I, when I read that, I chuckled and I was like, well, that's really well said. So when you put out these tweets, um, is this like an initial thought that you had, or do you, is, is there more that goes into putting out a tweet like that? Or is it an instinct that you've just developed over time?

.

**Kelsey:** My confidence level to say that I understand something, I don't believe it unless I can explain [00:40:00] it in simple terms, you know, because a lot of the stuff we work on is like, how's a four loop work? I know I can write it, but what's happening? What is the instruction set? What is the compiler doing? Why does it break sometime?

**Kelsey:** Like, it's just, there's so many things that just work that you don't understand. And so when we try to explain things we don't, for example, someone wins the lottery for 500 million dollars. And then they go around giving financial advice.

**Ronak:** How to lose it all. Oh,

**Kelsey:** when you ask them at that time, they say, how much you worth? I'm worth 400 million. It's like, what happened to the other 100 million? Oh, okay. I lost a lot of money in the stock market. It's like, why you didn't tell us you won the lottery and you don't know anything? And I think this is what happens when you don't actually understand what's happening. So for me, when I think about perplexity, I'm asking like, why would I use this over just Google [00:41:00] search? I'm like, what is the difference between these two things? And then you say, well, what does Google do? Right? They index the internet and they try their best to just say, this thing is over here.

**Kelsey:** This thing is over here. You click on it. And then you go there to get the rest of the context, like a book index would. So if, if it's like a book index, then what would, what would perplexity be in that analogy? And these analogies help you really frame. And also the thing that you do with these analogies is given my audience, when you put this out, the people that work at perplexity will say, you don't know what the hell you're talking about.

**Kelsey:** That analogy doesn't work at all. And so I'm risking a lot when I throw that out there, because I'm saying, I'm trying to take something so complex. and simplify it to a sentence or two. And then I remember the people from Perplexity was like, yeah, that's a, a good way to sum it up. One dude, he, he chimed in on a comment.

**Kelsey:** He said his [00:42:00] grandfather was Cliff, the, the actual Cliff. And he talked about his grandfather wasn't the only writer of all the Cliff notes. He would go get Um, college professors and other domain experts that would summarize these books and content and produce the cliff notes, and then he would allow them to bear his name.

**Kelsey:** And if you think about what Perplexity is doing, they are doing the same, right? They're summarizing things. Hopefully their models have enough domain expertise. And then we have to trust Perplexity's name. That they're going to summarize this stuff correctly because if Cliff no start being too far off Then we can't trust the whole brand and so being able to do that kind of knowledge compression Because I have people that work at the school district that follow me on Twitter I have people that are seasoned engineers or just starting now And so when I think about my audience and also the way I think when I get an analogy that works And I can test [00:43:00] that analogy.

**Kelsey:** And then the feedback is like, okay, that is a good way to summarize it. Especially when I get feedback from the people who work at perplexity AI, they say, yo, this is a good analogy. It really makes me feel like, okay, I think I'm starting to understand where we're going with this.

**Ronak:** In this case, you're willing to risk that too, of being wrong. In this case, like you have an analogy. In this case, perplexity folks are agreeing with it, which is great. There could be the alternative where they come back and say, well, Kelsey, this is not really how, Um, This product works, but it's something that you're open to.

**Ronak:** And I think

**Guang:** But then it starts a conversation, right? Which then you get to learn more, which,

**Kelsey:** Yeah. I don't have any fear anymore. I mean, I've been doing this so long that my mind now tries to simplify anything. When you're doing advisory work, it's an hour call. We don't have all day. To try to come up with a way to give very succinct advice, right? So they got issues. They got input. There's an agenda And you can come back with a really succinct [00:44:00] path forward.

**Kelsey:** It just the light bulb just goes off for people and one thing i'll do and you probably see in some of my live events I'll say thing one way and people look like And then I hit them with the analogy and they're like, oh my god I get it now and since i'm reading the room and a lot of these analogies come on the fly Then the light bulb goes off, and I was like, you know what?

**Kelsey:** I like this skill. And I used to joke with some of the distinguished engineers at Google, they would write these 20 page white papers like Brian Grant. Like he, he would write these, and they're beautiful too. Like if you really want to have a thorough investigation of a topic, some people are really good at writing the 20 pages.

**Kelsey:** So I'll read or skim it, I'll talk to Brian, and I'll just do a tweet. And I remember there was one tweet because he wrote this really nice piece about, um, config management and orchestration and how they differ and why they're so challenging. And a lot of it came down to the imperative nature of infrastructure as code.

**Kelsey:** And I was like, the difference [00:45:00] between, and I was like, Kubernetes isn't infrastructure as code, it's infrastructure as data. And when you have infrastructure as data, that means you can build pipelines. I can take the semantics of a pod, and Give it to Helm, Helm can manipulate that data structure, give it to an admission controller that can manipulate that data structure and land in Kubernetes.

**Kelsey:** And then the entire ecosystem of controllers and operators can operate on the exact same data model. And you now have coordination. And you're always left with a common API infrastructure, uh, infrastructure is code and config management is totally different. You have to write something like maybe an HCL or puppet or Ruby.

**Kelsey:** If you're using chef and you have to know the entire syntax before you can manipulate anything and you're manipulating the wrong layer. In the world of Kubernetes, you're implementing essentially the bytecode, the thing that the thing will be executed no matter what. But in the other tools, [00:46:00] you have to manipulate a thing that you don't have an idea how it's going to come out.

**Kelsey:** If you change an if statement in your puppet code, you have no idea what that's going to compile down to, what result you're going to get. And so, none of the tools are interchangeable. You can't pipe puppet to chef. It doesn't work, right? They're independent islands, but in the case of kube and you start to say infrastructure as data, you reframe the whole problem and you think about chaining together tools very differently.

**Kelsey:** Then the automation world infrastructure is code. So Brian Grant looks at this like two sentences and he's like, yeah, that's what I'm trying to convey in the 20 pages. Right now, look, you still need the 20 pages. I don't want anyone thinking that, Hey, you can excuse the 20 pages, but for a lot of people, it's the spark that makes people want to go and investigate deeper.

**Kelsey:** And then they can substitute or augment their knowledge with the 20 pages. But I found that you can inspire people really quickly. If you can kind of get to the [00:47:00] point and just give them the tools they need to go investigate further.

**Ronak:** That is definitely a skill. It reminds me of the Transformers paper. I haven't read it fully. I started reading it. It's like attention is all you need. Uh, for example, my wife introduced me to that and I was like, that's pretty interesting. Uh, like when you put it like that, it makes me want to go and actually read it.

**Ronak:** Uh, instead of if there was a, another technical title, it said here is a 15 page paper. Go read that.

**Kelsey:** 100%.

**Ronak:** Okay. So Kelsey, we are coming towards the end of the conversation and you've been very kind with your time and all your experiences as always. We really appreciate that. Um, before, before we wrap this up, a couple last questions.

So we talked about technical advising. We talked about, um, writing technical books. And in both of these cases, one thing that kind of stood out is having a business mindset of sorts as an engineer, uh, where even if you're technical advising, for example, you need to do that too. You need to [00:48:00] think about the business to give advice to the company you're working with.

**Ronak:** True for jobs as well. Like if you're working at the current company in case of book writing, it's again, thinking about that business aspect. In your opinion, What are the things that engineers could do or think about to use their technical skills outside of the nine to five? actually grow in any dimension could be technical could be financially could be right starting a business doing something on the side

**Kelsey:** A large part of society, unfortunately, has no time, will, ability to strategically think about what happens next. And it affects more people than you can imagine. Imagine someone that, and you've seen people like this. What are you doing? I'm going to work. And a hundred percent of their cycles Is about what train to catch You got to be safe on the train Got to get there on time.

**Kelsey:** Are you [00:49:00] gonna get fired? If I get a 15 cent raise Does it mean anything? Right because it may not do anything like what more can I afford with 15 cents an hour? It doesn't even change the trajectory and so You're just, I gotta get there on time, and I hate this job so much that I can't imagine making it better. So I just tune out. And so, they only think of five minutes ahead. That's it, five minutes ahead. So what happens when you think this way? If someone bumps into you on the train, and you're only thinking five minutes ahead, you may push them back and say, Hey, why you bumping to me? Cause you're still thinking in five minute increments. Now they hit you back and all of a sudden you're in a fight. And you get arrested. And you're late for work. And you get fired for being late for the second time. Now you have no money. You're evicted. [00:50:00] You can't afford a lawyer. All of these things spiral from just the fact that someone bumped to you on the train. Because you didn't have this analytical branching. So when we think about being an engineer, even though people aren't really paying attention, luckily you have this analytical mindset and even then it's underutilized because at work, you're just like, I got this bug and no one's going to be satisfied until it's fixed.

**Kelsey:** And we have a time boundary. So luckily you have math and science and. You know, you have these pragmatic tools like the ability to write software. And so you're constantly solving puzzles every day, all day. That is the expectation of you problem solve the problem. So in essence, a software developer, typically just a person solving problems.

**Kelsey:** Luckily for us, we have much more well designed problems to solve, almost like a jigsaw puzzle. This puzzle has 1000 pieces. These are the corner pieces. [00:51:00] Look, we'll even give you a photo of what it looks like if you do it correctly. And software engineering is a lot like that. We're typically given a vision of what the end state looks like.

**Kelsey:** And so we just do these jigsaw puzzles, putting together the right tools and pieces until they fit and we ship it. And if you think about outside of your job, if you're actually paying attention, because I think the thing that software developers do is they tune out the real world. They don't look at the people on the train. Some people have never caught the train. Because they never had to deal with public transit in their life. And so for them, they don't understand what the problem is. Why are people complaining about public transit? Just buy a car because they're too far from the problem. They don't see the picture on the box.

**Kelsey:** So a lot of times you got software developers with these amazing analytical skills, these abilities to solve some of the world's most complex problems. Um, and then [00:52:00] they take that and they just bottle it up and then that's it. So in the real world, since they're not paying attention, they're Maybe because they don't expose to enough of the problems.

**Kelsey:** And so they don't even apply themselves. So what we see more of isn't, you know, how to apply these skills. Like you're not even paying attention to the problem. It's like, you know, sometimes you're, you know, you get it, you're busy. You got too many tickets. You're like, look, man, if they, if they really want this thing to be blue, I don't care, like, I'm just going to do it right.

**Kelsey:** The ticket says you want it blue. I change it to blue, I shift it, what's the problem? And you haven't thought through the big, big picture. So I think when it comes to a software engineer, you have this amazing set of abilities to do this. Then you start to pay attention. Don't drive your car and try to catch the bus to your job.

**Kelsey:** And you'll be like, it's not possible, why? There are no bus stops. I have to walk two miles first. That's a problem. Maybe your neighbor really does need a bus and you notice that your neighbor's paying 30 to get to [00:53:00] work at a job that only pays 50, 000 a year. That's 60 a day back and forth. A large percentage of the income is just going to getting to work and back again. And so that person, how would you solve that problem if you paid attention to this scenario? You would say, Hmm, where could we put a bus stop? So you use your analytical mind and you look at the map, the drive map and say, Hmm, if I were to solve this problem, where would I put bus stops? In a way that's going to be safe for the patrol.

**Kelsey:** I know that there's no sidewalks outside of our subdivision. So putting a bus stop here with no sidewalks doesn't make any sense. That's dangerous. The person's going to get hit. So now you're an engineer, you got to solve the problem now, right? Because typically we can't run away from the JIRA ticket.

**Kelsey:** Once that JIRA ticket gets assigned to you, You need to solve that problem, but you don't have to solve the problem by yourself. You can get help the QA team, the product manager, the [00:54:00] support team. Society is the same way you have city council, you have engineers. And a lot of times, if you go to the city council meeting, if you go to the places where they're planning these things, cause a lot of that stuff is public information.

**Kelsey:** You can say, Hey, our area has grown by a population of 3000. On average, 1 to 2%, 5%, 10 percent of these people would prefer public transit. We've asked them and I've looked at the current bus routes and I've looked at the most optimal path. If we just had a bus stop here, here, and here, then people in my community can actually take the bus to work. And now that you've presented this design doc, then it becomes an implementation detail about when and where and how to prioritize. You can do this for any other aspect of your life, your health, a nonprofit, fit. A family member that doesn't understand, you know, they're broke all the time. It was always asking you for 20.

**Kelsey:** It's like, I can totally give you 20, [00:55:00] but maybe if we just made a budget so I can see where your money's going, you won't need the 20. And so as a software engineer, this is how I kind of think about the world. I, I was so appreciative of learning these analytical abilities because when I used to work in fast food.

**Kelsey:** It was more of like thinking linearly about things. I get paid on Friday. I will pay my bill. Don't get fired. Then I can continue to do this until I'm 65. But when you start to think about like branches, if this, then that, and you start thinking about optimizing and then there will be bugs and there's something you can learn from this feedback loop and you start applying it to your real world.

**Kelsey:** It's just, people notice you just think differently, so, when someone bumps into me in the train, Kelsey, you have too much money to be fighting. If I fight somebody, win or lose, I am going to court. And they're going to take my money away from me for some [00:56:00] assault charge. That's what happened. I'm going through that whole branch prediction. When someone bumps into me on the train, because I'm thinking through this, so, That's just kind of my advice for anyone that's an engineer of how you can leverage this. The takeaway here is you gotta pay attention to the real world. And based on our salaries, we are shielded from so much of reality that we don't necessarily point our skillset at the actual problems in society, especially the ones that live outside of a computer screen.

**Ronak:** For sure, for sure. That's very well said. I think that's a great place to bring this part to an end. Uh, Kelsey, as always, thank you so much for joining and sharing everything you did today. Uh, it's always a pleasure to talk to you. And we, we do hope that we can continue these conversations in the future too.

**Ronak:** Uh, and thank you so much for your time.

**Kelsey:** Awesome. Thanks for having me.

**Guang:** Thank you Kelsey.

[00:57:00] Hey, thank you so much for listening to the show. You can subscribe wherever you get your podcasts and learn more about us at SoftwareMisadventures. com. You can also write to us at hello at SoftwareMisadventures. com. We would love to hear from you. Until next time, take care.

We’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

Subscribe now

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:

**Kelsey:** [00:00:00] and a lot of times your initial advisory work will come from a person used to work with, right? So when 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?

**Kelsey:** 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 I like where I am.

**Kelsey:** I can't take this risk with you. And so then there's this opportunity typically is 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.

**Kelsey:** 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 kinds of things. Then it becomes a very low effort for you in terms of balancing that work with your day job.

[00:01:00] Welcome to the Software Misadventures podcast. We are your hosts, Ronek 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 learn more.

To chat about their path, lessons they have learned, and of course, the misadventures along the way. Hi everyone. It's Guang 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.

**Ronak:** Kelsey, super excited to have you back with us today. Thank you so much for joining again.

**Kelsey:** No, happy to be, happy to be back.

**Ronak:** So [00:02:00] how's retirement treating you, by the way? It's, it's been a few months now.

**Kelsey:** I'm a junior retiree. So I don't, I don't know, right? It's been, 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.

**Kelsey:** 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

**Guang:** sheeesh

**Guang:** Sheesh 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. You don't need them anymore. I try not to have any meetings scheduled before 10am. 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 [00:03:00] no need to rush because, you know, you have a lot more time to do those things.

**Kelsey:** 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. I haven't mastered it, but I do have a lot more time on my hands, which is great.

**Guang:** This might be a bit inappropriate but, like, how has your relationship with your wife has changed, uh, now that you guys have a lot more time

**Kelsey:** 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 non profit boards.

**Kelsey:** 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. [00:04:00] 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.

**Kelsey:** 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.

**Kelsey:** 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 gotta look across the room, and that person is still there, like, please, go somewhere.

**Kelsey:** Or, you may just wanna go to Walmart, and this person will be like, hey, can I come with you? It's like, no! I just wanna go to Walmart! Uh, [00:05:00] luckily for us, we don't really have that. It's more of, you know, we've really done a good job over the last 20 years establishing our own identities, our own career path.

**Kelsey:** 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 is, um, 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.

**Kelsey:** 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? Uh, so luckily for us, we were well prepared going into this.

**Guang:** Nice.

**Ronak:** 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 'cause I don't and I get a hard time for it. Um,

**Kelsey:** me, let's, let's do a sidebar on what cleaning means to me. Some people look at [00:06:00] cleaning as 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.

**Kelsey:** 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 take and you clean with patience, you get to appreciate the things you have.

**Kelsey:** 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.

**Kelsey:** 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 [00:07:00] 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. 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 you walk into a clean space, it feels refreshing.

**Kelsey:** 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.

**Ronak:** Mm-Hmm.

**Kelsey:** If you ever got a hotel room that wasn't clean, you immediately, like, I can't stay

**Ronak:** Yep.

**Kelsey:** Right. Everything is off, right? I expect it to be clean. So I take the same attitude to my home and I don't mind doing the cleaning.

**Kelsey:** 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 [00:08:00] style guide. And so it's just one of these things that, um, If you carry this attitude to all the tasks that you do, then that philosophy carries through.

**Kelsey:** So that's what I mean by clean. It's not just, I like doing dishes because no one else likes it. It's like, no, I like the fact that I have these things and I can show appreciation.

**Guang:** Wow. 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.

**Guang:** 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

**Ronak:** Uh, so last time you were chatting, you, you mentioned you were rebuilding your fireplace, I think, or at least you had already built your fireplace. So that was a new thing that you were learning. Uh, is there something that you're learning these days?

**Kelsey:** Yeah. I mean, again, I kind of appreciate the skills that you are necessary for the physical world when you're in the software [00:09:00] 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 where 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 installation, there's electricity, there's wires, there's standards around that stuff.

**Kelsey:** 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 of months ago, we pretty much had below freezing. Um, Uh, temperatures and one of my pipes frozen. This is a brand new house. I'm like, Oh no, how, how can there be any issues in a brand new home?

**Kelsey:** And it turns out the pipe was frozen, but before. I was willing to [00:10:00] 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 in 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 airlocks and then you go down this rabbit hole of like, Uh, all the physics to how water actually works, right?

**Kelsey:** 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, [00:11:00] Hey, put your hand right there.

**Kelsey:** It's like, what? Like you see the temperature that's hot water. And so it was 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 all the filters are, uh, how it all flows together.

**Kelsey:** Now I understand how to winterize my home to make sure that I'm not suffering from frozen pipes in the future. Uh, so paying attention to the details.

**Ronak:** Um, 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 help.

**Kelsey:** I'm gonna say, uh, get a blanket and wait.

**Ronak:** good advice. Good advice. Uh, so shifting gears a little bit, uh, like you mentioned, you've been continuing a few things since Google, uh, one of those being startup advising.

**Ronak:** And we, so we spoke about startup advising a little [00:12:00] bit, uh, in the last time we talked and you shared a lot of details with us, which have been super helpful. Um, 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?

**Kelsey:** 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. 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.

**Kelsey:** 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 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.

**Kelsey:** Some people will go get an advisor. Let's say, you know, you're building a system to improve 911 response times. [00:13:00] 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, right? And they will give you some feedback about how you would sell to police departments and so forth.

**Kelsey:** Some people just need to figure ahead. If I just get the right person's name attached to my startup, and when we launched 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're We'll get some buzz and people will join a waiting list for a product that doesn't exist.

**Kelsey:** And then there's another form of advisory, and that's the kind of advisor 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.

**Kelsey:** And so for those startups, you know, for example, there's one startup I'm working with called Q labs. They're behind the Q lang configuration management or configuration language tool. Very smart team, right? You have ex Google [00:14:00] 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.

**Kelsey:** You have a guy named Polly there. He's a kind of runs a lot of the business operation side. So, and then 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 know, you have the big companies using your stuff, right?

**Kelsey:** This, this is good. And so at that point, you've managed to figure out how to give away. Software for free,

**Ronak:** Yeah.

**Kelsey:** right? And surprisingly, that's also hard. Like even giving away software for free is hard.

**Ronak:** Yes, it is. Hmm.

**Kelsey:** 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 a hundred percent engineer, you [00:15:00] have no sales team. You have no marketing team. You have to learn how to sell that software. So if you take an, any standard open source project, what's the number one thing you can sell before you have.

**Kelsey:** Uh, 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.

**Kelsey:** 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.

**Kelsey:** 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 [00:16:00] 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?

**Kelsey:** 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.

**Kelsey:** 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'm just another engineer. It's like, yo, why are you building your own packaging format?

**Kelsey:** 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 [00:17:00] 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, right?

**Kelsey:** We already talked about. How high 90 percent 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, we'll probably be had in the first three to six months of your advisory.

**Kelsey:** 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. Uh, maybe there's going to be a webinar announcing the new feature set. And then the benefit will sometimes be rapid and immediate.

**Kelsey:** And then at that point, maybe you can do it one or two more [00:18:00] times within that year. But at that moment. Your vested equity is rolled into that impact. And at that moment, hopefully you, 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, uh, it's my way of saying no by saying yes.

**Kelsey:** Yes, I can be an advisor, but here are the terms. And some people say, well, we can't afford that. So I hate no problem. And maybe there's just not enough value that I'm providing that makes that worth it.

**Guang:** Interesting on that note. Um, one of my questions was, yeah, like, when do you say no to startups? Uh, like, in addition to the money, like, uh, how do you tell when there's a bad fit in terms of the advisor relationship?

**Kelsey:** there's, 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 a ton of value there, right? I know some fundamentals just from working at Google cloud for [00:19:00] so long. I have great common go to market strategies that I can bring to the table.

**Kelsey:** 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.

**Kelsey:** 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 five X, the type of equity I would ever ask for, plus the willingness to do the whole monthly stipend thing, and I looked at them and said, this is a very generous offer.

**Kelsey:** 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. [00:20:00] 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.

**Kelsey:** And typically this is the result of a company trying it, you know, they're in year six, right? The runway is low. Um, they don't really quite have the product market fit. They may not have the velocity, right? Because a lot of times when you look at these things, you have, 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.

**Kelsey:** 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 [00:21:00] about that I actually use. Uh, so that's, that's the tricky thing. So, 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 you, if you show me the thing you're working on and we go through and 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.

**Guang:** Interesting. And for, 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. [00:22:00] The

**Kelsey:** 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.

**Kelsey:** Sometimes just having that outsider's perspective just balances things out. Right. Cause if you're a founder, you don't, 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.

**Kelsey:** 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, uh, 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, [00:23:00] you said we should leave Heroku, put everything on Kubernetes and start hiring one or two engineers.

**Kelsey:** 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 four X what we were paying before. Um, this doesn't look like a great decision right now.

**Kelsey:** 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, uh, 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, right? Some companies will say, Hey, you've 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 a advisor slash [00:24:00] consultant.

**Kelsey:** Could you build a front end website for us? Like that, that's 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 it advice.

**Kelsey:** So I've learned that kind of the hard way is 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, [00:25:00] how it's set alongside the rest of the portfolio. How are you going to deprecate?

**Kelsey:** You know, I worked at companies where we had to deprecate a product. People don't realize that when you want your 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.

**Kelsey:** 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?

**Kelsey:** The first time someone jumps on hacking is like, Oh, I hate this company. They, they, they, 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.

**Kelsey:** [00:26:00] 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.

**Kelsey:** We did think through how this would disrupt your workflow, um, 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.

**Kelsey:** And this is why most of my. Uh, 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 that advise, we're on like year three or year four, where [00:27:00] you continuously show value.

**Kelsey:** 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?

**Kelsey:** 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.

**Kelsey:** Well, and so, you know, that's another trade off you have to think about.

**Guang:** It's interesting you brought up the, um, like, uh, 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, [00:28:00] you know, I do not give, two rats about what you just said.

**Guang:** 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 like, have you come across like situations where like, you're like, Hey, you guys should really do this. And. You know, they, they don't really follow along that and how do you sort of address situations like that?

**Kelsey:** One thing I learned that Google. I was never a manager of any teams there. And 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.

**Kelsey:** That prefers open source Postgres protocol, but they'd like the benefits of what Spanner has underneath. So how do you approach that? Like you can't just walk into the [00:29:00] 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 that define for themselves.

**Kelsey:** So let's take something like Spanner. Imagine a world, and this is just hypothetical. Cool. 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.

**Kelsey:** There's going to be some latency things to get that global consistency. Uh, but they'll do it anyway. They'll rewrite their code. They'll use the proprietary, uh, drivers and libraries, and they just are willing to make that trade off. And then you say, okay, well, what's the penetration for that? Right? You look at the numbers.

**Kelsey:** 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 [00:30:00] 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.

**Kelsey:** 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, you know, 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.

**Kelsey:** It would be the Gmail of, 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 [00:31:00] listening.

**Kelsey:** 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.

**Kelsey:** 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 or, and I've been impressed sometimes.

**Kelsey:** 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 could 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 [00:32:00] thing.

**Kelsey:** So I really try to approach this stuff for 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.

**Ronak:** That's really well said. Um, now when it comes to startup advising, like, as you mentioned, you have a social media audience and, uh, I don't know the exact timeline, but, uh, you're Kelsey. And when I say that, uh, 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.

**Ronak:** Uh, 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, uh, It's not the contracting, for example, it's not even a job. It's actually this other thing. [00:33:00] Uh, how did he go about recognizing that?

**Kelsey:** 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. Um, sometimes.

**Kelsey:** 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 not going to download the product.

**Kelsey:** 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 is say, hey, I have more skills than [00:34:00] that.

**Kelsey:** And then when you start talking about business, 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.

**Kelsey:** That's not what we're going to do. What we're gonna 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 cancel whenever you want.

**Kelsey:** You can cancel 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 [00:35:00] name on some slide deck.

**Kelsey:** 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.

**Kelsey:** So look, if someone knows that I'm involved in that adds value bonus, but if I can't impact the product, what am I doing?

**Ronak:** So for engineers, like you mentioned a few things that you provide value in. Uh, and it's not just engineering in this case. It's like go to market, like I said, um, 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'm just going to pick a random topic.

**Ronak:** Let's say databases. Um, 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. Uh, they, they don't necessarily, uh, they're not [00:36:00] enough people in the startup community who necessarily know them, but they want to put themselves out there to.

**Ronak:** 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're doing today is not an overnight thing.

**Ronak:** It takes a lot of time, experience and expertise. Uh, but what can engineers think about and in terms of doing that eventually they get there?

**Kelsey:** 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 have the BI business intelligent teams. You were reporting. You can help the Java developers write the best queries that's going to map well to the garbage collector of the [00:37:00] JVM.

**Kelsey:** 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 joins? The data you need is right here. And so you go into advisory mode.

**Kelsey:** 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 only 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 provisioned dev databases. There is no reason every team needs their own database. We can store some of these tables co located. [00:38:00] We can do things with users and permissions.

**Kelsey:** 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 this? Should we offload it to cold storage?

**Kelsey:** Should we, you know, think about, uh, you know, 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 in the 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.

**Kelsey:** 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 learning that to be an engineer is [00:39:00] more than, you know, You know, installing databases and creating tables and setting up foreign keys.

**Kelsey:** 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.

**Kelsey:** So then when a startup reaches out to you, and a lot of times your initial advisory. Work will come from a person used to work with, right? So when 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?

**Kelsey:** 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, you're not doing that, right? Like I need this job. I like this job. I like where I am.

**Kelsey:** I can't take this [00:40:00] risk with you. And so then there's this opportunity typically is 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.

**Kelsey:** 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 kinds 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, to be a DBA for startup on the side.

**Kelsey:** 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 percent if I stick around for a whole year, make an impact on helping you get off the ground. I'll even advise you 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.

**Kelsey:** So I think that is the right way to think about it. So that will [00:41:00] 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 a technology focus. And look, when you're starting out, you may not be able to demand, you know, like a fair amount of equity.

**Kelsey:** 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 kind of 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, uh, you know, foster kids, whatever it is, and they need help making technology decisions.

**Kelsey:** Go over there and practice giving great advice and living with those decisions.

**Ronak:** that's a really good idea, actually. Um, 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, uh, it's becoming two jobs [00:42:00] almost.

**Ronak:** So you have to draw those boundaries too. Should it be part of an agreement or is something you just figure it out?

**Kelsey:** So what I did systematically was say, listen, here is my advisory schedule. 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.

**Kelsey:** Um, 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.

**Kelsey:** But I would even recommend then, get an advisory calendar where you just count early or whatever you want and then just carve out set advisory time. And the reason why I like doing this is that the onus [00:43:00] 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.

**Kelsey:** You delete those advisor 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.

**Ronak:** And the, 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. Uh, you mentioned the other aspects that go to market and, uh, thinking about what the customers would want.

**Ronak:** 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.

**Kelsey:** Here's the thing, if you're an engineer, [00:44:00] 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 be swimming. That's not what bridge is designed for. It's not a, it's not a diving board.

**Kelsey:** They 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. No, 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, like someone assigns you a Jira ticket and says, Hey, um, we want to drop down on the website. And populated with this information, you could just take that, go to your framework, add it, you know, maybe the pixels get put in the [00:45:00] right place and then ship it.

**Kelsey:** 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?

**Kelsey:** Because then you start thinking about the people. If it's only us, 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.

**Kelsey:** 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 not waiting for a new release.

**Kelsey:** You need to fix this now. [00:46:00] So that means you may have to do some hacks. You may have to do some workarounds. You know, we're going to have to fix it now. We don't get to, 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.

**Kelsey:** 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. Who, again, who are our customers? Well, all of our customers, they use this one enterprise software package that only takes XML as input.

**Kelsey:** So you'll have empathy. You'll start saying, okay, [00:47:00] 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, who uses your thing? And then they say these things, you say, Hey, you know, have you thought about what the onboarding process is going to look like for them?

**Kelsey:** The customer shows up on day one, they log in, they get a token. Where do they put the token? Hmm. This is interesting. Uh, 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.

**Kelsey:** 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 [00:48:00] 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 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.

**Ronak:** I would add two things there. Uh, 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 and senior engineers directly where they're not just thinking about what, how, what is your API going to look like? But they're also thinking about who's going to consume your API and how exactly.

**Ronak:** Uh, 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.

**Ronak:** Oh, I mean, if you want to know where the stack sucks, go [00:49:00] 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.

**Ronak:** Uh, so you 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 SoftwareMisadventures. com. You can also write to us at hello at SoftwareMisadventures. com. We would love to hear from you. Until next time, take care.