The Engineering Trap: Why Most CTOs Never Become Real Executives

Speaker A: Foreign. 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 Cities, 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 a 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 plus, 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 strategy skills, which the role actually requires. Khalil, great to have you. Welcome.

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

Speaker A: Yeah. I'm glad you enjoyed it. I'm glad you enjoyed it. So, uh, we met in one of the, um, CTO's dinners back in the day. And, um, 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 in a 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?

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

Speaker A: Okay?

Speaker B: Structure and team. You're never gonna master tech growth if you don't master the art of building a team, uh, 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. Um, 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.

Speaker A: Why, why do you want to go there?

Speaker B: 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. Um, 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 passion and interest in business because ultimately it's a business role, it's not a technology role.

Speaker A: Uh-huh, I fully agree with that one. So I got this, uh, to take us a little bit into that picture of uh, what commonly happens and the wrong picture. Let's read this like this. So I have this uh, phrase which I found online which is called engineering trap. So it happens like very often when uh, uh, it's on a startup side. Uh, but it happens when you have a fresh cto. So someone gets promoted internally. You've been here for seven 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, you know, they can jump in and fix them. So that usually means uh, a business slowdown. It doesn't necessarily mean a tech slowdown, but the business slow. Do you see this pattern in the field as well? And uh, like what usually happens when a CTO sort of cannot stop and just remains in that like deep delivery mode.

Speaker B: I think this is quite a common problem with um, 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, um, um, 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. Mhm. Um, so what I see is often when that happens, like you don't mature as a business leader, you don't mature as a 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. Uh, 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 to, because some of them just aren't interested in that side. They want to continue to code M 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 um, 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. Um, 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, uh, 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.

Speaker A: Okay, I actually love that we'll circle back to that, um, uh, 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 uh, fact that the CTOs don't know how to do that and because they simply don't Speak, uh, 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, uh, so I tend to speak what I know, which is technology and coding, which is 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 Imperial College, or is it something I can read? It's like what, what, what is your advice to CTOs?

Speaker B: 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 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 uh, 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 skillset 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 six month program and it runs um, 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 M And then we move into like the real CTO stuff around innovation, ROI on technology, um, things like um, 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

Speaker A: think it's your program. Yeah, it's the best, of course.

Speaker B: Um, but yeah, so I would like find a coach, uh, um, engage with the wider community. There's actually a lot of really good communities, uh, 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. Um, 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, uh, 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.

Speaker A: It is one of the exact roles. Yeah. For. Yep.

Speaker B: I mean, I would have a question for you. Right.

Speaker A: Yep.

Speaker B: Can you name a single industry or company type these days that isn't a tech company?

Speaker A: Isn't the tech company. It's a tough question, isn't it? Uh, so, uh, things like groceries comes to mind like fish markets, but then when you think about sales system. Yeah, exactly.

Speaker B: Like online customer, email blast.

Speaker A: Uh, yeah. Tech is embedded in a lot of business functions, you know, because business at the end of the day is uh, 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, um, 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 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. Hundred percent.

Speaker B: And even if you are, even if you're outsourcing kind of the core technology function, right. Uh, um, 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.

Speaker A: Yeah, you will be dependent. 100%. That's a great question. It's one of these, like, you know, eye openers that every business, at the end of the day, uh, 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. Uh, which maybe doesn't have it, but it's not a business. I mean, you cannot call it a business, a hobby, right? So. So my wife's sister, she makes soap at home, right? So it's. It's a hobby, but, you know, it pays a little bit. So she makes soap at home and then. 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 U.K. here we have, like, Saturday, uh, 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, like, how do you buy all the required, you know, like, all the ingredients for that? So, um, you still buy it online. So there's. There's an element of sales, you know,

Speaker B: being online exposure somewhere in the chain.

Speaker A: Right? Exactly that. Yeah. But any big business, any business making real money. Headcount, 1040 plus. It's just tech is everywhere, Right?

Speaker B: Yeah.

