All Episodes

February 20, 2024 40 mins

This week, host Dan Lines welcomes back Zach Goldberg, CTO and author of the book 'The Startup CTO's Handbook: Essential Skills and Best Practices for High Performing Engineering Teams.’ Zach shares insights from his extensive career as a CTO and his journey in writing a book that condenses the wisdom of numerous other influential works into a single, comprehensive guide.

We explore the three core sections of his book:

  • Management Fundamentals: Interviewing, Hiring, Performance Management, Budgeting, etc. 
  • Technical Leadership Concepts: Developer Experience, Tech Debt, etc. 
  • Hard Technology Decisions: Pragmatism, Tech Stack, etc.

Zach provides advice for not only CTOs but anyone in a technical leadership position, offering strategies to develop empathy and understanding within technical organizations.

Episode Highlights: 

  • 1:59 From Startup CTO to Author and Executive Coach
  • 3:41 The Origin of Best Practices and Genesis of the Handbook  
  • 10:25 Why the Startup CTO’s Handbook isn’t just for CTOs 
  • 13:02 Part 1: Management Fundamentals Beyond Coding
  • 24:50 Part 2: Technical Leadership Concepts & Developer Experience
  • 30:57 Part 3: Technology Decisions from a Pragmatic Perspective

Show Notes:

Support the show:


Mark as Played

Episode Transcript

Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Zach Goldberg (00:00):
Like, as a leader, your role is to, in

a pragmatic way, evaluatethe trade offs and understand
that regardless of of yourpersonal opinions or your
team's opinions, What you'relooking at now is what's the
best fit for my business.
What's going to give usthe best performance or
the most reliability orthe fastest time to market?
What's both supported?
What has the best documentation?

You know, you decide whatactually matters for your
business and then have that,you know, that that clear
eyed view of let's go and andand make the right decision
for the company, even ifit's not my favorite tool.
Is your engineering teamfocused on efficiency, but
struggling with inaccessibleor costly Dora metrics.
Insights into the health of yourengineering team, don't have

to be complicated or expensive.
That's why LinearBis introducing free
door metrics for all.
Say goodbye to spreadsheetsand manual tracking or paying
for your door and metrics.
LinearB is giving away a free.
Comprehensive Dora dashboardpack the central insights,
including all ForkeyDora metrics tailored
to your team's data.
Industry standard benchmarksfor gauging performance and

setting data-driven goals.
Plus additional leading metrics,including emerge, frequency,
and pull request size.
Empower your team withthe metrics they deserve.
Sign up for your freeDora dashboard today at
LinearB dot IO slash Dora.
Or follow the linkin the show notes.

Dan Lines (01:22):
What's up, everyone?
Welcome back to Dev Interrupted.
I'm your host, Dan Lines,LinearB, cofounder and COO.
And today, I'm joined by my guy,Zach Goldberg, CTO, technical
executive coach, and authorof the new book, The Startup
CTO's Handbook, Essential Skillsand Best Practices for High

Performing Engineering Teams.
Zach, great to haveyou back on DI, man.

Zach Goldberg (01:49):
Great to be here again, Dan.
Thanks so much forthe warm intro.

Dan Lines (01:53):
I love having you here again.
You're doing some really,really exciting stuff.
But just as a reminder forpeople who don't know you
from the last time thatyou're on, you spent a lot of
your career As a CTO workingin a bunch of companies,
maybe you could say, like,specializing in startups a bit.

you're currently a CTO now,which you can Can talk a
little bit about, in a second.
You've written thisamazing amazing book.
You're doing technical, Uh,coaching as well, executive
coaching, but I have alittle quote here from you.
This was in morelike, preproduction.
You said, I alwaysthought it was a stupid

idea to write a book.
I'm glad I was wrong,let's start there.
What does that mean?
What what changed your mind?

Zach Goldberg (02:43):
It's a funny world we live in.
This idea that we stillprint things on paper, uh,
and that there's something,you know, with so many
ways to consume content.
But, you know, podcasts likethis and YouTube videos, email
summaries, TLDR is fantastic.
Uh, there's there's amillion ways to learn.
And so why in twenty twentythree, especially chat GPT,

Does anybody sit down andjust, like, spend, you know,
an extraordinary effort towrite and edit and go through
the publishing process ofproducing an actual book.
and that seems sort of silly.
But as it turns out, therereally is something different
in the way in a, the way peopleconsume content when it's a

book, whether it's an ebook,an audiobook, or a physical
book that the idea that I'mgonna dedicate A significant
quantity of time to this onesubject matter or this one
author or this one piece ofhistory, whatever the the
the subject the topic is.
but he also from the author'sperspective, certainly from
my perspective, you know, I'veI've been a CTO for, you know,
fifteen, seventeen years now.

And, You know, you you developthese thoughts, these opinions
on how the world works.
And it's not really untilyou force yourself to sit
down and start writing art.
These best practices thatI've been using intuitively,
where do they come from?
Why do I do things this way?
Or why I have why doeseverybody do things this way?
And, you know, when you doit from a book, you look at
it from so many angles and somany different parts of the

