Are You Really Thinking Like a CTO? with Alan Williamson, CTO & Author

(Josh at 00:00:01) Today, we're talking to CTO and author, Alan Williamson, about the most valuable lessons from his latest book, Think Like a CTO. You're listening to Joel Beasley, modern CTO.

(Joel Beasley at 00:00:16) We'll just jump right into it, Alan. I found you because I was looking for books that people were writing about thinking like a CTO, being a CTO. I've been studying the space for a decade, and I just saw your book. Did it recently come out within the past year or so?

(Alan Williamson at 00:00:32) Yes. Last June.

(Joel Beasley at 00:00:35) And why did you decide to write this book?

(Alan Williamson at 00:00:37) It's a great question. So, basically, I've been involved with helping CTOs and VP of engineerings evolve through my work in the private equity space. So in the private equity space that I work in, Joel, we're bringing first time companies into the ecosystem of PE, and from that perspective, these are well established companies. You know, five times out of 10, the CTO isn't really being a CTO. It's just simply that they're the most senior developer that was there, and they know the platform the most, and they've evolved up through it.

(Alan Williamson at 00:01:15) So part of my role was to help professionalize the sort of soft skills that a CTO needs to do outside of what they're already doing with engineering. And that is, it's not a broad sweep, but most engineers, we suck at talking to other non-engineers. We descend into buzzwords. We descend into technical jargon quickly. We generally are very passionate people.

(Alan Williamson at 00:01:49) We don't present terribly a great argument. We're always presenting left or right. Our nuances is a little bit caught up in that. And part of my role was to help educate, what does the CTO do in a growing, evolving company that has a board of directors, has a suite of investors? What are they needing from you?

(Alan Williamson at 00:02:14) How do you present yourself to a board? How do you manage a budget? How do you manage things like security, compliance? Making sure that you've got a technical stack that can go through diligence without any problems whatsoever that may impinge what a company can do in the future. And what I found, Joel, I kept saying the same things over and over and over again, and one of the things that I realized was that there is very little help in this space for an emerging VP of engineering or a CTO that's ready to take that next step.

(Alan Williamson at 00:02:51) If you're a CEO or a CFO, you can go to Barnes and Noble and you're completely inundated in the number of leadership books that are focused in and around that. You're also inundated for books at a VP of engineering level looking down in terms of, how do I run an engineering team? How do I build an engineering team? How do I do project management? All the things looking down the way.

(Alan Williamson at 00:03:13) But there was a huge gap looking up and looking out. And that's where I sort of said, okay. I'm gonna write a book for me that I needed ten years ago that I would have loved somebody to come in and say, right. Here's pretty much the full gamut that you need to run. And I sat down.

(Alan Williamson at 00:03:32) I spoke to many other CTOs that had gone through the same sort of stuff. I said, okay, what are the big topics that you wish you had known about? And so I basically wrote down 15 chapters. Now each chapter could be a book in itself, go deeper. It's a book that doesn't have a story arc throughout, so you can jump into each chapter as and when you need to.

(Alan Williamson at 00:03:52) I mean, not all chapters are relevant for everybody. But the goal there was to sort of lay down the landscape and say, hey. This is what you need to be thinking about. You've got the engineering bit down pat. Fine.

(Alan Williamson at 00:04:05) Great. Wonderful. Now we need to make you far more accessible to nontechnical people.

(Joel Beasley at 00:04:12) So you spend a lot of your time mentoring CTOs on talking to nontechnical people.

(Alan Williamson at 00:04:18) Yes. That's probably the biggest part of it. It's trying to help an engineer communicate their ideas in such a way that a CEO or a CFO, which are two of the most important pieces on the chessboard, who are maybe not technically orientated, to allow them to be part of that conversation. Okay? So whatever it is that you're trying to do will inevitably always require money and time.

(Alan Williamson at 00:04:52) The CFO is the one that's gonna determine how much budget you really do have and will make you accountable for the money you're spending. And the CEO is the one who's gonna give you the time to be able to do it. And from that perspective, you need to be able to talk in their language as to the consequences of why am I spending $3,000,000 on this particular project? Why am I spending $100 on this particular service? Whatever the numbers are.

