The Engineering Trap: Why Most CTOs Never Become Real Executives

Hey, what's going on everyone? Welcome back to Mastering Tech Growth, where we chat with industry leaders to bring you big ideas on how to grow. I'm Mike Sirius, and today we are talking about one of the most misunderstood jobs in tech, the Chief Technology Officer. Everyone wants to be one, but few really understand what the job is. It's not about being the best coder in the room, that's for sure. It's about leading the business through technology. Joining me today is Khalil Dimashki, a seasoned CTO who's grown teams from 1 to 100+, advises private equity firms during mergers and acquisitions, and now leads technology at Blue Light Card, serving over 5.7 million frontline members. He as well co-created Imperial College Emerging CTO program, which trains new and aspiring CTOs in business communication and strategic skills, which the role actually requires. Khalil, great to have you. Welcome.

No, great to be here. Thanks for that amazing intro, Mike. It's funny to hear it all played back to me, right? Yeah.

I'm glad you enjoyed it. I'm glad you enjoyed it. So we met in one of the CTOs dinners back in the day and I remember very clearly you came in, you know, into the dinner with hot ideas, good topics, good takes around the challenges we were discussing. And I was like, I really want to bring you on the podcast. So I'm really happy that months later, you know, we actually doing this. And let me kickstart with this one. When I say mastering tech growth, what comes to mind?

What comes to mind when you say mastering tech growth? I think the first thing that comes to mind is team.

Okay.

Structure and team. You're never going to master tech growth if you don't master the art of building a team, getting that bench strength and setting up the right processes. Right. And there's never like one right way to do it. Funny enough, like it depends on what problem you're trying to solve. It depends on what the company does. It depends on what your like operating structure is. Right. But it always comes down to the team and having that right structure in place because without it, you're going to get nowhere, right? And we can talk about a lot of different kind of, you know, transformations of what team means because as a CTO, team means a lot of things. But actually, if I go back a little bit, I'm definitely never the best coder in the room. Like that stopped happening a long time ago. So I very much agree with you, I think. Um, you know, and, and in terms of misunderstood job, I think it's funny how many people want to be a CTO. And whenever people ask me, you know, do you have any advice on how I can get to kind of be a CTO? Um, the first thing I say is don't.

Why? Why do you want to go there?

If you love, if you love hands-on tech, if you love building things like yourself, right? If you want to actually continue to be like that engineer, that coder, you shouldn't think of your next stage as a CTO because there's so many career paths for you. You should only get into this kind of path of things if you have also a real, you know, you love tech, of course you need to love tech, otherwise you won't be a successful one. but you need to have a real, also a passion and interest in business.

Okay.

Because ultimately it's a business role. It's not a technology role.

I fully agree with that one. So, uh, I, I got this, uh, to, to, to take us a little bit into that picture of, uh, what commonly happens and, and, and, you know, the, the wrong picture. Let's, let's read it like this. So I have this, uh, phrase which I found online, which is called engineering trap. So it happens like very often when it's on a startup side, but it happens when you have a fresh CTO. So someone gets promoted internally and you've been here for 7 years, you know everything, so here's a CTO hat for you. So they come in in these roles and they tend to remain quite deep in the codes because they just simply know all the systems, they can jump in and fix them. So that usually means a business slowdown. It doesn't necessarily mean a tech slowdown, but the business slowdown. Do you see this pattern in the field as well? And like what usually happens when a CTO sort of cannot stop and just remains in that like deep delivery mode?

I think this is quite a common problem with, specifically in the startup space and in, and even more critically in the scale-up space, right? When you stop being a startup, you get that funding that you've been working so hard to get. And, you know, you want to expand your operation, you want to do that. In the early stage startup space, it might be kind of something that's feasible, right?

Okay.

Having, because there's not that amount of actual kind of like business operations to do. And often, often it's, you know, you have a co-founder or, you know, it's, I find it's very rare that to have CTO sole founders, uh, I found often you have a founding CTO who's like a co-founder. I don't know if you found the same thing in the startup space, but that's more common, I think. Um, so what I see is often when that happens, like you don't mature as a business leader, you don't mature as CTO because you keep kind of just focusing on the same things that you're focusing on when you were an engineer, when you were a senior engineer, et cetera. So when it comes time to kind of raise that first real round, you raise that round and then suddenly you're accountable, right? You're accountable to investors. You're accountable to someone other than yourself and your co-founder or the founding team that kind of brought you in. And this is where you start really needing to develop that business mentality. And this is where a lot of kind of early stage CTOs actually really struggle. Because some of them just aren't interested in that side. They want to continue to code. So others just are interested, but they can't pull away and they don't know how to give up that control, almost. I've done like a number of consultancies actually with scale-ups that you would be surprised at what stage they're at, where they've had this issue where the CTO is actually still just making technical decisions, committing code. And not having enough time to do that strategic business development that needs to happen. Hmm.

Okay.

And often, you know, and often it's kind of like their co-founder that starts struggling because they have to lift a disproportional part of the weight, or your new investor comes in, they want to hear about your business strategy, they want to hear about growth, they want to hear, you know, what are you doing to like really scale up the business? And you're sitting there talking to them about technical details and they start losing confidence in the ability of this person to really be that business leader. I always, I mean, the advice I have when I coach CTOs is I always tell them, you know, you are a business leader first. Your team isn't the engineering team. Your team is the exec and the board.

Okay, I actually love that. We'll circle back to that when it comes to where you actually sit and what is the top and what is the bottom and how you navigate this. But I want to pick a little bit more on that, the fact that the CTOs don't know how to do that and because they simply don't speak business. So what is your advice if I don't speak money, I don't speak risk, I don't speak return of investment, right, in the executive meetings? So I tend to speak what I know, which is technology and coding, which is not not what they want to hear. How do I close that gap? It's like, what, you know, how do I translate my technology knowledge into that business value and how do I improve my, like, is it like programs you created in Imperial College or is it something I can read? It's like, what, what, what is your advice to CTOs like that?