process that I do actuallythink that, you know, the sum
is greater than the parts.
and, you know, the the greatestpart about it for me has been,
you know, the book is, youknow, open source, if you will.
It's available on GitHub foranybody to download free as
either a markdown file or PDF.
You can, of course,also buy it on Amazon.
Uh, but the reception to thathas just been phenomenal.
And it was well over ahundred thousand downloads,

uh, on GitHub, nine thousandsomething stars on the
repository, uh, and thefeedback has been very positive.
People find it useful.
And so that's really beenjust the most satisfying,
humbling, uh, experience.

Dan Lines (04:41):
let's go through the process.
So I I don't knowif it's true or not.
I have, like, uh, a notehere that said because we
wanna know, you know, whatinspired you to do do so.
Is it true that Dev interrupted,like, our pod or, like, our
conversations was part ofthat, They're like inspiration.
I'm sure there'smany other ones.
But, like, where did you get theinspiration for for the book?

Zach Goldberg (05:03):
Dev Interrupted was bigpart of it, actually.
And in our relationship, myknowing you, my, you know,
being familiar with the companyLinearB for many years and
just the you know, What thework you guys do, trying to
improve on the art and sciencethat is software engineering.
Like, providing visibilityand being able to quantify

elements that actually matter.
you know, actually trying toput intellectual thought into
what is good engineering.
Uh, and so, like, that idea andour conversations around what
is good software engineering,plus this you know, I've been
an avid reader for a longtime, and I I have this self
consciousness that you readall these business books.

And there's so many greatideas and these brilliant
minds who've written so manywonderful things, uh, and you
read, you know, book after book.
And by the time, you know,two weeks later, you've you
know, how do you put intopractice everything you've read?
And in fact, you youforget, You know, a lot
of the details, a lot ofthe really great insights.
So how does one over alifetime incorporate all of
the things you've learnedfrom various sources?

and I'm always self consciousthat, you know, I try my best to
incorporate what I've learned.
But certainly, ninety ninepercent of it at this point
Is, you know, stored way in theback of the brain and doesn't
always make it to the front.
and so part of my I had thisidea for a long time of,
like, take the best ideasfrom everything I've read and
consolidate that into a singletome, right, into a single
book you know, a book perhaps.

Uh, and my idea, you know,years ago was, what if
I just wrote a book thatsummarizes the best bits of
every other book I've read?
Maybe that would be interesting.
That's cool.
Uh, and so put those twoideas together, and you get
the start up CTO's handbook.

Dan Lines (06:38):
What does it, Like, physically take to
write a book, and I knowthat might sound dumb.
But, Let's say thatI'm a listener, and I
was also consider hey.
I have, like, a bunch of ideas.
Maybe I started blogging.
I'm, like, doing somestuff, and, like, I'd also
like to To write a book.
Like, what does it take?
Like, what's the what is theprocess of actually doing it?

How does a, uh, let'ssay, one week look or
a two week cycle look?

Zach Goldberg (07:04):
So, you know, it's a bit likeany other challenging endeavor.
If you wanna learn a newlanguage, if you want to go
get your pilot's license,if you want to, you know,
master pistol shooting,like, you know, choose some
Focus that requires mastery.
Uh, the ability to get itdone requires intentional

setting aside focus time.
If you wanna go learn German,the best way to do that is to
leave your job, go to Germany,and just live in Germany and
interact with German people.
do that, and in a couplemonths, you're gonna
speak German wonderfully.
So same thing withwriting a book.
It's not gonnahappen by accident.
The only way a book getswritten is if An author has an
idea and sets aside the time,effort, and makes the space

for themselves to make it work.
You know?
I think Obama famously whenwhen he wrote his most recent
book, like, you know, piecedout to an island in the
middle of the Pacific for amonth, uh, and just, like,
you know, no phone calls,no media, just a month wrote
the book, uh, which is Yeah.
Quasi similar to whatI did except without
the Pacific Island.
Uh, I left my job and, basicallyover a month, woke I I kept my

normal working schedule, uh,woke up at the same time, ate
the same meals as as if I wasworking my normal job, except
rather than running a softwareteam, I was sitting in front of
a Google Doc with a word counterin the top right as, you know,
quantitative motivation andwould make a point of writing as
many words as I could in a day.

Dan Lines (08:26):
Oh, that's awesome.
So you really did carve out,like, extreme focus time.
You treat it likebusiness hours.
Treat treat it like a job.

Zach Goldberg (08:34):
It really was eight hours a day, uh, and
I I mean, I had fun with it.
I would share someparagraphs with friends,
and they're like, what doyou think of these ideas?
And we'll get feedback.
And so it wasn't Just me, youknow, in the in the basement.
and, obviously, it was sittingin front of a word processor,
but I tried to make it ascollaborative as I could
and, you know, improve thecontent as well that way.

Dan Lines (08:53):
Do you think coming from a and this will, I think,
be my last, like, how to bookquestion, but I just gotta
ask because I haven't writtena book before like this.
Do you think coming from asoftware background, like,
influenced the way you wrote it?
And I'm more so thinking about,like, agile type practices.
Like, Did you try to writeit, uh, skeleton wise, like,