(Alan Williamson at 00:05:19) Why do I need to spend six months in this? Why can't I get it done in three months? Why can't I get it done in twelve months? What if I was to give you twice the development team? Could you do it in half the time?

(Alan Williamson at 00:05:30) All of these sort of conversations have to be done in a meaningful manner.

(Joel Beasley at 00:05:47) What are the mistakes that you see other than buzzwords? And what are some of the actual, do you have any good stories of actual mistakes that you've seen happen?

(Alan Williamson at 00:05:56) Sometimes, they'll get a little bit frustrated. And so I say, just trust me, because they can't find a way to articulate what it is they're looking for. You know, we often see, for example, languages that were probably a little bit too leading edge or bleeding edge to have been really chosen as a primary language. And what's happened is that the company has basically outlived the language, and now we're at a point whereby I can't find engineers for it, and I'm at the dreaded rewrite conversation, whereby we should have gone with this instead of that. I mean, typically, in today's environment, it's usually the JavaScript frameworks that are turning over so quickly.

(Alan Williamson at 00:06:46) So one has to be very conscious that while going with, say, a Vue or React may not be as sexy now compared to some of the other ones that are popping up, it will still be around because they're backed by large companies. Likewise, you know, nobody's ever gonna turn an eye if something's written in, say, Node or Java, but we may start to raise eyebrows if something's written in, say, Ruby or Go, for example, that just hasn't quite got the mainstream traction yet. But that's more at a macro level. Other sort of big decisions that CTOs haven't really grasped terribly well is budgeting. Perfect example is ask an average CTO, have you got the right number of engineers in your group?

(Alan Williamson at 00:07:39) And they'll inevitably say, no. I could always do with more. So, okay. Can you quantify that? Show me through data why you think you need more engineers.

(Alan Williamson at 00:07:51) And then they struggle. They struggle to sort of articulate from a data perspective.

(Joel Beasley at 00:07:57) They'll give you that email from the sales lead that sold a feature that didn't exist. They'll give you that. That's a lot. Ain't it?

(Alan Williamson at 00:08:04) But that's a great point, Joel. It's like, okay. Prioritization. A CTO has to say no. A CTO has to be able to say, okay.

(Alan Williamson at 00:08:12) We've gotta prioritize. Here are the options. Okay? And that's a perfect use case to talk through. A good CTO will be able to go to their management or their executive level and say, hey.

(Alan Williamson at 00:08:26) You've asked for all of this. I can't deliver all of this. You're gonna have to help me prioritize instead of making me choose what it is. But I have to give you the options and the consequences of each of those options. Right?

(Alan Williamson at 00:08:43) And they'll say, but I need it all. I said, well, that's fine. You know? I want the body of David with the head of Brad Pitt, but it's not gonna happen. Right?

(Alan Williamson at 00:08:49) No matter how much I work out.

(Joel Beasley at 00:08:50) Genetically, it might.

(Alan Williamson at 00:08:52) It won't. I hit that Peloton hard every day. It's not happening. But to have that strong personality, Joel, to be able to stand in front of your executive and say, guys, I know you want to have it all, but you can't. You can't.

(Alan Williamson at 00:09:09) And even if we were to hire new developers, it's gonna take at least a month, maybe three months time they're onboarded. They're found. They're recruited. They're onboarded, and they're actually knowledgeable in the company stack. So that's not a short term fix.

(Alan Williamson at 00:09:24) So we gotta decide as a group. We gotta decide as a team. And you can come back to me in a week's time and then change the goalpost on me again. And that's where a lot of the mentoring happens is figuring out the project management outside the way as opposed to inside your own group.

(Joel Beasley at 00:09:44) Yeah. That's great advice. I mean, there what you're describing is lessons that I've learned. You know? And it is true.

(Alan Williamson at 00:09:51) Awkward conversations to have. Nobody likes to say no to anybody.

(Joel Beasley at 00:09:54) It's against our human nature to say no. Sorry.

