The Startup CTO's Handbook | Zach Goldberg

0:00Like as a leader, your role is to, in a pragmatic way, evaluate the trade-offs. and understand that regardless of your personal opinion 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 most supported? What has the best documentation? You know, you decide what actually matters for your business and then have that clear-eyed view of let's go and make the right decision for the company, even if it's not my favorite tool. Is your engineering team focused on efficiency but struggling with inaccessible or costly Dora metrics?

0:42Insights into the health of your engineering team don't have to be complicated or expensive. That's why Linear B is introducing free Dora metrics for all. Say goodbye to spreadsheets and manual tracking or paying for your Dora metrics. Linear B is giving away a free, comprehensive Dora dashboard pack of essential insights, including all four key Dora metrics tailored to your team's data, Industry standard benchmarks for gauging performance and setting data-driven goals, plus additional leading metrics including merge frequency and pull request signs. Empower your team with the metrics they deserve.

1:15Sign up for your free Dora dashboard today at linearb.io slash Dora, or follow the link in the show notes. Hey, what's up, everyone? Welcome back to Dev Interrupted. I'm your host, Stan Lyons, Linear B co-founder 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. Great to be here again, Dan. Thanks so much for the warm intro. Yeah, I love having you here again. And you're doing some really, really exciting stuff.

1:58But just as a reminder for people who don't know you from the last time that you were 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 talk a little bit about in a second. You've written this amazing, amazing book. You're doing technical coaching as well, executive coaching. But I have a little quote here from you. This was in more like pre-production. 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?

2:41What changed your mind? It's a funny world we live in, right? This idea that we still print things on paper and that there's something, with so many ways to consume content, but podcasts like this, YouTube videos, email summaries, TLDR is fantastic. There's a million ways to learn, right? And so why in 2023, especially ChatGPT, does anybody sit down and just spend 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 audio book or a physical book that the idea that i'm going to dedicate a significant quantity of time to this one subject matter this one author or this one piece of history whatever the subject the topic is but also from the author's perspective certainly from my perspective, you know, I've been a CTO for, you know, 15, 17 years now.

3:48And, you know, 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, all right, 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'd look at it from so many angles and so many different parts of the process. But I do actually think that the sum is greater than the parts. And the greatest part about it for me has been the book is open source, if you will.

4:20It's available on GitHub for anybody to download for free as either a Markdown file or PDF. You can, of course, also buy it on Amazon. But the reception to that has just been phenomenal. There's well over 100 ,000 downloads on GitHub, 9 ,000-something stars on the repository. And the feedback has been very positive. People find it useful. And so that's really been just the most satisfying, humbling experience. Let's go through the process. So I don't know if it's true or not. I have like a note here that said, because we want to know, you know, what inspired you to do so. Is it true that Dev Interrupted, like our pod or like our conversations was part of that like inspiration?

4:58I'm sure there's many other ones, but like, where did you get the inspiration for, for the book? Yeah, Dev Interrupted was a big part of it, actually. and our relationship, my knowing you, my being familiar with the company Linear B for many years now, 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, being able to quantify elements that actually matter, you know, actually trying to put intellectual thought into what is good engineering. And so like that idea in our conversations around what is good software engineering, plus this, you know, I've been an avid reader for a long time.

5:39And I have this self-consciousness that you read all these business books, right? And there's so many great ideas and these brilliant minds. You've written so many wonderful things 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 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 99 % 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.

6:16And 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. 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. And so put those two ideas together and you get the startup CTO's handbook. 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 considered, hey, I have like a bunch of ideas.

6:51Maybe I started blogging. I'm like doing some stuff. And like, I'd also like to write a book. Like, what does it take? Like, what's the what is the process of actually doing it? How does a, let's say, one week look or a two week cycle look? Yeah, absolutely. So, you know, it's a bit like any other challenging endeavor, right? If you want to 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, the ability to get it done requires intentional setting aside focus time. If you want to 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?

7:36You do that, and in a couple months, you're going to speak German wonderfully. So same thing with writing a book, right? It's not going to 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 he wrote his most recent book, like, you know, peaced out to an island in the middle of the Pacific for a month. and just like, you know, no phone calls, no media, just a month wrote the book, which is quasi similar to what I did except without the Pacific Island.

8:04I left my job and basically over a month, I kept my normal working schedule, woke up at the same time, ate the same meals 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. Oh, that's awesome. Yeah. So you really did carve out like extreme focus time. You treat it like business hours, treat it like a job. It really was eight hours a day. And I mean, I had fun with it. I would share some paragraphs with friends and like, what do you think of these ideas and get feedback.

8:43And so it wasn't just me, you know, in the basement. 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. Do you think coming from a, and this will, I think, be my last like how to book question, but I just got to ask because I haven't written a book before like this. Do you think coming from a software background, like influence the way you wrote it? And I'm more so thinking about like agile type practices. Like, did you try to write it skeleton wise, like end to end and then keep iterating?

9:17Or did you go like chapter by chapter? Like, how did you do it? It's a great question. If I were to map how this book was written to software engineering process, I would describe it as 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. 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.

9:55I think, you know, there's a healthy percentage of the book is about hiring and interviewing, maybe 20 % of the content that was written over the entire lifespan of the writing journey. Yeah, very, very cool. Now, okay, let's 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 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? Great question. The book is for CTOs, but it's for anybody who is really in any kind of technical leadership position.