end to end and then keepiterating, or did you go,
like, chapter by chapter?
Like, How how did you do it?

Zach Goldberg (09:21):
It's a great question.
Uh, if I were to map howthis book was written
to software engineeringprocess, I would describe it.
It it was Kanban.
I had a board with a wholebunch of issues that I wanted
to think about and write about.
And whatever I was feelinginspired for in the moment or
whatever felt Most critical towork on, I pulled that one off.
Worked on that one,marked it as in progress.

Put together a draft,then picked up another
one, and then, You know?
Sort of there was just a boardwhere things were pretty fluid.
It wasn't, you know, this weekis the hiring week, for example.
I think, you know, there'sa healthy percentage of the
book is about hiring andinterviewing, maybe twenty
percent of the content.
That was written over theentire lifespan of the

of the writing journey.

Dan Lines (10:04):
Very, very cool.
Now okay.
Let's go go back to the book,The Startup CTO's Handbook.
maybe it's obviousthis is for CTOs.
But is there a certaintype of like, who is the
The primary audience.
Like, what type of person or,like, what experiences should
you be going through right nowto get value out of the book?

Zach Goldberg (10:24):
great question.
And The book is for CTOs,but it's for anybody who
is really in any kind oftechnical leadership position.
Uh, and so it's not just ifyou're a c level, if you're a
director of engineering, or evenif you're not in the technical
org, but in some way you'reresponsible for technology,
developing an empathy and anunderstanding for what happens
within the technical org.

Uh, I think the book is alsohelpful for that use case.
and so, you know, the I thinkthe the subtitle of my book does
a lot of the heavy lifting ofdescribing what the book is.
Like, the title of the bookTells you it's technical.
It tells you it's a handbook.
Uh, but the subtitle,Essential skills and
best practices forhigh performing teams.
That's What'sactually in the book?

And so it's a collection oftake different topics that
are important to technicalleadership, and here's some best
practices, some skills and someperspective on how those subject
matters, can be addressed.

Dan Lines (11:19):
That's really cool.
And what what I like thatyou said most, Uh, for our
listeners, like, you do nothave to be a CTO or a c level
person to get value out of this.
In fact, With this these typesof books, I really think if
you're trying to grow yourcareer, you're inspired to grow.
Read this Type of stuff now,maybe you're a team leader,

maybe you're a manager,maybe you're a developer
looking to be a manager.
This is kinda gives youSomething to be ahead of the
curve or, like, what whatit how should I be thinking?

Zach Goldberg (11:50):
I think one of the one ofthe key elements of being an
amazing team player, Right?
If your goal is to be agood team player at work,
right, understanding howthe people around you think,
what are the stresses andpressures and responsibilities
that my coworkers have?
And your your coworkers couldbe other software engineers, or
your manager is also a coworker.
Understanding what arethe stresses that are

placed on management.
Even if you don't ever wannabe a manager, you don't wanna
be responsible for people andperformance reviews like that.
I totally understand that.
even if that's not your goal,knowing The intricacies and
the nuances of well, actually,performance reviews are
very complicated, and it'svery easy as an employee
to be like, oh my god.
This performance reviewprocess It's terrible.
Like, why did theydo it this way?

Well, here's some of thethinking that goes into
designing those processes, andIt just gives you additional
perspective, ability toempathize, and and maybe allows
you to be more supportiveand help improve these
processes in a better way.

Dan Lines (12:45):
Or even do better onyour performance review.
Understand the concept be yeah.
Understand theconcept behind it.
Why do we have to do this?
That type of stuff.
So if we Move now intosome of the concepts.
What are some of theseessential skills that you
you're outlining in the book?

Zach Goldberg (13:02):
So the the book has three main Chapters, let's
say, are three main sections.
the first section is what Icall management fundamentals,
which is not necessarilyexclusive to technology, but
it's, at least for me, a wholebucket of things that coming
into technical managementaren't related to software

engineering, aren't related towriting code, but are essential
to being an effective leader.
So that's the hiring, Theinterviewing, the performance
management, the working withfinance on budgets, managing
vendors, building culture, howto show up as a leader, how
to drive to decisions withoutrubbing people the wrong way.
All all of these kinds ofskills are in the management

fundamental section, and that'sreally just a lot of there's
a couple of sort of largerframeworks specifically around
interviewing and hiring, butthere's a lot of small things.
Like, how do you thinkabout this kind of thing?
one of my favorites, whichpeople seem to just enjoy,
uh, is the idea of the hippo.
The highest paidperson's opinion, uh,
h I p p o or whatever.
And, uh, you know, it's justthe idea that that opinion,

for whatever reason, becausethey have Whoever has a
fancy title is just heavilyweighted in people's minds.
And so as a leader who mayor may not be the hippo,
just be mindful of that.
And that that might changeyour behavior and how you
present yourself in a meeting.
I I make a point of when there'ssomething being discussed as
a group, as a team, Almostnever do I speak first.
I wanna hear everybodyelse's opinion.