(Alan Williamson at 00:09:59) Well, yeah, you don't wanna be Mr. No. You don't wanna be the guy that people think that you're gonna say no. So you have to do what you said. Right? You have to come to them and say, hey.

(Joel Beasley at 00:10:07) I don't know. Here's the list. Help me organize this list. You know? And then you're involving them and you're basically having them. I picked up this skill with client work.

(Joel Beasley at 00:10:17) Right? When I was building apps for clients, they would just call me up. I've got this idea. It was great. Yes.

(Joel Beasley at 00:10:23) We're gonna do it. We should definitely make that happen. But where does it sit in the plan? And here's the amount it'll take. And are you able to write the check?

(Joel Beasley at 00:10:33) And so, you know, you'd put it back on them. But you, it's a hard thing to do because you have to hold the line. You have to help them be a part of the decision making, and you also have to be joyful or at least not a dick about it.

(Alan Williamson at 00:10:50) Yes. Yes. And that's where you need to be led by data. That truly is the key. And I mean, to try and figure out what is the throughput of an engineer, what is the throughput of a QA person, all of the different ingredients that make up an engineering team, they all pull in the same direction in terms of they all need to complete their job to be able to get a feature out or a product out.

(Alan Williamson at 00:11:15) And simply turning the tap on to produce more in each area doesn't necessarily increase the throughput.

(Joel Beasley at 00:11:21) Yeah. Because if you turn the tap on to increase more to build something, it's like, well, then how is that connected to revenue? Right? How is it really far away from value to the end user, or is it really close to value to the end user?

(Alan Williamson at 00:11:38) Yeah. And I think that's where, you know, as we think about the budgeting aspect of what a CTO does. And budgeting also means basically costing as well, which is, okay. Here's what I think I'm gonna spend, but here's what I did spend. And marrying up those two, at the end of every month, you can sort of say, okay.

(Alan Williamson at 00:11:58) I thought I was gonna spend $100,000 this month, but I only spent $90,000. Great. Why? Okay. Well, this person was off during that particular time.

(Alan Williamson at 00:12:07) Okay. Whatever it is, a lot of CTOs don't seem to have a true handle on the cost of their own department, and that's not just human capital. That's everything that they sort of go through. And it's just one of the first few questions that we ask as we onboard a company inside of this space is, okay. What's your production costs?

(Alan Williamson at 00:12:29) What's your development costs? What's your true R&D costs? What's your subscription costs? What is your recruiting budget? How often are people recruiting in your organization?

(Joel Beasley at 00:12:43) Always.

(Alan Williamson at 00:12:43) All of that sort of stuff. Exactly. You're absolutely right. You're always recruiting. How much time do you spend paying down technical debt?

(Alan Williamson at 00:12:52) All of this has to be factored into the overall big budget, so that. And that is always, I mean, you've been there yourself, I'm sure, whereby we'll look at the technical debt sprint this week. We'll push it next week because I've got this feature I need to get out. But all you're doing is you're incurring more interest on the interest you've already owed, so your technical debt gets worse. It's that one that always gets kicked down the can. So, again, a strong CTO is the guy that says no.

(Alan Williamson at 00:13:21) He's the one that says, no. No. I cannot let this one slip this sprint. It's gotta be done. Otherwise, we're gonna have a bigger problem at a later date, and I'm gonna have to shut down the whole production system in order to get this bit right.

(Joel Beasley at 00:13:40) I'd say that the weakest muscle that I encounter with just random CTOs would be their ability to, they fall in love with what they wanna do or what they wanna work on and what they think the software needs in relation to the software. And I think that's the mistake. I think they need to spend more time with the head of sales and marketing and the CEO and all be rowing in the same direction on, what are we trying to achieve as an organization? Because then that puts the technical debt into perspective. You know?

(Joel Beasley at 00:14:15) It lets you make decisions versus if you're just a really good product person and now you're the product leader, you're gonna solve the problems with product stuff. You know? You gotta develop these new business skills of figuring out what direction everyone's rowing in and then being a value add to that.

(Alan Williamson at 00:14:34) Yeah. And I think you bring up a beautiful point. There's definitely a strong cohort that simply don't even know what the end customer is doing or what the end customer's problems that they're needing to solve. Because at the end of the day, you're just a tool for them to build a business on top of you. Right?

