Strategy First, Tech Second: How CTOs Drive Business Value

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. My name is Mike Serdyas and today we are talking why the best CTOs put strategy first and technology second. Joining me today is Andrei Nita, CTO of Mackenzie Intelligent Services. Andrei's He's on a mission to help CTOs stop chasing tools and start leading with strategy to drive business value. Welcome, André.

Thank you, Mike. Excited to be here and wow, that's a much better intro than I would ever be able to give about myself. Thank you.

I love you, love that. So it's been a while. Now I'm reflecting on the show. It's been a while. We started with CTOs and then, you know, we had some other experts, sales and marketing and SEOs and content production, you know, founder-led things and social media. So I'm now thinking it's been a while that we had a CTO, so it's great to have CTOs back on the show. We'd love to kick off with this one, André. When I say mastering tech growth, what comes to mind?

I would say putting tech at the middle of the business and ensuring you can scale it with your business and have a long-term plan that will really drive the business forward.

I love how you put this. I wanna unpack this a little bit. So let me make it more difficult onto you. So from all the things you can choose, and I'll give you a couple of examples, you know, you can choose hiring Great talent, you can choose, uh, do you, you know, doing better with sales and doing better with marketing. So all these factors that influence business growth, a tech venture business growth, right? What do you think is number one or like from your perspective, what is number one?

Um, it, I mean, I wouldn't choose necessarily. I would rather see it as a timeline. Okay. Uh, uh, because you need to start with getting the right people in your team, then setting the right metrics, uh, always having the goal in mind, being very clear with what you want to achieve, and then kind of moving forward from there. So I wouldn't necessarily be able to pick just one. I would say it's more like, this is a good way in which you can think about it. This should go first, then that. And so on. I rather think it's a timeline as opposed to just this is the best thing or this is the one thing that you need to do.

Oh, I love that. That's definitely experience talking here, Andrej. So we're saying that in a business maturity, which is the timeline, while the business is maturing, there's different things which will matter more or less while the business is going through its journey, isn't it? Yes.

Yes, I would say so. Exactly. So, I've found myself giving this answer for everything lately. So the first time I ever found something similar was when somebody gave this answer for philosophy because somebody asked what's the best philosophy. And the answer is there's no best philosophy. It's whatever is good at the time. Okay. Each case is different. So you can't just pick one that will fit all. So it's the same in the business. There are different focuses that you need to have at different times in a business.

All right, excellent. So imagine you coming now in a business and let's say, you know, you just landed a role, you come in as a CTO and the tech stack is just a pure dumpster fire. What does that actually look like on the ground for the engineers managing that?

Yeah, that's a great question. I think it's easy to just think, uh, um, let me just fix the tech stack and, and start changing everything left and right because I know that it worked in my previous role. I know that this will work for this scenario, but, um, really you have to look at what the business is trying to achieve. Um, and then kind of play down from there. So really understand where, where's the business going? What, what are their goals? You know, they want to expand in a different geography, in a different region, right? They want to. Move from this vertical to that vertical. So going from the kind of business goals, the long-term business goal, then moving back into tech stack because you really need to know what you're building for as opposed to kind of picking the solution first and then forcing the business to fit that solution that you pick.

But I fully 100% agree with you, André. And at the same time, I have this follow-up is like, why do then so many companies hire engineers before defining like a product ownership or tying tech to actual business goals. Like why is this happening so widely?

I think it's just human nature because you tend to fill the gaps that you have, right? So you think, well, I'm really bad, maybe in this case, right? Maybe I'm not good enough at tech products. I'll just hire people that do tech and product, but I can't hire somebody senior enough. Maybe because I won't know exactly what to tell them, but I would know what I could tell an engineer that I want. So it might be simpler for me to hire an engineer. So I would say it's just human nature. People are more comfortable with things that they already know or they can understand.

Is this a mistake? Is it just like not knowing? You know, it's one of these things like you don't know what you don't know. So you're probably going to make that decision, which will be a mistake. Or as you put it, you know, you're sort of aware of it, but you know, it still feels like a progress. It still feels like, you know, you're doing something.

Yeah, yeah, exactly. It could exactly be that where you could say, well, okay, I'm not getting, I don't know, a VP or a director or a chief. I'm still getting an engineer. So there's still something that happens, something that moves the needle. It's a bit messy now. It's fine. I'll fix it in the future. So there's still progress, but it's not, I would say, like the exact progress that you'll need to get you where you need to go as quickly as you need to go. It's more like still going forward, but taking a detour or going slower, right? So there's still progress, but is it the right progress? Is it in the right direction? Okay. Will you need to migrate a few times in the future? You've done those decisions in the past. That's kind of what you need to think about.

So it's a trade-off situation. We're not saying necessarily that that's the mistake, but if you're making that call, which on paper might look as a mistake, but you're probably just making a trade-off. You're like, you're aware of it and you go like, you know what, that's the budget. That's what I can find now. I'm still gonna, you know, get this. And the trade-off is that, you know, I'll probably will need to pay for that. As you put it. Yeah.

Yes. And it could be that exactly as well. So it could be maybe I'm not comfortable with getting somebody very senior. So I'm not, I'm just going to get somebody at the IC level or maybe I can't afford somebody senior. So again, I'll get somebody at the IC level. So it could be a lot of things. Yeah, you're right.

Okay, excellent. I have this one thing from one of your posts on LinkedIn. You said, if everything is a P0, nothing is a P0. Can you unpack that? Like, how does that actually play out in like real scenarios for engineering teams?

Well, I think that sort of comes from teams constantly firefighting, right? That's not a scenario in which successful teams operate. So if you keep firefighting, then there's not really going to be progress, long-term progress. It's just going to be Survival, right? Survival mode. But in survival mode, you can't do things that really put you above the market, right? You can't really do R&D because it's a different mindset. If you keep thinking, what fires do I need to put out? You're not really thinking, what cutting-edge research could I focus on to really advance my field? So, um, The other part, I guess, that I was referring to in the post is that if you have, let's say, multiple departments all saying everything I need is important, then it's probably not the case because not everything can be important at the same time, right? What is it that is the most important, right? And one way to figure it out is where does the business need to go? And then you kind of go from there. So I think that's what I was specifically referring to in that post. But in general, P0s are not somewhere where you want to be. Having a lot of them is not a good kind of situation. So you kind of need to figure out why am I getting so many and how can I get rid of them?

So effectively, you need to sort that out. And I do have a couple of questions, you know, about firefighting in particular, but before we go there. I want to understand what that actually means then to the business. So if you prioritize that technology-first type of situation, you know, I need to fix the tech, I mean, maybe technical debt, maybe infrastructure change, and you just think about tech first rather than, you know, that strategy and aligning to business values, like what does that actually mean to like, you know, businesses and, you know, what do they lose by choosing this?