I don't wanna bias andanchor the conversation just
because I have a CTO title.
That doesn't makemy ideas better.
And I certainly don't wanteverybody thinking, oh, we
have to, like, rationalizeZach's opinion in order for
this conversation to go well.
That that's thelast thing I want.

Dan Lines (14:40):
That's, like, such a badfeeling when you're, like, one
of the con other contributorsin the conversation.

Zach Goldberg (14:46):
Oh, the the CTO saidsomething, and that shuts
down the whole conversation.
That's the, uh, that'swhere you wanna avoid.
so yeah.
So that's the the firstsection is the, uh, the
management fundamentals.
the second section ofthe book is all about
management, but specificallyto technology teams.
And so this is tech debt.
This is thinkingabout architecture.

this is Sprint cadence.
Do we do sprints?
Do we do Kanban?
So now we're talking actualmanagement skills that
really only do apply totechnical teams, uh, in
some way, shape, or form.
And then the third sectionis what I call the actual
hard technology section.
So this is you know, forsenior engineers who are
reading this book, this thirdchapter is Probably less
interesting and less new,uh, but it's it I would treat

it as a checklist of, like,yeah, you really should know
all of these concepts if youare going to be a senior lead
or an engineering manager.
And this is stuff likemicroservices versus monoliths.
Like, what is a serviceoriented architecture?
Understanding idempotency.
Like, why do I care thatmy services are idempotent?
If you're a senior, you'vebeen around the block,

maybe that's old hat to you.
Uh, but if you're not orif you're new or if you're
a manager looking to just,you know, make sure you've
got the some of thesefoundational, concepts.
You know, that's sort of whatthat third chapter's for.

Dan Lines (16:02):
Got it.
So those are thethree main Sections.
And let's let's try todo something on this pod.
I don't know if we cando it, But let's try.
Can we take one of the mostInteresting things from
each one of those sectionsand talk about them.
The first section, mostinteresting or most insightful.
Second section, mostfavorite, you know, most

insightful, and third section?

Zach Goldberg (16:26):
So, I'm very passionateabout hiring.
I I think there's a lotof room, uh, to go from a
mediocre hiring process toan excellent hiring process.
so I'm actually working witha company now as part of my
my coaching practice, uh,where one of the company's
core, tenants is they wantto be a fun place to work.

And I've really been thinkingabout what does it mean to
hire, uh, you know, talentthat contributes to making
a work environment fun.
This is something I I don'tI only touch on a little bit
In the the first chapter, wecall it, you know, the culture
interview and and culture match.
but I'm sure you've you'vebeen in this sort of
situation where you've gota group of people, Two,

three, four, five, whatever.
And conversation flowspretty smoothly, but then
another person is added whohas a different personality
type, and all of a suddenconversations are a lot harder.
There's something aboutidentifying personality
style or decision makingand argumentative style
that can drive Easyability for conversation
to move and easy not.
And how do you find somethinglike that in an interview?

you know, at at scale,a lot of companies do
personality surveys.
You know, there's researchinto what does that look like,
attention to detail orientedpeople versus big picture
people and things like that.
and I do think there's aa strong place for that
in the hiring process.
but I think, really, the the keyinsight is what I think a lot
of companies don't spend enoughtime on is understanding what

actually is the ideal candidate.
Most companies spend thevast majority of their time
filtering resumes, goingthrough, you know, interviews
and technical streams, whatever.
What percentage of thetime thinking about hiring
is actually answering thequestion, what kind of
candidate What propertiesdoes the best candidate have?

What what is theirpersonality type?
Are they more the attentionto detail kind of person?
Or, you know, arethey perfectionists
or are they scrappy?
Are they very vocal?
And going to make noise aboutevery single problem they
find, or are they perfectlycomfortable living in a world
where things are a mess?
And I'm not judgingany of these.

I think different situations,different ones, these could
be strengths or weaknesses.
What is this person wherewhat kind of company has
this person worked at before?
Where are they working now?
If you're a small start up, Iget this question all the time.
I'm a start up.
We have five people, tenpeople at the whole company,
and we're looking to hirethis guy from, I don't know.

Which has how many thousandsand thousands of engineers.
It's like, Zach, do you thinkhiring this guy for Netflix is
gonna be great for my company?
I said, well, Netflix,obviously, phenomenal
engineering team, like, youknow, very, very smart people.
but there is a risk thatsomebody who doesn't have
experience working in a teamof five people isn't going to
enjoy the start up environment.

And then just Yeah.
For some people, they likeit, some people, they don't.
And so that is an additionalrisk in that hire.
Versus if, you know, if youif you had somebody with
similar level of similar numberof years of experience in
programming whatever programminglanguage, and all their whole
career has been start ups.
The risk that they don'tlike your start up is
much lower, right, justby virtue of the fact that

they have that experience.
And so really thinking throughthis process, I think saves
it makes it a lot easier toknow when When you're at the
other end of the hiring processand you have two candidates
who've passed your interview,which one of these candidates
is likely to be a better fit?
The more you've thought aboutwhat a good fit is upfront, The
easier that decision is out isout the back and likely the the
higher ten percent chance ofsuccess, uh, with that hire.