I think the key is to know that you have that gap, right? Because if you don't know you have a gap, um, you're not going to do anything to plug that gap. Right? So the key is to first actually realize, and this is a phrase I use a lot, to zoom out and realize that, okay, what am I missing? Where am I dropping the ball? Why, why are things not going the right way? And then try and, um, kind of plug those gaps. I think the, the advantage you have actually as someone who came up as an engineer or an engineering leader is. Engineers are particularly good at kind of examining their skill set and trying to plug gaps, right? Because that's— technology is always moving. You're used to doing that. You probably started out in a completely different language than kind of you've been building things in now. You know, you have to adapt to new tooling. You have to adapt to AI, all of that stuff. So take that same mindset in building up your skill set and learning new things and apply it to business, right? And that's obviously you have that decision to make. Do I actually want to be a business-minded CTO? Do I want this career path? But if you make that decision, you need to apply that same drive and passion and to learn to that. And there are a lot of avenues, right? So you can, um, get a coach. There's a lot of people who do kind of one-to-one coaching actually really effectively on executive mindset. You could join a program like the one we were talking about. So I worked with Imperial College to start the Emerging CTO program, which is a 6-month program and it runs, basically it starts, it's in association with their MBA program and their business school. And it starts with really kind of business foundations, communication, operating in kind of the exec, the boardroom. That's the foundation of it. And then we move into like the real CTO stuff around, innovation, ROI on technology, things like emerging technologies, AI, cybersecurity, all of that from a very strategic perspective. So there are structured programs. Obviously Imperials isn't the only one, but you know, I'm biased because I think it's your program.

Yeah, it's the best, of course.

But yeah, so I would like find a coach, engage with the wider community. There's actually a lot of really good communities for CTOs and people who want to be CTOs, you know, I mean, CTO Craft is a really well-known one, right? But there are other smaller kind of more focused communities as well. Um, I think the main thing is reach out, put yourself out there and talk to people. Even that alone is going to help because it'll teach you to how to kind of, um, sell yourself almost, but not, not like in a negative way, but in like how to position yourself strategically. Because communication is, I think, probably 60 to 70% of this job, like just effective communication, right? Communicating with the rest of the exec, communicating with the board and communicating with your team who are kind of like the engineering team. You could own information security, you could own IT, you could own compliance. Some CTOs own product depending on the company, right? So actually it's a pretty wide ranging role. And it's no longer the role it was like 10, 15 years ago where it was like, oh, the CTO is the guy on the exec that just owns engineering or, you know, owns IT and is like siloed in that side. Actually, the CTO role is as important as the CFO role now.

It is one of the exec roles. Yeah. Yep.

I mean, I would have a question for you, right? Can you name a single industry or company type? These days that isn't a tech company?

Isn't a tech company. It's a tough question, isn't it? So things like groceries comes to mind, like fish markets, but then when you think about— Sales systems. Yeah, exactly.

Like online management, email blasts.

Yeah. Tech is embedded in a lot of business functions, you know, because business at the end of the day is a big set of functions to effectively get that value produced for the market. And some of these functions, if not majority of these functions, are enabled by tech. So you're either going to be hiring someone to do that tech for you, or you're going to have that tech in-house, which at that point in time, you're going to become to some extent a tech company or a full tech company. If you're hiring outside, you might have tech partners, but you're not going to avoid tech, right? Yeah. 100%.

And even if you're outsourcing kind of the core technology function, right? You're still using it to drive your operations, you know, just because you don't have a technology team in-house doesn't mean you're not very dependent on technology.

Yeah, you will be dependent. 100%. That's a great question. It's one of these like eye openers that every business at the end of the day Maybe it has a range, but the tech is just part of the business. It's just, there's no other way. Okay, let me give you another one, which maybe doesn't have it, but it's not a business. I mean, you cannot call it a business, a hobby, right? So my wife's sister, she makes soap at home, right? So it's a hobby, but you know, it pays a little bit. So she makes soap at home and then she doesn't sell it on Etsy. She doesn't sell it online. She takes those soap bars into local markets. So every, you know, every city in UK here, we have like a Saturday markets, right? So with the council, you can get like your spot and you pay for that spot. It's very cheap and you can go and sell it, right? Uh, you know, no tech really, right? But then you're like, how do you buy all the required, you know, like all the ingredients for that soap? I mean, you still buy it online. So there's, there's an element of sales, you know, being online, sales being—

There's definitely exposure somewhere in the chain, right?

Exactly that, yeah. But any big business, any business making real money, headcount 10, 40 plus, it's just tech is everywhere, right?

Yeah.

Okay, so let me, I got some notes, Khalid. Let me sort of take a step back. So you mentioned a very important phrase in my view is that understanding that you have a gap, right? So if you don't understand that you have a gap, then you effectively have blinders. And then it goes like, who's going to tell you that you have this gap? It comes to this feedback. Setup? So if I'm a CTO, should I expect a CEO or a board come to me and go like, like, hey man, like you're doing great, you're doing these things, but it's not really what we expect from you. So, so here's a feedback, here's a constructive feedback. You have gaps in here. Like we need more in this space and that space. Or are we saying it's actually, you should be proactively assessing yourself and your role, which then leads to a question. How do you assess of you doing this role well? Like, how do you actually understand that you have a gap and where you have those gaps?

It's a really good question. And the answer would be both, but there's different maturity levels and intensity levels depending on which one we're talking about. So, and what I mean by that is you should be self-aware enough to Evaluate where your gaps are. And this is where, why I was saying like engaging with the wider community, understanding what other technology leaders are doing, what other CTOs are doing. And, you know, reading a lot, looking at real case studies of successes, you know, and failures. A lot of people sometimes focus on success. You know, they love buying the success story, right? Everybody, I built this and I did that. And I, you know, people love to market themselves now and it's so easy to market yourself. But I think there's a lot more value in looking in a positive way on failures, um, whether that's places where others have failed before or how you failed in, in kind of trying to do things and implement things in the past, how people you've worked with have failed, how, you know, if you're like an engineer, engineering manager, director, or whatever, how the CTO you were working with failed, where they failed, what was their blind spots, you know, really kind of try and examine that. I think that'll be the best source of you trying to kind of build up that resilience and that, that skill set that you need. Now, don't get me wrong, the CEO or the board will come tell you when you have gaps. They will, right? Because that's their job. Like, if they're not doing it, they're probably, they probably have gaps too. Right. But if they're not coming to you and if you don't have that also feedback cycle at the exec level that is telling you where, where your strengths are, where your weaknesses are, you're never going to develop. You're never going to operate the business well.

Right.

So, and it's the same thing that you have to build for your verticals, right? Your teams. If you don't have that feedback cycle with your direct reports, indirect reports, kind of all the way down the chain, your operations are never going to be good because people will not like have that. You've probably read Radical Candor, right?

Yeah, everybody. I mean, I just said everybody, but I want to take this back. Probably not everybody, but it's a very well-known book when it comes to giving feedback.

And it's very foundational in really realizing and understanding how to effectively operate as a leader, right? And one of the most damaging things is a fake positive kind of environment where, you know, the, you don't talk about gaps where everyone is okay and everyone kind of has that everyone, um, even if they're not performing is not told that they're not performing and it isn't given the opportunity to improve. Right. And so, yeah, I think you have to be that self-aware leader. Otherwise you're never going to be successful.

