#150 - How to Think Like a CTO - Alan Williamson

[00:01:02] Episode Introduction

Henry Suryawirawan: Hey, what’s up my listeners. Welcome to the Tech Lead Journal podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening, don’t forget to subscribe on your favorite podcast app to get notified for future episodes. Also subscribe to Tech Lead Journal contents on LinkedIn, Twitter, Instagram, YouTube, and TikTok. And if you have been enjoying this podcast and its contents, support my work by either buying me a coffee at techleadjournal.dev/tip or becoming a patron at techleadjournal.dev/patron.

My guest for today’s episode is Alan Williamson. Alan is the author of “Think Like a CTO”. In this episode, we discussed in depth how to become a great CTO. Alan first described what a CTO role is, how the role differs at different companies stages, and the attributes of a good CTO. Alan then explained the importance of a CTO coming up with a vision and how we can all improve ourselves in visionary thinking. He then touched on how a CTO should work together and understand the expectations of the CEO. Alan also gave his tips on how to build engineering teams that can produce high quality results. Towards the end, Alan gave his personal advice on how a CTO can deal with imposter syndrome and the importance of a CTO doing a personal review.

I hope you enjoy listening to this episode and learn great insights on how to become a great CTO or engineering leader. Many of us aspire to become a CTO one day. And I hope this episode gives you some practical tips to build yourself into that direction. And if you enjoy listening to this episode, please share with your colleagues, your friends, and your communities, and leave a five-star rating and review on Apple Podcasts and Spotify. Your small help will help me a lot in getting more people to discover and listen to this podcast. And I really, really appreciate it. Without further ado, let’s go to my conversation with Alan.

[00:03:08] Introduction

Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have Alan Williamson here. So excited to have you here and we’ll be discussing a lot about the role CTO. I’m sure many of you are intrigued by this role. So today, I hope we have a good discussion about it. Welcome to the show, Alan.

Alan Williamson: Thank you very much, Henry. Honored to be here, my friend.

[00:03:28] Career Journey

Henry Suryawirawan: So Alan, I always love to start the conversation by knowing about you first. Maybe if you can share any career highlights or turning points in your career that may be good for us to learn from.

Alan Williamson: Okay. Well, I think being a child from the 1970s as it were, I started off life with my home computer, the ZX Spectrum. And I remember convincing my parents to buy me one of those. And for them, it was like a month’s salary for them. But anyway, fast forward a bit. I convinced them. And then I remember, I still remember it to this day, my mother’s face when she walked into my bedroom and I had it opened up. And I had things soldered into the back of it. And what I was doing was I’d figured out how to control my railway points, for changing points on my railway track, using BASIC in the ZX Spectrum.

And my mother just screamed blue murder, because this expensive piece of kit, I had managed to solder bits onto the back of it and trying to figure out what. And I said, look, but look at what I’ve done, I could, I can press this button, and it makes the train go that way now. The woman didn’t truly get the sheer genius of what I was doing. Many, many years. It took about 30 years for her to finally see, okay, that spectrum thing was a wise investment.

From that perspective, I’ve always loved this computing space. You know, I found university just, I was like a sponge. Bring it on, bring it on, bring it on. , I’ve never worked a day in my life. I truly do love this. And again, we’re in an industry where we reinvent ourselves every five years. And what I’m doing now with like cloud, serverless, all that sort of stuff. I mean, that’s not what I was doing 10 years ago, or five years ago, or 15 years ago. I absolutely love it.

So my career has always sort of been more from the embedded side of the fence. And as I’ve evolved through that, the embedded philosophies that we have in terms of memory constraints, processor constraints, multitasking, etc, with different areas of the embedded world. It migrates to the enterprise horrendously well, but just at a different scale. So all of the sort of the hardcore techniques and algorithms that I was taught 35 years ago is still as relevant today as what it was then. But it’s just in a different packaging now. And that’s why I always consider myself still a hardcore developer at heart, even though I’m at a CTO level now, as I guide and mentor other teams.

Henry Suryawirawan: Thank you for sharing your story. I think that childhood moment is, I think, very unique to you, right? And I think you could always remember it. But I think also another thing that I look from your profile, right? You have a very vast experience at the CTO level, so to speak, right? From startups, you know, SMEs, and even including from private equity firm, right? When you invest in different portfolios of companies.

[00:07:47] The CTO Role

Henry Suryawirawan: So today, we’ll be talking a lot about CTO role, definitely from your book, Think Like a CTO. But first of all, almost every engineers that I talk to aspire to become a CTO, right? But what does it mean to become a CTO, maybe a little bit of definition from you what is this role all about?

Alan Williamson: Sure. So you’re absolutely right. I mean, when I first started out, when I first graduated from university, I didn’t even know CTO existed. I didn’t know Chief Technology Officer was a thing. We always knew what the managing director and the CEO of a company did. But what did a CTO really do? A CTO, it’s about giving the business the technology it needs to be able to drive their success, okay? So from that perspective, you’re not simply delivering tools, you’re not delivering solutions, you’re delivering a vision. You’re delivering a roadmap to allow the company to be able to grow and scale at a level and at a speed where technology never holds up their growth, okay.

And in many respects, that’s the hard part that most, in my experience of mentoring and going through this with other teams, developers and senior developers have a problem with, is because they’re no longer talking to like-minded people. They’re now talking to the business. They’re now talking to clients. They’re now talking to board levels. So it’s a whole new vocabulary they need. They need to be able to distill down what is effectively complicated stuff into items that the board and the leadership can understand and appreciate. Because frankly, the board does not care if it’s Azure or AWS. Does not care if it’s Node or Java or Python or Go. They couldn’t give a crap about the latest framework. They just want to know, does it make our delivery of solutions to our clients easier or not? That’s all they’re interested in.

And sometimes, technologists, we get caught up and get excited with the detail. And we don’t know how to distill that detail in a way that says, okay, fine. How do I package that to the board for them to be able to say, wow, we can build a business off this. We can grow the business using this. Okay. Now, as a CTO, you’re there between the technology side of the fence and the business side of the fence. So yes, you do care if it’s Java or JavaScript or Symfony or hardcore PHP. What you’re trying to figure out is, if I make a decision one way or the other, is this going to speed up my ability to deliver or is it going to slow down my ability to deliver? Am I chasing the cool new technology that maybe hasn’t yet matured enough that we can bet the farm against.