Speaker A: Okay, so let me, uh. I got some notes. Uh, Kali, let me sort of, uh, 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 a blinders. And then it goes like, who's gonna 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 m 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, uh, assess of you doing this role? Well, like, how do you actually understand that you have a gap and where you have those gaps?

Speaker B: It's a really good question and the answer would be both, but there's different, uh, 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, uh, 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?

Speaker A: Everybody, I built this and I did

Speaker B: 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 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, whatever, how the CTO you were working with failed, where they failed, what was their blind spot? 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 exact level that is telling you where your strengths are, where your weaknesses are, you're never going to develop, you're never going to operate the business well. Right. Um, 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. Uh, you've probably read Radical Candor, right?

Speaker A: Yeah, everybody. I, uh, 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.

Speaker B: 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, uh, is not told that they're not performing and it isn't given the opportunity to improve. Right.

Speaker A: Yeah.

Speaker B: And so yeah, I think you have to be that self aware leader otherwise you're never going to be successful.

Speaker A: Yeah, sometimes you get, you know, sucked into operational mode and I've been, I've been on the receiving end of this and I've been guilty of, of these uh, you know, um, 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, you know, I need to go ask some questions. I feel like it's quite important to develop a workflows 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 1 numbers? You know, once you understand that serving pattern is 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.

Speaker B: 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 line manager if you want to think about it that way. Although in the exec world it's not quite that clear cut because yeah, they're the person operating the business. M. But they need to, you need to be in a peer relationship with them as well because otherwise the business doesn't run well. M. But so it's important to get that feedback from all of your peers across the board.

Speaker A: Right.

Speaker B: 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. Uh, 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, and be very receptive to it.

Speaker A: M. Oh, receiving a feedback that's uh, a, that's a topic on its own. I mean feedback in general, it could be, you know, like five episodes, five hours, you could talk about how to do this. Well, somewhere down the, somewhere down in our history of podcast we have a full dedicated talk about feedback. Somehow, and this is just my experience going through startups, scale ups 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, uh, majority, uh, people just work, uh, 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 washy 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.

Speaker B: 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.

Speaker A: Yeah.

Speaker B: Uh, I think if you look at American companies, the feedback can be a lot more direct usually.

Speaker A: Yeah.

Speaker B: And they're used to a lot more direct feedback. Um, but ultimately I think feedback needs to be structured. Right. And if cycles of feedback needs 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, the biggest kind of I've been CTO at was like 500 plus M. Um, 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. Um, 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.

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

Speaker B: I think a lot of it will depend on the circumstances, uh, um, you know, 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 two years to five 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 ah, 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, you know, progress to your current plan, roadmap, etc. Uh, and having a good view of kind of your branch 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, ah, 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. M. And so, for example, like, let's say you're in a company where, um, 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 what you track and metrics and stuff, there is one that I am a little bit obsessed with and 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.

Speaker A: Yeah.

Speaker B: Things, uh, 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, uh, 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 cost 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.

Speaker A: Mhm.

Speaker B: 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 M and it gives you that business mentality, you know what I mean? You're not going off and wasting your time on things that don't necessarily move the needle.

Speaker A: Okay, so roi, uh, the main KPI, do you have any others which, uh, you know, like top three, which you care about.

Speaker B: Top three, 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 time, uh, 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 go to market? What's my, uh, robustness, like quality. Uh-huh. 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? Um, 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.

Speaker A: 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.

Speaker B: 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.

Speaker A: Uh, so there's a lot of information

Speaker B: out there to actually gather, right? And, like, just to complete the whole snake eating its tail thing, use AI to find what people are doing, saying and doing. I mean, I'm being a bit facetious, right? Are ways to find it. Whether that's, um, getting indexes, whether that's getting consultancies in, whether that doing it, engaging with the wider. With your industry, engaging with your wider market. I mean, we met at a CTO event, right?

Speaker A: Y.

Speaker B: At that CTO event. What were we talking about?

Speaker A: AI.