Yeah. Sometimes you get sucked into operational mode and I've been on the receiving end of this and I've been guilty of these, you know, situations where I tend to just get sucked into very big projects and, you know, you're operating with the team and then you Somehow you don't find time to really just create distance from business as usual operations and just sit down and go like, how are we doing? You know, how am I doing? You know, what's happening above me? You know, are people happy? You know, I need to go ask some questions. I feel like it's quite important to develop a workflow where that cadence of sourcing feedback is actually just baked in how you operate because getting feedback, especially when it comes to the peers, and peers above you is really important if you are sitting in the middle management, especially if you're sitting as a CTO, you probably just have a board above you and your peers, other execs where that feedback comes from and you really need to understand how you serve them, right? You need to go like, hey CEO, what do you need from me? Like what KPIs, what numbers? You know, once you understand that serving pattern, it's just so much better to be good at your position because you know exactly what people expect from you. So if you don't have these conversations, you're just guessing basically.

And don't over-index on the CEO either. That's the thing, right? Because yeah, the CEO will have their opinions and obviously they're your direct kind of, you know, line manager if you want to think about it that way. Although in the exec world, it's not quite like that clear cut because yeah, they're the person operating the business, but you know, you, you, they need to. You need to be in a peer relationship with them as well, because otherwise the business doesn't run well. But so it's important to get that feedback from all of your peers across the board, right? All of the C-suite, uh, even the kind of directors, et cetera, that you don't necessarily directly work with. Your work influences that and your kind of attitude and the way you do things influences. Them, right? So it's really important to just kind of really seek feedback and be very receptive to it.

Oh, receiving feedback, that's a topic on its own. I mean, feedback in general, it could be, you know, like 5 episodes, 5 hours, you could talk about how to do this well. Somewhere down in our history of podcasts, we have a full dedicated talk about feedback. Somehow And this is just my experience going through startups, scaleups, and enterprises. It's a weak game. Like, it's just like you meet people who do this quite well. And usually if they give you feedback, they're very great at receiving feedback and they have some type of process they follow to just work with the feedback. But that's a minority. A majority of people just work. You know, if they're not happy with something, they just keep it to themselves. Maybe they try to tell you, but it's really like, I'm not sure what you're saying to me. You know, it's like a wishy-washy type of situation. I don't know if it's the UK, because the culture is like that, you know, very political and, you know, like I want to give you feedback, but I want to insult you or something like that. It's very, you know, I noticed that, yeah.

I think you have to be a bit more diplomatic in the UK when you're giving feedback, definitely. I think there is a cultural element of politeness. To it.

Yeah.

Um, I think if you look at American companies, the feedback can be a lot more direct usually.

Yeah.

Um, and they're used to a lot more direct feedback. Um, but ultimately I think feedback needs to be structured, right? And the cycles of feedback need to be structured. And look, I've worked with companies from literally that had one engineer, um, and then kind of grew out. To companies that had like, I think the biggest kind of I've been CTO at was like 500 plus. And they all have that in common where if you don't have the right visibility and feedback all the way from the top to the bottom, you get all kinds of operational problems, right? And visibility and feedback are two things that are very linked. Transparency of knowing, having the systems in place to know what's going on versus, and be able to influence it through feedback versus having just these layers of obfuscation in the way.

So, so we touched on what I believe are maybe core challenges of fresh new CTOs or how you do CTO role, but it's, you know, not really effective. So let's imagine a CTO who's doing their job very well. How do they day to day, week to week, month to month look like? What's the cadence? What's the rhythm? What's the rituals? What's the dashboards, KPIs they have? It's like, give us a picture of a good CTO.

I think a lot of it will depend on the circumstances, the processes and rituals and things like dashboards and whatnot, sometimes, you know, they're aspirational in terms of like, there is this ultimate kind of vision of what good looks like in terms of operating a business, right? And that's being able to come in, have a, you know, a really zoomed out view that gives you the information you need to make strategic decisions and be able to focus on the next like year or 2 years to 5 years ahead. Having a layer that operates the business, you know, on the quarterly basis. So you don't have to get too involved in that, not getting involved in the details and maintaining a strategic view, right? That's genuinely what like an ideal situation for a CTO looks like and being able to measure outcomes like, um, return on investment. And we'll come back to this, um, productivity. Progress to your current plan, roadmap, et cetera, and having a good view of kind of your bench strength, your team, and kind of also, you know, the operating model you want to be at in within the next few years. Now that said, this is never the case, not ever, right? This is a very idealized state that I think maybe, you know, achievable. I mean, I'm sure some people achieve it, but very often it's more of a journey on the way to that idealized state. But you have to make sure that the gaps you're plugging in that journey on the way are the most important ones and the ones that make the most impact to the business and to operating the business, right? And so, for example, like, let's say you're in a company where You don't have a lot of visibility on your key metrics, right? Then you need to focus on getting that up first, and then you can focus on strategy moving forward. Because if you don't drive that kind of getting the metrics done and having a framework that gives you the metrics, you can't do the strategy part. So there's a lot of things that build on top of each other to reach that idealized state. Now, in terms of like what you track and metrics and stuff, There is one that I'm a little bit obsessed with in that I think it's the key to everything. And, you know, people who, from an engineering background coming into this CTO role, think about things like DORA metrics, you know, velocity, cycle time, things like, they all have their place, right? They're all important. But to me, they're not like the strategic metric. For me, what the strategic metric is. Is ROI. Return on investment is everything for a CTO. And what that means isn't necessarily like, oh, if I build it, it's going to make this much money. I'm talking about real strategic return on investment where everything you do that has effort involved needs to have a payoff of some kind. And you know, whether it's you whether it's your team, whether it's in your roadmap. And that payoff could be increased revenue, could be optimizing profitability because they're not necessarily the same thing. Could be, um, uh, reducing costs to optimize the profitability. They could be scale, like there are tangible ROIs, which are money-based, but there are also intangible ROIs, which are operational returns on investment. right? So if the action you take makes it easier to go to market with something, that's almost an intangible ROI. Or if it makes, if it increases the health of your team so that they produce more, so that they are able, you have more retention, you have more knowledge retention in the company. That's an intangible ROI, but that's actually even measurable, right? How much knowledge am I retaining? How much do I have to keep onboarding people, et cetera? So if you really like constantly just zoom out and think in terms of ROI, I think that's a really good north star for a CTO. And it gives you that business mentality, you know what I mean? Like you're not going off and wasting your time on things that don't necessarily move the needle.

Okay, so ROI, the main KPI. Do you have any others which, you know, like top 3? Which you care about?

Top 3.

Yeah.