By being tech first? Well, again, long-term thinking, strategy, making sure that you always focus on revenue, having a revenue stream, because focusing tech, you know, there's a risk that you're going to increase the cost without really thinking about how you're going to cover that cost. So you really need to be sure that what you're developing will contribute to revenue at the end of the day.

Otherwise you just, yeah, you just, yeah, yeah, continue.

There's no point in living in a bubble where you think, well, I'm the technology team. I never really need to worry about revenue. I'm just going to stay here, develop, and then, or wait for people to tell me what to develop, not even have to think about what I need to develop. And how this is going to drive the business forward, right? That's not a good way of thinking about things. You really need to understand what the business is, where they're willing to go, how they make money, what do clients need, what does the market need, what the pain points are. And that's kind of the whole culture that you should have in the whole technology department. Hopefully, you know, every level will be able to think more or less within kind of those, within kind of that mindset.

Okay. Should we expect that mindset to be there for developers as well? I feel like it would be great, you know, don't get me wrong, if they would think from the lens of revenue and lens of value to the customer. But I feel like that's not what happens. Like when you talk with developers, they just want to use tech, you know, they want to use the newest tech, you know, they want to use AI at this point in time, you know, or this cloud or that cloud, you know, Kubernetes and things like that. They just want to get exposure to technology. They don't really think how that's going to help business, isn't it?

Well, I think that's the value system that you're going to instill.

Okay.

When I hire, I never hire just developers. I think about what I want to hire. And when I think about what I want to hire is I want a generalist. I want a program manager, a project manager, right? Not just an engineer. Somebody who has a very wide set of skills, is very flexible, can adapt to any situation, is hopefully business savvy in, you know, whatever capacity. So I don't just think about, oh, I need somebody who knows AWS and I'm just going to hire somebody who has done AWS in the past.

Okay.

That would be way too restrictive. And so if you start, sorry, I'm just going to finish it real quick. If you start at the generalist kind of mindset, somebody that is very flexible, then you have somebody that you can work with and you can kind of help take through the journey that everything you build will be for a client at the end of the day. They need to be happy. They need to keep buying your product, otherwise what's the point? So, okay, tech is fine, but what's the best solution for your clients at the end of the day? And then everything else comes.

All right. Are we talking generalist, business savvy, PM orientated or product orientated? Is this like a, what type of level that role is? Are we talking like team lead, senior developer, like, uh, like which level is that?

Any level.

Any levels. Okay.

Any level I hire, um, that person will eventually be autonomous.

Okay.

Across a bit of everything. They'll, they'll get to interact with every department. They'll get to, you know, do a bit of product work if they want. Um, they can take it away. So I, I kind of give the freedom to engineers, scientists, analysts, whatever they are within technology, to do as much as they can with their skill set. I don't really see a problem with them going above and beyond or outside of their job title. At the end of the day, it's just like, you know, a text in an HR tool. right? The job title.

So, um, I love you put it like that.

Yeah, some, some of the people that have gone the most above and beyond, uh, that I've hired in the past were fresh grads. This was their first job, and within several months they were performing at a mid to senior level because they got all of the freedom, all of the responsibility, um, and they also were the right kind of candidates, right? The right, with the right mindset. So they saw the opportunity and then they just did what they needed to do to get to that level.

That's excellent. I reflect on myself, André, and I was a head of engineering. I mean, it's been a while. I think it was probably like 10 years ago. And it was one of my first sort of like a higher level roles. And we've been, you know, a startup and I actually joined like the very first one, you know, they built a startup and they outsourced it in India and they then hired me as a head of engineering. I was the first hire here in London. You know, I took all of that, I will repeat, dumpster fire. And then I grew team, you know, internally to grow it and stuff. But I was fairly inexperienced. So these things you're talking about business savvy and product-led and product thinking, I developed them. But for about like 9 to 12 months, I really believed that if we do a better technology, our product will do better. I talked about like this cloud because being better than that cloud, I concentrated on things like uptimes and speed. I concentrated on just writing a better code. And I really deeply like, thought that this is my, my sort of value add to the business, right? So I was definitely putting tech first. And then eventually I learned like, you know, that was a mistake when we actually got a high-level CTO joining the board and he, you know, having a couple of chats with me and putting me sort of straight. And this is where this question coming from. I sort of think like there's a lot of like tech founders, you know, who launch startups or people, hands-on developers, you know, coming into these roles. I feel like they don't think like that. So I'm very like intrigued, like when you hire these people, I mean, do you find them quite easily or is it something which takes time to actually find that person?

No, no, no, it's not easy. Like if it's easy, you're doing it wrong, I think. It's a lot of work interviewing a lot of people and depends if you do it all internally or if you also go external to agencies. In my case, I had agencies as well as internal, so it was a bit quicker than if I would do it all myself. But no, it's not easy. It could be, you know, 1 in 10, 1 in 100, 1 in 500, depending on how many candidates you look at, how many resumes you look at, the seniority of the role. But yeah, once Once you get that person that, you know, you know will do the role, you kind of can tell from the first interview.

Yeah.

Let's go for the questions, let's wrap it up.

Yeah, it's like, I don't know how to phrase this, it's almost like a gut feel. And every time, like, you know, when I would go to roles and I would get interviewed and they would ask like, you know, how do you, you know, how do you like interview, you know, how do you hire, what's your like, you know, framework and stuff like that. And I never could articulate like what exactly is my way of hiring. And then I saw Elon Musk talking in some type of like conference and someone asked you like, you know, how do you hire talents? And he's like, I just have a gut feel, like I just feel if the person is good or not. And I was like, that's it, that's how I hire as well. So I think that's what we're saying is like, you just talk with person you just know.

Yes. You know, if you think about, I think Thinking Fast and Slow, Daniel Kahneman's book, right? He coined System 1 and System 2, right? System 1 is the one that thinks very fast. You give an answer right away without thinking, right? And System 2 is the one where you need to stop and really kind of think deeply about what of that topic, right? So I think everything, you've internalized everything and system 1 just goes and says, yep, that's the one. But system 2 then would find it hard to explain why that is the one, right? So that's kind of, I think, what we refer to as gut feel. And definitely it is gut feel. You know, if you ask me why exactly I think that specific person was the right one, I probably won't know how to answer, so I'll probably need to take like 20 seconds to think about it. But yeah, definitely, I also have gut feel, I say.

Yeah.

All right. That's cool.