(Alan Williamson at 00:14:53) So you gotta understand what they're trying to do with the tool. And I'm a strong believer that you've got to know what your end customer is doing. It's not to say you do everything your end customer asks you to do, but you gotta have empathy for them. You truly gotta be in their shoes to figure out, okay. Where is my platform causing you friction?

(Alan Williamson at 00:15:17) Where is my platform helping you excel? And where is that friction an acceptable loss at the moment, but will suddenly become an impediment whereby you may actually leave us as a customer? Right? And to understand that full makeup will allow you to have a much stronger conversation with head of sales, head of marketing, the CEO, the CFO, etcetera, because now you're talking in their language. Now you're talking in terms of the end customer, irrespective of what framework, what cloud platform, what database, what schema.

(Alan Williamson at 00:15:51) They don't give a crap about that. They just wanna know that it's gonna work and it's gonna scale as the business grows.

(Joel Beasley at 00:15:58) One of my favorite questions to ask CTOs is, how much time do you spend with your customers?

(Alan Williamson at 00:16:05) And what answers do you usually get?

(Joel Beasley at 00:16:08) I get a range. So I'll get virtually none or, oh, I should be doing that. A lot of people will know what they should be doing but not do it. So I get a lot of, oh, not enough. I talked to a customer here or there.

(Joel Beasley at 00:16:20) Or another one I get a lot is, oh, when we were first starting out, I was talking to customers all the time, but then we started hiring a bunch and engineering got crazy, and so I haven't gotten to spend time with customers in a while. And then there's the good response, which is, I spend a third of my time with customers. Right? That I think that's a pretty good amount of time to spend with customers. And then the question from there becomes, so people are saying, oh my god.

(Joel Beasley at 00:16:48) A third of time with customers. It's like, it's just my personal belief is that should be something you do. But then the question becomes, well, if I'm spending a third of time with customers, how am I gonna be able to do A, B, C? And then a lot of times, what's happening is their mind is imagining that they're spending time with the same set of customers.

(Joel Beasley at 00:17:08) But what should happen is your company should be growing, so you should move your window up. So you should spend your time with your top 10% of customers because then there's a revenue component to it.

(Alan Williamson at 00:17:20) Or you know who your top 10 customers are. I mean, that's a data point that a lot of people simply don't know. It's like, who are our big ones? And conversely, who are the customers that are costing us the most in terms of the amount of support they need or the amount of help that they always need? And is that because they just don't get it, or have we failed them in not providing the necessary tools to help themselves serve?

(Alan Williamson at 00:17:43) And you're right. That delta of not knowing what is huge, and that should shape your vision, which brings me on to another sort of small litmus test that I always do to determine, are you a CTO, or are you a CTO in name only? Which is, I put them in front of a whiteboard, give them a black marker. Give me your vision. Draw me your vision.

(Alan Williamson at 00:18:12) Those that can't do the vision, they're a VP of Engineering. Those that can do the vision have or are a CTO.

(Joel Beasley at 00:18:25) Yeah. Because you've got to be able to build for that too, by the way. There's tools to learn how to, like, visionary tools. I think I wrote something like ten years ago called, like, The Visionary CTO, and I bullet pointed out some tools to help people with their imagination.

(Alan Williamson at 00:18:39) To be able to lay out your vision in a heartbeat without preparation is what defines a good CTO from a poor CTO. Because you should always be selling that vision, and every decision that you make, every decision that every person inside of your group, should know what that vision is. And does that get me closer to the vision, or does it get me further away from the vision? And usually, if they do present a great vision through other conversations, I'll be asking various other members of their team, "Hey, what is the vision of the group?" to see how well they've communicated that vision. Is everybody marching in the same direction? And has everybody bought in to that vision? And have you allowed for voices to challenge you on that? And, you know, I've come across a lot of bad CTOs where fundamentally, they want, they're the only voice in the room.