Because scalability is more than simply how many hits can you process in a second. It’s about how healthy is the ecosystem around that particular area. Technology, software, whatever it is, that I can find resources. I can recruit for it. I can have a longterm vision for it. And, you know, somebody said something to me a few months ago that sort of resonated at that level. When a car manufacturer, for example, introduces a new car into the market, they have to be able to show and prove that they can support that car for at least 25 years, right. There’s going to be servicing, there’s going to be all of the warranties and all that sort of stuff. And that’s because you don’t want somebody to be able to buy a car and, suddenly, it to be not supported.

We’re the same in the software world. As technologists, we always love the new shiny bright toy. We’re always going for the latest version, the latest cool stuff, the latest stuff. And I suffer the same fate. But I just simply can’t turn the business around quick to say, right, we’re all going in this direction now, we’re all going in this direction now. Because the business is sitting there thinking, we’ve got clients to deliver by the way, guys. Are you creating more noise for us? Are you creating less friction for us? So from a CTO’s point of view, you’re always trying to balance those two areas.

Henry Suryawirawan: Thanks for emphasizing the importance of knowing about the business and also the clients, right? Because ultimately the technology that you use or deploy is actually used for a business impact, business growth, and also user satisfaction, right? And I like the way that you mentioned that CTO’s role is to come up with a vision and roadmap and ensuring that technology doesn’t hold up the business growth, right? I think that’s a very key important thing for people who aspire to become a technology leader, not just CTO probably, right?

Alan Williamson: Yeah and that’s always my sort of first litmus test when I’m introduced to a CTO. I say, okay, well, here’s a whiteboard pen, draw me your vision. And if they’re blanking, then I’m thinking, okay, you’re not quite ready for the CTO level yet. Okay, a CTO should be able to, off the back of their, get me a road map and a vision because everybody should be aligned as to where they’re going on that front.

And if they don’t even know what the vision is, then how does the business know what to plan for? And how does the engineering team know how to align to that vision? So it truly is, a CTO is simply not the guy that knows the most. It’s the one that knows how we’re servicing the business, how we’re moving towards that, and what are we going to look like in two to three years time.

[00:12:47] Different Flavors of CTO Role

Henry Suryawirawan: Right. But first of all, I mean, in the industry, there are so many different terms of, you know, there’s a CIO, there’s a VP of Engineering, there’s also a Chief Data Officer, you know, Chief Transformation Officer. There’s so many things, right? Is there any differentiation between CTO and all these roles, or are they just different names, but same flavor?

Alan Williamson: No. There, there, there is. I I would, I mean, again, this is a Pepsi versus Coke argument. There’s gonna be many people that will have different opinions on this. My opinion is that the CTO is the one that pretty much sits above them all. Because they take all of the stuff. So a Chief Data Officer, a Chief Information Officer is probably one that maybe sits alongside the CTO. But security officer, all of VP of Engineering, et cetera. The CTO at the end of the day is at the top of the pyramid coordinating and getting input from all of those different quarters in order to come up with that single vision.

[00:13:42] CTO At Different Company Stages

Henry Suryawirawan: Right. Thanks for the clarification. Another thing that people also think about when they have this CTO role, right. Is there any difference for, you know, maybe a startup, a small startup versus big companies or even like traditional corporate companies? Because I can see variations in the different types of companies as well. So what do you feel from your point of view?

Alan Williamson: For sure. At the sort of startup level, the CTO is often one of the founders as well. They’re also the ones that are truly building the product, they’re the ones that are coding, they’re the ones that are delivering, they’re the ones that are producing, they’re supporting, they’re doing everything. At that level, you’re not really being a CTO. Okay, you’re in founder mode. You’ve got the CTO title in order to show, yeah, I’m the tech guy. The other guy’s the business guy. But really, you’re playing the role of proving the concept of the startup. Right? You truly are in proof of concept mode. Because anything that you’re building at that level, nine times out of ten is going to be thrown away.

Because once you get a greater team around you and more discipline around you and much more responsibility around you. And the fact that, hey, we’ve got paying customers and they simply can’t go down. So therefore, I just can’t release this code tomorrow. I got to schedule it and there may be downtime. I’ve got to go through a process now and if something goes wrong, I’ve got to be able to roll it back. Because I’ve actually got paying clients that’s going to get angry at me and they may want refunds, etc. And that’s going to throttle my cash flow.

So the discipline comes through a natural evolution, not because that we love process. It’s because we want to guarantee a quality of service to our clients. That’s why these processes get started and get pushed in the first place. So, the CTO at the founder level, frankly, they get to have the most fun. They have no process. They are free rein. They get to play. They get to do all that stuff and they get to truly forage a new path in the trees. As that path starts to get more beaten, then the company starts to evolve. It starts to get either more investment, or it gets more money through simply organic growth, so therefore there will be a natural evolution that the CTO then becomes further away from the code or further away from the responsibility.

And often what happens is and again, another little test is, can that CTO go on vacation for two weeks and not worry about opening up his laptop? I would argue that most startups can’t afford that luxury. And again, why not? Everybody deserves a vacation, okay? So, you know, as we get up higher into bigger companies, even into the public companies, yes, the CTO can take two weeks off. Because there’s a team underneath them. There’s a team, I keep saying him, but it is sadly the majority of males. I would love to see more females in the world. And there are some great examples of female CTOs. So please apologize the gross sexualization there.

The fundamental difference there is that you want to be able to have an organization whereby the CTO is operating at the level that the business needs of it at the time of the business evolution. So you’re right, the startup needs to have that person cutting code. But the company that’s sitting at 5,000 employees. If the CTO is still cutting code and releasing it, something has gone wrong in the line there. They’re probably not a CTO.

Henry Suryawirawan: So thank you for clarifying that. So I think, yeah, it’s always like a misnomer, right? A title in the startup versus title in the big companies. They may not be all the same with the responsibility and also day to day job.

[00:17:04] What Makes a Good CTO

Henry Suryawirawan: So we have discussed a little bit about, you know, like what is the CTO role and, you know, responsibility and all that? I mean, in your book, I read you define a quality of what a good CTO looks like. You mentioned, just like what you mentioned in the beginning about technology probably is the least part of the CTO role. But you mentioned interestingly about the people that actually will make or break your success. This is probably a bit of something that unexpected for people to hear. As a CTO role, your success actually depends on people. Maybe if you can elaborate a little bit more about this part, what a good CTO does.

