Tech Titans: How to Know You’re Not Really a CTO with Alan Williamson

Today, we're bringing you our most timeless advice from our last conversation with Alan Williamson, author of Think Like a CTO. You're listening to Joel Beasley, Modern CTO.

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. Why did you decide to write this book?

It's a great question. So basically, I've been involved with helping CTOs and VPs of Engineering evolve through my work in the private equity space. 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. And, you know, five times out of ten, 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.

So part of my role was to help professionalize the soft skills that a CTO needs to do outside of what they're already doing with engineering. And that is, you know, it's not a broad suite, 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. We don't present a great argument. We're always presenting left or right. Our nuances get 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? 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.

If you're a CEO or a CFO, you can go to Barnes & Noble and you're completely inundated with a number of leadership books that are focused in and around that. You're also inundated with 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. But there was a huge gap looking up and looking out. And that's where I said, okay, I'm going to 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. I spoke to many other CTOs that had gone through the same stuff. I said, okay, what are the big topics that you wish you'd known about? And so I basically wrote down fifteen 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. 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. Great. Wonderful. Now we need to make you far more accessible to non-technical people.

So you spend a lot of your time mentoring CTOs. What are the mistakes that you see, other than buzzwords? And what are some of the actual—do you have any good stories, actual mistakes that you've seen happen?

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, yeah, 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, yeah, 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. So one has to be very conscious that, yeah, 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 going to 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 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? And they'll inevitably say, no, I could always do with more. I say, okay, can you quantify that? Show me through data why you think you need more engineers. And then they struggle. They struggle to articulate through a portal.

That email out from the sales lead that sold a feature that didn't exist.

They give me that.

Absolutely.

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, we've got to 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, you've asked for all of this. I can't deliver all of this. You're going to 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? And they'll say, but I need it all. I say, well, that's fine. You know, I want the body of Channing Tatum, but it's not going to happen, right? No matter how much—

I drink.

—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're wanting to have it all, but you can't. You can't. And even if we were to hire new developers, it's going to 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. So we've got to decide as a group. We've got to decide as an executive team. And you can't 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: figuring out the project management outward as opposed to inside your own group.

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.

Yes. Yes. And that's where you need to be led by data. That truly is the stuff. And I mean, to try and figure out what is a 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. And simply turning the tap on to produce more in each area doesn't necessarily increase the throughput.

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?

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 going to spend, but here's what I did spend. And marrying up those two, that at the end of every month, you can say, okay, I thought I was going to spend a hundred thousand this month, but I only spent ninety. Great. Why? Okay. Well, this person was off that particular time. 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 go through. And it's just one of the first few questions that we ask as we onboard a company inside of this space: Okay, what's your production costs? 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 you recruiting in your organization?

Always.

Exactly. You're absolutely right. You're always recruiting. How much time do you spend paying down technical debt? All of this has to be factored into the overall big budget. And that is always—I mean, you've been there yourself, I'm sure, whereby, we'll alter 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. He's the one that says, no, I cannot let this one slip this sprint. It's got to be done. Otherwise, we're going to have a bigger problem at a later date, and I'm going to have to shut down the whole production system in order to get this bit right.

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 want to do, or what they want to work on and what they think the software needs in relation to the software. And I think that's the mistake. I think you've got to develop these new business skills of figuring out what direction everyone's rowing in and then being a value add to that.

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 are 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? So you've got to 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've got to have empathy for them. You truly have got to be in their shoes to figure out, okay, where is my platform causing you friction? Where is my platform helping you excel? And 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, etc. 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, they don't give a crap about that. They just want to know that it's going to work and it's going to scale as the business grows.

One of my favorite questions to ask CTOs is, how much time do you spend with your customers?

Or even, know who your top ten 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? Yeah. And you're right. That delta of not knowing 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? 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. Those that can't do the vision, they're a VP of Engineering. Those that can do the vision have, or are, a CTO. 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. 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 into 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 to be the only voice in the room. 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.

Here's a fun one. I do networking calls, so I'll—I have emails that go out every single day. 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.

We're birds of a similar feather. I mean, you heard me at the start of the podcast when I said to Joel, you earned your salary today. I mean, it's one of the questions I always ask people: 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? And it's not that I want people to always be conscious of how much they cost or how much they're—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. And, you know, it's a sort of—yeah, 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 is just not my money. I'm spending the company's money. I say, no, no.

(Alan Williamson at 00:17:24) 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. So it's trying to figure out where is the money best placed.

(Alan Williamson at 00:17:52) 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:18:17) In return and in relation to what their objectives are?

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

(Joel Beasley at 00:18:29) Yeah. You know, I never thought about that, actually. There is a huge disconnect between 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:18:47) 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 intimidating 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.

(Alan Williamson at 00:19:09) That's an okay answer to it.

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

(Alan Williamson at 00:19:16) Okay.

(Joel Beasley at 00:19:16) What do you got for them?

(Alan Williamson at 00:19:18) Listen. Listen a lot. Listen to your counterparts, i.e. all the other C-levels in your organization.

(Alan Williamson at 00:19:31) Learn what their problems are, what keeps them up at night, what their stresses are, 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:20:03) 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, probably could've said that better. And I listen and I value his counsel. Right? And that strong right hand, I cannot put enough weight behind.

(Joel Beasley at 00:20:44) Budgeting, would you recommend that for first time CTOs?

(Alan Williamson at 00:20:47) 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.

(Alan Williamson at 00:21:00) Everything. Everything from that one Balsamic 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 has got the exact same numbers.

(Alan Williamson at 00:21:20) 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.

(Alan Williamson at 00:21:48) 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:21:55) Awesome. We did it. Alan, people can buy the book on Amazon. I think that's where I found it, right?

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

(Joel Beasley at 00:22:06) 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'd 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.