(Alan Williamson at 00:19:55) Because they've said it, therefore it's decreed that this is the way we're doing it. And did you pull any input in from anybody? No. Because again, that ego has kicked in by saying, well, I've got the title, so therefore, I know everything.

(Joel Beasley at 00:20:11) Here's a fun one. I do networking calls, so I have emails that go out every single day, just, like, contact a hundred new CTOs every day. And I'll say, "Hey, let's do a fifteen-minute networking call." And then in these calls, I'm sometimes asking them questions to figure out where they sit in the stack. One of those questions is I ask them if they understand how paychecks are made. You would be surprised at the number of employees—

(Alan Williamson at 00:20:36) That's a good question.

(Joel Beasley at 00:20:37) They think that there is a magical paycheck fairy. They've never thought about it. Most, 80% of the people I've ever asked this question to have never even thought about it. They think you get a job, you get a number for doing a job, and that's just magic. "It's what the market pays" is what they'll say. It's what the market pays. That's how they come up with the number.

(Joel Beasley at 00:20:55) So I ask people, do you understand how paychecks are made? And the reason why I think it's important, and I'm kind of a broken record with this, but if you understand that people are giving you money in exchange for making their lives better, then you could say, okay, that's the value exchange. You're giving money for me making your life better, whether that's processing a queue faster or building whatever it is. And then once you understand that reason, and there's usually two or three reasons why they're handing you the money, then you can orient yourself towards doing those things better. Right? And you can then justify.

(Joel Beasley at 00:21:35) Be like, you know what? I was gonna have this team do A, B, or C, but that's not even why people pay us. And that'll provide a marginal benefit over here, but we could reallocate this $500,000 a year to just doing these things better, and then that'll make everybody happy. But until you understand how paychecks—and that's how you can justify. It's like, when I made the claim, I think you should spend a third of your time with your customers.

(Joel Beasley at 00:21:59) The reason why is because it's incredibly justifiable, especially if you're in a tech product where they're relying on you and trusting you and doing huge deals with your company. You need to have a presence with them. It's gonna be how you build trust and retain the customer. And when you look at your salary, you're like, yeah, a good portion, and the way my salary happens is because of that.

(Alan Williamson at 00:22:19) We're birds of a similar feather. I mean, you heard me at the start of the podcast when I said to Josh, "You earned your salary today." I mean, it's one of the questions I always ask people is, when you go home at night, do you feel you were worth your money? Would you have written the check to you if you were a contractor coming into your business? Did you earn your salary today?

(Alan Williamson at 00:22:41) And it's not that I want people to always be conscious of how much they cost or how much they—it's more about, are you sure you're still contributing? Are you still enjoying this? Is this a two-way street here? And are you truly getting it? But it does feed into the overall, get a metric on your overall operating budget.

(Alan Williamson at 00:23:06) And, you know, I've chosen SQL Server, and I'm now spending maybe six figures sending that money to Microsoft every year just for the sheer privilege of using SQL Server. What if I didn't do that and I chose something else? Could I get another person instead? Yes. That's what economics is all about. That's knowing where your dollars are going. We sometimes get a little bit complacent by saying, "Oh, that SQL Server budget, that's not my money. I'm spending the company's money." I said, no. No. No. We're spending our money, and is our money going in the right place? I would love two more engineers instead of the Oracle license I'm giving away. Or if I get the right DevOps person, do I need that support contract because this person knows as much about that particular platform or that particular software that I'm gonna get at the other end of a phone call?

(Alan Williamson at 00:24:04) So it's trying to figure out where is the money best placed. And at the end of the day, the company is looking to you as a CTO to make those correct, educated decisions. And if you do decide that SQL Server is indeed what you need, can you justify that to the CFO that you're needing to spend X thousands of dollars a month on SQL Server licenses? What is that getting the company in return?

(Joel Beasley at 00:24:33) In return and in relation to what their objectives are?

(Alan Williamson at 00:24:38) Yes. And saying it's the only database I know is not an acceptable answer.

(Joel Beasley at 00:24:46) Yeah. You know, I never thought about that, actually. There is a huge disconnect between, you know, first-time CTOs and their CFO, CEO counterparts. Because it's just a different—the skills that got you to product lead or whatever it is are not the same skills that you need to interact with the executive team.