Speaker B: What was everyone talking about? Not just AI. What am I doing in terms of how do I measure my productivity? How do I engage with your wider market? Understand what's happening and try and measure yourself against that. Um, don't just measure in isolation. Also measure on. Okay, this is where I want to be, but do the. 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, uh, the next five years? Okay, so if I improve this metric, will it get Me there faster or not, if I improve certain collections of metric, what's going to be the effect on my boost? And then, you know, which ones are important and which ones to focus on. Go see what the wider market is doing about those M. And then, you know, measure them according to your internal kind of ambitious goal, but temper them with what's realistic in the market.

Speaker A: 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, uh, of cto, uh, and it's something like, it's literally like one pager. Right. What would you put on that page? Always zoom out.

Speaker B: So, number one,

Speaker A: uh, don't get too deep into operation. Yeah. Okay. Yeah.

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

Speaker A: Yep. Okay.

Speaker B: Always think, all right, 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 military thing where, you know, there's a famous saying in kind of strategic planning when it comes to the military and that no plan survives first contact with the enemy. It's the same in business. Okay. No plan, uh, 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. I'm a big fan of like thinking about things in terms of these types of playbooks.

Speaker A: Right.

Speaker B: Huh. 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, um, uh, 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. M so if you keep that in mind, if you focus on your people systems, um, I think you'll be in a really good place if you use those kind of three rules of thumb. Right, okay.

Speaker A: 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 them real steps to how to execute a certain function. Right?

Speaker B: 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.

Speaker A: Oh, uh, yeah, tell me about it.

Speaker B: We've got these SOPs, we've got this operating model, um, 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, um, you know, this comes back to the whole like dashboarding, zooming out 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, um, like CDC levels don't do is skip levels. Mhm. Um, talk to people that don't report to you, um, and build a culture where they're not scared of speaking to you. You know, be a bit, a bit human about it, I think. And then, you know, you'd be surprised what comes out.

Speaker A: M yeah, it'll get more. Yes. Skipping levels or just not, not sitting in your lane when it comes to just gathering information. That's it. Yeah. Uh, that's a very healthy practice. It usually gives you a lot more than you, uh, would expect to find. And that, you know, gives great ideas.

Speaker B: 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. Mhm. 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, it makes everything you do more efficient. Um, but also like just care about the people that you know, make up your team.

Speaker A: Yeah, 100%. Uh, would you put, would you put, get, get um, infrastructure done so you get metrics on that page. So let's say I'm a new cto, I'm coming in and you know, it's 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 or.

Speaker B: Yes.

Speaker A: Yep.

Speaker B: Yeah, yeah. So always be data driven. It's not necessarily about metrics alone though. Um, because sometimes, uh, 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 false. Mhm.

Speaker A: Yeah, right.

Speaker B: That's true.

Speaker A: Yeah. You can operate on metrics.

Speaker B: 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, in that metric shows a lot, that we're shipping a lot. But actually you're just sizing everything in, in ways to game that metric. Mhm. 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.

Speaker A: 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.

Speaker B: Good luck.

Speaker A: Uh, good luck to you. But it's a hypothetical. But some people potentially listening are, uh, maybe fresh in a role. Uh, what are the, uh, the first things you do in your first month? So you start on Monday, you come in, you know, you have four weeks, you know, what are the couple of things you're doing in that first month?

Speaker B: Um, I have a pattern of Things that I like to do. Uh-huh. Um, 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. Um, and then, uh, 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, 15ish days, I think, and this is something that I packaged up into its own product before. Uh-huh. 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. Um, 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, um, on just purely that, just understanding how the business operates, trying to map strength weaknesses and trying to understand, okay, how do we plug these weaknesses and. Or how do we even turn certain weaknesses into strength, et cetera. How do we fortify the strengths we have? You know, again, it's the zooming out. Mhm. 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, uh. 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.

Speaker A: Uh-huh.

Speaker B: 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? Uh-huh. 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? Um, 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. Um, 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 this 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, two 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 three to five 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.

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

Speaker B: 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.

Speaker A: Right.