So I would say ROI, um, because everything plays into it. Um, I would say, uh, one of the interesting metrics is, um, your efficiency and quality compared to others at the same maturity stage or in the same market. Because a lot of people go and they measure, oh, what's my velocity? What's my speed to, to go to market? What's my robustness, like quality in isolation? But actually, none of us work in isolation. No company runs in isolation. Every company is competing with others within your sector. So why not measure it compared to others in your sector? Because then it gives you also a better idea of what's achievable. And honestly, like one of the things, for example, that I see a lot of people doing right now is because everyone wants to leverage AI, right? Everyone wants to do AI well. Every board is going to their CEO, is going to their CTO and going, what are you doing about AI? Literally every board, right? But you can't measure that in isolation. You can only see, all right, what are others that are in a similar business to me doing? And am I doing at least as much or am I doing better?

How, I mean, how do you get a hold of these numbers? How can you measure yourself against someone else? Then we're talking about public numbers when we're not like otherwise.

Yeah. I mean, this stuff is well known, right? I mean, look, um, there are industry benchmarks. There are benchmarks for every sector in the business. Everyone is— the thing about our world today, and you know, we demonstrate it right now, is everyone's always talking about something publicly. Everyone's always screaming into this void. So there's a lot of information out there to actually gather, right? And like, to just to complete the whole snake eating its tail thing, use AI to find what people are doing and saying and doing. I mean, I'm being a bit facetious, right? There are ways to find it, whether that's, um, getting indexes, whether that's getting consultancies in, whether that's doing it, engaging with the wider, with your industry, engaging with your wider market. I mean, we met at a CTO event, right? At that CTO event, what were we talking about?

AI.

What was everyone talking about? Not just AI. What am I doing in terms of how do I measure my productivity? How do I like engage with your wider market, understand what's happening and try and measure yourself against. That. Um, okay. Don't, don't just measure in isolation. Also measure on, okay, this is where I want to be, but do the way, here's where I want to be based on what is my business objectives? What is my business plan? What am I trying to achieve in the next 5 years? Okay. So if I improve this metric, will it get me there faster or not? If I improve certain collections of metrics, what's going to be the effect on my booze? And then you know which ones are important and which ones to focus on. Go see what the wider market is doing about those. And then, you know, measure them according to your internal kind of ambitious goal, but temper them with what's realistic in the market.

I love that. So, I mean, we touched on a couple of things which is not good and a couple of things which are good. So, which leads me to this question. If you would create one-page operating system of CTO and it's something like, it's literally like one-pager, right? What would you put on that page? Always zoom out. So number one, don't get basically, don't get too deep into operation.

Yeah.

Okay. Yeah.

Whenever you're dealing with a problem with a strategy, with trying to find a solution to something.

Yep. Okay.

Always think. Am I, am I really looking at things from a zoomed out enough level or am I kind of missing the forest from the trees? That's number one. Number two is, um, a bit of a, like a, a military, um, thing where, you know, there's a famous saying in, in kind of strategic planning when it comes to the military, uh, and that no No plan survives first contact with the enemy. It's the same in business.

Okay.

No plan survives first contact with implementation, right? So when you're making plans, think about what could go wrong and make contingencies so that when the thing goes wrong or something similar goes wrong, you have a plan, you have a playbook. Playbook. I'm a big fan of like thinking about things in terms of these types of playbooks, right? And obviously don't confine yourself too much, but don't also be blind and go like, oh no, it'll be fine. And then you have to scramble all the time, right? So if you're always zooming out, you're planning contingencies. And then I think my third one would be, um, build systems, but build systems based on teams, like build systems based on real human things, right? So don't think that in an idealized state where, oh, I have this step and then that step and then that step. Think about, I need this capacity and this is how I build this capacity, whether it's hiring, whether it's training, whether it's, um, you have a team that needs retraining. Whether you need to bring in external help, you know, like a big part of your job as a CTO, as a business leader is that people side, right? That enablement, that how do I build the ability to do things? It's not about, you know, just business strategy, just technology strategy. Ultimately, people are the ones operating the business. So if you keep that in mind, if you focus on your people systems, I think you'll be in a really good place if you use those kind of three rules of thumb, right? Okay.

So the third one is effectively SOPs, isn't it? The standard operating procedures where you, where you just define how things should be done and that allows you to onboard people that gives, you know, gives them real steps to how to execute a certain function, right? Yeah.

Yeah. But not just that, it's also about being aware of what the real capabilities and capacity is in your team. Okay. Because I often see wishful thinking.

Oh yeah, tell me about it.

We've got these SOPs, we've got this operating model. So therefore it'll result in this without actually seeing how people are operating on the ground, how they're communicating with each other, how they're, you know, so as, as that strategic leader, you need to make sure that you have a realistic view of how things are operating. And you can get that from, you know, this comes back to the whole like dashboarding, zooming on metrics situation, right? If you see something broken in your engineering metrics or your velocity or your ability to hit roadmap, if it's consistent, that means there's something wrong either in the planning side or the execution side. Dig in and see what it is. I think one thing that a lot of like C-level don't do is skip levels. Talk to people that don't report to you and build a culture where they're not scared of speaking to you, you know, be a bit human about it, I think. And then, you know, you'd be surprised what comes out.

Yeah, you'll get more. Yeah, skipping levels or just not sitting in your lane when it comes to just gathering information, that's a very healthy practice. It usually gives you a lot more than you would expect to find and that, you know, gives great ideas. Yeah.

It's, it's amazing how much I know about what happens in my organization without just organically, because you build relationships, you build cadences, you have people comfortable coming to you with stuff. And then, you know, it's that human element as well. That's very like If we want to be really like clinical about it, it's also an element of return on investment, right? Because like it makes everything you do more efficient. But also like just care about the people that, you know, make up your team.

Yeah, 100%. Would you put, would you put get, get infrastructure done so you get metrics on that page? So let's say I'm a new CTO coming in and, you know, it's a, maybe it's a scale up and they just started expanding and you're like, oh, I don't know metric in that. I don't know metric in that. So right now I don't have anything. Would you on that one pager, would you say be data driven and make sure you're capturing the right metrics?

Yes. Yeah. Yeah. So always be data driven. It's not necessarily about metrics alone though, because sometimes you don't have the maturity to put the right metrics in place. But if you're properly data-driven, you can infer some stuff, or you can work towards building up to that metric, right? Or at least you'll know where your gap is to fill that process that enables you to build the metric. One mistake I see people often doing is going, I need this metric, so I'll build it on my system, even though my system is broken. And then the metric you're getting is, is false.

Hmm. Yeah, that's true. Yeah. You can't operate on that.