(Alan Williamson at 00:25:04) Yeah. And they usually ask you the questions that you think, can I go away and think about that? Because you've really hit me with an interesting one. And that is one of the pieces of advice I give to people: if the CFO hits you with a question that feels, you're intimidated or you feel out of your water, it's okay to say, "I'm gonna come back to you on that one. I need to give this thought." That's an okay answer to it.

(Joel Beasley at 00:25:28) That is an okay answer.

(Alan Williamson at 00:25:31) Because you wanna be the guy that gives it a bit of thought as opposed to the always off the top of your head.

(Joel Beasley at 00:25:37) And if you're with the right team and you're doing something worth doing, those questions are gonna come up. The problem I do see happen, rarely, but I do see it, is people who don't know how to say they don't know.

(Alan Williamson at 00:25:54) Oh, we come back to our ego thing again, don't we?

(Joel Beasley at 00:25:57) Yeah. I mean, it's beyond me. You know, I do a lot of interviews. So literally, in many interviews, what I'm doing is I'm trying to find the edge of my knowledge. And I can tell that some people will—and we edit the interviews and everything—some people won't admit that we've hit the edge, and they give me weak answers or fluffy stuff. But then some people, when I hit the edge, they're like, "Oh, that's just beyond my, you know." You see it like the CTO of Verizon and at the top level of business and competency, they'll just be like, "I don't know that. I'm more geared in this area or whatever it may be." But they get really good at explaining how they don't know. So they don't sound dumb, like, "I don't know. I don't know." They do it correctly.

(Alan Williamson at 00:26:43) Yeah. Yeah. And, I mean, particularly each little area has their own vocabulary, and I'll often find myself, "Hey, guys. Wait a minute. I'm still Googling that acronym here. Can you just give me a minute?" Because the three-letter words that I thought you were talking about isn't the one that I think you're talking about. "Okay. Now I'm on, now I'm on track. I'm back with you again. Okay. So that's what XYZ means. Got it." Right. And it's, again, it'll bring a little bit of humor into it. You know, just don't feel like you've gotta know everything.

(Joel Beasley at 00:27:15) You've got some funny social posts. I was like, I like this guy. You're ripping apart hotel bathrooms, airlines, and everything. I thought to myself, wow, Alan's somebody that I will continue to—I will go add him and follow him after this engagement.

(Alan Williamson at 00:27:34) Well, it's funny. I've got a whole rant about coming on about Peloton, to be honest with you. Because, again, I, you look at this from the perspective of if you were the engineer or the CTO of Peloton, what would you be advising to your executive leadership? And that's always a great "what if" game to play, right? Because you're putting yourself into those shoes, and there's problems all over the space. And one of the things that I'm sure you're finding a lot yourself, we've gone through an awful lot of cyclic waves. Last year was crypto. Previous year was blockchain. Then it was big data. Then it was Web 2.0. Everything is AI now, right? And when you scratch the surface, you realize, okay, it's not AI. You're just calling ChatGPT's API. That does not make you an AI company. It makes you a consumer of API, so let's not pretend otherwise. But it seems to be that new frontier whereby there's another layer of intimidation for another layer for people to get that sort of imposter syndrome thinking, "I haven't kept up with AI. Crap. What's—I feel behind. I feel behind. I should be doing something in this space." And sometimes you just gotta sort of step back and hold your hand up, and that's why I do certain posts like that is to let people know that, "Hey, I have no clue about this space, and that's okay. I'm still getting a paycheck at the end of every day just because I don't know blah." So be comfortable sort of in your own environment, and I have a whole chapter on that, which is You, Inc., which is figuring out your own value, your own worth, and not feeling stressed about waking up and suddenly feeling the world has moved on because, hey, buttercup, that's gotta happen. We're in an industry that redefines itself every five years. What you were taught at university, I am not using whatsoever when I first, when I graduated as an embedded engineer thirty-five years ago. So I have to keep learning. This is what I do, and this is what excites me, but it doesn't mean I have to know everything about the computing space.