Speaker B: 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, uh. 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, um, slide deck that covers certain things and I just make sure that I'm addressing those things when I'm looking at stuff. Um, I know that you need to have this process in place, you need to have this type of team structure, you need to have these types of business, um, to technology links. Um, 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, uh, 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

Speaker A: state, hopefully, you probably wouldn't reach that state if you wouldn't know how you do, how you get things done.

Speaker B: I mean, hopefully. Right. But, uh, you never know. I think there's a question in the chat that's interesting, actually.

Speaker A: Uh, yeah, uh, we'll put the questions to the screen in a second. Uh, 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, um, you come in, it's a fresh role, and you are cto, right? So you are, you know, the guy. And then you come in and, you know, you like two days in, and you're trying to do effectively what you, uh, have outlined, which is having conversations and then, you know, people run in the room, production is down, you know, and. And something else. You know, there's a, this defect. That defect. Oh, there's a timeline, you know, I need. We need to release next week. What do we do? You know, like, we don't have that feature. Make a decision. So you're getting, uh. 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, you know, uh, framework of plans of having chats and, you know, and building the, the team and standards, or, or you go like, hey, uh, 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 by two weeks in and, and, you know, here's a tech lead, he's been here for two years, he's going to make that call or something like that. It's like, what's your, like go to?

Speaker B: Yeah, I think one of the key lessons to learn, uh, 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 two weeks in, I'm not going to be the best person to make this call. M. 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 two approaches, give me three. 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, 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. M. 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, 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. Um, 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. M. 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 set 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.

Speaker A: Time.

Speaker B: There are different levels of.

Speaker A: Yeah, I feel like it though, depending on the team and how they. What the type of environment, you know, they create. I've, uh, seen people. So you take the same problem and then you have people which just remain calm under pressure and, 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.

Speaker B: Lean on your experience.

Speaker A: Yeah, exactly.

Speaker B: You need to lean on your experience to understand. Okay, but is it really that much?

Speaker A: Is it really that bad? Yeah, you might need to.

Speaker B: 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 a 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 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 really important to have very little ego as a, ah, as a c. 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 kind of, uh, build a view of where we should be going.

Speaker A: So effectively what we, what we are saying, set some boundaries from day one. Don't get sucked into things you should not be sucked into.

Speaker B: Yeah.

Speaker A: And just empower and delegate the team to just, just Put, uh, 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, even if you're

Speaker B: the team you have isn't perfect.

Speaker A: Yeah.

Speaker B: Still do that and give them that responsibility and then make notes of where they're failing and m. 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.

Speaker A: Uh, uh, you're preaching to a person who's been guilty of that multiple times. It's something I need to overcome all

Speaker B: the time because I just Such a natural thing.

Speaker A: Yeah, I just want things to be like, perfect perfectionist, you know, do you have all the details and it comes at the cost or a trade off of decision, uh, making, speed, you know, like, uh, 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's takes time and failure to learn that. That's not a best approach.

Speaker B: 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. Um, as long as you understand it and understand and 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 be like, no, we fucked this up.

Speaker A: Yeah, I love that Etsy, uh, who's. Again, to our point, you know, you might think is not A technology company. But it is, it's a big E shop. I mean, they build everything themselves. They have a, uh, yearly Christmas graduation where they reward the biggest failure of the year and they reward it with this weather which has three arms.

Speaker B: Yeah.

Speaker A: 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 everybody's like, good job, good job. But they do, uh, Spotify do something

Speaker B: similar from what I remember. I'm not sure.

Speaker A: 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.

Speaker B: Exactly.

Speaker A: Here's the learning, here's how we're going to.

Speaker B: You need to examine failure for sure. Right. But you can't examine it without in some way celebrating it as well.

Speaker A: And you cannot penalize. I mean, the moment you penalize failure,

Speaker B: you, you just made the people then start hiding it.