Like velocity is something that can be really gamed, like, uh, because like, okay, so let's size everything a certain thing. And then suddenly we're shipping at a velocity that, you know, in, uh, in that metric shows a lot that we're shipping a lot, but actually you're just sizing everything wrong, uh, in, in, ways to game that metric. So you need to understand what the metric is telling you, not just the metric on its own. So I'm, while I'm a fan of kind of data-driven stuff, I think you really need to understand what it is that you're measuring.

Yeah. Understand the context behind the numbers you're getting.

Okay.

So, um, let's say I got a CTO job. It's my first one. I'm starting, you know, next Monday.

Good luck.

Good luck to you. But it's hypothetical, but some people potentially listening are maybe fresh in a role. What are the first things you do in your first month? So you start on Monday, you come in, you know, you have 4 weeks, you know, what are the couple of things you're doing in that first month?

I have a, pattern of things that I like to do. And it's worked for me really well. And it's something that I've built over the years of experience, right? And I'll tell you where it comes from. I did a lot of work in consultancy, right? So early on in my career as well, I was an architect in consultancies. And then later on, I did a lot of like fractional CTO, consulting CTO, helping PE firms and stuff like that. And one of the things that I really learned, and it came from like almost productionizing the CTO role, making it a product rather than, you know, a thing where you submit your CV. And what I like to do is I like to do a discovery, right? And, you know, it's the same way when you're trying to build something, you know, you do a discovery, you figure out what you're building, you figure out what the gaps are, and you have a plan. So the way I spend the first, like, let's say 15-ish days, I think, and this is something that I packaged up into its own product before, is you go in, you talk to everyone in the team, you understand how things run, you, um, you know already kind of what the gotchas to look out for are. And what you do is you put together kind of, okay, here are the strengths of what we do and how we do it. Here are the gaps in what we do and how we do it. And then how do I plug these gaps and how long will it take me to plug these gaps? If you just focus in the first like month, let's say, on just purely that, just understanding how the business operates, trying to map strengths, weaknesses. And trying to understand, okay, how do we plug these weaknesses? And, or how do we even turn certain weaknesses into strengths, et cetera? How do we fortify the strengths we have? You know, again, it's the zooming out. A lot of people start from the bottom up where they go like, all right, how do we commit code? What are our coding standards? How do we, and then they build up to that. I say, no, start from the top. Start from a, what are we trying to do as a business? How do we achieve that? How do we plan that? Once we plan it, how do we execute it? And then what are our coding standards? What are— so, you know, build, build that instead of like building it as a pyramid, build it as like almost an inverse pyramid. Um, that's what I like to do. That's what works for me because I feel it gives me a better kind of strategic view of how things are. And that's kind of your first month or so, right? Then your second month. Is starting to gradually implement the things that plug those gaps. And you start with the team side of things. What's our operating model? What roles are missing? What are people's skill sets and how do we take actions to kind of move towards that? If you focus your second month on like the team side of things, you start, you know, first, so you have this strategic understanding. You're starting to plug it because the team is the engine that drives everything. And then maybe in your third month, you start looking at standards, you know, because you're like, okay, I have a plan to how to kind of get the team that I want. What are the standards and processes I need to put in place for that team to operate? Now, let's not be naive because you're not going to solve everything in these three months, but you've used your three months really productively. In kind of mapping out what you're going to be doing over the next year, year and a half, 2 years, right? Because you started with also, what are we doing as a business? And what are we doing as a business means what are we doing in the next 3 to 5 years? And so, you know, you've built yourself almost a roadmap. Now it's important to keep reexamining that once in a while and not think that that's going to be your roadmap forever, but that's kind of the approach that I like to take.

That's a great approach and great framework. I'll take us back to the first month. So what you gave sounded like a SWOT analysis, you know, like strengths, weaknesses, opportunities, and risk. Is that, do you apply any framework when you have these conversations or how you get that information and put it in sort of list or is it just purely like chats and just taking notes and looking patterns?

So I kind of do have a framework. But it's one that I developed over the years of kind of doing things badly and then learning from it.

Right.

And that's the best way to learn and develop a framework. But my framework won't necessarily work for everyone else. Right. Because I have a, you know, I thought, like I said, it's kind of like exactly what I said, but then I have like almost places where I plug things into, you know, I have like this slide deck that covers certain things, and I just make sure that I'm addressing those things when I'm looking at stuff. I know that you need to have, you know, this process in place. You need to have this type of team structure. You need to have these types of like business-to-technology links. But ultimately, I think it's a mistake to try and treat every business in a generic way. I think you need to pretty much adapt your process to what the business is really doing and the size. And yeah, so I wouldn't— my advice would be to not go like over-index on, oh, there's this, you know, trendy framework or this kind of book that someone wrote. Read a lot, research a lot, but come up with something that works for you in the way you— your mental model works, right? Because everyone's mental model works a little bit differently and no one knows how you work better than you do. Hopefully by now, right? By the time you've reached that CTO state.

Hopefully. You probably wouldn't reach that state if you wouldn't know how you do, how you get things done.

I mean, hopefully, right? But you never know. I think there's a question in the chat that's interesting, actually.

Uh, yeah, we'll put, uh, we'll put the questions to the screen in a second. Uh, I, I, I want to dig a little bit. I want to give you this scenario, which is not hypothetical, but it's a very real scenario. So you come in, it's a fresh role and you are CTO, right? So you are the guy and then you come in and you like 2 days in and you're trying to do effectively what you have outlined, which is having conversations and then people run in the room, production is down and something else, there's this defect, that defect. Oh, there's a timeline. We need to release next week. What do we do? Like we don't have that feature, make a decision. So you're getting, there's a very big, not strategic, there's a very big business as usual gravity pull into those operations and people just want to rope you in, right? So do you give in and you stabilize and then go back to your sort of framework of plans of having chats and building the team and standards? Or you go like, hey, I appreciate, you know, like you are in a problem, but you know, like I'm not going to make these decisions. It's been my 2 weeks in and, and you know, here's a tech lead. He's been here for 2 years. He's going to make that call or something like that. It's like, what's your like go-to?