I thought it's just only me who doesn't have answer to that, but gut feel is a good answer. I'll use that next time. So, let's say you come to this business and, you know, you are like firefighting, you did some moves and you, you know, you took this under control. How do you actually, you know, make the shift now from this like survival mode to a strategy-first leadership?

You kind of need to figure out what is it that if it happens, it would really hurt the business. Like, you know, the whole application going down, having 100 customers send complaint emails. To not being able to respect the clauses in your contract that says X, Y, and Z. So those kind of must not cross thresholds, you need to really kind of make sure that will never be crossed, right? That would be step one, right? And I guess you also mentioned, right? Some of those aspects that you would need to make sure that that doesn't happen, like monitoring, right? Learning. Making sure that you're always informed about the status, the situation of all of the services that you've spun up. So I would say that's kind of step one, making sure that, you know, they must not cross thresholds.

So are we talking here about like a business continuity plan, which is, you know, like a Scientific terms about that?

It's like, you know, yes, I would say that at the beginning of, um, you know, try to make sure that you're afloat. Thinking in terms of business continuity plan is gonna be extremely slow. Um, okay, I would say find those things that if they happen, you're in trouble, or the whole business is in trouble. Make sure they don't happen. I would really simplify it because if you really start thinking about disaster recovery plans, continuity plan, you know, anything that is intensely procedural, you're already talking about timelines of weeks to months as opposed to timelines of hours and days, which is what you need. Like in your first, let's say, 30 to 60 days.

Okay, I get you. I get you perfectly. So in one of your posts, you said align tech with strategic pillars. So when you say that, is that what you, you know, sort of mentioning right now is like, these would be the strategic pillars as in, you know, they must not cross threshold or whatever is that strategic pillar? Am I—

Yeah, I mean, this is quite binary. This is more like if this happens, then, you know, there's a clause in the contract that says I need to pay 5%, I don't know, of the contract amount, right? Something like that. In case you, for example, have, let's say, an a clause in your contract that says that if your uptime ever goes below 99%, then you need to pay us this much, right?

Yeah.

You never want that to happen because though a contract can be quite large, maybe you have a contract that is a million pounds and then you need to pay 5% of that. You're probably not going to want to.

To be there. Yeah. I do remember we literally had that. It was with the UK police forces with the same startup, which I talked before. And we had an uptime which was so aggressive. It was 99.7, and everything was so shaky. I mean, it would wake me up at night, basically. Yeah, I can—

Exactly. So, and then, and that's a very good point because you've said that now, that takes me to step 2. Take the steps necessary to make sure that nobody needs to work out of hours. Have that in play from day one, really have that at the top of your mind. Because I think it's kind of assumed in the business that you need to work outside business hours, but really it shouldn't be. Because if you design over your systems well, then you shouldn't have to work outside business hours, weekends, nights, your services shouldn't fail just all of a sudden. So make sure you design with that in mind. Have failovers. I think that's quite important as well. And it will help you hire. If you, if, you know, in your hiring process, you tell people, by the way, you might need to work 24/7, they probably won't join.

I get exactly what you're saying, André. And the business I'm currently working with, they have a pager duty. And when I joined, I was added as a second in command for the pager duty. So they would pager an actual hands-on people, which would be like a team lead and developers who, you know, in theory and in practice are able to resolve issue. And I was second, if they don't come online, as in, you know, they would pull me in so I can pull other people's. And, you know, it didn't happen too often. I mean, it's been a couple of years now and I had only one But that was like 3 AM. That's not, yeah, that's not nice. Okay. So you want to do this. Is there any more steps in what you would do?

Oh yeah. 100%. Once you get rid of, you know, the must-not-cross, then focus, how do I make sure that everything works? And if it breaks, it only breaks when I'm working on it as opposed to when nobody's around. Then I would say, then kind of think about, um, migration, right? Stuff that would work better than what I already have while having at the top of your mind everything from before what I've just mentioned, while also having delivery speed at mind. Because if you really think about, um, the commercial aspect of technology, a lot of it will be measured in delivery speed. How quickly can you deliver? How quickly can we go to market with these features? Right? Yeah. If you really think about it in that, in that sense, you have business that sets goals, then product translates those goals into a roadmap. That roadmap has features, right? Those features are part of a product or multiple products. And then who delivers those features? Technology. So at the end of the day, your business will be as competitive as the number of products it has, the number of features each product has, ignoring everything like market penetration and adoption, et cetera. If you ignore that and just assume that people will buy it, you have to ship as fast as possible. So that should be like number 3, developing while having delivery speed in mind. There as possible, as quickly as possible.

Is there number 4 in that list? I mean, that's a great top 3. I can't argue with any of these.

I usually stop at top 3 because then people kind of forget what happened before top 3. If you go like 4 and 5, everyone would have forgotten by then what happened. So let's stop at top 3. I think that's good enough, right?

Yeah, that's a, I mean, that's excellent top 3. So I see this as a, you know, as a process. I mean, it's definitely like a strategic positioning of all of these getting implemented, but you would come in and you would go like, hey, here's a process of how we're going to get that outcome, which is like, no one's going to wake up at night because, you know, we're going to have a more robust software development lifecycle or more robust observability or self-healing or something like that. You know, at the end of the day, I see this as a process and I have this question now looking from an executive eyes, why does credibility for a CTO from executive perspective comes much faster if you stabilize those processes first, rather than, I don't know, doing tech or something like that? From your point of view.

Why does the observability come first? Sorry.

No, no. Like why executives actually prefer that CTOs come in and get the right processes in place first, then chasing something like tech upgrades or infra upgrades or something like that, or like product features?

I think it's easy in technology to just do the work and not be able to track it. So that's one thing, making sure you can monitor and observe everything, having some metrics in place is always very, very important. Making sure you also can track changes because, okay, you can track a metric now, but can you track what it was a year ago, you know, or 7 days ago, et cetera? I think that's also quite important. Process is very useful. It's time-consuming to find a process. So I think it really depends, you know, how quickly you need to move. If it's an early-day startup and you need to prove value, spending a lot of time on process is not helpful for anyone, I think.

Okay.

Ensure you're doing the kind of the best you can with what you have. And then over time you can grow a process around it. I think, yeah, focusing on process too much won't help depending on how mature your business is. If it's a very mature business with enough budget with very strict deliverables, then of course process is extremely important. So It really depends on the maturity of the business, the nature of the company. Okay.

So, um, so we're saying you can, um, waste, uh, some value if you are startup to thinking about processes and concentrating too much on them. 'Cause ultimately what matters then is your ability to just ship things out and just give features to the customers. And, and, uh, yeah, hopefully that leads to more market share, more revenue.