Speaker A: Yeah. And then it's just not so good then. I, uh, do not give a names. You know, I've been of, uh, uh, part of very big merger acquisition where, where a company bought. Brought that failure in where there was a, ah, code base so, so important that there was internal joke. If you make a mistake in it, you fired in four 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 because the joke wouldn't be a lie if there wouldn't be an actual. So once I started digging, it was actually like that people were being very, uh, penalized if they would make mistake in that code base because it was dealing with financials. Right. So it would actually be a big problem to make a mistake that 100%. So, 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, uh. A business now has a legacy code needs to make a change, no one wants to make a change,

Speaker B: and you've just sabotaged yourself.

Speaker A: Exactly.

Speaker B: 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, uh, guardrails around that system.

Speaker A: Yeah, exactly.

Speaker B: Not take it out on the people who make the mistake.

Speaker A: 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. Uh, 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 a being cto? Okay, so ultimately a question is I'm not a dev. I probably don't have that much of technology. Ah, what is the level of technology CEO should have so you can be a CTO?

Speaker B: There are plenty of CTOs that weren't developers, um, 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, uh, 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, will prevent you from being able to sniff what's true and what's not. Uh, um, but it doesn't apply to every company or every CTO job. 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.

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

Speaker B: 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 climb to get there because, um, you will be perceived as being, oh, this guy won't get it right. So you'll have more to prove. But to me, the important technical director. There you go. I, uh, 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?

Speaker A: I think a hundred percent. I agree, Khalil. I mean the distance, uh, of you, uh, creating from writing code and ability to read code with every role is just, is 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 their Mars anymore. You're purely delivering, uh, dealing with deliveries. You know, you care about timelines and risks and teams capabilities. You go up to something like head of engineering. Then it's, you know, becomes a lot more strategic. You don't like even know, you 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, uh, ability to understand code, um, um, will just uh, 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.

Speaker B: Right? Yeah. And I mean, just to mention, um, 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, uh, lines of code a day or whatever. But you know what I mean? It's like uh, 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 uh, like, you know, working with people, that's probably more valuable than being super technical.

Speaker A: You have a different business profile, you know, probably in a startup. To your point, Khalil, uh, you're wearing like four roles in one. 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, uh, strategic thinking, ability to execute plans and timelines and being creative, you know, the art of possible as they call. Yeah, that matters a lot more. So, all right, let's do some other questions. So I got some rapid questions for you, Kirill. Um, these are fairly tactical, so I just want your point of view, you know, from, from the field. What three metrics should a new CTO publish in the first 30 days, uh, 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 three metrics.

Speaker B: Okay?

Speaker A: That's what I care about. Um,

Speaker B: progress, historical progress to roadmap. That's number one, M. Number two, team capacity. How. How am I. Do I have what I need to achieve, what I need to achieve? And number three is one that's often neglected. Uh, 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.

Speaker A: And we're talking about cyber security, right? We're not talking like business contingent. Uh, literally the chance of you getting hacked. Okay, Yeah. I love that. Yeah. Yeah.

Speaker B: I mean, such a threat nowadays. You see how much ransomware is just wrecking the industry at the moment. Even like, their vulnerability is being introduced through like, GitHub, npm pools and whatnot, like really popular modules as well. So, you know, um, okay, it's number one.

Speaker A: So two first metrics. Ah, 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.

Speaker B: What do I need to fix, essentially?

Speaker A: Yeah. Okay. Uh, which meeting, uh, would you put in immediately after starting the role to. So. 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, that what 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.

Speaker B: Um, do. How many days did you say?

Speaker A: Sorry, let's say like, you know, one month or a couple of weeks in, you know.

Speaker B: 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.

Speaker A: Okay.

Speaker B: 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 three questions with your leads, you start kind of moving in the right direction right away.

Speaker A: I love that. So here's a follow up on that one. Uh, I have my own answer, so I really keen to know yours. So you're coming in and, uh, of course There's a big, uh, ten expectations to you as a cto. But what decision. You have many decision rights, but what decision rights you take in from CEOs and PMs and others and you sort of go like, this is mine. You know, no one's going to make all about death. Do you have any.