Alan Williamson: Yes, and again. I mean, this often speaks to the engineering’s heart. We’re very ego centric personality. You know, we love our little wins, we love puffing ourselves up, we love to think that we’re the best at things, etc, right? And there’s usually the sort of not invented here syndrome that kicks out here. It’s like, well, I could develop that a bit. I could do that better myself. I could, oh, I wouldn’t have done it like that. Okay. The reality is that you should never be the smartest person in the room, okay? You should always have good people that you can bounce ideas off of and that can challenge you and pull you, and move you. And somebody that’s not scared to say no to you, okay?

And that’s why having strong people is so important to the development of any team that when you’re bringing on somebody to do a specific role, yes, they should be able to do that role at a very high level. But you should be able to give them the latitude and the responsibility to do their role and for you not to micromanage, okay? And if you find yourself as a leader having to micromanage each of the different layers, then either you’re not hiring correctly or you’re not a leader that’s confident to let go, okay? Why do I want to hire a SQL developer if I’m always writing the SQL statements for them? Save myself money, get rid of them. I’ll just do it, okay? But you’re never going to scale a team if you keep having that attitude. So you’ve got to hire well, you’ve got to hire of a good quality. But more importantly, you’ve got to let them do their job.

Henry Suryawirawan: Okay. So I think what you mentioned is actually very, very important for whoever is in the top, right? Not just CTO, but maybe also leaders, right? VP of Engineering or whatever that is, is to be able to help people grow and also scale yourself, right? You can’t be micromanaging every little bits of technology aspects of the organization. And this is something I find it difficult for some engineers, right? Because they are never trained for it in the first place, right? I mean, there’s no university that, you know, guides you to become a CTO or becoming a CIO, right?

[00:19:40] Visionary Planning

Henry Suryawirawan: So, you mentioned in the beginning that the most important part for the CTO is actually to be able to draw the roadmap, the vision. And I think probably this is also one thing that many people are not trained of. So maybe, can you tell us how can we actually improve ourselves to go into this route, so that probably become a better CTO?

Alan Williamson: So there’s usually one of two problems that happen when somebody’s laying out a vision. Well, the first problem is recognizing the fact that you can do one. You never have to be asked to do a vision, okay? And most developers probably have their own vision in a sort of very macro level in terms of, well, I want to upgrade to this version or I want to refactor this code, I want to do that. That is indeed a vision, okay. It’s a very short term vision for sure, but it’s still a vision. At a CTO level, you have to think of that vision a little bit longer and a little bit broader. But you have to give yourself license to come up with it in the first place.

Now, you can fail in one of two ways when you’re coming up with that. Failure one is not thinking long term enough. It’s thinking more in incremental improvements. But you’re not doing anything big. You’re not giving the business anything to hang their hat on, for example. And the other one is, your vision is too big. That it doesn’t have any detail in it. There’s no milestones in it, okay? You know, perfect example that I’m sure every CTO at this precise moment has got a line in their deck somewhere saying, we’ll move the company to AI in three years. What does that mean? Two years ago, we’re going to move everything onto the blockchain. Again, what? Years before that it was everything will be big data. You notice there’s a cyclic nature to all of this sort of stuff. But again, those are two big of visions. What does it mean that I’m going to go into AI? Which parts of the business is going to improve to get to there? What are my steps that I need to do in order for us to realize that vision?

Simply saying that I’m going to be the best technology company in the world, not enough. Your vision’s got to be able to lay out plans on how you’re going to get there and what are going to be the benefits to the business and to your engineers, because you’re going to recruit for this to be able to be part of that exciting vision. So, a much more down to earth vision would be, for example, an organization that has historically got physical servers in a rack. So we’re saying we’re going to move in the next three years to a cloud enabled, API-driven architecture. Brilliant. Benefits being reduced cost to the business, more flexibility for spending, easier way to utilize existing components and not have to keep redeveloping stuff. That’s a real vision.

Now I’ve got tangible results and now that every time we’re doing something, every time that we make a decision, say, okay, we’re creating a new file service, I need to buy four new Dell boxes. Hold on. Is that getting us closer to the vision or further away from the vision? Well, I’m having to buy more boxes, so therefore I’m getting away from the vision. Okay, so let’s not do that. That’s not in support of what our vision is, okay. So a vision truly has to be factored into every decision that’s being made in order to be realized that the vision is indeed correct.

Now, the vision is not a one and done statement. Because the business changes. The industry changes. So it’s got to be always evolving, always changing. But it’s not going to be changing to the point where it’s a complete and utter 360 every single six months that we’re going after a completely different vision, a completely different world. It’s got to be true to the nature. So for me, it’s usually a two to three year vision with a very lofty five year goal as to where we’re going. But you don’t want to be going any further out than that, because there are too many factors that are going to come in that could completely change the way you operate.

Henry Suryawirawan: Right. Yeah, I think, yeah, I think this is a good guidelines, right? So two to three years, your vision. But not too short because too short probably is more like incremental, like what you mentioned, right?

Alan Williamson: It’s more project management at that point, yes.

[00:23:40] Learning How to Create a Vision

Henry Suryawirawan: Yeah. So how can engineers train themselves to be able to come up with good visions? Because, you know, many engineers work on low level tasks and it’s always incremental, right? Unless there’s, you know, like a series of projects being driven from the top. So how can engineers prepare ourselves better to become a better CTO?

Alan Williamson: It’s a great question, Henry. So for this one here, I always sort of liken it to the stock market, okay? One of the nice things about the stock market is that you buy and trade stocks. And you can effectively play the game without losing money, okay? You can sort of say, okay, I’m going to go back ten years, and I’m going to sort of run my same sort of methodology or algorithm, if you will, on the stocks ten years ago. Would I have made the money fast forwarding it? Or I’m going to play with play money in the current stock market and see if that would have worked or not, okay?

You can do the same thing with a visionary statement. You can go back in a company’s history, and say, okay, at the time, and you know, perfect example would be like Microsoft. At the time that Bill Gates stepped off, if you were the CTO of Microsoft then, what would have been your vision at that point? Would you have gone all in to the internet? Would you have gone all in to Azure? Would you have gone all in? What would you have done there? And did that play out as what was expected?

We’ve plenty of examples of companies that have failed, and failed to adapt to the existing environment. Kodak, completely missed out on the whole digital phone sort of stuff, etc. So the CTO there probably didn’t do a great job. But what would you have done? Now, of course, you’ve got the benefit of hindsight, but that hindsight, history teaches us a lot about what’s going to come up. So even now that we’re all a little bit more intelligent, and it’s easy to look at the likes of Blockbuster and Netflix, Kodak and the smartphones, and say I wouldn’t have done that. Yeah, but at the time, given the knowledge you had at the time, what could you have done differently? Nobody can see it into the future, but at the time, what could you have done?

