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.
“As a leader, your role is to, in a pragmatic way, evaluate trade offs and understand them regardless of your personal opinions or your team's opinions. What you're looking at now is what's the best fit for my business? What's going to give us the best performance or the most reliability or the fastest time to market? What's most supported?
You decide what actually matters for your business and then have that clear eyed view. Let's go and make the right decision for the company, even if it's not my favorite tool.”
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
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Zach Goldberg: 0:00
Like, as a leader, your role is to, in a pragmatic way, evaluate the trade offs and understand that regardless of of your personal opinions or your team's opinions, What you're looking at now is what's the best fit for my business. Right? What's going to give us the best performance or the most reliability or the fastest time to market? What's both supported? What has the best documentation? You know, you decide what actually matters for your business and then have that, you know, that that clear eyed view of let's go and and and make the right decision for the company, even if it's not my favorite tool.
Ad Read
Is your engineering team focused on efficiency, but struggling with inaccessible or costly Dora metrics. Insights into the health of your engineering team, don't have to be complicated or expensive. That's why LinearB is introducing free door metrics for all. Say goodbye to spreadsheets and manual tracking or paying for your door and metrics. LinearB is giving away a free. Comprehensive Dora dashboard pack the central insights, including all Forkey Dora metrics tailored to your team's data. Industry standard benchmarks for gauging performance and setting data-driven goals. Plus additional leading metrics, including emerge, frequency, and pull request size. Empower your team with the metrics they deserve. Sign up for your free Dora dashboard today at LinearB dot IO slash Dora. Or follow the link in the show notes.
Dan Lines: 1:22
Hey. 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 author of the new book, The Startup CTO's Handbook, Essential Skills and Best Practices for High Performing Engineering Teams. Zach, great to have you back on DI, man.
Zach Goldberg: 1:49
Great to be here again, Dan. Thanks so much for the warm intro.
Dan Lines: 1:53
Yeah. I love having you here again. You're doing some really, really exciting stuff. But just as a reminder for people who don't know you from the last time that you're on, you spent a lot of your career As a CTO working in 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 this amazing amazing book. You're doing technical, Uh, coaching as well, executive coaching, but I have a little quote here from you. This was in more like, preproduction. You said, I always thought 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: 2:43
It's a funny world we live in. Right? This idea that we still print things on paper, uh, and that there's something, you know, with so many ways to consume content. But, you know, podcasts like this and YouTube videos, email summaries, TLDR is fantastic. Uh, there's there's a million ways to learn. Right? And so why in twenty twenty three, especially chat GPT, Does anybody sit down and just, like, spend, you know, an extraordinary effort to write and edit and go through the publishing process of producing an actual book. and that seems sort of silly. But as it turns out, there really is something different in the way in a, the way people consume content when it's a book, whether it's an ebook, an audiobook, or a physical book that the idea that I'm gonna dedicate A significant quantity of time to this one subject matter or this one author or this one piece of history, whatever the the the subject the topic is. but he also from the author's perspective, certainly from my perspective, you know, I've I've been a CTO for, you know, fifteen, seventeen years now. And, You know, you you develop these thoughts, these opinions on how the world works. And it's not really until you force yourself to sit down and start writing art. These best practices that I've been using intuitively, where do they come from? Why do I do things this way? Or why I have why does everybody do things this way? And, you know, when you do it from a book, you look at it from so many angles and so many different parts of the process that I do actually think that, you know, the sum is greater than the parts. and, you know, the the greatest part about it for me has been, you know, the book is, you know, open source, if you will. It's available on GitHub for anybody to download free as either a markdown file or PDF. You can, of course, also buy it on Amazon. Uh, but the reception to that has just been phenomenal. And it was well over a hundred thousand downloads, uh, on GitHub, nine thousand something stars on the repository, uh, and the feedback has been very positive. People find it useful. And so that's really been just the most satisfying, humbling, uh, experience.
Dan Lines: 4:41
let's go through the process. So I I don't know if it's true or not. I have, like, uh, a note here that said because we wanna know, you know, what inspired you to do do so. Is it true that Dev interrupted, like, our pod or, like, our conversations was part of that, They're like inspiration. I'm sure there's many other ones. But, like, where did you get the inspiration for for the book?
Zach Goldberg: 5:03
Yeah. Dev Interrupted was big part of it, actually. And in our relationship, my knowing you, my, you know, being familiar with the company LinearB for many years and just the you know, What the work you guys do, trying to improve on the art and science that is software engineering. Right? Like, providing visibility and being able to quantify elements that actually matter. you know, actually trying to put intellectual thought into what is good engineering. Uh, and so, like, that idea and our conversations around what is good software engineering, plus this you know, I've been an avid reader for a long time, and I I have this self consciousness that you read all these business books. Right? And there's so many great ideas and these brilliant minds who've written so many wonderful 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 into practice everything you've read? And in fact, you you forget, You know, a lot of the details, a lot of the really great insights. So how does one over a lifetime incorporate all of the things you've learned from various sources? Right? and I'm always self conscious that, you know, I try my best to incorporate what I've learned. But certainly, ninety nine percent of it at this point Is, you know, stored way in the back of the brain and doesn't always make it to the front. and so part of my I had this idea for a long time of, like, take the best ideas from everything I've read and consolidate that into a single tome, 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 that summarizes the best bits of every other book I've read? Right? Maybe that would be interesting. That's cool. Uh, and so put those two ideas together, and you get the start up CTO's handbook.
Dan Lines: 6:38
What does it, Like, physically take to write a book, and I know that might sound dumb. But, Let's say that I'm a listener, and I was also consider hey. I have, like, a bunch of ideas. Mhmm. Maybe I started blogging. I'm, like, doing some stuff, and, like, I'd also like to To write a book. Like, what does it take? Like, what's the what is the process of actually doing it? How does a, uh, let's say, one week look or a two week cycle look?
Zach Goldberg: 7:04
Mhmm. Yeah. Absolutely. So, you know, it's a bit like any other challenging endeavor. Right? If you wanna learn a new language, 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 it done 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. Right? do that, and in a couple months, you're gonna speak German wonderfully. So same thing with writing a book. Right? It's not gonna happen by accident. The only way a book gets written 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 when when he wrote his most recent book, like, you know, pieced out to an island in the middle of the Pacific for a month, uh, and just, like, you know, no phone calls, no media, just a month wrote the book, uh, which is Yeah. Quasi similar to what I did except without the Pacific Island. Uh, I left my job and, basically over 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 was working my normal job, except rather than running a software team, I was sitting in front of a Google Doc with a word counter in the top right as, you know, quantitative motivation and would make a point of writing as many words as I could in a day.
Dan Lines: 8:26
Oh, that's awesome. Yeah. So you really did carve out, like, extreme focus time. You treat it like business hours. Treat treat it like a job.
Zach Goldberg: 8:34
It really was eight hours a day, uh, and I I mean, I had fun with it. I would share some paragraphs with friends, and they're like, what do you think of these ideas? And we'll get feedback. And so it wasn't Just me, you know, in the in the basement. and, obviously, it was sitting in front of a word processor, but I tried to make it as collaborative as I could and, you know, improve the content as well that way.
Dan Lines: 8:53
Do you think coming from a and this will, I think, be my last, like, how to book question, but I just gotta ask because I haven't written a book before like this. Do you think coming from a software background, like, influenced the way you wrote it? And I'm more so thinking about, like, agile type practices. Like, Did you try to write it, uh, skeleton wise, like, end to end and then keep iterating, or did you go, like, chapter by chapter? Like, How how did you do it?
Zach Goldberg: 9:21
It's a great question. Uh, if I were to map how this book was written to software engineering process, I would describe it. It it was Kanban. Right? I had a board with a whole bunch of issues that I wanted to think about and write about. And whatever I was feeling inspired for in the moment or whatever felt Most critical to work on, I pulled that one off. Worked on that one, marked it as in progress. Awesome. Put together a draft, then picked up another one, and then, You know? Sort of there was just a board where things were pretty fluid. It wasn't, you know, this week is the hiring week, for example. I think, you know, there's a healthy percentage of the book is about hiring and interviewing, maybe twenty percent of the content. That was written over the entire lifespan of the of the writing journey.
Dan Lines: 10:04
Yeah. Very, very cool. Now okay. Let's go go back to the book, The Startup CTO's Handbook. maybe it's obvious this is for CTOs. But is there a certain type of like, who is the The primary audience. Like, what type of person or, like, what experiences should you be going through right now to 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 of technical leadership position. Uh, and so it's not just if you're a c level, if you're a director of engineering, or even if you're not in the technical org, but in some way you're responsible for technology, developing an empathy and an understanding for what happens within the technical org. Uh, I think the book is also helpful for that use case. and so, you know, the I think the the subtitle of my book does a lot of the heavy lifting of describing what the book is. Right? Like, the title of the book Tells you it's technical. It tells you it's a handbook. Uh, but the subtitle, Essential skills and best practices for high performing teams. Mhmm. That's What's actually in the book? Right? And so it's a collection of take different topics that are important to technical leadership, and here's some best practices, some skills and some perspective on how those subject matters, can be addressed.
Dan Lines: 11:19
That's really cool. And what what I like that you said most, Uh, for our listeners, like, you do not have to be a CTO or a c level person to get value out of this. In fact, With this these types of books, I really think if you're trying to grow your career, 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. Right? This is kinda gives you Something to be ahead of the curve or, like, what what it how should I be thinking?
Zach Goldberg: 11:50
Yeah. I think one of the one of the key elements of being an amazing team player, Right? If your goal is to be a good team player at work, right, understanding how the people around you think, what are the stresses and pressures and responsibilities that my coworkers have? And your your coworkers could be other software engineers, or your manager is also a coworker. Right? Understanding what are the stresses that are placed on management. Even if you don't ever wanna be a manager, you don't wanna be responsible for people and performance 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's very easy as an employee to be like, oh my god. This performance review process It's terrible. Like, why did they do it this way? Well, here's some of the thinking that goes into designing those processes, and It just gives you additional perspective, ability to empathize, and and maybe allows you to be more supportive and help improve these processes in a better way.
Dan Lines: 12:45
Yeah. Or even do better on your performance review. Understand the concept be yeah. Understand the concept behind it. Why do we have to do this? That type of stuff. So if we Move now into some of the concepts. What are some of these essential 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 I call management fundamentals, which is not necessarily exclusive to technology, but it's, at least for me, a whole bucket of things that coming into technical management aren't related to software engineering, aren't related to writing code, but are essential to being an effective leader. Right? So that's the hiring, The interviewing, the performance management, the working with finance on budgets, managing vendors, building culture, how to show up as a leader, how to drive to decisions without rubbing people the wrong way. All all of these kinds of skills are in the management fundamental section, and that's really just a lot of there's a couple of sort of larger frameworks specifically around interviewing and hiring, but there's a lot of small things. Like, how do you think about this kind of thing? one of my favorites, which people seem to just enjoy, uh, is the idea of the hippo. Right? The highest paid person's opinion, uh, h I p p o or whatever. And, uh, you know, it's just the idea that that opinion, for whatever reason, because they have Whoever has a fancy title is just heavily weighted in people's minds. And so as a leader who may or may not be the hippo, just be mindful of that. Right? And that that might change your behavior and how you present yourself in a meeting. No. I I make a point of when there's something being discussed as a group, as a team, Almost never do I speak first. Right? I wanna hear everybody else's opinion. I don't wanna bias and anchor the conversation just because I have a CTO title. Right? That doesn't make my ideas better. Right? And I certainly don't want everybody thinking, oh, we have to, like, rationalize Zach's opinion in order for this conversation to go well. That that's the last thing I want. Right?
Dan Lines: 14:40
Yeah. That's, like, such a bad feeling when you're, like, one of the con other contributors in the conversation.
Zach Goldberg: 14:46
Exactly. Oh, the the CTO said something, and that shuts down the whole conversation. Right? That's the, uh, that's where you wanna avoid. so yeah. So that's the the first section is the, uh, the management fundamentals. the second section of the book is all about management, but specifically to technology teams. Right? And so this is tech debt. This is thinking about architecture. this is Sprint cadence. Right? Do we do sprints? Do we do Kanban? Right? So now we're talking actual management skills that really only do apply to technical teams, uh, in some way, shape, or form. And then the third section is what I call the actual hard technology section. So this is you know, for senior engineers who are reading this book, this third chapter 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 you are going to be a senior lead or an engineering manager. And this is stuff like microservices versus monoliths. Right? Like, what is a service oriented architecture? Understanding idempotency. Right? Like, why do I care that my services are idempotent? Right? If you're a senior, you've been around the block, maybe that's old hat to you. Uh, but if you're not or if you're new or if you're a manager looking to just, you know, make sure you've got the some of these foundational, concepts. You know, that's sort of what that third chapter's for.
Dan Lines: 16:02
Okay. Got it. So those are the three main Sections. And let's let's try to do something on this pod. I don't know if we can do it, But let's try. Can we take one of the most Interesting things from each one of those sections and talk about them. The first section, most interesting or most insightful. Second section, most favorite, you know, most insightful, and third section?
Zach Goldberg: 16:26
see. So, I'm very passionate about hiring. I I think there's a lot of room, uh, to go from a mediocre hiring process to an excellent hiring process. so I'm actually working with a company now as part of my my coaching practice, uh, where one of the company's core, tenants is they want to be a fun place to work. Right? And I've really been thinking about what does it mean to hire, uh, you know, talent that contributes to making a work environment fun. This is something I I don't I only touch on a little bit In the the first chapter, we call it, you know, the culture interview and and culture match. but I'm sure you've you've been in this sort of situation where you've got a group of people, Two, three, four, five, whatever. And conversation flows pretty smoothly, but then another person is added who has a different personality type, and all of a sudden conversations are a lot harder. Right? There's something about identifying personality style or decision making and argumentative style that can drive Easy ability for conversation to move and easy not. And how do you find something like that in an interview? you know, at at scale, a lot of companies do personality surveys. You know, there's research into what does that look like, attention to detail oriented people versus big picture people and things like that. and I do think there's a a strong place for that in the hiring process. but I think, really, the the key insight is what I think a lot of companies don't spend enough time on is understanding what actually is the ideal candidate. Right? Most companies spend the vast majority of their time filtering resumes, going through, you know, interviews and technical streams, whatever. What percentage of the time thinking about hiring is actually answering the question, what kind of candidate What properties does the best candidate have? Right? What what is their personality type? Are they more the attention to detail kind of person? Or, you know, are they perfectionists or are they scrappy? Right? Are they very vocal? Right? And going to make noise about every single problem they find, or are they perfectly comfortable living in a world where things are a mess? And I'm not judging any of these. Right? I think different situations, different ones, these could be strengths or weaknesses. What is this person where what kind of company has this person worked at before? Where are they working now? If you're a small start up, I get this question all the time. I'm a start up. We have five people, ten people at the whole company, and we're looking to hire this guy from, I don't know. Netflix. Right? Which has how many thousands and thousands of engineers. It's like, Zach, do you think hiring this guy for Netflix is gonna be great for my company? I said, well, Netflix, obviously, phenomenal engineering team, like, you know, very, very smart people. but there is a risk that somebody who doesn't have experience working in a team of five people isn't going to enjoy the start up environment. Right? And then just Yeah. For some people, they like it, some people, they don't. And so that is an additional risk in that hire. Right? Versus if, you know, if you if you had somebody with similar level of similar number of years of experience in programming whatever programming language, and all their whole career has been start ups. Right? The risk that they don't like your start up is much lower, right, just by virtue of the fact that they have that experience. And so really thinking through this process, I think saves it makes it a lot easier to know when When you're at the other end of the hiring process and 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 about what a good fit is upfront, The easier that decision is out is out the back and likely the the higher ten percent chance of success, uh, with that hire.
Dan Lines: 19:57
Yeah. Totally makes sense. I I can say, like, I'm even guilty of that, of, like, putting, like, too much effort almost into the interview process itself. Ton of effort goes there as opposed to, like, upfront. Are we all on the same page of what we're looking for? Because, also, if you're in the on the same page of what you're looking for, everyone's Going to, like, adapt their interview style to make sure you're asking the right questions. Right? So you'll get in that situation. Hey. We have three candidates, and, like, We're totally in disagree we all they might all be good in, like, a certain company, but we're not in agreement of 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 your company, Like, being really precise on what that is is actually that precision, that framework, whatever that is, that list of requirements, list of responsibilities, list of competencies These should be the exact same thing in the job description. It should be the same way that the interviews are evaluated, and it should be what the person is held accountable for in their performance reviews down the line. Right? If Yeah. You know, you want a scrappy engineer who's just gonna ship code really quickly and the quality bar is low, you know, for whatever reason, then the the JD should talk about that. When you interview the person, their scores should be related to that. And then when they're actually on the job and they're getting performance reviews, it should be the same criteria. Right? You want a a level of consistency of expectation for what does success for this role look like. Right? And that the start of that process is your job description.
Dan Lines: 21:33
Totally make Sense to me. And, actually, honestly, best case 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 sure I'm the right fit. Yeah. Self selection. Absolutely. Let's move on to the next, you know, person or someone can say, yeah. I think I am a good oftentimes, I don't think the candidates know either so from your experience, if we're thinking about earlier stage companies, Series a, even series b, are there any characteristics or behaviors, for developers that you Should look for in the interview process people that tend to do better in those early stage settings.
Zach Goldberg: 22:14
Yeah. You know, of course, I wanna be very careful about saying, you know, Universalities for any type of company. Companies are different. Circumstances are different. Different managers work well with different employees, different different candidates. But I think what is pretty safe to say, uh, is one clear line you can draw is whether or not the company is either finding product market fit or growing and scaling product market fit. Right? And that pre product market fit time, you're throwing stuff against the wall as fast as possible to try and find something that sticks. Right? And so so you wanna ignore some cost fallacy. You want folks who are very comfortable working on a prototype for a period of 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 necessarily a reflection of an engineer's performance. Right? That's just the nature of trying things and and adapting. And I think if you get a mismatch there, That is it it it's a really hard thing for morale. Right? It's very easy and and totally reasonable. Engineers take pride in the work that they do. Like, you're building things. You're putting all this time and effort in. And then for the business to say six weeks later, actually, we're not gonna go this direction because, you know, whatever the market is telling us, Throw away all the work you just did. Right? You need to, a, set the expectation upfront that that's possible. Right? And then just have a a team That is okay with that, and, you know, that they've signed on for that journey upfront. Uh, and I think that's a key thing in that pre product market fit phase.
Dan Lines: 23:36
Great example. It's like a bill like willingness or openness to change. It's like, hey. You're gonna be measured on your willingness to Come up with ideas, collaborate, change the direction. How fast can you do that? We highly value that. And some people might self select out. Like, no. I like. Yeah. I like Absolutely. Projects, long period of time, the direction set.
Zach Goldberg: 23:57
I mean, then I don't blame you. You know, there's a lot of really interesting problems in distributed computing, scaling. Now most startups don't have trouble scaling to multiple regions and hundreds of processors and big Kubernetes clusters. Like, those are real problems, very interesting problems. And, like, I mean, that sounds like tons of fun to me, but that's not the problem that the vast majority of seed, a, b companies have.
Dan Lines: 24:20
No. You would love to get there if you're series a. You would love that to be your problem.
Zach Goldberg: 24:23
Champagne problems. Right? Exactly.
Dan Lines: 24:26
Okay. Cool. So, You know, first part of the book, I know there's ton tons of topics there. We only, like, talked about one of them, but I I do really like that insider takeaway of, like, Spending time in the interview, uh, hiring process on what 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
Sure. That's the, uh, the technical leadership concepts. I think my one of my favorite pieces of this chapter is just the conversation around developer experience. and I'm I'm so glad that sort of across the industry, there seems to be a phrase And an idea that's catching on very quickly, I think five or ten years ago, the phrase maybe didn't even exist. But now pretty much everybody has some Part of their process or is thinking about developer experience as its own thing, which is wonderful. Absolutely. I I was actually I was talking to 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 with really clear instructions. It's a single command to get everything compiled and ready to run. And imagine you're given a ticket to build a feature, and it's super easy to find in the code base where that feature is. And then you make the change in the code. The type system passes. The feature runs correctly the very first time. And then you go to add tests and the libraries are just there. The patterns are clear. It's easy to add your functional test that tests actually what you want. And then your pull review process takes less than, you know, two hours from start to finish, opening the PR, getting the feedback, and then your code is merged that afternoon. You didn't have to fight a single trace back that wasn't related to your code. You didn't have any friction integrating with other services. You didn't have to spend time browsing documentation or or finding another engineer, asking them to help you debug something unrelated to your work. Right? Doesn't that sound like, a joyful way to get work done. Right? I think every team should in themselves Paint that meant mental cathedral of, like, what is the best DX? Like, if I could wake up in the morning and just do the fun parts of software engineering, What would that look like? And that's your no star pre developer experience.
Dan Lines: 26:47
The stuff that LinearB is measuring that you and I used to talk about all the time. Absolutely. You can start with, like, DoraMetrics, but flaky tests, for example, and build times. Mhmm. How fast can I get up and Running, uh, after I'm hired? What's the onboarding process like? When how can I contribute to value? How does my release look? All that stuff.
Zach Goldberg: 27:07
Super important. Yeah. I I would think, uh, you know, the the gold star is can a new engineer employee on day one ship something on day one? Ties that value. Feasible. Absolutely. Yeah.
Dan Lines: 27:20
do you have, like, a Insight or a takeaway there? Is it, like, you should be measuring this? what did you learn While writing 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 term payoff investments. Right? Like, I think Many teams the engineers will tell you. The engineers know that we need to do this tech debt. Right? Like, it's worth prioritizing. And the struggle generally is convincing the project managers, the higher ups, the managers that it's worth doing putting the time into the developer experience in the tech debt. Uh, and I I am joining that course, uh, voices as a manager myself, as the guy who wrote the CTO's handbook, that absolutely those things are worth the time because the payoff is so fast. Right? If you can get rid of twenty minutes of headache that an engineer has every day by making the build a little bit quicker We're reducing the number of spurious failures or flaky tests or whatever. Right? That multiplies not just in the twenty minutes. Right? But think about the additional context switching, the additional frustration. Right? The time venting to other colleagues about how annoying the build system is. All of that goes away, and it allows you to just spend your mental energy, that focus time that we were talking about earlier, actually on the creative work that is developing value for your users.
Dan Lines: 28:49
Yeah. Yeah. Yeah. And I think, like, the the skill that's needed as the leader is to be able to convey that to the business stakeholders in a way that they Believe and understand you. Usually, data can help with that. If you looked at it showed them, 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 ship as many features as you all want to, because I wanna ship these features just like you. That's the pushback that you'll get. Oh, if you work on this tech debt, then you're not doing the feature I wanna do. It's like, no. We're gonna do many more of those features, but you gotta back me on letting us solve these problems. Like, I think that's, like Absolutely. That's one of the missing pieces that I see from, like, some executive engineering leaders is not being able to convey To the business, what the developers are 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 like any other kind of engineering. If you were gonna go build a bridge, how many rivets does it take to put together a bridge? And you're gonna hire a team and their rivet gun breaks. Right? Are you gonna say, okay. Well, just use use a hammer. Right? Like, uh, you know, just be okay with being thirty times slower. No. You're gonna say, okay. Go to the store and get a new rivet gun. Right? And that means you're not hammering rivets for an hourwhile you're at Home Depot. When you come back, you could be productive again. Right? Like, that's an obvious decision. It should be the same thing in software engineering. If my tool doesn't work, right, why would I keep moving with broken tools? Right? No. 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
Yeah. Very, very important. Something near and dear to our hearts at at LinearB, so I'm really happy you included that type of stuff. So if I keep us moving so that was the second that's an example of something in the second section. Now the third section, it's more even more technical. Right?
Zach Goldberg: 30:45
Yep. That's right. It's just covering actual technologies, actual, you know, concepts, best practices.
Dan Lines: 30:50
Favorite, you know, concept or something that you think would be really insightful for the audience in the third section?
Zach Goldberg: 30:57
I think one of the opening sentences in the third section is about making Decisions on technology in a in an unemotional, pragmatic perspective. Right? I I think leaders, engineers, everybody has their preferred technology, and we often use words like, I like This language or I don't like this language or this framework sucks. Right? Like, this is the nature of our conversation socially. But I think, professionally, when you're actually in the hot seat deciding between Angular or and React or, You know, React Query and Apollo client or a Go back end or a Rust back end or whatever. Right? When you're in the hot seat, that's not the time for social editorial of technology choices. Right? Like, as a leader, your role is to, in a pragmatic way, evaluate the trade offs and understand that regardless of of your personal opinions or your team's opinions, What you're looking at now is what's the best fit for my business. Right? What's going to give us the best performance or the most reliability or the fastest time to market? What's both supported? What has the best documentation? You know, you decide what actually matters for your business and then have that, you know, that that clear eyed view of let's go and and and make the right decision for the company, even if it's not my favorite tool. Right? And I think Yeah. Separating those two things, it's totally okay to have preferences. But when it comes time to the business, that's where you really have to optimize and then taking that emotion out of it. And especially as a leader, if you enter the conversation and you put your foot down and say, you know, I hate React. Right? Like, it's gonna change the whole conversation. Um, and I'm not I'm not meaning 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 for your business, right, do you need this kind of performance. Would you need this kind of framework? Or, you know, who supports it? What companies are buying these things? Are they gonna are they still gonna be here in five years is often an important question that 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 and you whatever the, you know, tech stack is, you try to ask Question of, like, why hey. Why did we, like, choose this? Oftentimes, the answer is just, like, oh, that's what, like, the leader liked As opposed to, like, this is how we feel it will impact the business for what we're trying to build, where we are in the mark like, I've never gotten that answer before. I was always just like, Yeah. That's what they liked. Yep. Or
Zach Goldberg: 33:34
or the timelines are feels weird. We we chose this technology because it will scale to a billion users. Meanwhile, you don't have product market fit yet. Right? Like, you you know, the it all has to line up so that it actually makes sense for what the business needs right now. and that and I don't I don't wanna discount the team having experience with a particular set of tools or frameworks or whatever. Right? That is One of the components which will lead to how quickly can we get to market, what's the quality gonna be in the early iterations, uh, but it certainly shouldn't be the only component.
Dan Lines: 34:05
Well, it's a I mean, like, hiring matters too. I mean, when you're early on, you're trying to hire great people, but you're also trying to hire quick, get something up and going. If you're gonna pick something more obscure, It's gonna be harder to find people that are, like, you know, you wanna hire in, uh, languages and tech where there's a community, where there's passion, whether you're gonna get some exciting people that match.
Zach Goldberg: 34:26
Absolutely. Yeah. If you're a startup right now writing code in Haskell, like, You've made your life a little harder when it comes to maybe a lot harder when it comes to hiring. Right? Let let alone any of the pros and cons of the programming language, but that that's something you should take into account. Absolutely.
Dan Lines: 34:42
This is awesome stuff, man. I I'm, like, super excited for you and this book, and it just seems awesome. Let's move a bit into any of the, like, the Feedback, the community engagement, the future plans. So you mentioned, like, you had you have the GitHub repo for direct engagement. But, like yeah. What have you heard from the community so far, and what's going on there?
Zach Goldberg: 35:04
Yeah. I think, Uh, first of all, it's been I'm very humbled. Right? When I launched the book on a Friday and the Saturday afternoon, it was the number one, number two on Hacker News, uh, for Saturday evening. Uh, and so I think there there clearly is, you know, an appetite for this idea of a resource. And I I think that's what's been most successful about it is it is you know, you could read the book cover to cover, and that would hopefully be valuable to you. But I think that's not the majority use Case. Right? The idea is you pick it up, you skim the table of contents, maybe you read a couple chapters here and there. And then in the back of your mind, I have this handbook. Right? And so You come back to that table of contents a couple weeks later, and there's another page or two that will, you know, help give you perspective on whatever the next problem is. Uh, and I think that's really Where it is, I you know, I I don't think every page and every chapter is incredibly helpful to every engineer. Because like I was saying, you know, especially that third section about hard technology. Like, a lot of senior folks will know that stuff already, and that's cool. Right? But, hopefully, they can find value 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 been The key thing, and that that's what I was hoping for as well. that that's what the goal was. You know, I I really did 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 about the future plan too.
Zach Goldberg: 36:27
Sure. Yeah. as my friends well know, uh, I haven't read a book on paper myself since high school, probably. Um, a huge fan of audiobooks. You know, listen. I've got my headphones in listening to audiobooks all the time. Uh, and so I you know, I've I've been made fun of. Zach, you published a book, and you didn't publish the audiobook. It's like, okay. Okay. It's it's coming. as it turns out, recording an audiobook is, uh, is It takes time and effort and is a skill and is has challenges. I'm personally finding recording 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 physically doing the voicing for it?
Zach Goldberg: 37:07
I am physically doing the voicing for it. I think there's something you know, just like there's something special about it being on paper, there's something special The author being the narrator for certainly for the style of book. Yeah. that said, you know, Five years from now, if I publish a a second edition or if there's another book, uh, will will an AI Zach, who has perfect intonation and never needs a drink of water, Be the one to 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
Okay. So you got you got the audiobook. Do we have an a date for the audiobook? Uh, I'm
Zach Goldberg: 37:45
gonna take a page out of my own recommendations from my own audiobook, and I'm gonna give you an accurate answer that's not precise. You ready for it? Q one twenty twenty four. Perfect. Perfect. Great.
Dan Lines: 37:58
So we have that coming. It's been amazing having you on the pod, man. You know, both of the episodes have been I know this is gonna be a killer episode. The other one was amazing too. I think we actually might have gotten your list of audiobooks on the last one. If we if we didn't, We'll post that again because there's some great reads as well as, uh, your book. you're also doing the executive coaching, which we touched on A little so two things as we're kind of exiting this pod. If I want to get in touch with you about executive coaching, How can I do so, and what can I expect? And two, just the bay the second will be just, like, the basics of where can I go buy your book?
Zach Goldberg: 38:42
Of course. if you wanna get in touch with me, uh, you could find me at c t o h b. That's short for CTO handbook dot com or zach goldberg dot com. That's that's my personal website. They go to the same place. if you wanna get in touch with me for coaching, feel free to send me an email. There's a, uh, a link on my LinkedIn profile, actually, just to directly schedule, 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 most unusually, it's on GitHub. And so it's, uh, github dot com slash Zach Goldberg slash startup c t o handbook. A bit of searching will find it for you. And, uh, yeah. Hope, uh, hope it's helpful for you.
Dan Lines: 39:23
Awesome. So everyone listening, let's support Zach. Of course, you can go to GitHub, get it for free, but let's book. Um, thank you everyone for listening. If you do want to get in touch with Zach, We'll put all of his details and including the links to hit them up for some of that technical executive coaching. thank you so much, Zach, for giving, You know, back to the community, this book that you're making and these types of books are super valuable for our audience, leaders everywhere. And thanks again, man, for coming on the pod.
Zach Goldberg: 39:54
No. Thank you, Dan. It's been an absolute pleasure. You're the best.