I would say so in the beginning. Yeah. If you're an early-age startup, if you spend too much time on process, you're probably lagging behind because as an early-age, sorry, as an early-stage startup, you're already behind because you need to catch up to very big players that are already there on the market. Right. Would they think Oh, I should probably slow down to think about process and allow other people to overtake me. They probably won't. So then why would you?

Okay.

Don't give yourself a disadvantage in the race that you're already starting in last place.

So would that mean then, you know, we sort of doing what pretty much Facebook said, we, you know, we're failing fast, right? We just like iterate, iterate, ship, ship, ship, get feedback. This works, that, that, that, and we just like, you know, boom, boom, boom things out and we're just learning. And eventually though, probably we're getting feedback that, you know, something around the software development lifecycle process is, you know, is breaking that there's a bottleneck and then we go and improve that process. So it would be sort of like a reactive process improvement, right? Rather than strategic from a get-go.

And listen, there's a strategic way to do the iterative process. Which is make sure you don't have too many dead ends. Make sure that what you develop can be updated, migrated, you know, that, that, that's the other very important thing that you need to keep in mind. You can take very small steps, but make sure you don't develop yourself in a corner and everything that you build can be changed in the future if you need to, can be improved. If you, if you let's say, if you don't necessarily focus on process, but you still have scalability in mind, you're still good. You're still gonna get there in the end without a lot of headaches.

So when you say dead end, André, you mean dead end is when you build something and you just cannot expand it anymore. It's just like whatever it is, it's like, it's that.

Yes. So if you think like in terms of decision-making, right, you can have a decision that can be undone and a decision that cannot be undone, right? Um, say a decision that cannot be undone is I'm going to cut a wire. If the wire is cut, you're not going to be able to do anything with it anymore. Um, I guess the other decision would be if I needed the wire to be shorter, I could have tied a knot. So then, then the wire is shorter, but if I need the wire to be back to its original length, I can untie the knot. Does that make sense?

It does make sense.

If you kind of think like that, what decisions can I make now that won't put me in a corner? I think that's quite important. And let me think about a real life scenario. Potentially finding like, let's say a software package that has already reached end of life, right? Won't be updated. Or you won't have support for it anymore, but it was really easy to use it at the time and you thought, yeah, what the hell, let's go with it.

Yeah.

Right. But maybe within a year it has so many security vulnerabilities that your security department will say, no, you have to get rid of this. It does fail our penetration tests. Clients, you know, have their own scans and their scans are telling us that this is you know, this is a security risk, so you have to take it out. But by that time, you've realized, oh, but that's 30% of my application. So this is a major migration for me. I need to stop everything that is on the product roadmap so that I can get this done because it's a blocker for the business.

We probably could just fork that package and fix the, you know, fix this, fix, fix this security rather than. Throwing it away, right?

That, right? Because then you're an open source contributor while you're supposed to run a business that produces profit, but probably nobody will want your fork anyway.

Yeah. I get exactly what you're saying. And I could add to this one, which is a real scenario when we were selling a startup, when you go through due diligence process, they You know, they check all the licenses for all the open source packages you use. And if any of those open source packages somehow has a license, which doesn't allow you to sell it and then boom, there's a hole in your product. You have to now change or fill to be able to sell that business or you'll need to pay the package owners.

Exactly. That's a very good example. Yeah. If you don't know what the licensing is for every single part of your application, then you're not in a good spot because you're opening yourself to, you know, legal ramifications down the line.

Yep, exactly that. So let's imagine that, you know, we sort of in a good spot, we came in, you know, we had this firefighting, we fixed it. We're thinking strategically, you know, all the steps you did, we sort of there, you know, we've got as well executive, you know, love nowadays, like, hmm, you got everything. Things are going well. So we earned that trust from executive. How do you actually start building on tech strategy that leadership understands and supports? And what I mean by that, it's often if you're very like tech savvy, potentially your presentations are not landing. People are not really understanding why they need to now migrate to cloud or something like that. It's like, Do you have an approach where you sort of, you know, get that tech strategy really accepted?

Hmm. Great question. So if we're talking about presentations, I would say always build your presentation as if you're presenting to a customer.

To a customer. Okay.

Yeah. To an actual end customer, right? If, if the customer of your product doesn't understand what you're building, then why are you building it? And if you think, yeah, but I'm, I want to talk about the tech stack. Well, probably they don't care about the tech stack.

Yeah. They don't give a shit. Yeah.

Yeah. If, if, if you're telling a customer, yeah, we're going to put Kubernetes behind it. Great. Is it going to, I don't know, maybe it's like a credit card. Is it going to make my credit score go up? I don't know.

Yeah, exactly that. Yep.

So I think assume that you're presenting to a customer. And go from there because it's important that you distill the message to its true kind of value. If you think about the best kind of presentations out there, right? You think about Apple, what do you want? They're really good at presenting. Why? Because they really think about what clients need, what the pain point is, what people react to. And it's no different to when you're presenting to executives or when you're presenting to heads of, when you're presenting to anyone really, really think about what any person with any kind of access to information would be able to get value from what you are presenting. Don't assume people know, assume people don't know and get them through the journey. I think, you know, everyone likes to say, explain this as if I were 5. That's sort of what they mean. Assume that I don't know anything and explain this so that it's actually valuable to me and you have my attention.

Okay. So are we aiming to talk about return of investment and outcomes instead of like features in that, you know, while we're trying to get that roadmap accepted by, you by the board or executive, or is it actually what you said about the customer journey, or are we still sort of putting in some numbers and data and return of investment numbers and things like that?

Oh, 100%. Yeah. Data would of course validate and strengthen the points that you are trying to make, right? Having actual measurable data in there will only help you. In no way did I say do not put any features. Sorry, maybe I wasn't clear. Yes. Do put the features in, do put exactly what the product is, explain what the value is. Why is it that we're doing this? What the value to the end customer would be. I think that's very, very important. Don't just assume the developers will be happier if we do it or QA will be faster. It's too small in the grand scheme of things, if that makes sense. You need something much bigger. Much more tied to a customer, right? Or much more tied to revenue or much more tied to profit, right? That's really what you need to think about when you present.

Okay, so we wanna basically, what we're saying, we need to close that gap. So you're gonna go in, you know, here's a strategy, here's what we're gonna be building, the features. Here's a closing the gap and talking about what is the value to the customer. We're trying to sprinkle some return on investment and you know how that's getting realized to potentially revenue, market share, churns, and all of the business metrics they actually care about. And we basically saying, if you do like that, the executive buy-in—

Keep in mind that they also have their own goals. So think about what their goals are and then make sure that your message strengthens their goals. 'Cause if you're focusing only on your goals, then they won't be as interested. You won't have the buy-in. They are the business goals, the business goals get passed on to, probably from the boards to the execs, from the execs to directors and so on, right? So if executives, those executives would have had goals set by the board. So if you know what their goals are, then make sure that your presentation kind of goes towards their goals. Okay.