So as you look at the evolution of your own company. Yes, the developer sitting there, who doesn’t maybe have the authority or the visibility, they do have a history of their own company. They can see how the company has evolved. And even from the point of view of when they first joined to where it is now, be king for the day. What would you have done? What difference would you, what change would you have done? As opposed to sitting there going, well, I told you so. I knew that wasn’t going to work. We should never have gone with whatever the language of the day was. Play that game. And and then sort of look at it.

And if you’ve got a good, strong relationship with your management and your leadership; in your one on ones, ask them the questions. So why did you go that path? I’m interested. What was the thinking there? Why are we now considered a Java shop and not, say, Node? Teach me what you did to get there. A good leader will never shy away from that conversation. And they could be, they said, well, yeah, you know what? At the time, it was the right decision, but given where the industry’s moved now, we’re going to have to pivot a little bit and move off of that stack, and we’re going to go this direction. Or we’re going to go away from servers, going to the cloud. Whatever it is.

A good CTO and a good leader will always be mindful of being adaptive to the current environment, and therefore will change. You never want a person in that role that’s just so frigging stubborn. It will work. I just need the rest of the world to catch up to my vision, okay? No, we’re not Amazon. We don’t get to set certain tones. We have to figure this out by ourselves. So from that perspective, ask, ask, ask. And do it in a respectful way. You’re not sort of going to your manager. Well, why did you do it this way? I wouldn’t have done it that way. No, you’re listening. You’re listening, so make the conversation fruitful and understand their data points.

Because the bit that you’re probably not appreciating is the business side of the fence that you may not have exposure to. Okay, you may not be seeing certain details that, at your level, doesn’t make any difference to your job. So therefore you wouldn’t get to see the balance sheet. You wouldn’t get to see the current sales sheet. You wouldn’t get to see the forecast, because it doesn’t help you in your job really. But as you’re laying out the vision of where it’s going, then yes, you do want to start that.

And areas that we’ve seen before is where a CTO would say, right, we’re now moving towards an API driven architecture. And you get people sort of thinking, well, well, what? Aren’t things working the way they are? I know this code is doing well. What they may have missed is that clients are now starting to ask for the API so they can go deeper into their organization. And any time that a client asks for an API from your organization, you want to run 100 miles an hour towards that request, because that creates a very sticky client.

Now that’s the sort of tools and the sort of way that a CTO can truly help the business get a lot more integrated with their clients. By providing them tools that the clients are looking for, as opposed to saying, well, we don’t do API. Just give us a file upload in an FTP directory. How old school is that? So when it comes to visions, when it comes to figuring out what a vision should be, ask, ask, ask.

Henry Suryawirawan: Thanks for sharing this interesting technique, right? For all engineers out there, if you want to exercise your so called visionary skills, look at the evolution of your own company. Make sure you probably analyze some of the key decisions, whether it’s right, whether it’s wrong, right? Maybe you can analyze and use that as your knowledge, right? And maybe even ask your leaders if they are supportive to share with you, right? I think these are all great, great learnings. Don’t forget that you can also learn from the past history as well.

And I just want to quote a few things about, you know, you mentioned about visions, right? Vision is not just one project. So let’s say you want to develop this API driven technology, right? It’s not just once done and, you know, dusted, right? So it could be a series of projects. Two, three years. That’s kind of like your rough guideline. And also one thing that is very important, I find that it can be delivered and celebrated by the people as well, right. So it’s not something that’s never celebrated.

Alan Williamson: Exactly. And that’s very important because otherwise, you’re just a snake oil salesman. You’re never delivering. You’re always delivering tomorrow. You’re always delivering tomorrow. One company that suffers from that big time would be Tesla. I mean, I was a Tesla owner, and I got sick of self-driving’s coming next year. No, it’s coming next month. No, it’s coming next year. Self driving’s still not there. It’s like, okay, Elon, can you actually deliver on a product? I don’t think you can. So the Cybertruck, it may not be released this year. It may be released next year. I mean, they are the never release company. Now they do eventually get there. But think of the fatigue that that puts on your customers and your clients and all that sort of stuff. So a good vision should not be too lofty that it cannot be celebrated when it’s delivered.

Henry Suryawirawan: Right. So yeah, please do think about milestones when you set up your vision. Don’t think of like too far ahead, and you’ll never, you know, deliver some incremental milestones in the journey, right?

[00:30:54] Working With the CEO

Henry Suryawirawan: So one thing when you mention about business, right, definitely CTO needs to talk with other leaders, especially CEO, right? And it could be also their boss, right? The CTO’s boss. So, these dynamics is, for sure, it’s very interesting. So maybe a little bit of wisdom here. How do you actually work collaborating with the CEO? Any gotchas that CTO must know about in order to maybe collaborate better?

Alan Williamson: It’s the hardest part of the role, Henry, to be quite honest with you. Because the CEO, while you’re the CTO and you’ve only got the responsibility of the technology side of the fence, they have the responsibility for the overall company, right? We are just one buttleg that reports into them. They have many other legs and they’re trying to straddle the vision for the company as a whole, delivering to the clients as a whole, putting together the growth plans, etc. And a good CTO has got to appreciate that they’re a small cog in a much bigger engine. They have to serve everybody towards that end goal.

And to also have empathy as to what the CEO is trying to accomplish. And that is, they don’t want to micromanage you any more than you want to micromanage your people, okay? They want to be able to look to you and say, “Is this done?” And you’ll say, “Yes, we’ll get that squared away.” You don’t need to micromanage me here on this front. I understand where you’re coming from. I know what you’re trying to do and what you’re trying to accomplish.

Now, the flip side of that is understanding the level of detail to which your CEO enjoys to have a conversation with. And I’ve worked with many different ones where some are truly business level. They don’t want any details as to what stack we’re doing, what we’re doing, da, da, da, da, da. They trust us to do what we’re supposed to do. Then there are others that are a little bit more interested. They would actually like to know, well, what are we using? Are we cloud? Are we data? Why are we going this direction? Da, da, da, da. Have you thought of this, etc? Those are wonderful CEOs to work with as well. So it’s finding that balance with that CEO. And then talking in their language to know that, okay, they’re interested at a sort of, let’s call it an API driven layer. But do they really care if it’s driven by Java, Node, or third party service? Not really. So I don’t need to go into that level of conversation when I’m talking to them.