Yeah, I think one of the key lessons to learn as a leader and as a CTO is delegation and understanding the right resource for the right job. And it's very much like you said, like 2 weeks in, I'm not going to be the best person to make this call. Um, but I can tap the people that have been here that have been dealing with this stuff and go like, hey, strengths and weaknesses of this approach. Give me, give me an approach. Give me 2 approaches. Give me 3. What do you think? What do you think? What do you think? Um, and then going, okay, this makes sense or that doesn't make sense. It's the only thing you can do at that stage. And I would actually very much advise that you do go, hey, um, I need ramp up time if you want me to be effective. So I need to do this investigation. I need to do these 10 days. I need to do these 15 days or whatever. But if you're doing it effectively after the 15 days, you kind of have an idea because ultimately also like. It depends if it's your first CTO job or not, right? Because if it's not your first CTO job, you almost have like this pattern recognition of, or, and it doesn't have to be CTO actually. If it's your first like high-level management job, um, then you won't have that pattern recognition. But if you've done it a bunch of times, you'll be like, oh, this is this type of problem. So let's do this. Um, it's important to leverage that pattern recognition. Uh, but yes, lean into the people who have been there, who kind of know what they're doing, even if they're not brilliant, even if they're not perfect, because you need to build up that knowledge. You need to build up that operating model before you can do it. And I would say anyway, as CTO, you shouldn't be making these like very low-level operational decisions. Um, so for a simple reason, you shouldn't build systems that have high levels of dependency on an individual. And so you shouldn't build systems that have a high level of dependency on you either. You shouldn't be that linchpin, right? There should be decision-making structures in place. I appreciate you're new and those structures probably aren't there, but it's a good thing to establish as a starting point, right? Where like, hey, I expect you as a team to be able to make decisions. Come to me, give me options, but be decisive about making these decisions. And then I can help you with the option. Um, so we said ownership from really early on, set those expectations, right? Now, obviously, if it's literally everything is on fire, you can pause your kind of onboarding for a little bit, but don't make it a habit and don't make it a everything is on fire all the time because realistically everything is not on fire all the time. Time. There are different levels of fire.

Yeah. I feel like it though, depending on the team and how they, what the type of environment, you know, they create. I've seen people, so you take the same problem and then you have people which just remain calm under pressure. And when you communicate with them, it doesn't feel like things are on fire. And then you have people who doesn't deal with pressure that well, and then you communicate with them and you think, you know, we're going to run out of cash flow tomorrow or something like that. So, so it really like as well depends how people give you information. So you have to be sort of, uh, emotionally intelligent.

That's where you need to lean on your experience.

Yeah, exactly.

That's where you need to lean on your experience to understand, okay, but is it really that much of a problem?

Is it really that bad? Yeah, you might need to pick—

And again, this goes back to who's your team, right? Who's your team? It's the exec. So lean on them.

Yeah.

You're new. but they understand the business. So go like, hey guys, I've got this problem. I can deal with it like multiple ways. I've got people telling me we're going to run out of cash. CFO, are we actually running out of cash? CEO, what's our priority here? This new launch or the, the other thing? Don't be afraid to go, hey, I'm new. I don't have the full picture. I'm still ramping up. I think it's, it's really important to have very little ego. As a, uh, as a see anything, but especially as a CTO, uh, you know, I'm, I don't always know everything. I depend on other people to have that information. And, but what I can do really well is I can sort through that information and I can know, and then can then build a view of where we should be going.

So effectively what we are, what we are saying, set some boundaries from day one, don't get sucked into things you should not be sucked into and just empower and delegate the team to just, just put the fires down, make your own judgment decision if it's actually a fire you need to be involved in and help them with, or just go like, no, no, you got this. Tell me the options. I'll guide you through the solutions. But you know, you, you're going to decide.

Even if the team you have isn't perfect, still do that and give them that responsibility. And then make notes of where they're failing and then plug those gaps, whether it's capacity, whether it's training, whether it's bringing in the right people, you know, like it's, don't be afraid of like a little bit of failure to get to the strategic goal, right? You're never going to be able to do everything perfectly from day one. I think I see a lot of CTOs actually getting really frustrated with that and like not understanding that perfect takes a bunch of steps to get to. They just want perfect right away. Um, and they inevitably fail. They frustrate themselves. They burn themselves out. They focus on the wrong things and they get too stuck in the details because of it.

Mm-hmm. You're preaching to a person who's been guilty of that multiple times. It's something I need to overcome all the time because I just—

Such a natural thing.

Yeah. I just want things to be like, mm. Perfect perfectionist, you know, do you have all the details and it comes at the cost or a trade-off of decision-making speed, you know, like overthinking things just too big, over-engineering and stuff like that, which comes at the cost of timelines and stuff like that. Yeah. So I get exactly what you're saying. It takes time and failure to learn that that's not the best approach.

Yeah. And failure is sometimes a very good thing. We need to, so one of the interesting things is a lot of people are very afraid of failure. Um, I'm of the mindset that you should somewhat celebrate failure as long as you understand it and understand, learn from it and understand the root causes of it, but you're never going to understand the root causes of it and understand it if you're not in a way celebrating it, if you're just so scared of it all the time. That you're like, can't fail, can't fail, can't fail. You start like paving over things in your head that, because you don't want it to be a failure, but actually like be like, no, we fucked this up.

Yeah. I love that Etsy, uh, who's again, to have a point, you know, you might think is not a technology company, but it is. It's a, it's a big e-shop. I mean, they build everything themselves. They have a yearly Christmas graduation. Where they reward the biggest failure of the year and they reward it with a sweater which has 3 arms.

Yeah.

So they celebrate the failure and the person comes on stage and they go like, I fucked it up. I did this this year. And then everybody's like, good job.

Good job.

But they do it.

Spotify do something similar from what I remember. I'm not sure.

Yeah. It's basically allowing people to celebrate failure and creating a culture of not being afraid. You know, to fail. And they have a very good framework of if the failure happens, here's a retrospective, here's all the details.

Exactly.

Here's the learning, here's how we're gonna—

You need to examine failure for sure, right? But you can't examine it without in some way celebrating it as well.

And you cannot penalize. I mean, the moment you penalize failure, you just made a mistake.

People then start hiding it.

Yeah. And then it's just not so good. Then I, to not give names, you know, I've been part of a very big merger acquisition where where a company board brought that failure in, where there was a codebase so, so important that there was internal joke. If you make a mistake in it, you're fired in 4 months. And that joke, of course, you know, like when people shared with me, I was like, this has to be some truth behind that joke. Cause the joke wouldn't be alive if there wouldn't be an actual. So once I started digging, it was actually like that. People were being very penalized if they would make mistake in that codebase because it was dealing with financials, right? So it would actually be a big problem to make a mistake there, 100%. So eventually what happened that no developers wanted to touch anything around that. So they just refused work because they were afraid to lose a job if they make a mistake. And then here's a business now, has a legacy code, needs to make a change. No one wants to make a change.

Exactly. And you've just sabotaged yourself.

Exactly.

There are ways of guarding against the impacts of the failure because you can have systems in place that, you know, it just sounds like they need to improve their testing, right? They need to improve the guardrails around that system.

Yeah, exactly.

Not take it out on the people who make the mistake.