(Joel Beasley at 00:29:51) Let's do some rapid-fire best advice for first-time CTOs.

(Alan Williamson at 00:29:55) Okay.

(Joel Beasley at 00:29:56) What do you got for them?

(Alan Williamson at 00:29:58) Listen. Listen a lot. Listen to your counterparts, i.e., all the other C-levels in your organization. Learn what their problems are, what keeps them up at night, what their stresses, what their goals are, and learn about your own team's stresses. Do you really know what your team is struggling with? Have you got a true virtual open-door environment where somebody can come in and say, "Hey, I need this help"? The other great piece of advice I'd give is find a strong right hand.

(Alan Williamson at 00:30:43) Find that one person that you can truly trust. I have that one person. He's been with me for nearly fifteen years now, and he's the guy that will effectively shut the door after a meeting and say, "What the hell was that?" He's never gonna give me the feedback in front of everybody else, but he's gonna come in and say, "Yep. Yeah. Probably could've said that better." And I listen and I value his counsel. Right? And that, a strong right hand, I cannot put enough weight behind.

(Joel Beasley at 00:31:23) Budgeting, would you recommend that for first-time CTOs?

(Alan Williamson at 00:31:26) Yes. Get to know your spreadsheet. Your spreadsheet does not have to be complicated. It does not have to be sexy. The most difficult formula you need in that spreadsheet is SUM. But just list everything. Everything. Everything from that one Balsamiq subscription that one person is using right through to the Azure or AWS bill that's on that. Every single line item. Get to know your numbers. Be comfortable with your numbers. Don't be intimidated by your numbers because the CFO's got the exact same numbers. He knows exactly, or she knows exactly, what you're spending, but you should be able to tell them what you're spending. And likewise, same with the salaries. Know the salaries of every single person in your group. Know what the market value is. So when it comes to appraisal time of the year and you're trying to fight the CFO for a 5% increase or a 3% increase, whatever it is that you feel that each person deserves, you're not there just to simply dole out money for the sake of it. You're not Santa Claus. But you're there doing it based on merit, and you're there doing it based on what that's gonna do to your budget.

(Joel Beasley at 00:32:36) And then what advice do you have for technical leaders staying out of the weeds? Like, if you see your team going to make a decision and you know that this decision is going to explode, do you step in, or do you let them fail on their own?

(Alan Williamson at 00:32:55) You sort of put guardrails around them that you let them stumble as much as possible without making too much of a problem so they can learn from it. You want to be able to let them play it out to a certain level so you can sort of say, okay, what I call a teaching moment. "Let's talk about how you presented that. As a person coming in cold, what do you think you communicated there?" "Well, I did blah, blah, blah." "Yeah. No. You didn't. A nontechnical person had no clue what that particular thing that you just described. What does that mean?" And so, "We decided we're gonna make the API—we're gonna make the platform all API driven." "Okay. Great. But what's the talking point for the CEO? What does that allow them to do?" And part of this sort of advice I give when you're thinking about that is you're not explaining it to the CEO.

(Alan Williamson at 00:33:53) Get that out of your head. What you're doing is you're explaining it to the CEO in such a way that they can then explain it to their board and their counterparts. You're giving them the talking points that they can then make it into their own words and their own phrases, so when they talk confidently to the board or outside customers, they're talking about it in a comfortable, confident, comes across as "hey, you know what you're talking about" manner, as opposed to you're parroting somebody else's words and you really have no clue what you are saying there, because our body language betrays us when we're in that sort of scenario.

(Alan Williamson at 00:34:32) So as you figure out your own language, as you figure out how do I talk to my nontechnical engineering colleagues, you're giving them an education on how best they do that. And it's okay to jump into stuff and say—and I use a lot of analogies when I'm explaining this sort of stuff because, again, everybody loves a good analogy. We can get ourselves around a good analogy. Sometimes the analogy takes off in a world of its own. You're thinking, "Okay, we're spending way too much time arguing over the logistics of a certain analogy here."