And the other important part that I often sort of spend a lot of time mentoring people with, and I go over this in the book as well which you’ve probably read. When a CEO is asking you a question, most of the time they’re not asking the question for themselves, okay? They’re asking the question on behalf of probably somebody else, okay. Because they have to stand up at a board or stand up to a client or stand up to other leaders of the business to be able to effectively communicate what you’re telling them for their audience. So therefore think about your answers in such a way that you give them the talking points. To make it easier for them to convey their results. So the last thing you want to do is to get sucked into a whole buzzword laden, geeky explanation because woof, it may go over the CEO’s level, but sure as hell it’s going to go over the board level, right? They don’t care.

So when you’re talking, talk in the language that their audience is going to be in. And that’s very, very important. And a good CEO will help guide you in that respect, particularly when you’re first starting out in that journey. But they will come to respect you and start to sort of look forward to your conversations, your one to ones, your quick five minute calls, etc. Because they know that you’re going to be able to distill this down in such a way that A, they can understand it. And B, they can envelop that into their own words. And then go and do what they need to do with that piece of information. The last thing you want to do is, “Yeah, the website went down because Java went through a upgrade and we didn’t have the blah, blah, blah, blah, blah, blah, blah, blah.” And all they heard was the website went down. It doesn’t help them understand what we’re doing and how we’re mitigating that future problem as part of that example.

So talk to the CEO in their language, and that’s the hardest part that a technologist has. Because you talk to any technologist, we love our buzzwords. We love our geek speak, because it makes us sound way more impressive than we really are. It makes us sound way more intelligent than we really are. But in a business setting, you don’t get away with saying out a buzzword. And then thinking, well, it’s your fault if you don’t know what that buzzword means.

What do you, what do you mean you don’t even know what that means? Well, you must be… be gone with you, okay. We have a very arrogant attitude at times. And we do this in sort of microaggressions as we talk, as engineers talk with each other and what have you. We subconsciously do it. It’s just what happens. You don’t get away with that at a business level, okay. Because you’re there as a team. You got to empower your CEO. You got to empower your CFO. You got to empower everybody else that’s at the same level as you to know that, “Oh, don’t talk to Alan because Jesus, I feel stupid after every conversation I have with him because he just hits me with lots of buzzwords.” You’ve failed as a CTO when you’re getting that conversation.

Henry Suryawirawan: Right. So I think it’s important to know what success to them, right? So like explaining things in their own language as well. Don’t get too much details as well, especially the jargons, the technologies, they may not get it anyway. But they also want to convey your message to other, maybe the board directors, or maybe other people who are interested in the growth of the company, right. So thanks for sharing all that.

[00:36:47] Building Engineering Team

Henry Suryawirawan: So, one aspect is be able to understand what CEO wants, translates that to technology. The other part down there is actually to build a great team, right? Maybe have the leaders under you as well who can perform and execute your visions. So any tips about building and managing teams for engineers here?

Alan Williamson: Yeah and I think, like, to your point, you know, a CEO will say, and let’s assume we’re sitting in New York at the moment. We’re driving, I need to get to San Francisco. That’s the level of detail he’s going to give you, right? Now as a CTO, you’ve got to figure out how are we getting to San Francisco? Are we going to fly? Are we going to take the train? Are we going to take the car? If we take the car, how many cars do we need? Da da da da da da da da. As you think through the ask of what the CEO is doing and the spirit of what the CEO is saying, that then dictates the team to which you need in order to get to that vision.

And as long as everybody is completely clear as to where they’re going and what role they play in that particular journey, then building the team up becomes relatively simple. Because you know exactly what you’re looking for. I’ve been quoted many times before that I’m not a big believer in the full stack developer mantra because it’s like, okay, you’re a jack of all trades, master of none. But in this journey, do I need more of an API person or do I need more of a web person? And frankly, if those were two separate people, would I be able to get there faster? So this notion of building up a team of effectively jack of all trades, master of none isn’t a good way of building a team.

You want disciplined people that know their particular area very well, that know that they’re going to deliver at the best level, that this is the best code or the best query or the best structure or the best infrastructure that I can build because I eat, breathe, and live, this particular discipline. So therefore, I’m of course going to be far better than somebody that’s just got a cursory view of it as a whole. And as the company grows, you have more budget to allow yourself those very strong disciplined areas. As a startup, of course, you’ve got to have that one person that knows everything. You can’t afford to buy each of the different expertise.

But as the company evolves, you get to a point where you say, okay. We’re now a database company because we’ve got like literally terabytes of customer data sitting in databases. Maybe we need a SQL person. Maybe we need a dedicated DBA to be able to manage this, to optimize our queries, that eats and breathes and lives this. Whereas before, eh, data wasn’t that big a deal in our company, so therefore we could make do. So as the team evolves, you will find what you need that’s very disciplined and focused expertise to maximize the resources and again to not get in the way of the business delivering what they need to do.

Henry Suryawirawan: Right. So thanks for explaining how to hire the team, right? Especially the different stage, different growth, right? Requires different kind of people, right? Maybe in the beginning you have more full stack engineers. As you grow, maybe you need more disciplined people.

[00:39:58] Building Quality In

Henry Suryawirawan: So the other aspect apart from just skill set is actually how to execute, right? How to make sure the team aligns. That’s the first thing, because sometimes it’s very hard to align. And how they can execute it with high quality. I think this is probably a million dollar question for every technology company out there.

Alan Williamson: Quality is, it’s my number one bugbear to be honest with you. Quality to me, Henry, is kind of like the old school. How you treat your waiter is how you treat other people. It’s kind of like that litmus test how well you’re going to do it. Same thing for me. I like to see quality at all levels. So if, for example, you’re building a web form and there’s a little bit of inconsistency with UX or there’s a label that’s misspelled or there’s something that’s just not quite right. Why was that little simple thing not corrected? And if you missed that little thing, then what did you miss in the back end of the stuff I can’t see? What shortcuts did you do back there that I’m never going to see in maybe one in every hundred execution paths it’ll get triggered? So, okay. So for me, that’s the litmus test.

So if a team is truly focused and gathered around quality, then it trickles down to every level. And what we all like in any product or anything, pick it your favorite car, your smartphone, anything. There’s that one thing that it does that you go, that’s cool, oh, I really like that. That’s a nice little touch. Okay. And for that reason, you’re now loyal to that particular thing, okay. Cause you like the way it does it. You create that relationship with it.

We sometimes forget to do that as software engineers and as the products that we’re delivering. We’re too focused on getting the clinical solution over the line. We sometimes forget about the spirit of what it is we’re delivering. And I like to instill that sense of spirit and quality into the things that we’re building, so we can anticipate what the end user is going to need. So instead of us just delivering the bare minimum, we give them that little extra, extra little touch that makes it easier for them to fulfill their job. And again, it comes down to quality.