Speaker B: What do we roll out when, ah,

Speaker A: uh, yeah, I got exactly the same. So release.

Speaker B: I am notorious for being a dictator with that.

Speaker A: Yeah.

Speaker B: I will have other C suite members and directors and whatnot negotiating with me like, can we do this? And they know that if I say no, it's a no.

Speaker A: Yeah, right.

Speaker B: Because I am like, no. My number one priority is for us to be able 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 the, you know, again, most, most CTO roles are in very tech enabled businesses and if something goes wrong, the business can't trade. It's a very heavy responsibility and you have to take it seriously and you have to be really assertive about it.

Speaker A: Yeah, I love that. Uh, what's the single uh, biggest money leak in tech teams? You see? And CTO should be sort of aware and looking to fix it.

Speaker B: Um, lack of knowledge, uh, of um, cloud systems, cloud infrastructure. It happens so much, so much, so much, so much. Because people just go like, oh, we'll roll this out, we'll uh, we'll spin this up, we'll do this, uh, 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, uh, 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. Um, 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? Yeah, 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, uh, 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.

Speaker A: Yeah, a real example I have, and by the way, my experience is 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 the system um, is a high, low system, uh, billions of transactions every month and the code was capturing logs. So it was writing M locks in um, 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, ah, full body dumps. You know, you have like an object and you, 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 where you log in and log exactly what you need instead of just everything that cost went back to 6K.

Speaker B: You know why they were logging info events.

Speaker A: Yeah, yeah, exactly. Yeah, yeah, exactly.

Speaker B: Do you know how often I see that? That's so common.

Speaker A: So common.

Speaker B: Uh, 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. Uh, 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 in, as an aspect of everything else.

Speaker A: I mean in this case I shared, it was a very good example, you know, to talk uh, with the stakeholders was you could have another eight 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, uh, then they go like, oh damn it, we should get finops. We should Move left of, you know, teaching people to think financially.

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

Speaker A: M 100%. Right. So you inherited an engineering team because you just joined. What is the first question you ask every manager?

Speaker B: Um, how often do you have one to Ones?

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

Speaker B: Yeah, um, 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, uh, 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, uh, or once every two 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.

Speaker A: 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, like, you know, uh, uh, 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, 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, you know, great details coming in. You start getting these, you know, elephant in a room type of conversations which give you so much intel to make better decisions. I really love one to Ones.

Speaker B: But they also need to be structured. Right?

Speaker A: Yep.

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

Speaker A: M Amen.

Speaker B: Not just positive.

Speaker A: M Amen. What's one daily habit that separates a business focused CTO from a purely technical one?

Speaker B: Oh, easy, easy. Do you, do you check your daily business metrics? Do you check trading in the morning? Or do you check your uh, infrastructure? Because if you're checking trading. Mhm. You have the right attitude and the Right. Kind of, um, North Star, give us

Speaker A: a little bit more about trading. What's in a trading matrix? What are you looking at?

Speaker B: Um, 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 user 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.

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

Speaker B: Um, depends on the board, to be honest. Um, and depends on the nature of the business. But I think, generally speaking, cover security, uh, posture. So Cyber sec, infosec, things like that. Um, cover milestones, uh, in terms of. Towards the board plan. Because there's always a board plan. Uh-huh. Right. Uh-huh. 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, um, the things that aren't working, basically? And these days, what are you doing about AI?

Speaker A: 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?

Speaker B: Uh, you can connect on LinkedIn. I'm happy to have a chat. Um, you know, go take my course at Imperial. Um, but, you know, I'm always happy to chat, to be honest. And, you know, I've got, um, kind of, um, contact details and whatnot. And, uh, yeah, I do like to keep myself out there. Um, I do these types of things. I do events and whatnot.

Speaker A: Excellent.

Speaker B: Happy to connect with whoever.

Speaker A: 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 emerging cto. Uh, um, it's gonna 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 Integral to check our community out. Until the next time, stay safe and see you guys online.

Speaker B: Sam,