On our 10th episode, Eiso and Jason present a conversation dedicated to CEOs and everything they need to know about their engineering organization and leadership. From tech debt to dependency management and communication styles, understand engineering team's infrastructures, the timings and expectations of building product, and much more.
If you want to be a better CEO for a company that builds tech, this one is for you. If you're an Engineering Leader, or work in Software Engineering, this episode will have some great insights for you too.
https://www.podbean.com/player-v2/?i=h88q5-113251f-pb&from=pb6admin&share=1&download=1&rtl=0&fonts=Arial&skin=f6f6f6&font-color=auto&btn-skin=ff6d00
Heard a term or concept you want to learn more about? Jump to Topic Explainers
I remember going into my very first board meeting where looking around the board room at everybody besides myself and the CEO, it was financier, financier, financier, X marketer, X salesperson, financier. And they would talk about the marketing conversion funnels to sales efficiencies, to all of these different things about the business, which are incredibly important. Then they will look over to the product and say, "so what are you building? How long is it going to take?" The disparity and dichotomy were so stark. Over time, I've started to see how that is not actually how well-run boards are. But it's also a testament to how poorly understood product engineering has been in our industry.
Something comes into the product organization, you sequence it, you figure out which team is going to work on it, and you do all of the dependency management at one time, in one big grand "planning process". And so sometimes the small things do take longer to get done in that model. But I think that the lack of understanding comes from when the CEO might've seen an engineering team of five people, very early on and they always want to get back to that same sort of cadence and energy, which is, "Hey, five people just kind of like frenetically worked on everything, and therefore they were able to blow through features really quickly. Why can't we do that when we're 500 people?" Well, that doesn't scale. That's the point of five people and frenetic energy, that type of stuff doesn't scale.
So imagine you have a CTO who is incredibly technical-minded. Very architecture-oriented, but "prototypey". You ask that person how long it's going to take to do something, you're going to get a very different answer than if you ask a VP of Engineering who's very process-oriented, very methodical, and also very completionist. And you have to understand and how to filter the answer, how aggressive somebody is or how conservative they are, or how hell-bent on perfectionism they are.
There's the concept of gardening if you want to use it for software, which is, you can let your garden go for a year, but the amount of effort you're going to have to do to maintain that garden once a year, the cost, the energy, the effort is very, very high. But if you were to do just a little bit of work every week or every month, or better yet, just a little bit every day, you always have an actually maintained garden. Which one of those worlds do you want to live in?
Product can't tell you how long something's going to go take. They can actually go do the coordination with people, on the engineering side, to go figure out how long it's going to take, but when you ask a product person, on the spot, how long is it gonna take to get something done, you're gonna get a made-up answer. If you ask an engineering leader at that same moment, it will be a little bit more educated, but it'll also be made up. So instead of asking them how long it's going to take, ask them what makes this possible in certain timeframes and what are you trading off.
I want everyone in engineering to hear this. Think about who you report to, who they report to and who they report to, all the way up the chain. Now imagine that most of these people are probably reading your status update on the phone. And what they really need to do is within one screen, have one emotional feeling come through for this. Either, "oh, crap, I need to go do something," or "they seem to have this under control. Let me follow up with them." Your job as the person reporting these things up is to give enough information at a high level so they're aware, give them a sense of burning urgency or "I've got this" and drive that "I've got this" home with what steps you're taking and how you're going to follow up with it.