Empathy is another word that I use a lot on a weekly basis. Have empathy for the person that’s using your product. Now, it could be the person that’s reading the report. It could be the person that’s doing the data entry. It could be the person that’s installing your software. Have a little bit of empathy. What can you do to make their job that little bit easier? And it could be as simple as a DevOps guy writing a README file to make it easier to be able to turn on this service. Okay, whereas in their head they’re thinking, oh, but this is so goddamn obvious. Why do I have to even write this out? Well, you probably don’t, but there’s going to be that one person that one day is going to look at your README documentation and go, Oh, thank God. He just saved me hours worth of work. That’s wonderful. Thank you.

So that little bit of empathy, that little bit of quality check does help a lot in building up confidence, building up faith and building up stickiness of your users. When something is delivered, they look forward to the next release. They don’t fear that, “Oh my God, what have they broken now?”, from that perspective. And again, I go back to Tesla. Every time they did a major release in my car, I knew that three days later, there’d be two more releases coming. Because they’d have to fix the stuff that they released the first time. I’m speaking from like a two year old release, so maybe they’ve got better. But they locked me out of my house for three days, because I couldn’t use the garage door opener to be able to get into my house. I was like, URGH! Two days later they released a fix and suddenly my garage door started to work again. I was like, okay guys, there is such a level of lack of quality that was being pushed out. But we have that at all levels. Okay.

And, you know, we no longer distrust the Windows update. We no longer distrust the Samsung update on our phones because it just works. Same thing with our Chrome update. It updates in the background because we just have faith that it just works. When was the last time somebody updated their Chrome and it completely destroyed everything that they were working on? Rare, very rare. We as software engineers have got to get back to that level of quality and it all starts with the team. It all starts with everybody knowing that that’s what you’re needing to be doing as part of your role. And collectively, it’s how we build a great product. It’s how we build a great team.

And we never want to get into a situation where we say, oh, but QA will find it. QA will catch it. No, QA is not your safety net, okay? QA, if they’re doing their job right, should never find anything. They should be that level of assurance that, yep, you did have a good quality. You know, the clue is in the title. Quality assurance. Yes, I’m assuring the quality is there. Too many teams rely on QA to find the bugs, to find the stuff. And for them to be the, I’ve got it off of my JIRA ticket list, it’ll come back to me if it’s really broken. Knowing fine, well, it is going to come back to you, and you should have done it right in the first place. So yes, I believe a good QA team, it’s not your safety net. It’s there to assure that the team is indeed producing quality and it all comes down to everybody’s responsible for producing the quality.

Henry Suryawirawan: Thank you for emphasizing that quality is at all levels, right? I think one of the aspects of CTO is to ensure everyone, every team understands about this aspect and be able to deliver quality results, right? Not just, you know, they’re like delivering features over features, right?

[00:45:36] Dealing With Imposter Syndrome

Henry Suryawirawan: Another aspect that I want to ask you about CTO is actually sometimes as individuals, right, they are suffering from imposter syndrome, right? Because they can’t know everything for sure. In the technology, you’re saying that they keep reinventing themselves every five years, right? So first of all, how do you manage yourself as a CTO dealing with the imposter syndrome, dealing with uncertainty, and dealing with not knowing the, maybe, the results of the visions that you are taking? So maybe a little bit of guidance here for CTOs.

Alan Williamson: It’s a great question, Henry. And you know, imposter syndrome. I had imposter syndrome five minutes before we had this interview. Am I gonna live up to Henry’s quality? Am I gonna live up to the quality of the guests that you’ve had historically? Did I have self doubt? Of course, I did. Everybody has it. We all have it. And it’s that stage fright. It happens.

So how do you deal with it? Well, frankly, you don’t. You just learn to live with it. Okay, you’ve got to live with the fact that you don’t know everything. You got to live with the fact that some days you’re going to wake up, that everybody’s going to be talking about a new buzzword and you have no clue what they’re talking about. And you’re going to feel dumb, dumb, dumb, because I’ve heard this buzzword four different times now from four different people. I’m thinking, how the hell do you know about that buzzword? But I have no clue what you’re talking about, okay.

So embrace that and actually run towards it. And instead of sort of trying to bluff your way through a conversation and thinking, Yeah, blah, blah, blah, blah, blah, blah. No, just say, guys, I have no clue what you’re talking about. Somebody educate me here. And what you’ll probably find is that most people are probably playing the buzzword game themselves and they don’t really know it truly at a level themselves. I’ve discovered this a lot. How somebody says something confidently can make you convinced that they actually know what they’re talking about.

So get past that confident layer and simply be vulnerable to ask questions. I don’t know what you’re talking about, okay? And there are certain times when this will happen inside of an organization. You know, we’ve all been there. We’ve been talking to somebody. We’ve maybe met them at a party. We’ve maybe met them at a meeting. But it’s gone beyond that point where you think, I should have remembered their name at this point. I’ve forgotten their name. Now it’s going to feel real awkward when I ask them, what’s your name again? Because it’ll feel awkward. That’s imposter syndrome, okay?

Every so often in a company that you may have been there for a number of years, a term will come up and you’re thinking, I should know that by now, but I don’t. Can somebody help me? What, what, what do you actually mean by that? And again, it’s just letting yourself to be vulnerable and to be that person that is comfortable holding their hand up in a class and saying, “Teacher, can you go over that one again? Because I don’t know what you’re talking about.”

Because if you have that confidence, then I can guarantee you that there’s probably somebody else in the room that’s a little bit nervous to hold their hand up and ask the same question. But the nature of you asking it, they will get their answer as well. And hopefully it will inspire them to see that, Hey, I asked about this particular term. People seem to be receptive to it, I didn’t get fired. In fact, I increased the knowledge of the room. Maybe it’s okay for me to do it next time. So the whole imposter syndrome is just acknowledging the fact that you don’t know everything, you won’t know everything. But don’t be scared to ask the question there and then when something new does come up.

In terms of how one tries to get ahead of some of this stuff, and I pull out a couple of examples in the book as well. If you’re in a given industry, then there are going to be certain disciplines within that industry that you should probably be keeping an eye on. And that can be done very easily through trade journals, websites, etc, that you read maybe once or twice a week etc just to hear what’s going on. But if you’re not, say, for example, in blockchain or crypto, then don’t be concerned about what’s going on in Bitcoin that particular week. Don’t feel stupid or don’t feel dumb that you don’t understand what the latest and greatest contract protocols are going to be for blockchain. No, you’re allowed to not know that. Okay? Just like embedded stuff, I’m allowed not to know certain stuff, because it’s not within my field.