100%. Right, let's jump into questions. So we got one from people listening in us live. So I'll put it on the screen, read it live. So we should be seeing, might sound like an odd question, but how technical should a CTO be? Should they have solution architect level or technical knowledge? I'm not a developer. I'm not a developer. Does that rule me out as being CTO? Okay. So ultimately a question is I'm not a dev. I probably don't have that much of a tech knowledge. What is the level of technology you should have so you can be a CTO?

There are plenty of CTOs that weren't developers. And some very successful ones. Um, I would say it depends on the nature of the business. Some businesses are extremely technical and even to be able to operate them at a strategic zoomed out place, you need to have like a solid amount of technical knowledge, right? Or if you're coming in and like fixing companies that are very technical that aren't operating well, not having that background. Will, you know, will prevent you from being able to sniff what's true and what's not. Um, but it doesn't apply to every company and, or every CTO job. Um, and it depends kind of from the question. I'm not sure if they mean that they are a solutions architect or that they are not technical at all.

No, it's saying I'm not a developer. Does that rule me out as being CTO?

Yeah, but some of solutions architects aren't developers. It depends on the nature of the business as well. Uh, I would say it doesn't rule you out. I think it just gives you more of an uphill struggle climb to get there because you will be perceived as being, you know, oh, this guy won't get it. Right. So you'll have more to prove, but to me, the important part, technical director, there you go. Uh, I think that's fine. Because the important part is being able to understand the tech at a high level and just having that business sense and that strategic sense is more important than being kind of in the weeds, right?

I think— 100%, I agree, Khalil. I mean, the distance of you creating from writing code and ability to read code with every role is just it's just bigger and bigger and bigger. You go to team lead, you still see the code, but you now not writing the code anymore. You know, you're leading a team. You go to something like a developer manager, you're not even looking at the MRs anymore. You purely delivering, dealing with deliveries. You, you know, you care about timelines and risks and team's capabilities. You go up to something like head of engineering, then it's, you know, becomes a lot more strategic. You don't even know what they're doing. You don't even know the Jira now. You're just looking at the bit. And the higher you go through all these level and you go to CTO, depending on the size of organization, ability to understand code will just really not be there. It's going to be more like costs and risks and yeah, business acumen. And I think that's the message we're trying to send with this episode is that you manage business through technology. You don't manage technology directly, right? Yeah.

And I mean, just to mention kind of my emerging CTO, course, again, there's no technical element to the course. Even the technical modules, like the infrastructure management and stuff, take a purely kind of business strategic perspective because it's about teaching business and teaching how to have a business-minded approach to leading tech, right? Leading tech is different from building tech. And a lot of people I see like get really offended and disagree with that and go like, you can't be a CTO if you're not like committing 15,000 lines of code a day or whatever, but you know what I mean? It's like, these people are naive and they don't, they genuinely don't understand kind of the, what it takes to be a strategic CTO at a certain scale. Obviously it's different than a scrappy startup, but yeah, I think the business-minded strategic perspective is much more important, even if you're just really good at communicating. And like, you know, working with people, that's probably more valuable than being super technical.

You have a different business profile, you know, probably in a startup to your point, Khalil, you know, you're wearing like 4 roles in one, you know, so it's like you are CTO, you need to be strategic, you're probably doing a little bit of product, maybe you're still writing code or doing some infrastructure setup, but that's because it's a small company that The bigger company you go, the more that doesn't matter. And leadership, communication, strategic thinking, ability to execute plans and timelines and being creative, you know, the art of possible as they call it. Yeah, that matters a lot more. So, all right, let's do some other questions. So I got some rapid questions for you, Kirill. These are fairly tactical, so I just want your point of view, you know, from the field. What 3 metrics should a new CTO publish in the first 30 days? of starting at that role?

Publish?

Well, you know, share it to the business or the board or the peers. It's like, here's my 3 metrics.

Okay.

That's what I care about.

Um, progress, historical progress to roadmap. That's number 1. Hmm. Number 2, team capacity. How, how am I, do I have what I need to achieve what I need to achieve? And number 3 is one that's often neglected, but security posture. How resilient is my system? How much of a risk do I have to business operations from just not paying attention to security? Because so many companies don't.

And we're talking about cybersecurity, right? We're not talking like business continuity plans. Literally the chance of you getting hacked. Okay.

Yeah.

I love that. Yeah. Yeah.

I mean, it's such a threat nowadays. You see how much ransomware is just wrecking the industry at the moment. Even like there are vulnerabilities being introduced through like GitHub NPM pulls and whatnot, like really popular modules as well. So, you know, it's, um, okay. It's number one.

So two first metrics, uh, fell to me. Like a proxy metrics of ability to execute. And so, so you're looking just as historical execution and then you're looking at your team capabilities, which is effectively one part of execution.

What do I need to fix essentially?

Yeah. Okay. Uh, which meeting, uh, would you put in immediately after starting the role to sort of, so you come in, it's quite chaotic, right? It's quite chaotic. You know, a lot of bugs and, you know, maybe roadmap is everywhere. You're not Like, yeah, never happens. Like literally never happens. Sarcasm. So, so that's your picture and you come in and it's like, what, you know, what like meeting or cadence or whatever you put in just to have a grip of all of that?

Um, do, how many days did you say? Sorry. Did you say?

Let's say like a, you know, one month or couple of weeks in, you know.

Yeah. Um, operational review meetings. Need to happen. So with all of the leads that you have of, of the squads, what are we, what are you, what have you done? So I like a monthly cadence for stuff at a CTO level generally. What have you done? What do you need my help with? What do you need to know that you don't know today? Okay. If you answer these 3 questions with your leads, you start kind of moving in the right direction right away.

I love that. So here's a follow-up on that one. I have my own answer, so I'm really keen to know yours. So you're coming in and of course there's a big tin expectations to you, you know, as a CTO, but what decision, you have many decision rights, but what decision rights you take in from like CEOs and PMs and others and you sort of go like, this is mine, You know, no one's gonna make call about death. Do you have any?

What do we roll out when?

Ah, yeah, I got exactly the same. So release dates.

I am notorious for being a dictator with that.

Yeah, release dates.

Like I will have other C-suite members and directors and whatnot negotiating with me like, can we do this?

Yeah.

And they know that if I say no, it's a no.

Yeah.

Right. Because I am like, no, my number one priority is for us to be able to, to give us the ability to operate as a business. Right? So I'm not just saying no because I'm like, I don't understand or I'm mean. I'm looking after, you know, our ability to trade. It's a huge responsibility, you know, um, the CTO role is genuinely a very heavy burden because it's on you usually if, if the, you know, again, most Most CTO roles are in very tech-enabled businesses, and if something goes wrong, the business can't trade. Yeah, it's a very heavy responsibility, right? And you have to take it seriously and you have to be really assertive about it.