Dan Lines (19:57):
Totally makes sense.
I I can say, like, I'meven guilty of that, of,
like, putting, like, toomuch effort almost into the
interview process itself.
Ton of effort goes there asopposed to, like, upfront.
Are we all on the same pageof what we're looking for?
Because, also, if you're in theon the same page of what you're
looking for, everyone's Goingto, like, adapt their interview

style to make sure you'reasking the right questions.
So you'll get in that situation.
We have three candidates, and,like, We're totally in disagree
we all they might all be goodin, like, a certain company,
but we're not in agreementof what's the best for us.
Like, that sucks.

Zach Goldberg (20:35):
I think it's actually here here's the
insight from the chapters.
a person's fit at yourcompany, Like, being really
precise on what that is isactually that precision, that
framework, whatever that is,that list of requirements,
list of responsibilities,list of competencies These
should be the exact samething in the job description.

It should be the same way thatthe interviews are evaluated,
and it should be what theperson is held accountable
for in their performancereviews down the line.
If Yeah.
You know, you want a scrappyengineer who's just gonna ship
code really quickly and thequality bar is low, you know,
for whatever reason, then thethe JD should talk about that.
When you interview theperson, their scores

should be related to that.
And then when they're actuallyon the job and they're getting
performance reviews, itshould be the same criteria.
You want a a level ofconsistency of expectation
for what does successfor this role look like.
And that the start of thatprocess is your job description.

Dan Lines (21:33):
Totally make Sense to me.
And, actually, honestly, bestcase one a good case scenario
is even in the first interview,you might be talking to
someone very, very intelligent.
But even if they can say, hey.
I I'm not sureI'm the right fit.
Self selection.
Let's move on to thenext, you know, person
or someone can say, yeah.
I think I am a goodoftentimes, I don't think

the candidates know eitherso from your experience,
if we're thinking aboutearlier stage companies,
Series a, even series b, arethere any characteristics
or behaviors, for developersthat you Should look for in
the interview process peoplethat tend to do better in
those early stage settings.

Zach Goldberg (22:14):
You know, of course, I wannabe very careful about saying,
you know, Universalitiesfor any type of company.
Companies are different.
Circumstances are different.
Different managers work wellwith different employees,
different different candidates.
But I think what is pretty safeto say, uh, is one clear line
you can draw is whether or notthe company is either finding
product market fit or growingand scaling product market fit.

And that pre product marketfit time, you're throwing
stuff against the wall asfast as possible to try and
find something that sticks.
And so so you wannaignore some cost fallacy.
You want folks who arevery comfortable working
on a prototype for a periodof time, and then, well,
customers didn't like it.
They're gonna throw it away,and we'll do something else.
And that's not necessarilya reflection of an
engineer's performance.
That's just the nature oftrying things and and adapting.

And I think if you geta mismatch there, That
is it it it's a reallyhard thing for morale.
It's very easy and andtotally reasonable.
Engineers take pride inthe work that they do.
Like, you're building things.
You're putting all thistime and effort in.
And then for the business to saysix weeks later, actually, we're
not gonna go this directionbecause, you know, whatever
the market is telling us, Throwaway all the work you just did.

You need to, a, setthe expectation upfront
that that's possible.
And then just have a a teamThat is okay with that, and,
you know, that they've signedon for that journey upfront.
Uh, and I think that'sa key thing in that pre
product market fit phase.

Dan Lines (23:36):
Great example.
It's like a billlike willingness or
openness to change.
It's like, hey.
You're gonna be measuredon your willingness to Come
up with ideas, collaborate,change the direction.
How fast can you do that?
We highly value that.
And some people mightself select out.
Like, no.
I like.
I like Absolutely.
Projects, long period oftime, the direction set.

Zach Goldberg (23:57):
I mean, then I don't blame you.
You know, there's a lot ofreally interesting problems in
distributed computing, scaling.
Now most startups don'thave trouble scaling
to multiple regions andhundreds of processors and
big Kubernetes clusters.
Like, those are real problems,very interesting problems.
And, like, I mean, thatsounds like tons of fun to
me, but that's not the problemthat the vast majority of

seed, a, b companies have.

Dan Lines (24:20):
You would love to getthere if you're series a.
You would love thatto be your problem.

Zach Goldbe (24:23):
Champagne problems.

Dan Lines (24:26):
So, You know, first partof the book, I know there's
ton tons of topics there.
We only, like, talked aboutone of them, but I I do really
like that insider takeawayof, like, Spending time in the
interview, uh, hiring process onwhat is the right fit upfront.
If we move to section two,remind us what section
two is and let's, like,choose, like, one thing one

insight to dive into there.

Zach Goldberg (24:49):
That's the, uh, the technicalleadership concepts.
I think my one of my favoritepieces of this chapter
is just the conversationaround developer experience.
and I'm I'm so glad thatsort of across the industry,
there seems to be a phraseAnd an idea that's catching
on very quickly, I think fiveor ten years ago, the phrase
maybe didn't even exist.