Do you have any example, Andrei, where, you know, you yourself needed to do this? And you know, it like, you know, any sort of, I don't know, like, you know, tips or checklists or whatever you did to make sure that whatever you were presenting, you know, landed well.

Yes, I think in my previous business, they needed a data strategy to cover them for every single use case that the business will need to grow in the future from basic analytics to, um, extracting data, loading, transforming data, um, to having, um, any kind of capability that they would need for machine learning, for AI, etc. Um, really understanding where the business needed to go, right? What were they trying to do? So in, in that case, it was an AI software development platform. So they wanted to give customers the ability to just type something in text or speak to a chatbot and then they would get back a list of features, a timeline, a price, and then a project manager get assigned to them, right? So that is what I just had in mind from the beginning. What would be the strategy that would cover every single kind of point that I know the business needs, let's say within 3 to 5 years. So I had a very simple slide in which I talked about, this is sort of a suite of services that we could use. This is another option. This is a third option. I always give three options. I don't, I don't just say, this is what we need. I just say, these are three things that we need. Here's And here's the comparison. Here are the features, price, what I would need to maintain, what I would leave behind me. So looking at it from very different angles. And then maybe on the last slide, I would say my recommendation is this, but again, it's open to discussion. Does that kind of answer the question? That's one example that I have. It does.

I'm interested. Why 3? Why not 2? Why not 5? It's like, Yeah.

Yep. 3 is just a number that everyone is comfortable with. Society just enjoys things coming in 3. So I think, yeah.

Magic 3, magic number 3. It is often 3. Yeah. I do get you. I, you know, I see that, but it's interesting why it's 3. Why is it not 4? I don't know.

I haven't found the answer, but It's, it's just, I think the number that comes most natural to us and that we can relate to the most. If it's 2, probably it's not enough. Probably you think like you're forcing me to choose. And when it's 3, it's a bit better, right? Because when it's 2, it's like, this or that. No, you're forcing me to choose. But when it's 3, you don't feel like you're forced to choose. You feel like, okay, so I have options.

And 4 is too much, right? You think you're making me to think.

Too many things, too many options.

Yeah. Okay. I get what you're saying. It's just, it's a sweet spot. It's a Goldilocks zone of choices, number 3, right? Okay. So let's imagine, let's talk a little bit about the first 90 days as a CTO. So I'm joining and, you know, I'm stepping into this messy environment. What's the first thing you do in the first week? Not overall, but in the first week, in your first like 7 days or like, you know, 2 weeks, maybe 14 days, like just walk through the door and it's quite messy. You know, what do you do in the first week?

Meet everyone, understand all of their pain points, understand all of their goals, see how people are tracking things right now. See what metrics have already been defined. If there are no metrics, how can we define metrics? That would be kind of really important because you need to know what your, what business you've walked into. You shouldn't assume that all you need to worry about is tech. You're there as part of a business, not just a silo. So meet everyone, understand what pain points are, understand how people want to work with technology, see if there's more that you can do, not just technology, because you can focus on digital as well. You can help integrations and integrations cover the whole company because different departments might want to integrate with what you've built or with other tools out there. And see how the relationship is. Do all of the departments work well together? Any friction? If yes, that should be the first thing that you focus on, removing all friction. I think those would be the main things that I would do in the first 7 days, other than the regular, you know, know what the tech stack is, you know, look at what tools are in place, etc., right? Okay. Everyone already does those, so I— it's kind of already understood.

I love that. I do similar thing, just reflecting back, you know, when you come in a new business, I do love as well one-to-ones and just understanding where everything is. And I love to ask, you know, to just tell me all the worst things, you know, there is to tell. I just wanna know all the elephants in the room. Just give it to me right now, just straight. So it is like a little bit of like information gathering in a sense, because otherwise how you gonna make decisions? Okay, so In your view, what makes a powerful signature win in your first 90 days that builds trust with executives? Like, do you have something, you know, in your mind where you sort of would chase by default?

Yeah, give me the project that you've not been able to deliver and I'll, you know, I'll try to deliver it within the first 90 days. I think that's the most important part. What was the biggest thing that you've not been able to go up until now? And then I'll just find a way to do it.

Okay.

Whatever it is. In the case of my current business, it was the inability to create a damage assessment computer vision model. My current company, right, covers all major catastrophes all around the globe. And one problem, right, that we needed to solve was looking at hundreds of thousands or millions of properties and assessing the damage on them. Right now it's done by hand because the business has intelligence analysts, but of course computer vision, computer vision models could do what humans would do, well, you know, in minutes as opposed to days or weeks depending. So I think within the first 6 months that was built. And it was working and tested. So I would say ask what's the biggest thing you've tried to do and have not been able to do and just get it done.

And you could get it done. I love that. Okay. So you gotta come in as like, yeah, okay. You couldn't achieve this without me, so I'm just gonna make it happen for you. You know, so now you know that I can make things happen. That's a great strategic—

Well, that's why you're there. Yeah. Right. You're there to fix the problems that couldn't have been fixed without you. If you can't fix those problems, then the problems are still there. So why are you there?

Just maintain stuff, status quo, just be there so they can float.

Yeah.

Right. Okay. So, okay. So we got that when we talked about getting the strategy in as well and, you know, presenting to executives, getting buy-in. So I have this question is like, when you get that and, you know, things are rolling, Do you care about keeping a pulse? Do you set some type of cadence that you're going to come in, present the results, and just make sure that they are part of your journey? Or is it more like, you know what, I'll do my thing and then if you need, I'll come and present, but you don't proactively push yourself onto the executive and the board?

I mean, it should be every day. It should be constant. It should be that you constantly chat and you give people updates as soon as it happens. I'm not a fan of just waiting for recurring meetings or putting recurring meetings in there. It's what was your most immediate need? All right. I'll get right on it. As soon as it's done, you get a message. It's done. Have a look. Right. So I, I, I, I don't genuinely think that you should wait for, I don't know, quarterly reviews or whatever. You have a list of things to do. You can, you can just give an update. It could just be a message on a chat, right? Like just DM the person update on this and it's done or update on this. It's going to take longer than I said. It's going to take 4 weeks instead of 2 weeks. Because of this, this, and this and that. Is that okay? Right. So I think it should be constant. The communication should never stop. There should never be gaps. It should just be like Facebook notifications, never ending.

I mean, I do tend to ignore all the notifications I get on social media. So I'm now thinking like—

Targeted to you, right? They're not targeted to you, right? They're just noise. But, you know, especially if it's a direct message, we can target it tailored to you.