Yeah, I love that. What's the single biggest money leak in tech teams you see and CTO should be sort of aware and looking to fix it?

Lack of knowledge of cloud systems, cloud infrastructure. It happens so much. So much.

So much.

Because people just go like, oh, we'll roll this out. We'll spin this up. We'll do this, you know, the whole like, oh, I'll do microservices. Well, yeah, but do you have really long-running workloads? Do you need to be on all the time? Or are you actually bursty? Because one business that I worked with. Um, we're able to cut the costs by, I mean, I kid you not, 90% by just not using microservices and going to more traditional, like, oh, here's virtualized infrastructure. Whereas with other businesses, because they're very bursty, they're very on demand, actually microservices will do that same reverse effect, right? But even when it comes to that, it's like, how do I manage my platform costs? How do I put savings plans in place? How do I continuously monitor that and continuously have a strategy and a plan? You know, FinOps, embedding actually FinOps in your whole kind of engineering structure is very neglected. People think, oh, I'll get in a consultancy to do FinOps. Yeah, but unless it's embedded in the way you do things, it's not going to scale. Stick.

Yeah, I'm, we, a real example I have, and by the way, my experiences as well that a lot of money leaks are in the cloud and how infrastructures are getting set up. And we recently dealt with the real use case where, you know, the system is, it's a high-low system, you know, millions, actually billions of transactions every month. And the code was capturing logs, right? So it was writing in, you know, logs in a in a database. So if there's an issue, people can trace back and stuff like that. And a lot of code had just a pure, you know, a full body dumps, you know, you have like an object and you dump it in the logs. And the cost of logs were basically like $70K a month. And then when we asked the devs, hey, can you look at all your codes and what you're logging and log exactly what you need instead of just everything? That cost went back to $6K. So.

You know why? They were logging info events.

Yeah, yeah, exactly. Yeah, yeah, exactly. That's, yeah.

Do you know how often I see that? That's, that's so common.

So common.

Logs, by the way, are deadly because people, uh, kind of treat them as a, as an extra, as an also, right? So they focus on the functionality they're doing and then they're like, also we log. Yeah. And, uh, like I've run into a problem before. Where, and this was for a major infrastructure company, and they were rolling out a new system. We rolled it out. It was just dying. It wasn't scaling. You would increase the infrastructure and it would perform worse. And then when we really found the problem, it was because they had single-threaded logging. And so the more infrastructure you were adding, the more contention there was on that single-threaded logging. So you were like sabotaging yourself. Logging is super important to consider as an aspect of everything else.

I mean, in this case I shared, it was a very good example, you know, to talk with the stakeholders was you could have another 8 people for that budget and you could have had those 8 people for the last 9 months if you would have thinking, because it was $70K a month, which went back to $6K. So you have like $64K a month. Which is basically like 8 people headcount for the whole last year, you could have another team driving your product, right? So when you give that story, they go like, oh, damn it, we should get FinOps. We should move left of, you know, teaching people to think finance.

That's always the way you need to frame it, right? It goes back to our initial conversation around return on investment. This action, what does it result in in terms of return on investment, right?

100%, right? So you inherited an engineering team because you just joined. What is the first question you ask every manager?

How often do you have one-to-ones?

How often do you have one-to-ones? What are you looking for there? So let's say they say, you know, once every two weeks we talk about statuses, you know, how the projects are doing.

Yeah. Exactly right. That, that shows me a lot because then I know, well, they're not using their one-to-ones effectively. This is a conversation that needs to happen operationally, that they don't have the operational processes in place to be aware of what's happening.

Right.

And actually one-to-ones should be more of a, hey, how are you doing career development? Here are your KPIs. How are we tracking? What do you need help with my help with? Boom, done, right? And that should be like maybe once a week or once every 2 weeks, but the content of it is important as well. I mean, I've even seen situations where you can have like actual structured one-to-ones once a month and it's fine because you have such a good cadence of operational communication.

Okay. I love that. I love one-to-ones and maybe because I love talking, you know, maybe that's why I opened the podcast, but I do enjoy one-to-ones. I feel like, you know, it's a really unique forum where trust gets built, right? Because when you have more people, usually things are not getting shared, you know, and if you share yourself things where people perceive as less shareable, they start developing trust that they can share it back. And then you start getting great details coming in. You start getting these elephant in the room type of conversations, which give you so much intel to make better decisions. I really love one-to-ones.

But they also need to be structured, right?

Yep.

And I think probably the second question I would ask is, when was the last time you gave someone constructive feedback? Hmm.

Amen.

Not just positive. Hmm.

Amen. What's one daily habit that separates a business-focused CTO from a purely technical one?

Oh, easy, easy. Do you check your daily business metrics? Do you check trading in the morning or do you check your infrastructure? Because if you're checking trading, you have the right attitude and the right kind of north star.

Give us a little bit more about trading. What's in the trading metrics? What are you looking at?

Revenue, call, uh, profitability depends what you do, right? So if you're a consumer business, it's around user behavior. So like how many transacting users, how many users are logging in, transacting users versus users logging in. There's usually every business that's run decently has like these daily dashboards that happen, right? And if as a member of the C-suite, you're not looking at the commercial daily dashboards and you're only focusing on your like system health, um, you're blinding yourself, right?

What's one communication or report every CTO should send monthly to the board?

Um, depends on the board, to be honest. Um, and depends on the nature of the business, but I think generally speaking, cover, uh, security posture. So CyberSec, InfoSec, things like that. Cover milestones in terms of towards the board plan, because there's always a board plan, right? Don't go like, oh, we released this feature, but go like, hey, we're tracking to this plan, or, and what are you doing to fix the things that aren't working, basically. And these days, what are you doing about AI?

What are you doing about AI? 100%. 100%. I love that. I mean, that was amazing, Khalil. So if someone wants to keep learning from you, what is the best place for them to connect?

You can connect on LinkedIn. I'm happy to have a chat. You know, go take my course at Imperial. But, you know, I'm always happy to chat, to be honest. And, you know, I've got kind of contact details and whatnot. And yeah, I do like to keep myself out there. You know, I do these types of things. I do events and whatnot. So, yeah, happy to connect with whoever.

Well, just scroll down to the show notes, guys. You'll get a link to Khalil's LinkedIn and as well, we'll put a link to his course in Imperial London College. It's a great course for anyone who are thinking to be a CTO or already is an emerging CTO, it's, it's a, it's a, it's going to put you on the next level. Let's put it like this. And for everyone listening in, I appreciate your time. Drop your questions in the comments and go to Master Integro to check our community out. Until the next time, stay safe and see you guys online.