But now pretty much everybodyhas some Part of their
process or is thinking aboutdeveloper experience as its
own thing, which is wonderful.
I I was actually I was talkingto an engineer a month or two
ago about, you know, what is DX?
And and or he asked me,like, Zach, what is good DX?
And I said, here's my answer.
Imagine a code base withreally clear instructions.

It's a single command toget everything compiled
and ready to run.
And imagine you're given aticket to build a feature, and
it's super easy to find in thecode base where that feature is.
And then you make thechange in the code.
The type system passes.
The feature runs correctlythe very first time.
And then you go to add tests andthe libraries are just there.

The patterns are clear.
It's easy to add yourfunctional test that tests
actually what you want.
And then your pull reviewprocess takes less than, you
know, two hours from start tofinish, opening the PR, getting
the feedback, and then yourcode is merged that afternoon.
You didn't have to fighta single trace back that
wasn't related to your code.
You didn't have any frictionintegrating with other services.

You didn't have to spend timebrowsing documentation or or
finding another engineer, askingthem to help you debug something
unrelated to your work.
Doesn't that sound like, ajoyful way to get work done.
I think every team shouldin themselves Paint that
meant mental cathedral of,like, what is the best DX?

Like, if I could wake up inthe morning and just do the fun
parts of software engineering,What would that look like?
And that's your no starpre developer experience.

Dan Lines (26:47):
The stuff that LinearB is measuring
that you and I used totalk about all the time.
You can start with, like,DoraMetrics, but flaky tests,
for example, and build times.
How fast can I get up andRunning, uh, after I'm hired?
What's the onboardingprocess like?
When how can Icontribute to value?
How does my release look?
All that stuff.

Zach Goldberg (27:07):
Super important.
I I would think, uh, you know,the the gold star is can a
new engineer employee on dayone ship something on day one?
Ties that value.

Dan Lines (27:20):
do you have, like, a Insight or a takeaway there?
Is it, like, you shouldbe measuring this?
what did you learn Whilewriting the book on that topic.

Zach Goldberg (27:30):
So I think that the key idea is investing in
DX in developer experience.
Investing in tech debt.
These are not long termpayoff investments.
Like, I think Many teamsthe engineers will tell you.
The engineers know that weneed to do this tech debt.
Like, it's worth prioritizing.

And the struggle generally isconvincing the project managers,
the higher ups, the managersthat it's worth doing putting
the time into the developerexperience in the tech debt.
Uh, and I I am joining thatcourse, uh, voices as a manager
myself, as the guy who wrote theCTO's handbook, that absolutely

those things are worth the timebecause the payoff is so fast.
If you can get rid of twentyminutes of headache that an
engineer has every day bymaking the build a little bit
quicker We're reducing thenumber of spurious failures
or flaky tests or whatever.
That multiplies not justin the twenty minutes.
But think about the additionalcontext switching, the

additional frustration.
The time venting to othercolleagues about how
annoying the build system is.
All of that goes away, andit allows you to just spend
your mental energy, that focustime that we were talking
about earlier, actually onthe creative work that is
developing value for your users.

Dan Lines (28:49):
And I think, like, the theskill that's needed as the
leader is to be able toconvey that to the business
stakeholders in a way that theyBelieve and understand you.
Usually, data canhelp with that.
If you looked at it showedthem, hey, I wanna talk to
you about our cycle time.
Let me explain it to you.
This is happening many, many,many times a day, and it's

the reason that we cannot shipas many features as you all
want to, because I wanna shipthese features just like you.
That's the pushbackthat you'll get.
Oh, if you work on this techdebt, then you're not doing
the feature I wanna do.
It's like, no.
We're gonna do many moreof those features, but you
gotta back me on lettingus solve these problems.
Like, I think that's,like Absolutely.

That's one of the missing piecesthat I see from, like, some
executive engineering leaders isnot being able to convey To the
business, what the developersare feeling and why it impacts
what the business wants to do.

Zach Goldberg (29:45):
I I love the analogy of, You know, think
of software engineering likeany other kind of engineering.
If you were gonna go build abridge, how many rivets does it
take to put together a bridge?
And you're gonna hire a teamand their rivet gun breaks.
Are you gonna say, okay.
Well, just use use a hammer.
Like, uh, you know, just be okaywith being thirty times slower.
You're gonna say, okay.

Go to the store andget a new rivet gun.
And that means you're nothammering rivets for an
hourwhile you're at Home Depot.
When you come back, youcould be productive again.
Like, that's anobvious decision.
It should be the same thingin software engineering.
If my tool doesn't work,right, why would I keep
moving with broken tools?
Of course.
You you go to Home Depot.
You get a new tool.
You fix the tool,whatever, so you can resume
actual productive work.

Dan Lines (30:27):
Very, very important.
Something near and dear toour hearts at at LinearB,
so I'm really happy youincluded that type of stuff.
So if I keep us moving sothat was the second that's
an example of somethingin the second section.
Now the third section,it's more even more technical.

Zach Goldberg (30:45):
That's right.
It's just covering actualtechnologies, actual, you
know, concepts, best practices.

