← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS The Startup CTO's Handbook With Zach Goldberg
00:41:01
BONUS: Zach Goldberg shares how to build high-performing engineering teams and master the startup CTO role In this BONUS episode, we dive deep into the world of startup leadership with Zach Goldberg, author of . We explore the critical transition...
Loading summary
Transcript53 lines
- [00:04]
Vasko
Hey there, agile adventurer. Just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast. Hello everybody. Welcome to this very special CTO series episode. And for today's episode, we have with us Zach Goldberg. Hey, Zach. Welcome to the show.
- [01:22]
Zach Goldberg
Hey, thanks so much for having me.
- [01:23]
Vasko
Absolutely. So for all of you to know a little bit more about Zach, he's a seasoned technical entrepreneur and executive coach and also the author of of the Startup CTO's Handbook, the book we're going to talk about today. He has a founder's mentality and a passion for systems thinking. Zach helps engineering leaders build high performance teams. And he also founded advance the World, a nonprofit inspiring youth organization in STEM through immersive experiences. And stem. Remind us what that stands for, Zach.
- [02:01]
Zach Goldberg
STEM is science, technology, engineering and mathematics.
- [02:04]
Vasko
So there you go. So STEM for young people all over the world. The link to the book is in the show notes, the Startup CTO Handbook. But Zach, before we dive into all of the lessons you've collected in that handbook, share with us. Why did you even start writing this Startup CTO Handbook?
- [02:24]
Zach Goldberg
Yeah, great question and thanks again for having me. So the book came about. I have a classical training in computer science and computer engineering. I went to school for it. I started my career as a software engineer and found myself early in my career as an entrepreneur, later on in leadership positions and realized that my original training on how to write software and how to think about software systems was not all that useful as a technical leader. Certainly it was a requirement for having conversations and being in the weeds about the subject matter of the technical work we were doing. But all of the people and the management and leadership and organizational skills that were required to be good at the job, I sort of had to learn through trial and error, learn through my own research and reading, and realize that as a CTO there's a set of skills that are generally applicable, sort of regardless of what your company is. You know, there are some things that will be different if you're doing B2B versus B2C. If you're at growth stage versus startup stage, there will be fundamental differences to your company. But regardless of the stage or your vertical, you'll always be hiring people. You're always going to be thinking about what efficient process, how many meetings do we have as a team. You'll be thinking about performance management, about who's performing well on my team and who needs improvement on my team. And so there's this set of people and leadership problems that's universal, universally applicable at startups and growth companies that I didn't feel like there was a single resource for. And I felt like I had put a ton of energy into trying to learn and become good at and work with peers on and get many mentorship on. And so sort of organically I was keeping a. I had a Google Doc with just a list of topics related to being a CTO that were non technical, right? Not how do I write unit tests or you know, what sort of architectures make sense in front end applications, but questions related to the leadership side, the management side of being a technical leader. And I invited friends as well to contribute bullet points to this list. And so I, I ended up after a month or two with six or seven pages of just bullets of topics related to being a technical leader that are not traditionally covered. And I was reading or had read Matt Mosheries, the Great CEO within, which was sort of a very to the point, concise handbook of topics for CEOs. And it seemed a natural extension of, well, Matt had done a great job for CEOs. There's sort of a gap here for CTOs. And so I took those bullets and tried to recreate the magic of the great CEO within but for the CTO. And about two years later the CTO's handbook was born.
- [04:59]
Vasko
And of course people listening to us are already thinking, okay, what were the items? Zach, Zach, what were those initial bullet points that you started with? Okay, we've talked about some of those. Hiring, performance management, we have this high level label for it people, leadership problems. But what are some curious, perhaps even surprising bullet points that ended up in your original Google document?
- [05:25]
Zach Goldberg
Oh goodness. Well, the magic of Gouldocks. We can go back in the version history and see exactly what those bullets were. But I imagine, I think a lot of it was there's not actually that much magic in being a good leader. It's about common sense frameworks for making good decisions related to leadership, strategy and people. And I think what ends up happening is there are a lot of opportunities to make decisions where you can just sort of shoot from the hip and you can rationalize it in the moment. But being a good leader is often about being consistent, about having predictability. So the people around you understand the strategy and they can also understand and predict what direction things are going and way decisions are being made. And having a framework to make those decisions allows for that consistency allows you to contextualize what's going on. And so a lot of the content became, what are the frameworks that are useful for making decisions? I think the most poignant example and what gets talked about probably the most is hiring. It's very easy to have a 30 minute phone call with somebody and think to yourself, oh, that went well, or that didn't go well, and make a hiring decision. So just based on a gut reaction after an interview. But if you have a framework that says, for every interview, I'm going to ask this set of questions, this is generally what good answers look like, this is what great answers look like. And then I'm going to look at it with some sort of methodical way and ask the question, was this a good interview or a great interview? And I can objectively compare this interview versus a prior interview or subsequent interviews. Now you start to add a bit of sophistication. There's a method to the madness of actually doing hiring that hopefully will lead to better outcomes and seems to do so in the real world.
- [07:08]
Vasko
And of course, a very important aspect of that method you just talked about is that you can always improve an existing method. But if you just do things off the cuff without preparing, any improvement will be by accident.
- [07:23]
Zach Goldberg
Yes, 100%. I use metaphors from gaming from time to time in the book. And also metaphors are actually just direct applications of the scientific method. When you're dealing with people, the right answer, there's not always a single right answer. And the answer will change day by day. And so part of your job as a manager is you're thinking like a scientist. You have a hypothesis of how something might work, you gather some data in the real world, you adjust your hypothesis, and over time you become a bit better and a bit better at understanding the people in the world around you just by having that curiosity that Willingness to adjust your mental models as you collect new data.
- [08:01]
Vasko
So talking about scientific method and learning, of course, you already mentioned that a lot of what you learned to write the handbook came from mentorships. And you talk about a personal story with one of your mentors, Max Mintz, and what he taught you to focus on learning. So why did you open the book that way? What was that lesson that from Max that you hope readers carry to their work as CTOs?
- [08:27]
Zach Goldberg
Yeah, if it's okay with you, Vasco, I'll sort of just recount that initial story. It's probably the most profound or impactful single coffee I ever had in my entire life. So prior to going to college, I was assigned Max as my advisor. And Max loved students. He loved education. He was very passionate about it. And so he invites his students prior to the school year, starting to meet him in person to start talking about your academic journey. And I had an idea of what I wanted out of college before I even took a single class. I wanted to do both business and technology. And, you know, my. My university had a special program for that, and there was an application process and a bunch of hoops to jump through and logistics. And so I wanted to talk to my advisor about how do I most efficiently go through the system to get into this program? And so I sat down with Max at a coffee shop in downtown Philadelphia, and I said, max, how do I get into the program? He looks me dead in the eyes. He takes my napkin from. He reaches across the table, takes my napkin, puts it in front of him, takes a pen out of his pocket protector and starts writing, draws an XY axis on this napkin. And he looks me in the eyes and says, what do you know about special relativity? And I'm thinking to myself, like, well, that's not really answering my question about this business program, is it? And he just refused to have any conversation about, you know, paperwork and business programs. And we spent about two and a half hours, you know, probably in vain, trying to teach me the basics of special relativity and. And. And physics. And over the next year and a half, Max and I would have many more conversations about, you know, business and technology. But Max didn't care about what degrees I got, what paper I walked away from after my four years in school, Max only cared about how well I learned and my personal curiosity and passion for learning. And this is why he said, let's talk about special relativity. He wanted me to be excited about something interesting. He wanted me to dig deep and get curious about something hard, to really wrap my brain around and that process, not because he wanted me to become a high energy physicist or anything, but he wanted me to learn to deal with complexity and learned to love the idea of learning. And that that stuck with me. And I did take that away from my four years in college. I did not ultimately get that business piece of paper, that extra degree that I wanted, and it didn't matter. Right. I'm so much better off for those lessons of learning. And even after college, Max was a fantastic mentor to me. I had talked about writing the book with Max. Unfortunately, Max passed away a couple years before the book was published. And so the book is a tribute to him and to the value of learning.
- [11:06]
Vasko
Absolutely. And it sounds to me that Max would have been a great CTO, because that's one of the key characteristics of great CTOs. Right. Like they're passionate about learning and bringing others along to learn with them.
- [11:19]
Zach Goldberg
Max would have been a phenomenal cto. And I think there are hundreds and hundreds of students that were fortunate to have Max's tutelage over the many decades with which he was a professor and advisor. And I'm sure there are many successful CTOs because of Max's learnings, Max's teachings.
- [11:37]
Vasko
So you've also worked across multiple startups. You had every technical hat as you describe in the book, from engineer to CTO to founder. What are the consistent leadership mistakes that you see startup CTOs making and how does your book aim to help them avoid it?
- [12:00]
Zach Goldberg
Yeah, so there are a couple different types of mistakes. When you're buying a house, what are the three most important things when buying a house? You've probably been told at some point it's location and then location and then location. Well, when you're a leader of a new team in a startup, the three most important things are the people, the people and the people. And so having the right people on your team, who have the right mindset, the right passion, the right energy is first and foremost. It will impact everything that you do. And so step one is assembling the right team. You want the right blend of skill sets that enables you to actually bring technology into the real world. You want the right temperament. There's going to be ups and downs with every company. So folks who are, you know, who can see the long term picture understand that success doesn't happen overnight, who are motivated by the big picture and not necessarily by their, you know, just trying to maximize the size of their next paycheck and who are culturally aligned, who work well with the other folks on the team. And then the second category of mistakes is the class of investment, right? Every day when you sit down and write software code, you're basically turning some form of currency, dollars flows in the US into software code in some way, shape or form. And you're asking yourself, what is my return on that investment? And over what time span am I expecting a return on that investment? And what's somewhat unique to startups is the time span that the ROI matters is actually relatively short. As a startup, you are every day trying to earn the right to live another day. You're trying to justify that you have traction, justify your product market fit, make it to that series A, that Series B. That's ultimately what your business cares about, is these relatively near term objectives. And so your technology generally should also be optimized for those near term objectives. And one mistake is either under investing in those near term objectives or over investing. And for a longer term objective to make it concrete, you should not be writing software on day one for a billion users. Unless somehow LeBron James is going to tweet your app and get 100,000 users in one day. You're almost certainly not going to have crazy scale. And even if you did in 2025, the technology is so capable that for the vast majority of applications, you can be building on some CDN globally distributed platform that'll get you to very reasonable scale very quickly. So that's one end of the spectrum where you're over investing. You're building this huge architecture that doesn't actually ship quick enough. And then the other end is you're under investing. You know, the quality is so poor and the cost is so cheap that it actually impedes your growth. Right. And so there's a minimum bar of the technology is good enough to help us meet these milestones, to get traction, demonstrate product market fit, handle our current scale. But it's not so overbuilt that we can't move, that we're over investing in everything we do and that we can't move quickly enough to find the product market fit we need. And so there is sort of a Goldilocks sweet zone that the startup CTO is looking for there.
- [15:19]
Vasko
Yeah, absolutely. And of course that trade off is not necessarily easy because you have a lot of pressure coming from multiple stakeholders, your own team, you have the, I mean, at least many of the CTOs that I've worked with had, they have this problem of trying to please the their stakeholders because you know, even the boss has a boss. Everybody's got a boss, right? And then you have also the team that you know is clamoring for, hey, we should really invest in this new technology because the old one is not motivating anymore. Whatever. There's this bunch of conflicting requirements that are all converging on the cto. What are some of the tips you have in the book to help CTOs handle and navigate these different pressures that are coming at them all the time?
- [16:09]
Zach Goldberg
Yeah, there's two lessons I think I'll call out from the book. The first is don't treat technology as a religion. Right? Think of technology as each particular tool, you know, react or angular or whatever framework you're looking at. They're just tools at the end of the day to get a job done. Right. And before you can make a good decision about, you know, my team is pressuring me to adopt this new tool. Should we do we do it or do we not? The first question you have to ask yourself is, well, what does the business actually need, right? Does the business need a cutting edge, globally distributed non SQL data store or can we get away just fine with some super cheap postgres box somewhere which will be simpler, have better library support, have better documentation, so on and so forth, Right? And so I advocate in the book I reference a pattern called boring technology that in most cases the boring answer is the right answer for the business. Right? And in general, your job as a CTO is to optimize for what's right for the business. At some point you're optimizing for morale on the team. You're trying to hire the smartest, most creative people and giving them opportunities to work with. The new and shiny tool is part of motivating the team. But you have to balance that with what does the business actually need. And certainly early on at a startup, it's a relatively low priority, giving the team the shiny new tools just for morale's sake. And instead you're focusing on what's going to get the job done again for that near term time horizon. The second piece when it comes to working with stakeholders is you're optimizing for at the end of the day, velocity is what you're trying to ship for. And the way you unlock velocity is you focus on what allows the team itself to move quickly. You're not focusing on the outcome of velocity, you're focusing on the input metrics to velocity. And what are the inputs that enable developers to go quickly. Well, they have good tools. Their tools are laid out in an organized way. When you pick up a tool that actually works so to make that concrete, the code base is reasonably organized, it's reasonably well documented, something AI can help with quite tremendously. Nowadays, the test suite is reasonably reliable. It doesn't flake. When a developer picks up a code base to add the feature to an application, their path to go from I got this ticket to I have the application running to I can make my change to I can test my change is relatively straightforward. They're not going on side quests. They're able to actually get the work done that they tried to get done. And so the developer experience ultimately is a very strong input metric to velocity. And so if I'm working with, you know, a CEO who's saying, well, why is this thing not going faster? I can feel confident, well, it's because of the fundamental nature of the thing we're trying to build, not because we're tripping over our own feats, because we can't have our testing in order, so on and so forth.
- [19:01]
Vasko
That's a great, I think, balanced perspective. One of the things that you mentioned there is rather important. Although developers, tech people in general are motivated by the new and shiny technology, what really helps them do the day to day work and get things done might be things like, you know, there's an off the shelf development environment in the company that they can just, you know, download the virtual machine and start coding right away without having to go through a number of yak shaving sessions. This is what we called it in my time, yak shaving sessions to get even. Just the basic things to compile if that's the case, or to run if that's the case.
- [19:42]
Zach Goldberg
Right, yeah, exactly.
- [19:44]
Vasko
And I really like how you phrase this. You are optimizing for velocity. But I do want to be a little bit specific here because when people hear that, some might think, okay, but velocity is just the number of things delivered, whatever, like number of stories completed or whatever. But, but you're not just talking about that, right? Like, because from a CTO perspective, it's actually not the number of things that matter, it's the time it takes to go from having a great idea to having it tested out there in the real market.
- [20:15]
Zach Goldberg
Right, exactly, yes, thank you for pointing that out. Everything is anchored on the value ultimately delivered, right? Yeah. Measuring how many pull requests or pickup time or defect rates, all of these things are indirect measurements to and get at are we delivering value for our customers? And so whenever I use the word velocity, I'm not generally referring to how many story points or sprint points or whatever you're Getting done in a sprint. I'm referring to how quickly can you get something out the door for customers that's validated, that's actually moving the needle. Right. Is it making the product faster or more responsive or better adapted to the use case or whatever it is? And when I'm reporting to a CEO and I'm putting together a slide deck, I don't put story points in my slide deck for a board or for a CEO. Right. I put, what are the features that we delivered? How did technology deliver value for our company? Am I building tools that make our internal processes more efficient? Are we delivering new value, new features for customers? Are we expanding our TAM for who our sales team can talk to by supporting additional platforms? This is the nature of the conversation on an executive level. Not, you know, did we move from 16 points a week to 18 points a week? That doesn't mean anything to your board of directors. But what does is, well, now we can target this whole additional segment when we go to market for sales.
- [21:34]
Vasko
Yeah, absolutely. And it's really important to say that, right? Like, CEOs don't care about story points. They care about what are the things we delivered that actually made an impact with the customer.
- [21:44]
Zach Goldberg
Right.
- [21:45]
Vasko
It's very important.
- [21:45]
Zach Goldberg
And that's what you should care about as well.
- [21:47]
Vasko
Everybody. Right? And we should organize and optimize for that. Exactly. You also talked about something else that I thought was a really insightful and important realization for all of us who are perhaps on track to become CTOs ourselves. Right. Because of course, not everybody needs to become a cto. But of course, some people naturally gravitate towards those positions because they have a desire to influence and direct and help teams deliver. And you had this idea of the professional skill tree. Explain that for us really quickly.
- [22:27]
Zach Goldberg
Yeah, I love this one. It's hopefully a relatable metaphor. So if you've ever played any sort of video game that has a character progression, an RPG or something along these lines, imagine even if you're not a video game person, you can imagine when you start a game, you begin as relatively low capability, right? There's not that many things you can do, you're not that powerful, your magic isn't that strong, so on and so forth. But you're going to go out forth and venture and you're going to do a bunch of quests and do many things, and hopefully you're going to level up, right? You're going to gain additional skills, your magic's going to get more powerful, you're going to speak more Languages, whatever. And so the way video games manage this is usually there's literally some sort of point system and along the way you get to make decisions as to where to put those points. Do I put those points into speed or strength or whatever? The same thing happens with your career. Every day you go to work, you are learning something, you're getting better at a certain type of skill. Maybe it's putting together presentations, maybe it's writing code, maybe it's tests, maybe it's writing requirements, documents, whatever it is, every time you do those things, you're activating a muscle and the muscle gets stronger. And so what I'm doing is I'm making it explicit that those are investments you're making every day, and you have a conscious choice about where you're making those investments. And so if you're spending, you know, 35 out of 40 hours a week writing code, then I'm expecting you're getting better at code, but you're not necessarily getting better at writing documents or managing people or doing hiring. Right. And so if your goal is to become a cto, the question you should be asking yourself is which skills related to being a CTO do I need to be investing more skill points in and how do I find an opportunity to gather those points and be making those investments?
- [24:13]
Vasko
Yeah, and for us, investment investing skill points is that it's rather easy. It's just how much time are we exposed to that skill, whether it is observing or executing.
- [24:24]
Zach Goldberg
Right, exactly.
- [24:26]
Vasko
And, and you, what you just said about if you're always coding, you're just get getting better at coding, actually is a great intro to the next question, which is this, I would say unfortunate but perhaps also necessary situation that when people are promoted to a management position, they typically get there with what you would call a level 100 engineer skill set, but a level 1 manager skill set. Right. And of course we still need to learn. So what are some of the tips, some things you have learned from your own career that really helps us to find, select those skills and then really create the space in our work lives. Right. To learn those skills so that we might level up using the metaphor in that management side of the skill tree?
- [25:17]
Zach Goldberg
Yeah, I think it's very fortunate that the way building technical projects works, actually there is a relatively smooth on ramp to go from engineering to management, if you're thoughtful about it. And so what tends to happen, and what I encourage people to be conscious of is if you are a senior engineer on a team, you've become very good at the skill of coding, you understand the problem your product is trying to solve. What tends to happen over time is you informally or formally become the tech lead of the project. And so now you're not necessarily managing anybody. Your job title is not a manager. But now you're organizing work for other engineers on the project. You're perhaps responsible for their code reviews, you're setting a culture and a set of standards for how technical work is done on a project. Well, these things are quite a bit similar and very much alike to what being a manager is. And it's sort of doing some management skills without being a full time manager. And so if your goal is to get into management and you're concerned you're a level 100 engineer, but only a level 1 manager, then look for opportunities to be a tech lead on technical projects. Start investing some points into management skills before actually being a manager. And then when you, you know, if and when you have the opportunity to go into management, you're not starting from scratch, right? You have some, some, some time under your belt, running meetings, putting together documents to explain things, setting culture, setting standards, holding people accountable for doing good work and these kinds of things. And then once you've realized that, okay, you, you've gained a few skill points as a manager, what you'll realize is there's actually another million skill points that are required to really be a great manager. Being a great manager is a lifelong journey and at that point you look for every opportunity to accelerate that journey. That's reading books, finding a mentor, working with a coach, having a management peer group. There's lots of ways to collect signal on being a great manager. And the number one correlated element with being a great manager is wanting to be a great manager and putting in the effort to pick up those skills and keeping that fresh.
- [27:28]
Vasko
Yeah, absolutely, that's very well said because as you said, it is a lifelong journey, but it doesn't need to be led or traveled alone. Right? Like finding a mentor. Finding a group of peers within your organization or outside and practicing those skills will get you up the skill tree much faster. Now, one thing I wanted to add to what you just said and get your feedback on that is that of course not all leaders come from a coding background. Right? Like this could be product managers, this could be UX designers, this could be testers, this could be scrum masters who are not necessarily level 100 engineers, but they could be already maybe level 3 or 4 manager because they've been practicing those skills. And I think it's important to recognize that the process applies to everybody. Right. Like this is not just, you know, only engineers can be CTOs. That's not the case because being a CTO goes far beyond understanding the details of the technology. Right?
- [28:33]
Zach Goldberg
Yeah, absolutely. I think one thing that's unfortunate about this conversation is when we talk about cto, that means many different things at many different places and in many different companies, and it changes over time. The job of a front end react engineer is by and large relatively predictable and well understood between companies. Like if you tell me you're a react engineer building front end applications, I have a pretty good idea of what your job is like regardless of what company you work for. But if you tell me you're a cto, then what you're spending your time on day to day is going to be very different today versus next week versus a year from now at a startup in California building consumer tech versus a B2B company somewhere in Europe. Right. Like the, the, the day job of being a CTO is very variable. And so. Yes, absolutely. Depending on the circumstances in the company, what that person's background is, what skills they're exercising is going to be highly variable. But there's always going to be a technical strategy component to using technology. But what that means will be very different in different places.
- [29:41]
Vasko
Yeah, absolutely. Well, picking up on that, you also talk about Kaizen, this culture of continuous improvement. And this is something many of our listeners are intimately familiar with because that's something we talk about on a regular basis. But of course, when we are in a startup, there's this, let's say, balancing forces of the need to improve over time and the need to deliver results short term. So what are some of the tips you have for us exactly in that regard of balancing this? We need to be getting better as team, as an organization versus we need to deliver today.
- [30:22]
Zach Goldberg
Yeah, the, the healthy tension of fast and quick, sorry, quality and speed. You know, I think of it as, I like the finance analogy. We talk about technical debt, right? And we use that phrase sort of offhandedly. We don't get too sophisticated about the debt part. But if you do apply the analogy with a little bit of depth, you realize it's actually very applicable. You think of traditional debt, right? You get a mortgage on a house, right? Well, there's some sort of principal payment that needs to be covered over time and you're gonna, the way you're gonna do that is you're gonna pay it down month over month and there's an interest if you don't pay. Right. Like and so if you think of your technology the same way, you make some sort of decision that is a shortcut, right? You decide not to do some sort of architecture or you decide not to invest in thoughtfulness on an abstraction. You just take a shortcut, whatever it is. Now you've got your principle and the question is, how much interest is there on that debt and what is the strategy for paying it off, if ever. And so at a startup, you're probably accumulating debt more quickly than you're paying it down. But if you're conscious about that trade off, then you can choose which debt has high impact and make investments in the stuff that's really going to slow you down, and then consciously choose not to invest in the debt that doesn't impact your business in the near term. And that's difficult, especially that last part. To choose not to tackle some of your debt feels wrong, it feels sloppy. It's like, oh, you're not really a good engineer, there's a sense of pride and we don't have debt. But the reality is you're going to, whether you know it or not. And if you're consciously making a choice to say we're not going to tackle this debt and that frees you up to say yes to other pieces of debt. And so you do need to be making payments, but you need to choose how much. And especially early days when urgency is of the utmost and there's not that much there, then the investment will be small, but there must be an investment over the medium and longer term to continue to enable that velocity as things go.
- [32:31]
Vasko
Yeah, absolutely. And I think that the Kaizen idea really kind of encompasses that thought really well because it is about making sure that you're constantly paying some of that principle on the technical debt over time instead of just saying, hey everybody, let's stop and let's do nothing else for two weeks than pay technical debt down. And because that's never going to happen in a startup environment.
- [32:56]
Zach Goldberg
Yeah, very seldom and I have seen it done. But I think it really depends on how stable things are, where you're at on product market fit, what sort of support, burden and requirements you have with your customers. But certainly early on pre product market fit, the idea of not developing features for two weeks is very painful and unlikely to be met with much change.
- [33:18]
Vasko
I've seen it done one time in my career and it was not a startup. I imagine some startups might do it, but it's hard to believe though another aspect that you talk about, which is, I guess A critical aspect of the leadership role that CTOs play is the the importance of communication. You talk about email hygiene, radical candor. In your view, what's the single most undervalued habit that can help tech leaders, especially startup tech leaders, really get their performance up and really be on top of the situation with their teams?
- [34:00]
Zach Goldberg
I think the single hardest skill and the single most valuable skill, especially for very technical leaders, is that of audience empathy. Right. You have an idea in your head that you're trying to communicate and it's probably very simple to you, right? All of the inputs that led to that decision, all of the background technical knowledge, it's at the front of your mind. And so therefore the outcome is obvious. And then when you go to explain it to people, a common pattern will be you make large assumptions about where your audience is at as far as their understanding, their alignment, and you jump very quickly to whatever the outcome of the solution is. And in some audiences that's appropriate. But by and large, pausing and asking, what does my audience actually already know? Do they have this technical understanding? Have they already been reasonably and rationally walked to the insight? And then calibrating how much depth you go into in your communication based on where your audience is already at is just critical to getting people and getting audiences to follow along and getting them to the same destination you're trying to get them to. Right. Whether that's explaining a technical strategy or explaining why a bug occurred. If you walk into an executive room after an outage and just immediately say, well, the Kafka queues were overloaded and we had too much memory pressure and thrashing and we didn't have a large enough swap space, I'm not making something, obviously, but like whole bunch of technical buzzwords, right to the maintenance, the SRE engineer on call, yeah, of course he understands that explanation, but your CFO has no idea. Your CFO wants to know, was there a process that failed? Did we not plan appropriately? And so.
- [35:45]
Vasko
And how does it calibrate the AWS costs for the month?
- [35:48]
Zach Goldberg
Yes, and our future AWS cost. And so having that empathy, using the right kind of language, starting your explanation at an approach appropriate altitude and appropriate level of technical depth, and then walking people to that final conclusion. And it's all about just empathy with the audience.
- [36:07]
Vasko
This is a great lesson because that empathy with the audience is at least, if not even more important when talking to the teams that we work with in leadership positions, because they are also not in the same place we are.
- [36:24]
Zach Goldberg
Yeah, absolutely. And I see this every single day. When it comes to leadership, part of leadership is being decisive. Right. And sometimes you have to be decisive about things that not everybody agrees with or that is bad news. Right. We're not going to have a major company Christmas party in Hawaii this year because we didn't perform well enough. Right. The budget doesn't afford it. Right. So as a CEO, you're very factual. You know, making this story up. This didn't actually happen, but it's a good example. You're very fact based, right. You're very rational. It's like, okay, we're not going to spend $50,000 on a party, move on. Right. But to the company who maybe had that expectation, because perhaps it's been done in the past, maybe it's been messaged, the fact that we're not doing whatever this event is like could be a signal that something's really wrong. Right. Maybe they don't have the context around the budgeting to understand why we're not doing whatever this event is. And so taking a step back, walking people to the decision, empathizing with the fact that maybe this is disappointing. Right. And looking forward to the future with, well, how might things change? Really adds context and gives people a lot more sense of support and really helps with morale as you walk through what can be difficult times at startups.
- [37:36]
Vasko
Absolutely. Communication, Communication, communication. The three most important things about being a leader. All right, Zach, it's been a pleasure. So everybody check out the Start Startup CTO handbook. The links are in the show notes. There's a bunch of different ways to get the book on Amazon as an audiobook. The GitHub site which is also up, and the original already outdated Google Doc is also available. So check it out. And Zach, if people want to contact you to connect with you, maybe ask a few follow up questions, get in touch. How could they do it?
- [38:17]
Zach Goldberg
Yeah, you can find me at ctohb hb, short for handbook.com and or I'm zack, zackgoldberg.com as well.
- [38:27]
Vasko
Absolutely. We'll put the link to those in the show notes as well. So you guys can go and ask a few follow up questions from Zach. Zach, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [38:39]
Zach Goldberg
It's been an absolute pleasure. Thanks again for having me.
- [38:44]
Vasko
Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile.
- [39:02]
Zach Goldberg
Every day.
- [39:03]
Vasko
We're talking access to over 700 hours of agile Goals, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community.
- [40:33]
Zach Goldberg
Slack.
- [40:36]
Vasko
We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is carrying.