I'm sure like if you are CEO, if you're on the board, I'm sure you would appreciate getting constant information pushed onto you rather than you needing to pull on that. Yeah, I did see different, you know, situations where, you know, people do, I want to say people, I mean CTOs get sucked into the past pace of what often startups are, where they prioritize the value adds and communication sometimes is not a direct value add, right? I mean, it's, I need to write this report, come and present this, you know, I could be spending maybe these 2 days doing something else and sort of gets forgotten to some extent. So that's why I really cared what's your view and your view is like, look, that's your weapon, right? Like that's very important that you do that proactively. So that should just be, part of your habits?

It should be because it's a risk not to.

And why?

Because a business, especially if it's a startup, needs to move very quickly and things change quickly. So if you don't communicate constantly, then you lose that kind of update, right? Because maybe the direction has changed and it could change, right? In a In an early-stage startup, it could change from one day to the other, but you're still kind of operating by last week's directive. So you're behind. So you're building something maybe that is no longer needed because you're not talking to anyone. So I would say communicate constantly because it's extremely important that you keep updated with what's happening around you.

Okay, that's excellent. Let's do a rapid question round. So it's, some of them might be a little bit open-ended, but let's see if we can be precisely or short answers with them. What's the fastest way to prove ROI on technical debt reduction?

I don't want people to think about technical debt that aren't outside of technology because it's not necessarily relevant for the business. I would rather again focus on speed of delivery. For me, technical debt is more about, um, if I make these changes, will I be able to deliver faster? Will it unlock some projects that in the past might have taken 6 months, but now because I've made these changes, they will take 1 month? So I'd rather think about it in, I'm going to deliver faster if you give me, let's say, 2 weeks. To do something, I promise that these changes that I've estimated for 3 months in the past, I'll do them in 1 month. So in a way, you'll be gaining time. It's an investment.

Okay.

That's how I would tackle that. I don't think you should ever go to a business and say, hey, can I have a month for technical debt? I think that's definitely the wrong approach. And most executives will probably shoot you down because they just see other business problems that are much more important.

So is it just then the positioning and narrative? I mean, we're still gonna do, we're still gonna go and fix technical debt, right? But which is saying different words of its value.

Okay. Let me answer it in a different way. You should always take care of technical debt. There shouldn't be a specific ticket or project in your roadmap that is technical debt. Make sure that you cover technical debt. Every ticket. Just do it as part of your normal work. Don't have it as a separate thing.

Okay. Yeah, I get exactly what you're saying. That's actually what we're doing as well with the team.

That's unfair to say, you know, but ideally that should be how it, how it, how, you know, how all technology departments operate. Technical debt should not be its own separate thing. You should do it. With every development that you do.

Amen. I do agree 100%. How can engineering OKRs be linked to business goals without heavy process? And I want to give you just a simple context. Anytime I do any type of OKR or OKRing within the engineering and business goals, trying to connect this, It's just never easy, man. It's just always, it's just so much science, you know, in all of that. So I very much hear how, understand how you think about that and how you actually get that done.

Going from the business OKRs, so the business has some goals, then again, think about it as a journey and it starts with the business goals that again, usually are set by the board or by investors. Then that gets translated at an executive level, then at director level, then head of level, let's say, then lead for management and lead and, you know, ICs and whatever. Really think about the goals that I set, will they go towards the business goal? And how do I frame them so they kind of translate into the business goal? One simple way, for example, in engineering, is to go from the product OKRs because product really will take business goals from, let's say, executives, translate them into a roadmap. I've mentioned this before, right? Then features, and then you deliver those features, right? So your OKRs could be deliver this within 6 months, right? Deliver this product within 6 months. That could be a very simple way in which you define your OKRs. So look at it, I guess what I'm saying in 2 different ways, either focus on one, the business goals and then translate your engineering goals into business goals or simpler potentially, cause it's closer to you. Look at what product says, and then kind of fit your objectives to objectives that achieve the product goals, if that makes sense.

Yeah, it does make sense, André. So effectively, it's a chain of OKRs that all pull the same direction. That's what we're looking for.

100%. Exactly. That's why it's a journey. We're all on the journey. It's just that we're focusing on different parts within that journey.

Do you have never-ending OKRs or do you do OKRs for like quarter, half a year, or it's like, you know, maybe OKR, which is always there, you know, don't drop in defect rates below that line and it's just always there.

So yeah, I would say there's like permanent OKRs. Your uptime should always be this. You should always be delivering, let's say, this many major projects over that period. And so on. So there's always like overarching OKRs that I'll have regardless of what the business OKRs are. And then I would just see whatever the business decides in terms of OKRs. But yeah, it really depends how the business runs, because if the business runs, let's say annual appraisals and they only check them once a year, then you probably only have like annual OKRs. If they have quarterly OKRs, then, you know, you check them every quarter and make sure that people are on top of them and so on. So it really depends on the business, really. You could have your own system, but you won't really have buy-in from your team because you're doing your own thing and they're going to say, why are we forced to do this thing when the business isn't? Right? So it's a balance that you have to strike.

Okay. After inheriting an outsourced stack, so let's say someone builds something in India, South Africa, or Ukraine, very popular now, should the first hire be product owner or an engineer and why?

I feel like there would need to be a few follow-up questions from the person.

I get you.

If I assume that what was built before is viable, is of a good quality and can be maintained, then the answer is both. Probably, right? Because you need to have that product vision, but you also need to have the engineer to maintain it and upgrade it. I don't necessarily just want engineers working without any product guidance, without any product specifications. It should be both. If you're going to force me to answer just one, then the engineer, because it's much more likely that that thing won't work and somebody needs to fix it.

Yeah.

So we need an engineer to keep it alive or maybe even build a new thing.

It's a, yeah, I mean, I fully agree. If it breaks, who's fixing it, right? It's still a tech product at the end of the day. So, you know, you likely to start with, you know, engineering, then maybe you yourself can drive product, you know.

My answer, you know, to be truthful, my answer would have been I would have never gone outbound anyway. So that would have never been a problem.

That's a mistake by itself. The question is wrong.

I love that. So in a way, what I would recommend is build a center of excellence in-house and don't necessarily build your core product outside so that you don't have to be in this situation, I would imagine.

Okay.

But I'll keep my initial answer, which is Get the engineer.

Get the engineer. Excellent. I want to ask about infrastructure upgrades. It's a very, very, very popular thing. I think it's like toning down now a little bit because we're all in the cloud, but it was a huge, huge thing probably like 5, maybe 10 years ago where everybody was just digital transformation and going from on-prem or some type of data centers to a cloud. And everybody just wanted to move cloud because again, enabled speed and cost and everything like that. From your perspective, what is the quickest proof point for executives around infrastructure upgrade? It's like, how do you sell that as a thing to your executives?