Dan Lines (30:50):
Favorite, you know, concept or something
that you think would bereally insightful for the
audience in the third section?

Zach Goldberg (30:57):
I think one of the opening sentences in
the third section is aboutmaking Decisions on technology
in a in an unemotional,pragmatic perspective.
I I think leaders, engineers,everybody has their preferred
technology, and we often usewords like, I like This language

or I don't like this languageor this framework sucks.
Like, this is the nature ofour conversation socially.
But I think, professionally,when you're actually in the
hot seat deciding betweenAngular or and React or, You
know, React Query and Apolloclient or a Go back end or
a Rust back end or whatever.
When you're in the hot seat,that's not the time for social

editorial of technology choices.
Like, as a leader, your roleis to, in a pragmatic way,
evaluate the trade offs andunderstand that regardless
of of your personal opinionsor your team's opinions, What
you're looking at now is what'sthe best fit for my business.
What's going to give usthe best performance or

the most reliability orthe fastest time to market?
What's both supported?
What has the best documentation?
You know, you decide whatactually matters for your
business and then have that,you know, that that clear
eyed view of let's go and andand make the right decision
for the company, even ifit's not my favorite tool.
And I think Yeah.
Separating those twothings, it's totally

okay to have preferences.
But when it comes time to thebusiness, that's where you
really have to optimize and thentaking that emotion out of it.
And especially as a leader,if you enter the conversation
and you put your foot down andsay, you know, I hate React.
Like, it's gonna changethe whole conversation.
Um, and I'm not I'm notmeaning to pick on React.
We use I use React all the time.
React's here I am again,passing judgments.

but, you know, the point is foryour business, right, do you
need this kind of performance.
Would you need thiskind of framework?
Or, you know, who supports it?
What companies arebuying these things?
Are they gonna are they stillgonna be here in five years
is often an important questionthat I don't think gets
asked enough at start ups.

Dan Lines (33:02):
I gotta back you on that because I've I've
seen it a few especially with,like, really early startups,
Like, series a or earlier?
You know, you get a job andyou whatever the, you know,
tech stack is, you try to askQuestion of, like, why hey.
Why did we, like, choose this?
Oftentimes, the answer isjust, like, oh, that's what,
like, the leader liked Asopposed to, like, this is

how we feel it will impactthe business for what we're
trying to build, where we arein the mark like, I've never
gotten that answer before.
I was always just like, Yeah.
That's what they liked.

Zach Goldberg (33:34):
or the timelines are feels weird.
We we chose this technologybecause it will scale
to a billion users.
Meanwhile, you don't haveproduct market fit yet.
Like, you you know, the itall has to line up so that it
actually makes sense for whatthe business needs right now.
and that and I don't Idon't wanna discount the
team having experience witha particular set of tools

or frameworks or whatever.
That is One of the componentswhich will lead to how quickly
can we get to market, what's thequality gonna be in the early
iterations, uh, but it certainlyshouldn't be the only component.

Dan Lines (34:05):
Well, it's a I mean, like, hiring matters too.
I mean, when you're earlyon, you're trying to hire
great people, but you'realso trying to hire quick,
get something up and going.
If you're gonna pick somethingmore obscure, It's gonna be
harder to find people thatare, like, you know, you wanna
hire in, uh, languages andtech where there's a community,
where there's passion,whether you're gonna get some
exciting people that match.

Zach Goldberg (34:26):
If you're a startup rightnow writing code in Haskell,
like, You've made your lifea little harder when it
comes to maybe a lot harderwhen it comes to hiring.
Let let alone any ofthe pros and cons of the
programming language, butthat that's something you
should take into account.

Dan Lines (34:42):
This is awesome stuff, man.
I I'm, like, super excitedfor you and this book,
and it just seems awesome.
Let's move a bit intoany of the, like, the
Feedback, the communityengagement, the future plans.
So you mentioned, like,you had you have the GitHub
repo for direct engagement.
But, like yeah.
What have you heard fromthe community so far, and

what's going on there?

Zach Goldberg (35:04):
I think, Uh, first of all,it's been I'm very humbled.
When I launched the book ona Friday and the Saturday
afternoon, it was the numberone, number two on Hacker
News, uh, for Saturday evening.
Uh, and so I think therethere clearly is, you
know, an appetite forthis idea of a resource.
And I I think that's what'sbeen most successful about

it is it is you know, youcould read the book cover
to cover, and that wouldhopefully be valuable to you.
But I think that's notthe majority use Case.
The idea is you pick itup, you skim the table of
contents, maybe you read acouple chapters here and there.
And then in the back of yourmind, I have this handbook.
And so You come back to thattable of contents a couple weeks
later, and there's another pageor two that will, you know,

help give you perspective onwhatever the next problem is.
Uh, and I think that's reallyWhere it is, I you know, I
I don't think every page andevery chapter is incredibly
helpful to every engineer.
Because like I was saying, youknow, especially that third
section about hard technology.
Like, a lot of seniorfolks will know that stuff
already, and that's cool.
But, hopefully, they can findvalue in effective on hiring,

