What did a CTO really do? A CTO, it's about giving the business the technology 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 in scale, at a level and at a speed where technology never holds up their growth.
Hey everyone, my name is Henry Surya Virawan and you're listening to the Technical Journal Podcast, the show where I'll be bringing you the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our journal. Hey, what's up, My listeners?
Welcome to the Technijunal 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 Technijunal 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 Techly journal dot def slash tip or becoming a patron at Techly journal dot def slash 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 company 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 5 star rating and review on Ale Podcast 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. Okay. Hey everyone.
Welcome back to another new episode of the Technical 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 you have a good discussion about it. Welcome to the show, Alan. Thank you very much, Henry. Honored to be here my friend. 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. Okay. Well, I think being a child from the 1970s is it where 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 cause this expensive piece of kit. I had managed to solder bits onto the back of it and trying to figure out what and 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 cheer genius of what I was doing many, many years. It took about 30 years for her to finally see OK 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 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 was 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 actually 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, 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 as what it was then, but it's just the different packaging now and 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. This episode is brought to you by Miro.
Being a CTO or engineering leader requires you to share your vision, strategy, systems and processes within your team or with the other leaders and stakeholders. Not to mention when building them.
You will also need to collaborate interactively with multiple people to come up with the best ideas, and one tool I find that allows us to do so effectively and in a fun way is Miro. MIRO Mirror is an online virtual workspace and a visual collaboration tool where the whole team can build on each other's ideas and create something innovative together from anywhere. With Mirror, you need only one tool to see your vision come to
life. Strategic planning becomes easier when it's visual and accessible. Planning, researching, brainstorming, designing, and feedback cycles. It can all happen across teams In Mirror you can quickly start collaborating within 90 seconds without having everyone registered as a mirror user before. There are also more than 300 predefined templates you can use to kick start your collaboration
within seconds. So the next time you're looking for a digital tool to support your strategic planning and online collaboration, do give Miro a try. You can Sign up today at mirror.com podcasts miro.com Podcast. And your first three mirror boards are free forever when you signed up now. And now let's get back to our episode. 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 SME's and even including from private equity firm right when you invest in different portfolios of companies. So today we'll be talking a lot about CTO role, definitely from your book think like the 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? 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 that 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 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 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 it's 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 Symphony 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 long term vision for it. And you know, somebody said something to me a few months ago that that sort of resonated at that level is 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 you. 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 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. 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? Yeah, and that's always my sort of first litmus test. When I'm introduced to 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 in 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 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, 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 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, that same flavor? No, there there is. I would, I mean again, this is a Pepsi versus Coke argument. There's going to be many people that will have different opinions on this. My opinion is that the CTO is the one that's pretty much sits above the malls because they take all of the stuff.
So Chief Data Officer, Chief Information Officer is probably one that's maybe sits alongside the CTO, but Security Officer, all of VP of Engineering, etcetera. 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, 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 startups or small startups versus a 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 for sure at the 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 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're truly are in proof of concept mode because anything that you're building at that level 9 times out of 10 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 I've 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
1st place. So the CTO at the founder level, frankly, they get to have the most fun. They have no process, they're a free reign. 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 it is sadly the majority of males. I would love to see more females in in the world and there are some great examples of female CTO's.
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 is sitting at 5000 employees. If the CTO is still cutting code and releasing it, something has gone wrong in the in the line there.
They're probably not a CTO. So thank you for clarifying that. So I think, yeah, it's always like a misnomer, right, the 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. 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 do.
Yes. And again, I mean, this often speaks to the engineering's heart. We're a very egocentric personality. You know, we love our little wins. We love puffing ourselves up. We love to think that we're the best at things, etcetera, right. And and there's usually the sort of not invented here syndrome that kicks out here. Well, I could develop that better. 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 they 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. 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 will never train for it in the 1st place, right? I mean, there's no university that, you know, guides you to become a CTO or becoming a CIO, right? So you mentioned in the beginning that the most important part for the CTO is actually to be able to draw the roadmap division.
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. 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 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 bit broader, but you have to give yourself license to come up with it in the 1st place. No, 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.
OK, You know, perfect example that I'm sure every CTO with this precise moment, it's 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 was everything will be big data. Notice there's a cyclic nature at all of this sort of stuff. But again, those are two big visions. What does it mean that I'm going to go onto 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 plants and 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 do 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 Iraq somewhere 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 and say, okay, we're creating a new file service, I need to buy 4 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. No, 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 5 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. Right. Yeah, I think, I think this is a good guidelines, right.
So two to three years of vision, but not too short, because too short probably is more like incremental like what you mentioned, right. It's more project management at that point, yes. Yeah. So how can engineers train themselves to be able to come up with good visions? Because many engineers work on low level tasks and it's always incremental unless there's a series of projects being driven from the top. So how can engineers prepare ourselves better to become a
better CTO? 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 10 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 the 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 CT of Microsoft, then what would have been your vision at that point?
Would you have gone all into the Internet? Would you have gone all into Azure? Would you have gone all like what would have 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 though 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, is it? Well, 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 seize 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's 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? I suppose you're 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 and your Oneonones, ask them the questions. So why did you go that fast? 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 the, 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 look, 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. It'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 the set certain tones. You have to figure this out by ourselves. So from that perspective, ask, ask, ask and doing a respectful way, you're not sort of going to your mind, well, why did you do it this way? I wouldn't have done it that way. No, you're 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 division 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, why 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. Integrate it with their clients by providing them tools that the clients are looking for. As opposed to saying, well, we don't do APIs, just give us a file upload and 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. Thanks for sharing this interesting technique right for all engineers out there. If you want to exercise your socalled visionary skills, look at the evolution of your own company. Make sure you probably analyze some of the key decisions, whether it's right or 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 wanna quote a few things about, you know, you mentioned about visions, right? Vision is not just one project. So let's say you wanna 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 2-3 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 never celebrated. 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 is 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 I don't think you can. So the cyber truck, 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. Right. So yeah, please do think about milestones when you set up your vision. Don't think of too far ahead and you'll never deliver some incremental milestones in the
journey, right? 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 boss, Yes. So this dynamics is for sure is very interesting. So maybe a little bit of wisdom here. How do you actually work collaborating with the CEO? Any gutters that CTO must know about in order to maybe collaborate better? 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 but leg that reports into them. They have many other legs and they're trying to straddle the vision for the company's whole delivering to the clients as a whole, putting together the
growth plans etcetera. And a good CTO has got to appreciate that there are 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 stock we're doing, what we're doing, da, da, da, da, da, da.
They trust us to do what we're supposed to do. Then there are others 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, Dadadada, 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 CEO was 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 roof, 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, talking 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, etcetera. 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 envelope 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, blah. And all they heard was the website went down. It doesn't help them understand what 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, hey, it makes it sound way more impressive than we really are, makes it 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 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, ah, 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. 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 board directors or maybe other people who are interested in the growth of the company, right. So thanks for sharing all that. So one aspect is to 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? Yeah. And I think like to your point, you know, a CEO will say that that's assume we're sitting in New York at the moment. We're driving what 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 got to figure out how are we getting to San
Francisco? Are we going to fly, We're going to take the train. We're 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 Mentra, because it's like okay, You're 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 said it wasn't that big a deal in our company, so therefore we could have made do so. As the team evolves, you will find where you need that 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. 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. 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 $1,000,000 question for every. Technology. It sure is. Quality is. It's my #1 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 that I can't see? What shortcuts did you do back there that I'm never going to see, Maybe one in every hundred execution path 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 ticket, your favorite car, your smartphone, anything, there's that one thing that it does that you go that's cool. How I really like that that that's a nice little touch Okay. And for that reason, you're no loyal to that particular thing Okay because 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's 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 read me file to make it easier to be able to turn on this service. Okay. Whereas in their head to 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 read me 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 2 year old releases. 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 2 days later they released a fix and it's suddenly my my guy's door started to work again and it's 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 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.
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 got it
off 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 1st place. So yes, I believe a good QA team is 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. Thank you for emphasizing that
quality is at all levels, right? I think one of the aspect of Cto's to ensure everyone, every team understands about this aspect. And be able to deliver quality results, right? Not just, you know, like delivering features over features, right. Another aspect that I want to ask you about CTO is actually sometimes as individuals, right, they are suffering from impulsive 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 busser 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 great question, Henry, and you know, imposter syndrome. I had imposter syndrome 5 minutes before we had this interview. Am I going to live up to Henry's
quality? Am I going to live up to the quality of the guests that you've had historically? Did I have selfdoubt? 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? Oh, frankly, you don't. You just learn to live with it. Okay. You 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 4 different Times Now for four different people. I'm thinking, how the hell do you know about that buzzword? Well, I 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, 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 is 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 that this will happen inside of an organization. You know, we've 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. We think I should have remembered the name at this point. I've forgotten their name.
Now. It's going to feel real awkward when I asked them, but what's your name again? Because it 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 laying yourself to be vulnerable and to be that person that is comfortable holding their hand up 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 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 keeping an eye on. And that can be done very easily through trade journals, websites, etcetera that you read maybe once or twice a week, etcetera. You 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. OK, just like embeddeds that I'm allowed not to know certain stuff because it's not within my field.
If, however I'm 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 5th 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 that I've had to sort of come around 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, 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 between that and say, machine learning and AI? And you get like blank expressions and so 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 laying myself bare to say I have no clue what
genitive a I really. I think I've got to guess at what it is. But I I'm not confident enough to 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 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, yeah. Thanks for emphasizing that. We have to live with the Impulsive 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 not enough probably when the time you really need it and you can dig deeper, right. So I think thanks again for reminding that.
So apart from dealing with the impulsive 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 OK, 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 attract, 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've done something differently afterward? 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, ha, 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 just go for 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, I'll name him Ryan Birch who has the license and has the authority to say to me, 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 was that right, etcetera? No, he can't Like, he 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 reclarify 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 and and right.
So having that trusted person huge, and he has helped me a lot and that I think is, is, 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 would usually spill over to being a little bit more empathetic to the people that
you're trying to lead. If your rock star 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 now 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.
So 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? Very interesting answers. I was thinking that you might want to say, you know, find a mentor, read the books and things like that. But actually you first advocate having a journal. Surprisingly. Actually, I do have a good journal as well. I use an app for that.
And sometimes you can find interesting insights just by tracking your activities and the So what sort of things do you track, Henry, when you say that? So that's wonderful. I'm glad you do that. 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, playing sports right and activities that I also want to track as habits.
So all these things I normally track in an app called De Leo. 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. Fascinating. I'll check that out. And yes, to your point, I do have a mentor. You know, Jim Millbury 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 hello, How do I handle this for sure? And he will tell me he doesn't sugarcoat it. 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
trusted exactly yes. Yeah. And I think it's really interesting if you got that person in your team as well who can give you the cues and give you feedback. I may not necessarily direct feedback in the activities of 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.
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 get an advice you want to give to the listeners here so that we can learn from you better.
So what will be your 3 technical leadership wisdom, Alan? OK, that's I, I I love that 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. 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 listened, the more I learned. 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 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 at 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 by the
right skill sets. And then finally my last leadership thing is and just finished I've just I've just finished reading the the the the power to fail book which is the whole history on General Electric. It's been absolutely fascinating. The the author goes through each of the different CEO's and he focuses of course on Jack Walsh which is the 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 was one of these people that love to have an argument that was never a personal argument, it was a argument around the 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. We're never really, we never really kicked the tires on those at General Electric and it was absolutely fascinating to see the two different CEO's being contrasted back and forth from
one another. So again, it's have people argue and 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. Thanks for sharing this wisdom. I like the last one. Right? Have people to argue, Of course, in the spirit of good faith, right in the best psychological safety as possible, right? Otherwise, it will be just a debate and fight internally.
You've got to argue with data. You're not allowed to argue with emotion. That's the key differentiation. 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. In the end, I think the best ideas should win, right? Not just the highest person pay opinion, you're absolutely right. 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 dot IS keep it simple and you can also find me LinkedIn. 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. Thank you again, Henry. Thank you for listening to this episode and for staying right until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit
from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better. You can also find the full show notes of this conversation on the episode page at techlyjuno dot dev website, including the full transcript, interesting quotes, and links to the resources mentioned from the
conversation. And lastly, make sure to subscribe to the show's mailing list on techlyjuno dot dev to get notified for any future episodes. Stay tuned for the next Techlyjuno episode, and until then, goodbye.