I wouldn't sell the infrastructure upgrade. I would sell the results. What would this achieve? Because at the end of the day, you really need to think about developer hours, right? That's your unit of cost. You have however many developers, the average salary for them is this much. You do a calculation, you know, how much is that per hour? How many developers do I need? And then you come up with a cost. So I'm gonna spend this much for what, right? What do they get out of it? What does the business get out of it? It really needs to be what, it really needs to be focused on the goals. So I would never just sell, I'm gonna just upgrade infrastructure, I'm just gonna move from on-premise to cloud because this is great. I'm gonna sell the results, you know, what is the advantage of cloud? What features will be unlocked once I move there, right? What capabilities will be possible? So I would focus on the opportunities from the upgrade versus the upgrade itself.

Yeah, so we're selling, we're looking at the outcome and the wins of all this exercise and we're effectively going like, you know, here's the wins which we'll get with all of this move. So we're talking their language. So ultimately it is like a return on investment to some extent, isn't it? Like we'll spend this time and that's what we're going to be unlocking.

Okay.

How can a CTO reclaim product ownership? And maybe it's even a question if they should, but the situation is that the CEO just keeps hijacking that.

Well, yeah, good question. I guess, should a CTO have product ownership?

Um, oh, let's, let, let me put it like this, Andrei. It's a CPTO, right?

CPTO.

Okay. So it's a CPTO, but the CEO is a founder and he's very opinionated, or she, and they just keeps hijacking the roadmap.

Okay. Um, I think the, the question is, um, how will the business move forward? What is the you know, what is the best thing that you can build to get your business forward? Because if you have a roadmap already, let's assume you have the roadmap already, and then maybe the recommendations from the CEO would make more sense, so then you would change the roadmap, then yeah, of course, a roadmap shouldn't be an inflexible thing. It should be just like This is what I think at this point in time that is okay to build. Shouldn't be like, this is it and nobody touch it for 5 years, right? That's wrong. Again, businesses need to be very flexible and a roadmap is not like a contract. A roadmap is more like, I'm trying to predict the future and this is the best I could do.

Yeah.

So I would say it really depends if the CEO has things that make more sense to be in the roadmap, then yes. If not, then understand why they're being asked for. What is the driver behind it? Was it actually that the CEO had a meeting with the board, had a discussion with investors or with with potential investors, with some prospects. Well, where is it coming from? Why do they think it's better? And if you put that in the roadmap, what would that impact, right? You need to understand that if you change that, then the repercussion is that the other 3 projects maybe that you had, uh, won't be able to be delivered in time. Sorry. So, um, You need to understand also the drawbacks because everything will have a drawback. But yeah, hopefully it's a discussion where the chief product officer, CTO, and, or in this case, as you, I guess, define it, the CTPO, has a discussion with the CEO and it's more like a partnership where both of them are trying to do the best he can to drive the business forward.

Hopefully. Hopefully it's not like clashing because someone is leaving and it's probably you because the CEO is the founder. So he or she, she, they're not leaving, but I get exactly what you're saying. Hopefully it is a collaboration, isn't it?

Yeah. Let's assume that even if you're forced to do those changes, would you then monitor them and then present the results at the end? Because any person at the end of the day will, you know, just understand that, okay, so the results are saying that it wasn't good. So maybe I'll think twice about, you know, pushing something next time. So I think measure everything. Yeah. Okay. You have to do it now. Fine. Get it over with. Monitor it, see what happens. And go from there.

I love that. What's the most common failed, failed signature win you've seen in your, you know, in your first 90 days when you come in, you're like, oh, I'm going to go after this. I mean, you mentioned the project, but something which is like failed and you've seen that multiple times.

So a major failure within the first 90 days, an example.

Yeah.

Probably some of the hires that I've made where I had, I guess, the wrong gut feeling and then they ended up not being the right candidates.

So how quickly you got them out?

Well, I don't know if necessarily how quickly is the right. It's more like how difficult was it to have those conversations, I think, right?

Okay.

Yeah, it will, I guess, whatever their probation period was is the answer.

There is a saying, right? No one, no one, no one, what's the saying? It basically goes about spend time hiring, but don't dwell on firing. There's a saying, I just can't remember now, but effectively it goes like, you know, definitely don't hire fast, you know, spend time making sure you hired the wrong person, but if you make a mistake, just don't dwell on it, you know, just cut it, because no one regrets basically exactly that, just waiting too long to fire someone.

Yes. Yeah, I think it's a difficult situation for both sides, right? If you really think about it, because that person maybe didn't think about failure, right? They didn't think that I'm not going to be good at it. And then it was more like circumstance where they thought something is not right. Something is not working. They keep telling me it's not working. I don't know why, how did I get myself in this situation, right? So it's a difficult situation for both sides.

Yeah. I do agree. How do you move from that? Let's say, sorry, not from your perspective, but if we are on a receiving end, let's say, you know, we are the CTO and, you know, we think we're doing everything that needs to be done and, you know, we're doing everything that works maybe in another company, but the executives, the board are just complaining, complaining, and you're like, I'm doing everything what I think should be done, and then you're like, how do you deal with that? Do you just leave and you go like, look, I don't understand what you want from me? Or do you try to do something like feedback sessions? I don't know. How do you actually handle that yourself on the receiving end?

Yeah, I think it's important to have the goals defined. Just be very clear with what needs to be achieved, right? And within what timeline, because once you have that, then there's something that you can use to understand what it is you're doing well or not doing well, right? If one of the goals is to deliver these 3 projects by the end of the year and you've only delivered one, then it's quite simple. You've, you know, you can figure it out. You've not delivered the other 2 projects that you were supposed to deliver by the end of the year, right? I think having very clear definitions of the goals that the business wants you to achieve is key. Um, because otherwise it's just very subjective.

Yeah.

It's just, I think you're not doing well. Okay, good.

What do I do with this? Like, how do I action this?

What is good? Yeah. Or what is not good? Um, so yeah, being very clear about what the goals are.

You start with that. Let's just define a good goal. So it's almost like a shadow PIP in a way, right? Because the PIP is about like very measurable goals. 'Cause they give you, you know, like if you ever been on the PIP or if you ever put someone on the PIP, right? Performance Improvement Plan, right? So you go like, this is what's gonna happen in the next like 12 weeks, like these are results. And so it's almost like that, but it's not actually a Performance Improvement Plan on paper, right? Yeah. You're not gonna lose your job if you not do it, but it becomes very similar in nature in the sense that, you know, defining goals and stuff. Okay.