10:31And so it's not just if you're a C-level, if you're a director of engineering, 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. I think the book is also helpful for that use case. And so, you know, I think 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. But the subtitle, Essential Skills and Best Practices for High-Performing Tees, that's what's actually in the book, right?

11:06And so it's a collection of, take different topics that are important to technical leadership, and here's some best practices, and some skills and some perspective on how those subject matters can be addressed. That's really cool. And what I like that you said most 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 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.

11:43right this is kind of gives you something to be ahead of the curve or like what what it how should i be thinking 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 co-workers have and your co-workers could be other software engineers or your manager is also a co-worker right understanding what are the stresses that are placed on management even if you don't ever want to be a manager you don't want to be responsible for people and performance reviews like 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 is terrible like why do 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 maybe allows you to be more supportive and help improve these processes in a better way.

12:45Yeah, or even do better on your performance review. Understand the concept. 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're outlining in the book? So the book has three main chapters, let's say, or 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.

13:26right 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 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, is the idea of the hippo, right? The highest paid person's opinion, HIPPO or whatever.

14:03And 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. And that might change your behavior and how you present yourself in a meeting. 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 want to hear everybody else's opinion. I don't want to 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's the last thing I want, right?

14:40Yeah, that's like such a bad feeling when you're like one of the other contributors in the conversation. Exactly. Oh, the CTO said something and that shuts down the whole conversation, right? That's where you want to avoid. So yeah, so that's the first section is 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 in some way, shape, or form.

15:18And 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. But I would treat it as a checklist of like, yeah, you really should know all of these concepts if you're going to be a senior lead or an engineering manager. This is stuff like microservices versus monoliths, right? Like what is a service-oriented architecture? Understanding adempotency, right? Like why do I care that my services are adempotent, right? If you're a senior, you've been around the block, maybe that's old hat to you.

15:52But 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 some of these foundational concepts, you know, that's sort of what that third chapter is for. Okay, got it. So those are the three main sections. And 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 see so i'm very passionate about hiring 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 where one of the company's core tenets is they want to be a fun place to work and I've really been thinking about what does it mean to hire a talent that contributes to making a work environment fun.

16:55This is something I only touch on a little bit in the first chapter. I call it the culture interview and culture match. But I'm sure 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?

17:28You know, 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 strong place for that in the hiring process. But I think really 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. Most companies spend the vast majority of their time filtering resumes, going through interviews and technical streams, whatever. What percentage of the time thinking about hiring is actually answering the question, what kind of candidate or what properties does the best candidate have?

18:10What is their personality type? Are they more the attention to detail kind of person? Or are they a perfectionist? Or are they scrappy? Are they very vocal 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. I think different situations, different ones, these could be strengths or weaknesses. What is this person, what kind of company has this person worked at before? Where are they working now? If you're a small startup, I get this question all the time. I'm a startup. We have five people, 10 people at the whole company.

18:48And 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 from Netflix is going to be great for my company? I say, well, Netflix, obviously, phenomenal engineering team, 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 startup environment right and then just for some people they like it some people they don't and so that is an additional risk in that hire right versus you know 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 startups right the risk that they don't like your startup is much lower, right?

19:34Just 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 you're at the other end of the hiring process and you have two candidates who 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 up front, the easier that decision is out the back and likely the higher percent chance of success with that hire. Yeah, totally makes sense. I can say like I'm even guilty of that of like putting like too much effort almost into the interview process itself.

20:06Ton of effort goes there as opposed to like up front. Are we all on the same page of what we're looking for? Because also if you're 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. 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. I think it's actually, 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 should be the exact same thing in the job description.

20:55it 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 you know you want a scrappy engineer who's just going to ship code really quickly and the quality bar is low for whatever reason then 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 level of consistency of expectation for what does success for this role look like, right?

21:30And that the start of that process is your job description. Totally makes sense to me. And actually, honestly, best case, 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'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 fit. Because 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?

22:10People that tend to do better in those early stage settings? Yeah. You know, of course, I want to 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 candidates. But I think what is pretty safe to say 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. In that pre-product market fit time, you're throwing stuff against the wall as fast as possible to try and find something that sticks.

22:42And so you want to 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 going to 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 adapting. And I think if you get a mismatch there, that is, it's a really hard thing for morale, right? It's very easy 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.

23:13And then for the business to say six weeks later, actually we're not going to go this direction because whatever the market is telling us, throw away all the work you just did. You need to A, set the expectation up front that that's possible, and then just have a team that is okay with that, that they've signed on for that journey up front. I think that's a key thing that pre-product market could face. Great example. It's like willingness or openness to change. It's like, hey, you're going to be measured on your willingness to come up with ideas, collaborate, change the direction. How fast can you do that?

23:49We highly value that. And some people might self-select out, like, no, I like projects, long period of time, the direction set. I mean, I don't blame you. You know, there's a lot of really interesting problems in distributed computing, scaling. 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 C to A, B companies have. No, you would love to get there if you're Series A.

24:22You would love that to be your problem. Champagne problem, right? Exactly. Okay, cool. So, you know, first part of the book, I know there's tons of topics there. We only like talked about one of them, but I do really like that insider takeaway of like spending time in the hiring process on what is the right fit up front. 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. Sure. That's the technical leadership concepts. I think by one of my favorite pieces of this chapter is just the conversation around developer experience.

24:58And I'm so glad that sort of across the industry, this seems to be a phrase and an idea that's catching on very quickly. I think five or 10 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 was actually, I was talking to an engineer a month or two ago about, you know, what is DX? And 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.

25:37And 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 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 traceback that wasn't related to your code.