perspective on budgeting,perspective on different ways
to think about tech debt,you know, so on and so forth.
So I think that's really beenThe key thing, and that that's
what I was hoping for as well.
that that's what the goal was.
You know, I I reallydid lean into it.
It is a handbook.
It is not a novel.

Dan Lines (36:23):
That's awesome.
what's coming next?
I talk to us aboutthe future plan too.

Zach Goldberg (36:27):
as my friends well know,uh, I haven't read a book
on paper myself sincehigh school, probably.
Um, a huge fan of audiobooks.
You know, listen.
I've got my headphonesin listening to
audiobooks all the time.
Uh, and so I you know,I've I've been made fun of.
Zach, you published abook, and you didn't
publish the audiobook.
It's like, okay.
It's it's coming.
as it turns out, recordingan audiobook is, uh, is It

takes time and effort and isa skill and is has challenges.
I'm personally findingrecording the audiobook actually
harder than writing the book.
Uh, so you read a chapter,then you listen to it back
and go, that's terrible,and delete the three minutes
of recording you're doing.
We have yeah.

Dan Lines (37:03):
I, like, do the audio part of This by now,
are you are you physicallydoing the voicing for it?

Zach Goldberg (37:07):
I am physically doing the voicing for it.
I think there's somethingyou know, just like there's
something special about it beingon paper, there's something
special The author beingthe narrator for certainly
for the style of book.
that said, you know, Five yearsfrom now, if I publish a a
second edition or if there'sanother book, uh, will will
an AI Zach, who has perfectintonation and never needs

a drink of water, Be the oneto do the recording, perhaps.

Dan Lines (37:32):
AI Zach is the only person I trust
that I wanna listen to.

Zach Goldberg (37:35):
I would trust AI Zach over myself as well.
You know me very well, Dan.

Dan Lines (37:39):
So you got yougot the audiobook.
Do we have an a datefor the audiobook?
Uh, I'm

Zach Goldberg (37:45):
gonna take a page out of my own recommendations
from my own audiobook, andI'm gonna give you an accurate
answer that's not precise.
You ready for it?
Q one twenty twenty four.

Dan Lines (37:58):
So we have that coming.
It's been amazing havingyou on the pod, man.
You know, both of the episodeshave been I know this is
gonna be a killer episode.
The other one was amazing too.
I think we actually mighthave gotten your list of
audiobooks on the last one.
If we if we didn't, We'llpost that again because
there's some great readsas well as, uh, your book.

you're also doing the executivecoaching, which we touched
on A little so two things aswe're kind of exiting this pod.
If I want to get in touchwith you about executive
coaching, How can I doso, and what can I expect?
And two, just the bay the secondwill be just, like, the basics
of where can I go buy your book?

Zach Goldberg (38:42):
Of course.
if you wanna get in touchwith me, uh, you could
find me at c t o h b.
That's short for CTOhandbook dot com or
zach goldberg dot com.
That's that's mypersonal website.
They go to the same place.
if you wanna get in touchwith me for coaching, feel
free to send me an email.
There's a, uh, a linkon my LinkedIn profile,
actually, just to directlyschedule, uh, an intro if
that's interesting to you.
And, uh, the book, of course,you can Google CTO handbook.

Uh, it's on Amazon.
Uh, CTO handbook as well.
You can find it on Goodreads.
And, uh, I think perhaps mostunusually, it's on GitHub.
And so it's, uh, githubdot com slash Zach Goldberg
slash startup c t o handbook.
A bit of searchingwill find it for you.
And, uh, yeah.
Hope, uh, hope it'shelpful for you.

Dan Lines (39:23):
So everyone listening,let's support Zach.
Of course, you can goto GitHub, get it for
free, but let's book.
Um, thank you everyonefor listening.
If you do want to get in touchwith Zach, We'll put all of his
details and including the linksto hit them up for some of that
technical executive coaching.
thank you so much, Zach, forgiving, You know, back to the

community, this book thatyou're making and these types of
books are super valuable for ouraudience, leaders everywhere.
And thanks again, man,for coming on the pod.

Zach Goldberg (39:54):
Thank you, Dan.
It's been an absolute pleasure.
You're the best.
Advertise With Us

Popular Podcasts

1. Start Here
2. Dateline NBC

2. Dateline NBC

Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations.

3. Amy and T.J. Podcast

3. Amy and T.J. Podcast

"Amy and T.J." is hosted by renowned television news anchors Amy Robach and T. J. Holmes. Hosts and executive producers Robach and Holmes are a formidable broadcasting team with decades of experience delivering headline news and captivating viewers nationwide. Now, the duo will get behind the microphone to explore meaningful conversations about current events, pop culture and everything in between. Nothing is off limits. “Amy & T.J.” is guaranteed to be informative, entertaining and above all, authentic. It marks the first time Robach and Holmes speak publicly since their own names became a part of the headlines. Follow @ajrobach, and @officialtjholmes on Instagram for updates.

Music, radio and podcasts, all free. Listen online or download the iHeart App.


© 2024 iHeartMedia, Inc.