(Alan Williamson at 00:35:17) I think we've missed the point. Let's bring it back here again. But ultimately, you're trying to be that fountain of knowledge, that fountain of trust, whereby the CEO feels, or any C-level feels like, "I can come and have a closed room, closed door conversation with you and not be felt like an idiot because I've asked you what you probably will feel like a dumbass question."

(Joel Beasley at 00:35:46) Yeah, I do that by mistake a lot. That is—when I—but that last part that you said, where I'll ask a question and then they'll feel like an idiot because they'll start to answer it and they'll be like, "Oh, I made a mistake." So you have to do that softly sometimes.

(Alan Williamson at 00:36:03) Yeah, I do the same thing with—you know, many times in my career, I've gone into the CFO's office, shut the door, and said, "Right, this EBITDA they keep talking about, what the hell is this all about?" And there's some phrases that keep coming up that I've had to, you know, sit down and say, "Okay, I have no clue."

(Alan Williamson at 00:36:24) I have not gone through finance school. I have not gone through business school. I'm a technologist. What the hell does this mean? Give it to me in dumbass terms.

(Joel Beasley at 00:36:34) Yeah. Yeah. The entrepreneurship helps cut a lot of these corners to be a great CTO from the business side, because when you're operating a small business, you have to understand the P&Ls, you have to understand cash, you have to understand customers. When you were talking a minute ago about telling a story in a way that it's useful for them to repeat that story, we learned that when we were selling into Fortune 1000s.

(Joel Beasley at 00:37:03) So the person that we would be on a call with, they never let you come talk to their team. They're like, "Oh, I'll field this and I'm gonna sell it to my team." Well, it turns out a lot of them suck at selling because they're not salespeople. Right? They're just whatever marketing people for us.

(Joel Beasley at 00:37:22) And so what we learned to do, we didn't get upset about that. We recognized where we were losing a certain amount of business, and we instead changed our pitch to only focus on the two or three things that they're gonna repeat later versus how we do it and why it's—but all this stuff. We just really focus on: here's the opportunity, here is the cost associated, here's how you can measure it, and here's examples of people that have done it before. Just a very few number of things, so then they would take that one sheet back to their team, and then they could have that one conversation to get us into a meeting to talk with everybody. And so we learned that.

(Joel Beasley at 00:38:05) And then I think that skill is applicable right to your C-level peers. Right? If you're gonna go talk to your CEO, they're gonna go back and talk with the board or their internal advisory network that they have set up within their friend group.

(Alan Williamson at 00:38:19) Yeah. And that's before we even talk—I mean, that's a whole other podcast—is how do you talk to the board level? I mean, those are people that are not involved in the day-to-day of the company.

(Joel Beasley at 00:38:30) So you've

(Alan Williamson at 00:38:31) got a level of abstraction from that perspective that you've got to decode some of the company language in such a way that your board members or your investors can truly understand why and what you're trying to achieve.

(Joel Beasley at 00:38:46) Yes. And they are usually the most macro, the board members.

(Alan Williamson at 00:38:51) And they think everything's simple. That's okay.

(Joel Beasley at 00:38:54) It is, because they have no details of the underlying problems, which is what I do. People call me up and they're like, "Hey, I've got this problem." I was like, "Well, that sounds simple, but I bet it's not."

(Alan Williamson at 00:39:04) Yeah. Yeah. Where's the detail on this, people? What's the detail?

(Joel Beasley at 00:39:07) Yeah. Well, this is great. Let's—we're gonna give away a copy of the book. So, Josh, what is the giveaway requirements? How do people win a free copy of Think Like a CTO by the great and powerful Alan Williamson?

(Josh at 00:39:23) Yeah. So people can send an email over to [email protected] and include your favorite advice from this episode. We'll pick two of you to win a copy of Alan's book.

(Alan Williamson at 00:39:34) Nice. Thank you, Josh.

(Joel Beasley at 00:39:37) Awesome. We did it, Alan. People are—you—they can buy the book on Amazon. I think that's where I found it. Right?

(Alan Williamson at 00:39:42) Yes, sir. Yes, sir. Joel, this was an absolute pleasure and I'm humbled to spend an hour with you.

(Joel Beasley at 00:39:48) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.