If I’m however in this sort of database field and I’m not being kept up to date with the latest releases of the particular server that I’m on or the particular trend that things are going on, then yeah, that’s a problem. Don’t try and consume the full space. Consume the space to which you’re focused in on. Give yourself the license to say, I’m okay not knowing about that. It will come up as and when I need it. So I’m not going to stress about it. Okay. And as long as you’re open to new knowledge, because, yes, we do reinvent ourselves every five years, but that doesn’t mean that suddenly on the fifth year, we get all of this knowledge suddenly inherited to us.

No. We get pointers that things are starting to go off in a different direction. Things are starting to go, this buzzword keeps popping up time and time again. Maybe I need to learn a little bit more about that. Give you an example that I’ve had to sort of come around to in the last six months. Machine learning and AI. Yes, knew all about that. But generative AI? We keep reading about that all over the place. What is this generative AI and what’s it, why are we now calling it that? I had to go and learn about that. I had to go and read about that. Now that was everybody was starting to drop it into buzzwords. And I said, well, what’s the difference between that and say, machine learning and AI? And you get like blank expressions.

I said, well, you’re clearly not the person to ask about that. Okay, let me go and ask somebody else. I eventually found that person that could sort of sit me down and say, okay, let me take you through. And now I suddenly feel much more knowledgeable on it. But that was an evolution. That was me letting myself bear to say, I have no clue what generative AI really. I think I’ve got a guess at what it is, but I’m not confident enough to use it in a conversation. Somebody explain it to me. We’re going to have that every single year. And there’s big seismic shifts every five years, as you know. So don’t get stressed about suddenly needing to know everything about everything on a five year window. Embrace the learning. Embrace the lack of knowledge in certain areas and use that as a mechanism to run towards. But imposter syndrome? Live with it. There’s no cure.

Henry Suryawirawan: Yeah, thanks for emphasizing that we have to live with the imposter syndrome, right? And I think in your book you mentioned that it doesn’t mean that we have to be at the bleeding edge, but we have to be at the leading edge, right? So know enough probably when the time you really need it, then you can dig deeper, right? So I think thanks again for reminding that.

[00:52:11] Reviewing Yourself

Henry Suryawirawan: So apart from dealing with the imposter syndrome, which you cover really brilliantly just now, right? So I have one other question about managing yourself as a CTO. So most of the times, as an engineering leader, right? Most of the times when you’re at the top, it can be very lonely up there, right? So with very limited input signals for people to give you feedback. So maybe my next question is how do you actually review yourself? Maybe your performance, maybe your skill sets, and how can you improve in order to also be effective CTO?

Alan Williamson: Okay. It’s a great question, Henry, and I think there’s a couple of answers and a couple of techniques that I do personally to keep myself in check as it will. The first thing I do is I keep a journal. I keep a dear diary. Now that journal is, ironically, it’s actually a Google spreadsheet. It’s linked to every device that I’ve got, every browser, etc, and it’s got a line item for every single day, and a column. It’s for free, for the various different things. Now what I do in that journal, it’s not like a, you know, dear diary, he didn’t speak to me again type sort of thing. It’s more of a, I track my emotions, okay? I track, did I feel I had a good day or a bad day? And if I had a bad day, what made it a bad day? Did things not go the way I wanted it to go? And if things didn’t go the way I wanted it to go, then how could I have done something differently afterwards?

So what I do is, I don’t try and analyze the journal, frankly, on a daily basis. What I do is that I collect all that data during the week, and it could be silly things like had X number of meetings, da da da da da, various emotions, etc. It’s more like tags, if you will. And then at the end of every week, as I’m planning my next week out, which is usually Sunday evening or Sunday morning, I look at the week that just gone by and say, okay, huh, what could I have done better? What did I do? Okay. Which members of the team impressed me? Which members of the teams caused me problems? Which meetings were productive? Which meetings were not productive? What new things came in that were completely out of my control that I had to do something about.

So I use my journal very much as that touch point and I also like note things like when I was traveling, where I had to go, did I have doctor appointments and all that sort of stuff. Because it’s funny how I discovered every time I go near the dentist, which is my every four months I go to the dentist, any meetings I have beforehand are generally not good, because I’m anxious about going to the dentist. But that’s a data point I didn’t realize I had for such a long time until I tracked it. So it’s as silly as that may seem. So I do that.

Now the other secret weapon that I’ve got, I have a good strong right hand. I’ll name him, Ryan Burch, who has the license and has the authority to say to me, Hmm, well, you didn’t do that well. Okay, he’s my man, that is pretty much in a lot of my meetings or our orbits collide a lot. But he’s the one that I will always use as my litmus test to see, did that go well, did that, was that right, etc. Now, he technically reports to me, yes. But we have that strong relationship whereby he will tell me how he feels. Sometimes he’s right, sometimes he’s wrong. But to have that trusted third party person, that’s not just going to be a yes person to you. That’s going to say, yeah boss, you probably were a little bit strong there. Or maybe you weren’t strong enough. Or I have no clue what the hell you were talking about there, so maybe you want to re-clarify that again to see how well that worked, okay?

Because in your head, you think you’ve communicated perfectly. And we don’t sometimes feel how we came across. And what Ryan does beautifully, he never tells me at the time in the meeting. It’s always a one on one. Very confidential. I trust him, right? I’ve also got a little visual cues from him that during the meeting, I can read his face at times and say, okay, I need to get that right. So having that trusted person, huge. And he has helped me a lot. And that I think is something that will help with keeping a check on yourself.

So between that and the journal, what I’m basically saying Henry, is be open to feedback. Be open to the fact that, maybe, you have areas to improve. Nobody is getting it right all of the time, okay? And different external factors will affect your moods, because, hey, we’re not machines. We are emotional beings. We’re affected by our environment. So therefore if one can be a lot more mindful of your own environment, well that, that will usually spill over to being a little bit more empathetic to the people that you’re trying to lead.

If your rockstar developer is suddenly having a bad week, maybe there’s something else going on. Maybe there needs to be a bit more latitude given, because something, you know. You don’t need to get into details as to why it’s going on. But be empathetic to the fact that, hey man, there’s clearly something that’s changed. Do you need a little bit more time? I don’t need the details, but do you need a little bit more time? That is an empathetic leader. That is somebody that’s truly keeping yourself. But it starts with yourself. Can you be introspective to yourself? And can you be honest with yourself?