I think, I mean, if a business has not defined goals very clearly, then something's wrong in the business, right? And if somebody leaves without even knowing what the goals were, then again, something is wrong with that business. So probably the person is better off going somewhere else, right? It's probably a gain for the person that leaves, even though at that time it's very traumatic because you're losing your job. but working somewhere where the goalpost is constantly moving because somebody doesn't define what the goalpost is, then it's not really an organization you want to work in.

It's not healthy in general. I mean, if you emotionally feel like, you know, you're doing your best and you think, you know, you're trying and you're not like slacking off or something like that, and, you know, people are not happy, something is just not sticking, right? And then, yeah. I think you probably can find a more fruitful environment for yourself. Okay. How do you lead as a CTO when the company culture resists change? So you come in, you know, you're hotshot, you fix everything. You're like, this is what's going to happen now. And let's say some senior developers or whatever, they go like, nah. Okay.

So the company culture you said is resistant to change. Yeah. Across the board or just in my team? Because you mentioned the developers.

Well, yeah, you CTO, so it's pretty much like across the board. Let's say it's a technology business, so we probably have sales marketing, which cares less, but you know, you still half of the business. Let's say it's a huge part of business, which is tech, which constructs more than half of culture, let's say like this.

Yeah. Okay. Well, again, what are the goals? What have been the goals in the past and how have you achieved them? Show me your revenue. Show me the growth over the years. Has it been growth? Has there not been growth? If there has, then you're doing something wrong. You know, show me, show me your EBITDA. Let's have a look there. Right. So I think. Pointing it down to essentials. How healthy is this business?

Yep.

Are you achieving the, you know, the usual goals that a business has? If you're not, then maybe something is wrong here and these are the things that probably should change. So if there's a broader kind of issue within the business, then that's how I would approach it. Focusing on revenue and ROI and, you know, anything else on that front. Within my department, well, first I will start with product because that's the main kind of entry point, right? I need to make sure that product has a very clear idea of what needs to be developed, has a roadmap, has timelines on there. Has all of the projects, has all of the features defined, take that, then give it to my team, translate everything that they need to in case it's not clear, uh, create that, uh, relationship with product. And then for a technology team, it's quite simple to be honest, because you put in all of their tickets, you assign a person to a ticket, you put a deadline on the ticket. That's it. Right. That's good.

If only it would be like that, André. It never is as simple as that, right? Like, ticket, deadlines, done. Like, it's always—

Then I guess, you know, if it can't be like that, then probably it would be a discussion that you mentioned before with the PIP. But I think at the end of the day, we all have work that we need to do. And I think for Yeah, for developers, it's generally I have the product tickets, the specifications, they get translated into technology tickets, and then I'm just going to work on my ticket.

Okay, I love that. You mentioned the EBITDA, which is a financial term, right? And I mean, our listeners likely know that because we talk a lot about, you know, buying and growing businesses. Do you believe, or your point of view is that CTO should be financially literate in the sense that they could read financial statements of a business?

Yes, 100%. I mean, if we could replace the C in, you know, with from chief with C from commercial, that would probably be better. Instead of chief technical officer, let's call it commercial technical officer. Okay. Because by that point, you should have been commercial, right? I mean, probably from head of, from director, you should be very clear on the commercials. Of your business.

So you're basically saying that CTO should know the business numbers?

100%. I mean, if you're an executive and you don't know the numbers in your company, then something is wrong. Yeah. What is your North Star? Right? How do you know how much you need to spend? Are you just going to be told how much you need to spend? Or, you know, it's very important that you know everything about the business from every angle. But I would go even further. You need to talk to clients. You need to understand their pain points. You need to understand sales. As an executive, you should really get involved in all aspects of the business.

I love that. It's a very great shout. I think a lot of young CTOs don't really think too much about this. They still look down into technology And what that episode, this episode is about is that you should think strategy first. What's one decision filter you have when everything feels urgent?

Going, God, I feel like this is the answer for every question. The goals. Yeah. Yeah, going back to the company goals, which one of these urgent things is most likely to help me with my company goals and then going further. Because the company goals generally should have been defined again by the board, by investors, and then executives get their goals and so on. So that's sort of how I would probably go about it. Okay.

So your decision lens is basically the OKRs of the business goals, which is the business value, right?

Exactly. So say it's, say right now the business is all in on sales. We need sales, sales, sales, right? If there's one thing that says, if I do this, then I win this client contract. Yeah, probably that, right? Yeah, that's probably the most urgent because that's extra revenue.

I'm talking with you, André, and I'm just going back in history with that startup, and I'm like, I made so, so many mistakes. I was not even thinking like that. I was like, you know, fuck your goals. I want to do like Cloud. It's like, that was terrible, right? Terrible. So I want to say, I know the answer to this question. What's the first win? Sorry, after your first win, after your signature win, right? So we basically executed the project. No one could do, we got that done, right? What's the next milestone you push for? Like, what's the next big thing?

Yes. I'm assuming, okay, so this is my first 3 months, probably at that point I've not had a good enough chance to influence the product roadmap. So probably my next one would be deep integration between product and technology, making sure that that roadmap is very clear, very value-driven. Everything has kind of a problem that we will solve from the client attached to it. And then having the validation of it. So am I tracking my user in my platform so that I know that they're using that feature, they're not using that feature? Am I getting feedback in? Am I having, you know, regular checkups with my clients? So probably that's the next one thing. Really working on the relationship with product.

Just getting, get that marriage happy and tight.

Yes. So that within, I don't know how long it will take, let's say within 6 months to 1 year, then I can move away from it and then focus more on the strategy because extremely important that things just have, you know, that autonomy to move forward. So product and technology can just move forward together. Releases just happen without you getting involved, right? That's extremely important. So making sure engineers work in perfect harmony with product managers.

I love that. It's never perfect harmony, but it's a good goal. It's a good goal to have, but you want to be as harmonious as you can, isn't it?

It's a dream. You know what they say, goals should be easy dreams should sound impossible.

There you go.

So let's call it a dream. Yeah.

Put your heads in the cloud, go after it, right? Okay. Well, you shared a lot of great insights, Andrei. So people listening, if they want to learn more, what is the best way to connect with you?

LinkedIn, I would say is the best way to connect with me. Medium as well. I use Medium if they want to read any articles that I've posted. And potentially conferences. I'll do my best to go to Big Data London every year. So yeah, I would say LinkedIn is the main one.

Is the main one. Okay, cool. For our listeners, just check the show notes and you'll see the links over there. And to everyone tuning in today, I appreciate your time. Drop your growth questions in the comments. We love to answer them or head to masteringtechgrowth.com to check out our community. And as always, guys, until the next time, stay safe and see you online.