Fact: There are guidebooks for everything in programming except for actually leading, managing, and inspiring programmers.

That’s why I was so happy to have my friend Zach Goldberg on the podcast.

Someone who has made learning and self-improvement a core pillar of his professional and personal life, Zach Goldberg is someone who I turn to when I need to know who smart CTOs are turning to.

In this great conversation, Zach talks about the most important things he’s learned in separating signal from noise in the realm of engineering leadership. He also provides some amazing guidance on who you should be listening to (when you’re not listening to us). Enjoy.

Episode Highlights Include:

• (2:20) There are few truths in software engineering
• (11:45) How Audible changed Zach's life
• (17:22) The teachings of Martin Fowler
• (21:09) Applying ship/show/ask to your team
• (32:05) Transformation: shipping once a month to daily
• (47:11) Imperative engineers be fluent in architecture

Conversation Excerpts

On Listening to Books at 3X Speed

Dan: Let's start there. Like, why is Audible so important to you? How did it impact your life?

Zach: So the way I consume information and you know, I'm an impatient person and I recognize that, you know, there's strengths. There's good and bad to that as a personality trait. You know, I'm trying to work on that. But one of the, you know... catering to that, trying to leverage it as a strength. I've picked up speed listening. So Audible has a speed slider in the bottom. And so, you know, I regularly listen to nonfiction books between 2 and 3x speed. And so an ordinary business book, generally speaking, 8 to 12 hours of audio content. If you listen at 2 or 3x speed you know, you bring that down to 3 to 5 hours. Now, all of a sudden that's you know, that's my car ride for the weekend. If I'm going to take a 2-hour trip to go somewhere, 2 hours there and back, I've got a whole business book done in one weekend. And so, you know, the way I hold myself accountable to that is I have a spreadsheet where I track all the business books I've read and I take little notes like what were my key learnings from these? And you know, which ones I'd like to re-read in the future, things like that. So yeah, so the story goes probably seven, eight, nine years ago my co-founder Lukens was listening to audiobooks all the time and he said, You should really do this too. And I said, "I don't have time for that." But, you know, he sort of pushed me on a little bit and I started doing it and I'm like, Wow, like I'm learning a lot. This is sort of fun. I'm walking down the street whenever, you know, I get half an hour in here, half an hour there. You'd be surprised how quickly it becomes a habit and how quickly you find excuses. You know, you're in the middle of a book you're really enjoying. You find excuses to go for a walk or go for a drive or run on the treadmill, whatever it is, you know, to listen to whatever that story or whatever that lesson is that's interesting.

There Is No CTO Playbook, but There Should Be

Dan: How is that kind of like, learning mentality helped you as a CTO?

Zach: Yeah, I think there's no handbook or textbook on how to be a CTO, right? Matt Mochary has written a phenomenal book titled The Great CEO Within. If you're going to be a founder of a company... I don't know, Matt. I don't get any money off this. I just think it's a great book. The Great CEO Within. This is sort of a guidebook on how to start a company, right? It covers everything from financing to hiring people to making business decisions, marketing. It covers the gamut. It's very broad, right? Not super deep, very broad to breath for search in how to be a CEO. I haven't found an equivalent, good book on how to be a CTO, right? And I think there are just as many concerns and different, like as you're saying, you know, hiring and managing people and architecture and technical decisions and frameworks. There's a lot of table stakes skills that are part of being a CTO. So, you know, to answer your question, how do I do it? I think it really does start with humility. You know, I recognize my training from undergraduate is how to write code and algorithms optimization and things like that. And yes, that's helpful in the job of being an engineering leader. And in fact, some of that education is certainly prerequisite. That is the key thing to acknowledge is one, the problems you solving are fairly universal, right? Like, as a CTO, every other CTO has similar issues: hiring people, keeping people happy. How do you organize the team? Thinking about process. So a little bit of humility will say, I'm not the first person to try and solve this problem. And so step one is to recognize, alright, what is the state of the art? How do other people think about this particular problem? And what I found throughout my career is that the combination of independent effort to try and find solutions, usually via books. That's sort of my thing, I'm a huge into audiobooks. But also just peer groups, working with mentors. Generally, you can talk some of these kinds of problems out and find resources that can help level you up really quickly. Sort of ramp up that learning curve. Because there is no textbook to know all of these things.

Video

While you’re here, check out this video from our YouTube channel.

Want to know how engineers at Slack and Stripe connect their dev teams’ work to the business bottom line? Or how do team leads at Shopify and CircleCI keep elite cycle time while minimizing dev burnout and maximizing retention? These are just two of the topics we’ll tackle at Interact on October 25th. A free, virtual, community-driven engineering leadership conference, Interact is a one-day event featuring over 25 of the most respected minds in development, all selected by the thousands of engineering leaders in the Dev Interrupted community.