Henry Suryawirawan: Very interesting answers. I was thinking that you might want to say, you know, find a mentor, read books and things like that. But actually you first advocate having a journal. Surprisingly, actually, I do have a mood journal as well. I use an app for that. And sometimes you can find interesting insights just, you know, by tracking your activities and the mood.

Alan Williamson: So what sort of things do you track, Henry, when you say that? So that’s wonderful. I’m glad you do that.

Henry Suryawirawan: Yeah. So the first thing is about mood tracking, right? And then I, most of the time, I put the high, not so much highlights, like interesting activities that I do. So things like, for example, meetings, you know, playing sports, right? And activities that I also want to track as habits. So all these things I normally track in an app called Daylio. And the good thing about the app is that it also gives me statistics and, you know, interesting visualization of how I do those stuffs. So sometimes it gives me a very good, interesting insights.

Alan Williamson: Fascinating. I’ll check that out. And yes, to your point, I do have a mentor. You know, Jim Milbery is my mentor. He’s been a mentor for the past sort of near on 20 years. I’ve known him for over 25 years. I dedicated my book to him. He’s my guy that I ring up and say, how do I handle this? For sure. And he will tell me, he doesn’t sugarcoat it.

Henry Suryawirawan: And the second interesting thing that you suggest, right, find so called the right hand, right, maybe in your team. It could be direct report. Although I know that some, maybe leaders may not have access to this trusted right hand person. It depends on how you build trust, right.

Alan Williamson: Takes time. Yes.

Henry Suryawirawan: Yeah. And I think it’s really interesting if you’ve got that person in your team as well who can give you the cues and give you feedback. May not necessarily direct feedback in the activities itself, right? But maybe through private one on ones and things like that. So I think that’s a very good interesting advice that you give for all of us engineering leaders out there.

[00:59:09] 3 Tech Lead Wisdom

Henry Suryawirawan: So thank you so much for all these great, wonderful coverage about Think Like a CTO. Due to the interest of time, right, we have to cut it short. And I’m sure we could talk all day long about being a great CTO. I have one last question because, you know, this is a custom question that I normally ask for all my guests, which I call the three technical leadership wisdom. You can think of it like an advice you want to give to the listeners here so that we can learn from you better. So what will be your three technical leadership wisdom, Alan?

Alan Williamson: Okay, I love that question. First one is listen. Listen to not only your own team, but listen to the outside, because they’re your real customers. Listen to management, listen to that sort of stuff. And don’t be quick to offer solutions as part of that. Sometimes we jump to, I can solve that, I can do this, oh, you need to do it, we can use that tool, we can use this. No, just listen. And the more you listen, the more data you’re receiving, so the better validated solution that you have. Now you may quickly jump to a solution in your head. Great. Continue to listen. That’s number one key. Uh, and something I’ve had to learn myself, because as a young engineer, I was always quick to solve a problem, quick to think. I was like, everything is easy, everything can be done. But the more I listen, the more I learn.

The second tip I would have is assemble the right team around you. You are not going to do everything yourself. Therefore you have to rely on others. And you have to rely on what they are bringing to the table and the skill sets that they are doing. So the first thing that you have to do as a leader is determine what skill sets do you need to be around that table for you to be successful in your role as you deliver for the company as a whole. So very carefully and strategically determine that skill set and then recruit accordingly. And it’s sometimes you’re going to have to make hard decisions because there are certain people that you think, I really like you, you’ve done a great job for the company, but your skill sets just don’t match what’s going forward. And we’re going to have to have that conversation. Square peg round hole does not work. Get the right people or the right skillsets.

And then finally, my last leadership thing is, and I’ve just finished reading the Power to Fail book, which is the whole history on General Electric. It’s been absolutely fascinating. The author goes through each of the different CEOs. And he focuses, of course, on Jack Welch, which is considered to be the greatest CEO in the world. And his big tip, which I have to say, I’ve, I’ve embraced myself and I have been doing it a long time and it was kind of like, oh, Jack does it as well, so I must be on the right track as well. That sort of validation stuff, which is make sure you have people around you that will argue. You want people that will actually put up a strong argument with you, will not be intimidated by you or your title or your role. And it doesn’t matter if they report directly to you or not, but have people that will actually put up an argument. If you don’t, then you’re never going to evolve to the right solution.

And what’s interesting about the Power to Fail book is that Jack was one of these people that loved to have an argument. That was never a personal argument, it was an argument around a particular issue of the day. And apparently, Amazon works in the same manner as well, from what I’ve read from their books. But the following CEO that came after Jack, he didn’t like the argument. He surrounded himself with people that were effectively “yes” people. And therefore an awful lot of solutions were effectively never really vetted out or never really, we never really kicked the tires on those at General Electric and it was absolutely fascinating to see the two different CEOs being contrasted. Back and forth from one another. So, again, it’s have people argue. And that tip came from my mentor a long, long, long time ago, which was make sure people are not scared to stand up and say, Alan, you’re wrong. And here’s why I think you’re wrong. That’s my top three.

Henry Suryawirawan: Thanks for sharing this wisdom. I like the last one, right? Have people to argue. Of course, in the spirit of, you know, good faith, right? In the best psychological safety as possible, right? Otherwise it will be just a debate and fight internally.

Alan Williamson: Oh, no, you’ve got to argue with data. You’re not allowed to argue with emotion. That’s the key differentiation.

Henry Suryawirawan: Right. I think that’s a very good tip as well. So for people who, you know, you feel that you don’t have enough argument, especially for engineering leaders, maybe create that ecosystem or, you know, culture in which people are not afraid to give their feedback as honest as possible, right. And you do have to listen and, you know, maybe acknowledge. Even though maybe you don’t agree, but in the end, I think the best ideas should win, right? Not just the highest person paid opinion.

Alan Williamson: You’re absolutely right.

Henry Suryawirawan: So Alan, it’s been a wonderful chat. If people want to continue this conversation, is there a place where they can find you online?

Alan Williamson: alan.is. Keep it simple. And you can also find me on LinkedIn.

Henry Suryawirawan: Right. Very short and simple. And I’ll put it in the show notes as well. So thank you so much for your time, Alan. So thank you for writing the book. I think this is a very, very rare book for people who are the CTO. Not many resources I find that will give people advice or insights how you can become an effective CTO. So thanks again for that.

Alan Williamson: Thank you again, Henry.

– End –