The Dev is in the Details
This podcast is about the world of Software Development in particular and technology in general. Here, you will find thoughtful discussions about tech leadership, AI, the future of technology, and success stories told by the people who made them happen. Your host is Lukasz Lazewski, a seasoned software engineer, tech leader, and entrepreneur.
The Dev is in the Details
Becoming CTO: Transitioning from technical expert to strategic leader
► Is it possible to be a hands-on CTO while driving your company’s business strategy?
As companies scale, the CTO's role becomes more complex. In today’s episode, we’re joined by Dawid Adach, a seasoned CTO who has navigated the tough decision many face: Should a CTO stay hands-on with the tech or step back and focus on business strategy? Dawid will unpack the key moments when CTOs need to redefine their roles to support the company's growth.
► Our guest 🌟
Dawid Adach 👉 https://www.linkedin.com/in/dawid-adach/
CTO, tech leader, and startup advisor with a passion for scaling companies and solving technical challenges.
► In today’s episode:
- How the CTO role differs between startups and large organizations.
- When CTOs should shift focus from technical work to business strategy.
- The impact of AI on the CTO role and how it’s changing tech leadership.
- Signs it’s time to delegate coding and focus on growth and scalability.
- Common fears CTOs face when stepping away from the technical side.
- Strategies for balancing technical responsibilities with business leadership.
► Decoding the timeline:
00:00 – From engineer to executive: The CTO's path of transformation
25:54 – The CTO's view: Perspectives on leadership and decision-making
42:35 – CTO 2.0: How the role is evolving in AI age
55:33 – AI impact on leading, learning & programming
01:01:58 - Adapting CTO role to modern challenges
► Materials mentioned:
- What Got You Here Won't Get You There (Marshall Goldsmith)
- Scaling Up (Verne Harnish)
- Rework (Jason Fried, David Heinemeier Hansson)
- The hard thing about hard things (Ben Horowitz)
***
The Dev is in the Details is a podcast where we talk about technology, business and their impacts on the world around us.
Łukasz Łażewski 👉 https://www.linkedin.com/in/lukasz-lazewski/
Write to us 👉 podcast@llinformatics.com
When it comes to technical people, especially the ones who are super passionate about their job, they very often tend to focus too much on the quality, and not that I want to say that the quality isn't needed, but sometimes they focus so much that could refactor the same piece of code 10,000 times, while the project is stuck. Are you the person who can actually grow and scale a company as it grows and are you capable of changing? You are willing to do it or not? Now the CTO also are challenged with this decision. Can AI actually impact, and how it will impact, their role and, of course, the company they are working for?
Speaker 2:and, of course, the company they're working for. I'm excited to have David Adak with us today to talk about an important topic for many CTOs as their startup grows, how their role changes over time, and whether to stay focused on technical work or shift more towards business strategy. David is the co-founder of mdbootstrapcom and cognivisai and has been recognized by Forbes' 30 Under 30. He's an expert in AI integration and digital transformation, helping companies such as NASA, amazon and Airbus to improve their performance using cutting-edge software. David, welcome to the show.
Speaker 1:The pleasure is mine. Thanks for having me. Yeah, very, very crucial question. And thanks for having me because you know it's kind of funny.
Speaker 1:I feel like I made a whole circle when it comes to working for different companies. So I actually started with Accenture, which is probably the biggest IT corporate you know, 700 people, 700,000 people around the globe, so very huge company working for huge customers. And I, you know, when I thought about our discussion, I actually remind myself not only how the CTO role differ from company to company, but I happen to observe, you know, three differentTOs within the same company and I'm going to show it, probably later, how the approach can differ. Even when we talk about the same company, the same scale, the same size. It's just like two, four years later or before. But then I started talking about the circle because then I gave up and I gave up on corporates and I started my own startup and then, moving forward, transitioning to running a few companies now. So, yeah, that's definitely something different and a lot has changed and I think we're going to cover a lot of this today. So super happy to be here.
Speaker 2:Nice Thanks. So I would like to start maybe by mutually agreeing or defining the role of a CTO in startup. What's the difference between that, you know, in corporate, and a freshly created company by two guys who just got some founding, some idea and got their hands dirty with coding right away?
Speaker 1:Definitely. I think you know, I know you for some time already and I know we are on the same side when it comes to, you know, liking details. So I think we also should define what kind of startup are we talking about? Because, like you mentioned, that will be definitely a different role or different approach when we talk about two founders, like CTO CEO trying to build something and trying to get funding, because of course, then the CTO is probably the only technical person in the company, so definitely the deep knowledge and technical skills and so on and so on. But we can also talk about startups which are already in CD and so on and so on, when they have can also talk about startups which are already in crowds, cd and so on and so on, when they have already 200 people on board.
Speaker 1:But, of course, when we compare this to corporates, I think the very first difference which comes to my mind is that when we talk corporates, it's definitely more strategical. Right. We talk about, we think about many years ahead. You know we are not that lean anymore. We cannot change technology every day, unless we decide that might be also the option, unless we decide that every unit can design upon its own technical stack, which is an option, and I've seen companies like this, but of course there are risks to this decision as well, right? Because then you don't have it's way more difficult to have any sort of standards across the company.
Speaker 1:So I think that the first and the major difference would be that when you're a CTO to a larger company, you have to think strategically, you think long term, you think about stability more than today and tomorrow. Today and tomorrow. And the second one would be is that sometimes you also become sort of a face of your company. Right, I mean because when it comes to huge companies the city also you know they are attending conferences, they are having guests, they are, you know, they are important to companies, right I mean? Think about all the huge banks or telco companies. There are so many companies who are trying to approach them to sell them something.
Speaker 1:So actually you are getting more involved, also into political discussion and so on and so on, whereas when it comes to startups, yeah I mean, of course you're much more lean, you have much more decision. You can change approach every now and then you can change it almost as soon as you realize that the change is required, but you are definitely much more also involved into coding yourself, or at least being very much involved on what's going on and building this startup, and I know you have a lot of experience, is that right? I mean, even when it comes to the startups, which were very they were already companies, right, we can call them this way and yet they required a lot of your expertise. So, to stay involved, to make sure that the quality is there, that you are not producing maybe not any, but too much technological depth, and so on and so on. So, yeah, that's how I see it.
Speaker 2:Thanks for sharing. For me, you know, cto is a formal C-level position, especially in a corporate environment where there might be a board member or you know otherwise involved in a high-level leadership and, as you said, also externally and as a representative of the company for conferences and procurement. But in the startups especially like when I say startups I mean like something which just happened to start its life last night, you know, two guys hacking together, one business guy, one tech guy. I wonder what might be the main reason for over-inflating this title, because you could imagine we could call this person a tech leader or somehow, you know, main programmer or something like that. But instead there is like a culture of calling them CTOs right away. And I wonder why? Do you have an opinion about this? Sure?
Speaker 1:You know, I think this is exactly the same reason why people call them CEO. Right, you could just call yourself founder. You could just call yourself, you know, entrepreneur, trying to run. You know your, whatever it is. You're building e-commerce. You'll be. You're just writing your own blog. I think this is.
Speaker 1:This is this is caused by actually two sides of this equation. So one is startupers right, they want to feel important, they want to, they want to feel better, but, on the other hand, whenever you're pitching to the investors, you need to, you need to sell them. Story, right, and I just happened to talk to one of the M&A specialists recently about one of our products. This is a product, and basically the whole narration was that hey, if you want to pitch this product, we need to get you on board some known names from AI world, because we're going to pitch the story.
Speaker 1:We're not going to pitch the product. We're not going to pitch the product. We're not going to pitch the. You know your skills. We're going to pitch the story that this is the guy, this is David, this is Lukasz. You know, they are famous for this. It doesn't matter they don't have customers yet, it doesn't matter that they don't have a product ready. This is the story which investors want to buy. So I think this is the main reason why it is like that. And, of course, on the other hand, you have those ambitious startupers, wannabe startupers, who basically follow this trend and they are somehow forced to it, right, because we all know those LinkedIn titles, right?
Speaker 2:Right, but the story that you're describing with the startup you're having this is pre-seed money, right, this is like very early, okay. So, because I want to understand, you know at which point the team and the story are key. At the pre-seed, I guess, right, and afterwards it's more important what kind of traction and revenue they can bring in or, yeah, who the prospects are. Maybe the letters of intent or whatever else is there. At which stage you know, starting from zero from that storytelling, at which stage do you think that person in that role who holds this title needs to either be replaced or make up their mind on which way they want to go? Um, being more specific, you know, expert or, yeah, stay cto, but be like a hands-on tech leader, really, versus actually growing into the direction of being the business representative for technology?
Speaker 1:This is. This is very good question, and when I, when I, when I was preparing for this call and I've seen some of the question upfront, I actually have a lot of thoughts about it, because certainly there is a point where you have to scale, even not not as a CTO, but also as a C level right. I mean, when the company grows, when you scale, you have to scale, even not not as a CTO, but also as a C-level right. I mean, when the company grows, when you scale, you need to, you need to change your um, your, your role will change, I mean, whether you like it or not. So you need to adapt um and and, of course, that has to adjust. But, on the other hand, you know, um I thought about few stories um like um. My favorite one is actually from Amazon.
Speaker 1:You know, there was this story when Jeff Bezos wasn't already involved. I mean, he had the whole board. You know people who've been paid so much money and Amazon was actually doing great. And there is this story, which is which I read in one of his biography. Is that basically, on the meeting? It was in 2017 annual planning meeting, when basically everyone is in the room, the numbers are matching Amazon is growing. And then Bezos is coming to the room and he's basically asking this question how much money are we making from selling products, without counting the money from the ads? And it took like an hour to get the numbers and apparently, long story short, what happened is that they didn't realize that the overall growth was caused by more and more revenue for selling ads on the main page, on the homepage of Amazon website, whereas the revenue from the e-commerce itself it was declining, but overall it was. If you sum up those numbers, they were actually growing up. And he was the only one who actually realized it.
Speaker 1:So he was the one who asked this very difficult question, which even CFO didn't realize. So this actually made me doubt whether there is a point where you should totally separate yourself from, maybe not day-to-day to work, but especially when it comes to CTO. I think that being involved technically it also makes sure that you remain sharp, because technology changes every day and you have to adjust. So this is a very difficult question and, to be honest, I don't have a. You have to adjust. So this is very difficult question and, to be honest, I don't have a good answer to it. I feel like, of course you have to grow, you have to outsource, of course you have to get more people, of course you have to do less and less daily work. But I'm not pretty sure whether you should really totally disconnect or detach from being actually the person who you really are.
Speaker 1:At first you were, let's say, a programmer, coder or technical guy who came up with the idea. And there's another story I can share with the. I think it was Netflix. I made some notes here. So, yeah, in the case of Netflix, it was CTO Nailhound who actually came up with all the idea of CDN. So when they start, you know streaming and they wanted to outsource everything to the AWS, another cloud platform. He actually was the one who said hey guys, we cannot rely on the third party, we need to build our own content delivery network. He was the one who pushed the idea. So those examples actually show me that you can't really detach like fully detach. I don't know what's the percentage or percentile for that, but there's definitely some part of it where you should remain involved if you really want to be a responsible CTO, so to say.
Speaker 2:I really like these examples. You know both very successful, fast-paced, growing well startups and now corporates, really. But do you think it's if you compare it to something I don't want to say more old-fashioned, but maybe from a different technology background or from a maybe different vertical, entirely industry? Would you consider this to be industry specific, or maybe organization culture specific, that CTO stays so much involved, so much driven and is able to still propose so much value and solutions to the organization, despite the fact that its size is different? I'm asking this because, just to quickly give a context, there's more and more humane factor, soft skills required in managing people and growing tech teams and also negotiating with business stakeholders. That's not something which is very common in engineers, right? So for that reason, I wonder where that line is. Where does it blur?
Speaker 1:absolutely and I love what how did you call it? This is, this is organization, culture specific. I, I would definitely say this is the one. And the reason why is because, um, I happen to work for, you know, telco companies in poland and you know the polish market, maybe without even knowing the name. We have some brands which are international brands and they have just branch over here, and then we have some local brands which are just on here in Poland and what I've seen is that, even though the company are doing pretty much the same, the approach to using technology was so different.
Speaker 1:So the big brands you know the international companies, of course they would have pretty much standardized stack and everything was pretty much outsourced to other companies. So they had partners and you know, whenever this new company was launching or entering new market, the partners will follow. So the role of the CTO, where most of your work is pretty much outsourced to others, is more political. It's more soft skill, like you said. It doesn't. I don't want to say that the other option doesn't require that, but you don't have people on board, right? You, you, you, you are much more. I don't know lawyer, so to say, right, you need to really care about the contracts you are writing monitor, exactly monitor, all of that.
Speaker 1:And at the same time, the other company, our Polish company, with the pretty much I think they are the biggest one, they are known for building everything in house so doing I witnessed myself is that within a couple of years I've been with them there were two shifts of board and along the board there was new CTO. So the very first when I joined the company, the first board, first CTO, had, I would say, pretty average or standard approach to this. So we are a banking company and we understand how technology changed the world, so we have some internal teams, but we also outsource something which we don't know and we don't want to know. And then there was a new CTO who said hey, I'm old fashioned, I'm a banker, I know how to make money and I don't want to know how to make IT. So basically he wiped out all the IT teams, right. So he removed all the people, thousands of people around the continent. They were laid off, they were asked to leave and he outsourced almost everything from the consulting companies.
Speaker 1:And three years later, when the you know consulting companies and three years later, three years later when, when the board changed again, the new CTO basically came said hey, no, no, I come on it, it's, it's so important to us. I mean, this is our is nowhere vessels, we need to have it. And he had to rebuild everything from scratch. You know so, and this is the same company, and it was, of course. The company survived, didn't change a lot. Maybe you know a bit. That was worse, was better, but basically they survived. And you can see three different managerial ways or approach to the same subject. So I'm definitely on the side of organizational culture and this is what defines how you want play this role. I would say.
Speaker 2:And in the first startup, an organization, when you have a partnership with one more colleague or friend, or and you partner to build this new venture, do you think how much of that decision on venture, do you think how much of that decision on the role of CTO now versus half a year, versus five years is only on him or her? How much is it also on other stakeholders? Do you see it as something which is an independent development of an individual that they can decide what the role is? Or in some cases, maybe investor, maybe you know ceo, an old colleague might ask for a change that is not in a direction that individual would imagine? How you know, what is the, what's your experience in that regard and also what would you be, what would be your recommendation and how these kind of scenarios could be handled?
Speaker 1:I would look at this from a slightly different perspective. You know this book we both refer to very often what got you there won't get you further, right, marshall Goldsmith? This is this nice book what got you here won't get you there, right? So I think this is pretty much a very personal question, right? Whether you, first of all, are you the person who can actually grow and scale a company as it grows and are you capable of changing? You are willing to do it or not? If not, then most of the time, you know time, you know the c levels who stick to this role. They're mostly blocking company from from growing and but the, the question was different. Your question was when, uh, and where?
Speaker 1:I think, for me, my experience is that this pretty much aligns with the, the value of death, uh, which we basically, you know, define as this, like, let's say, 10, 30, 60, which we basically define as this, let's say, 10, 30, 60, 90, 250, 500 plus. So, in my opinion, this aligns with it pretty much, because this, like you said, being CTO, also means, at the same time, you are C-level and this brings a brand new challenges to your role, both as a technical person, because starting from something as silly as tech stack, whether everyone is allowed to have its own laptops and software or we have to standardize them. And, by the way, the last issue with the not Microsoft, not Microsoft update around the globe showed how standardization can go wrong. So, starting with something as simple as this, to trainings for your staff, right, how do you go around it? Do you force them? Do they have to upskill?
Speaker 1:Uh, every now and then? Uh, what about the kpis? And so on. So, of course, those, those challenges are coming, uh, and from my personal experience, they pretty much align with the value of death. Uh, which are for?
Speaker 2:uh pretty much for every department the same and it also redefines with each Valley of Death, right From Varnish's book. I would imagine you expect that person to reinvent themselves, right? Because it's one thing to build a company up to ten mil and it's another thing to then build the team of leaders who manage teams when you want to go above 100 mil. And how likely is it that the same person in you know value of dev one and value of dev four I believe this was four are the same person? Or what kind of work and transformation has to happen? Right? Because and consider it from this perspective, this is, I guess, the basis of my question If someone is capable of doing four value of dev, what stopped them from working for Google to start with versus, you know, like growing into that role to the for value of death through all of that? Absolutely.
Speaker 1:And I really like this example, which also sort of reminds me that you know, it's always so easy to judge backwards. You know, sometimes ago I read this quote it was actually, I think, this financial book when the author was giving the example that the same people who judge, or who are super excited about Facebook and his founder for not selling Facebook when he got the offer for $1 billion and they say that was the best decision ever, they are complaining about Yahoo, who rejected pretty much the same offer a few years before. And for me this is the same story. They both had the same chances to really win the market and one actually did it, whereas the other we all know where the Yahoo is today. So it's so easy to judge backwards. So to me, it's again about the person and whether this person is willing to grow.
Speaker 1:I love what you say you have to redefine yourself. This is it's it's it's it's so different from one you know one value to another value and the question is are you capable? Um, you know building the, the huge scale, going international, new challenges. You know building branches and offices outside, selling to different markets. Again, you have to reinvent yourself and you have to find a new way of dealing with that, not to mention all the legal stuff like GDPR and so on and so on. So, yeah, I mean, if someone is capable for going through three, four of them, I could judge he's capable of doing also fifth and going further, defining new standards for that. But on the other hand, examples like Yahoo also shows us that they pretty much had everything to actually become another Google, but something went wrong. And now, of course, it's easy for us today, a few years later, looking backwards and judging what went wrong. And now, of course, it's easy for us today, a few years later, looking backwards and judging what went wrong.
Speaker 2:But when you are there making this decision right and having enough courage to say, hey, I'm not the one for this position, you really have to be self-reflective, I guess From a personal story when I used to be really, really deep into the code, I couldn't imagine that anything in business would interest me Today. I think exactly 180 degrees in the opposite side. I think that the challenges of the business and scalability and people management are far more challenging and random in a lot of different ways. So I find it fascinating and that's also what's driving me forward. What would that be for you and how did the transition happen for you? So I find it fascinating and that's also what's driving me forward. What would that be for you and how did the transition happen for you? I know you're still very much hands-on, right, I have given up coding about three years ago. I'm having a sporadic watching video here and there and enjoying some conversations, but completely on sidelines and without comprehending 50% of it already.
Speaker 1:What are your thoughts on this and what is your experience? So definitely, I'm still very much hands-on, but what I believe in and what I'm actually doing is that I also don't code myself anymore, right, but by being hands-on I mean that every time we are approaching new challenges and I'm not talking about just writing another piece of code or another module within the application I'm talking about coming up with some new idea or pretty much trying to come up with a brand new product, and we need to sort out technology for that. I'm still pretty much hands-on, so I'm trying to, you know, be above the edge. I'm not coding, but still I'm capable of doing this stuff if needed. And again, I wouldn't use my code in production, but still very much often my role is to basically find the solution. You know this is what you just described.
Speaker 1:When you switch to this more C-level role, you have different perspectives. You see the overall business, you see overarching input for what you have to take into consideration, because usually the tech people in your program or scudders analysts, they see only just the piece of the information. They don't understand. Why is it like that? And you know the story behind and, what's sometimes even more important, you know what are the plans forward? Right, you know what the company is about to be. It's what about to happen, what's the transition is going to be?
Speaker 1:So, to me, this is and again I'm going to say something which is exactly opposite to what I wanted to share in the next paragraph but basically there is no silver bullet, right? But I wanted to say that my silver bullet is basically to be involved as much as it's required to make sure that there are no stoppers. And, of course, if you're people, you have a good team which can do it without you. That's perfect. But sometimes, especially when you're coming to the new projects or new ideas, it might be you. Or maybe your role as a CTO would be to find someone to solve that problem for you, right? Maybe you can outsource, maybe you can get someone else, maybe you can get some consultants from other companies. That's also the option and, at the same time, as little as possible, because you don't want to uh, you know, stick to this because you're going to lose uh, you're going to lose your time on something which can be pretty much outsourced.
Speaker 1:And I mentioned the Silver Bullet because there is also this person which I like very much, and this is the author of Rework. This is David Heinemann, hanson, rework, rework, right. This is the uh, david hyman, handsome, right? So he's the founder on the of the of the base camp, if I recall correctly. Right, so he's like both ceo, cto, he's very technical and and he's uh, he's he's writing his blog and I think last year he had a set of articles on basically why we quit cloud, which is super shocking to some extent.
Speaker 1:While the entire world is going cloud and everyone tells you that you have to go cloud and actually you are getting extra point while pitching to investors that you are scalable, you are using AWS, so you have almost no cost of running infrastructure. He did proper calculation, he showed that for them it didn't make sense and even though it cost them a year to roll back all the transition, he decided they're using actually their own service and I think this is to me, this is the pure, you know, CTO sense, which is very important Skill. You have to see the big picture. You have to understand. You can't just blindly follow everyone and say like, okay, the cloud, we are doing cloud. No, you need to understand where the cloud is making sense. When it's not, what are the drawbacks? And you need to understand where the cloud is making sense. When it's not, what are the drawbacks? Because this is not only positive, right, I mean, there are good reasons to use cloud, but you need to understand that.
Speaker 2:No, absolutely, and I think it's also important to look at it from a stage of the company. Right, and David is amazing, right, I mean, he's a creator of Ruby on Rails framework and massive impact on, you know, I used to code in this, so massive impact on my personal life, on my career. At the same time, I believe there are still like just 20, 30 people at Basecamp, so they consciously chose to be there, was a conscious choice to stay that size. And at the same time, you know, he's doing full spectrum of all activities. To my understanding, right From one day he can speak to clients, from another one to designers on their side. So that's really fascinating how they're able to balance this with his co-founder.
Speaker 2:And regarding cloud, I mean at the stage that they are, which is, it's a private company, so no one really knows, but I guess it's like two digit millions a year or something, maybe even three digit millions a year in revenue. I guess at that stage maybe they just made a calculation and I believe that was kind of mentioned in that blog post that it's like 10x more expensive to run an AWS at this point and given, you know it's not apples to apples, because no one really knows what their infrastructure looked like and how efficient or inefficient was it. But it's fascinating to actually see that even in such a standardized environment like the industry agrees that cloud is the way someone goes against the wind and actually wins. It's fantastic. But you know what is?
Speaker 2:Yeah, what is fascinating about David and also Mark Zuckerberg, which came up here before, is that there are both technical founders who are CEOs, right, and or David is CTO, but I mean, he's co-CEO of the Basecamp, I believe, or it's a mixed world. You have a similar setup right with your co-founder. You're both kind of equal in the decision-making for the business. But I wonder, if I'm not mistaken, right, Sorry, if you could confirm that. I wonder if this has something to do with it. You know, Ultimately, what coders are is problem-solving on various levels, and then they're scaling up to be solving bigger and different problems, like you said yourself, to coach and mentor your team on a bigger picture, but also to bring external help when you need it. So I'm just thinking very hard now about the example of company where that didn't happen because the founder was someone else, their background was different. Not to praise that. This is the only right background, to do it that way because it comes at the cost right, Workaholism and whatnot.
Speaker 1:We are definitely in the bubble. What are the?
Speaker 2:traits.
Speaker 1:For sure there are other companies, but actually the first one which came to my mind there was Jobs, who had his Wozniak to do the technical stuff right. You have still you have the Microsoft founder, who still, you know, grew to the level from the, you know, just simple maybe not the simple, I shouldn't say it this way but from very technical guy, programmer himself, gates, become the CEO of the richest company in the world at a certain point of time. I think in the Oracle we have the same story, right, but those are the first which are coming to my mind. Of course, we are in the bubble, right, we praise them, we look at them because we are technical ourselves. The bubble, right, we, we, we praise them, we look at them because we are technical ourselves. Um, but yeah, I mean, this is, this is, uh, that's very interesting, you know.
Speaker 1:There is another example, of course, which I'm not a huge fan, um, but you know the person behind tesla and x and um, you know Tesla and X and you know I'm having mixed thoughts on Musk, but what I hear from here at least, I don't know I couldn't verify that he's also very much involved, you know, technically, into all the discussion. That's what he says right, and I could actually believe in that, which is just yet another example which shows that you can still combine it. I don't know how much is it required. Maybe he could. Maybe he's doing this for fun, maybe he just likes it or not, or maybe his decision or his input is so crucial that's a great question to ask him someday how about yourself.
Speaker 1:You've been doing a lot of you know you were actually even auditing others' companies, as far as I can remember. You know doing the due diligence, you know how much, what's your experience, you know how do you think, how many times you spot something which probably no one from your team could, could actually yeah, this happens a lot, but it's not like um, it's a technical detail, but more of a exercise in reframing, you know.
Speaker 2:so, starting with things like are we solving the right problem or are we asking the right questions? Because sometimes we're really insisting on a solution and then, when we zoom out or someone with a fresh perspective comes in who is also a problem solver, they ask well, hold on if that's your like, if you, you know the rubber duck debugging idea, right and just for our listeners, the idea that you hold a rubber duck in your hand, sorry, and you start talking to it out loud and you start hearing yourself and suddenly and you walk the rubber duck through your problem in code, and suddenly this pops up in your head what the problem is, because you're just hearing yourself.
Speaker 1:I think that's what I do most of the time and the question is so what's the skill you possibly have which helps you to phrase it? Because, again, I could bet that most of the people within the team couldn't do it, couldn't spot this, couldn't see this this way. Uh, the way david hanson, you know, realized that maybe for them cloud is not the option, so it's a bad option.
Speaker 2:But sure not for them. I wouldn't be. I wouldn't be the guy to also challenge a notion of the cloud. To be honest with you, I think the question should be what is everyone what, what is everyone biased about in the team and who is the person to break through the bubble right?
Speaker 1:so that's a good one. But you know now when, when you talk about it, there was a there's, there's, I had a spark, you know. And when you said that all these uh ceos, the cto's, uh founders, technical founders who manage to build a company, they are also problem solvers. Maybe that sounds silly and it's too simple, but you know, as a founder, and you know it yourself, you have to deal with so many different issues, problems starting with. You know tax, regulation, hr. You know first recruitment, first layoffs, and so on and so on.
Speaker 1:So you really think out of the box. So even you know, and then when there is a technical issue, there is a technical challenge. Maybe this is the difference, maybe this is what makes you looking differently. Not technically right, because maybe, developer, as you said, probably you have better specialists in Ruby and other programming languages than yourselves, but maybe this is what they are missing. If they were thought to be programmers, they only think like programmers, whereas you, you have different history. You've been dealing with so many issues that probably maybe less than 50% were technical and more of them were actually non-technical issues.
Speaker 2:It's an interesting point. But I'm also thinking on the reverse. When I'm really bad at something, I go for an expert. I am really not great with labor law, right, so I have HR and they're highly trained individuals with passion for this and a deeper understanding of what needs to be done and how the contract should be structured and who to hire, who not to hire, what the review process should look like. That doesn't interest me at all, you know, and hence, because it doesn't interest me, I'm really bad at this because I'm naturally driven to something that interests me.
Speaker 2:So I wonder if, in the cases of helping the clients on the work that we do here or within the team, when we get stuck or someone gets stuck, even when I myself get stuck, it's just fascinating to have a discussion, and I'm passionate even about describing the problem to a bystander, to seek their opinion or shift in perspective so we can actually move forward, and it excites me even when I'm stuck. Well, there are other topics when it isn't like this and it doesn't have to be technical Structure of the company, structure of the team, reporting structures, all of these things, and tooling that we use on a daily basis, all of these things related to the day-to-day activities of the business, which are not even technical, are somehow fascinating, right. Well, where I don't know, legal and other aspects are not so much.
Speaker 1:Absolutely, and you said a very important thing which resonated with me a lot. You said to move things forward, which is also yet another skill, I believe, because I'm sure you also have this experience. Yeah, I like this because we are getting to the outcome, which is a combination of moving things forward, solving problems, but still having in mind a bigger picture.
Speaker 2:This is not only my piece of code, not only my line of code to to be folks, but also to make make sure it matches yeah, some other blocks yeah, and it's that leader's choice and responsibility to find that balance with between equality, because you still don't want to sacrifice it entirely, but also perfection, because perfection doesn't exist and you just don't want to dwell too long on something that's fascinating. And based on the balance, you also attract different talent into your company absolutely.
Speaker 1:And then now, which also came to my mind, as you were saying, is that you know, as a, as a programmer, as a, as a, as a technical lead, you basically pretty much focus on what's ahead, right, you think about new projects, you want to build something new, something fascinating, whereas as a CTO, you have to think about the legacy, you have to think about the technical depth, right, maybe sometimes it makes sense to sacrifice the quality because you know you're doing POC and you don't even know whether you're going to get the funding for that, but, on the other hand, if you're going to spend too much on that, I actually experienced this myself. I've been working for one of the banks which I mentioned before. What happened is that we were super excited because there was a new project coming in, and then imagine our disappointment when we got the update that the Windows was actually rolling out the support they're not going to they say they're not going to continue the couple of millions of the brand new sexy project which we're about to deliver. But on upgrading, on replacing all this, you know atm, you know operating system, right, and of course, this is something which which which you I mean only cto has to deal when it comes to it, but keeping this balance, you know, like balance.
Speaker 1:Would you outsource this to the, let's say, asian market, which is cheaper but the quality might be slightly lower? Or do you do it in states when the prices are so high? But technically I'm not sure about the quality, but at least the promise is that it's going to be better, or at least, maybe even not the quality, but you can pitch to your investors that, hey, we are using this company as a provider for our platform, which of course, gives you some extra plus points because you are working. This is the reason why people are using Accenture. By the way, right, there are certain amount of customers for which Accenture is too expensive, but they're actually paying for that to show that they are big enough to afford Accenture or other consulting companies. Yeah, it's an entirely different topic.
Speaker 2:I call it game of prestige, but I hear you. I think it just really depends what the core business of the organization is right and whether they want to have some IP inside or what they want. You know, like the banking example you just given a few minutes ago. You know, under one CEO it was clear that their banking company and they should focus on the core business of the banking and outsource everything else. And the other CEO just thought look, we're not going to be competitive in the modern market if we will not build our own fintech solutions and potentially challenge the status quo and beyond normal. You know average current accounts and credit cards. So they did that. So I think it's an overall strategy of the company and based on that, you have people that follow it and very you know. You know the bank. It was probably.
Speaker 2:It's an interesting case because they're publicly trade, privately held, I don't know, but there is probably some shareholders which influence the direction and and it's a bank, so there's not that much you can do, probably. I don't know. I don't want to speak too much to it. I know there's still new interesting startups in fintech. Well, if you have a company which is like.
Speaker 2:Take Facebook, for example, with such an impact that they have, they constantly have to reinvent themselves, right? Because now they accumulated so many users, they had to acquire Instagram and WhatsApp or WhatsApp first actually to create that connecting element for communities for local communities, international communities and I don't think bank has to go for the same lifecycle, like BCG has this graph where they say 18 months is what it takes from product or service to be launched and before it starts being copied by competitors, right, when other people, other players, move in, and I think it's a completely different game in banking. There's a lot of different factors to influence this, including B2B factors or governmental decisions versus social media, social networks and individuals, or even B2B versus B2C. To be honest, it's just that level.
Speaker 1:So, for sure, banks talking about the banking area I think they could do it without tech. But currently, if you look at what's going on right now, if you look at all the fintech startups, I don't think they can do it. They can't continue like this. So we moved from nice-to-have technology to must-have technology right, and for them this is absolutely not actually being competitive. It's being above the water.
Speaker 2:I would say Okay.
Speaker 1:Because otherwise and of course this is an absolutely different discussion, because now, think about it you have Apple Pay, you have Google Pay, so banks have been really pushed away to the very last layer, like like almost.
Speaker 1:You know infrastructure infrastructure right and they don't know anything about their customers because, because their customers are not paying with with their cards, they're paying with master cards or they're paying with apple pay, they have no information and so on. So different discussion, but, um, what I'm essentially trying to say is that, given the AI and the impact on pretty much everything, I think the cycle which BCG showed a few years ago, I think it might be much shorter. This is actually an interesting point now because we didn't touch upon AI, but let's pose this question how AI will influence actually the job of CTO, because it's also very interesting. There's someone's discussion. This is like the Dropbox they laid off 7% of people, including programmers, because of AI. Oracle, just a few months ago, they laid off 8,000 people in the European Union because of AI. So now the CTO also is challenged with this decision. Can AI actually impact and how it will impact, their role and, of course, the company they're working for? Are you?
Speaker 2:betting on that or not? Yeah, yeah, at first I was going to make a joke that you just gave me a business idea, but you know, I think there is too many things happening in different dimensions at once to challenge this role outright. You know, it's like even with the coders in different dimensions at once to challenge this role outright. You know, it's like even with the coders, I have this doubt that AI will replace them. I mean, it's a supplemental feature. Well, it's a supplemental thing versus something that does provide a solution A to Z instead of them. Right, so it may.
Speaker 2:It definitely makes people more efficient, but these people also need to know what they're doing. The best example is ChatGPT. I mean, everyone has access to it right For free or for a very small fee. But comparing to some people what they can do with it versus some people just asking for very simple things, it's a completely different game and I think it's going to be similar in here.
Speaker 2:Nothing can replace that experience, because you need to know, you need to probe and see what. You can ask who to wear or who in the organization or, you know, it's an entirely different question, even if CTO should or would have an interest in influencing architectural decisions, for instance, right, not beyond vendors, but even things like, oh, whether that should be a queuing system or Lambda functions on Amazon or something else. I don't know if those are two good comparisons, but you know what I mean. So, ultimately, I don't think AI would challenge it at that level. It can support, for sure, because you could ask for alternatives or to argument for or against some idea, but at the end of the day, one of the key components is CTO bears accountability and AI cannot be held accountable just yet.
Speaker 1:So I think, till we get there, Absolutely true, but let me challenge this a little bit, because I think this is what this sort of conclusion also shows what CTO has to deal right with on a daily basis. So, you know, cto from two years or five years ago didn't have to deal with the issues or questions like this right, whether to replace or not. But coming back to challenging this, let me put it this way I don't know whether you agree with me or not, but I would say that for the last 10 years, we've been living in times where we were like, essentially everyone was short of programmers. Right, because, I mean, that's my experience. Do you agree? Yes, I agree, that's my experience, do you agree?
Speaker 1:Yes, this situation basically caused that we had pretty much people who, just because they know how to write simple loop for and if and I'm exaggerating, of course, but they've been paid a couple of thousand bucks. Yes, I believe this is pretty much the situation we are in now. Now you have this AI coming in and you as a CTO, have to pretty much decide or bet on whether this. You know and I'm not saying that AI will replace programmers, I think it will not, I think it will change, but what I'm quite sure, because I see it already happening that AI is already replacing this. I don't know how to call them, how we distinguish between programmer like the coder with experience, deep knowledge and understanding, versus someone who was just like another coder, typing from human understandable language to just JavaScript or whatever. Because this is happening. We don't need juniors to write this simple function.
Speaker 2:Well, yes and no.
Speaker 1:And if you already have them. Let's say you're a CTO and you have 500 people. It's like this so most of them let's say 100, are senior 200 meets, but you have 200 juniors. So what do you do with?
Speaker 2:them.
Speaker 1:Not necessarily junior, because I don't, I wouldn't necessarily bind it to, because this, this is also attitude. Right, you can have senior people who are just writing the code.
Speaker 2:Yes, and I mean, you know you can pre-generate code or we can have this shifted into the direction of low code solution or no code solution, right? I think it depends on what the problem is. Uh, that we need, that needs sorting, um, and in some cases even no code solutions will be more efficient than the best programmer in the world with AI. So that's my number one. Number two is I think that I've seen a lot of coders use AI with a promise that it makes them 10x or 100x more efficient, and this happens, but over time, the code that they produce that they have written is less and less readable, less and less in context of what needs to be done, and hence it's less and less manageable and maintainable. I just recently had a couple of cases where I was asked for kind of emergency help with our team because people got stuck so deeply with pre-generated code by AI that they couldn't move left or right whatsoever and they had bug where they were leaking money for months and no one could fix it for months. Hundreds of people, literally hundreds of people from let's call them Asian competitor with AI, they couldn't fix the issue, burning on it, probably hundreds of thousands every month and they couldn't fix it. So the question is, what are?
Speaker 2:Experience and a unique ability to look from a different perspective will still be an advantage, at least as long as AI is in its current stage. Because once you start adding some sort of solution where ideas are bounced off multiple models, or they're bounced off even, you know, maybe there could be online people and experts that ai could, you know, hire for the company automatically and they would just come in and they will help ai to redefine the problem, whatever it had, its had, its shortcomings, and eventually, probably ai will even reach you know, reach the level of I don't know subconscious consciousness, whatever that it would be able to dwell its own, on its own experiences and build on those own experiences. But till this happens, I think, I think it's like with every work or every role not necessarily CTO, but from any role those are very powerful users. And, yes, there are jobs like maybe in I don't know where, but that could be immediately they're more prone to replacement by AI. But also, like in the market.
Speaker 2:You see, there's a lot of people in marketing right, for instance. They have a choice, they can freak out and they basically make themselves redundant because AI will replace them. Or they can learn it and choice they can freak out and they basically make themselves redundant because AI will replace them, or they can learn it and use it to be more efficient and then be, you know, even better at their job and make better earnings for themselves and you know, better name and reputation and everything that comes with it.
Speaker 1:But still, I believe that you know the overall headcount might shrink, you know. So if you had 10,000 people in marketing, you know now you will have 2,000 people utilizing AI. That's my bet on that. But secondly, there was another thing which you mentioned and I would like to dwell into it for a little bit, because you said you gave the example of this let's call it Asian company overusing AI, right? So now imagine, let's put ourselves into the shoes of the CTO of this company. So this is what is actually happening, right? So you have the programmers trying to use, utilizing different models. You know Copilot and GPT, so this is yet another challenge for you as a CTO to approach.
Speaker 1:So how are you ensuring that people actually won't end up with what you just described as like over-engineered code? Because this, at least, I don't know about you, but I see it also in my company as well right, I see that people are trying, and this is super cool that they are trying and they are seeking for the answers. But this can lead you to this like you know, I would go to loop of death when AI is just fixing another, fixing another, another, another problem for you until, unless you are lucky and it's there is no further issues, or you're unlucky and even ai cannot fix his own. So what do you do as a cto? How do you approach it right? Do you train? Do you come with policy like overarching policy for the company, or how do you? How would you approach?
Speaker 2:this? I think this question is answered to your previous statement about juniors and regulars and seniors and only promoting maybe cheaper regulars or cheaper juniors, to my understanding, because they could use AI. I don't think this is the right approach and I don't even think that optimizations that happen now in the market. I think it's just in my personal opinion, for the record right, full disclosure. I think market is in a downturn and I think a lot of companies are using an excuse to get rid of people and AI is just one of those excuses.
Speaker 2:Second favorite excuse that I see a lot is and hear a lot is okay. They didn't want to get back to the office because we were never remote. Covid is over now. They didn't want to get back to the office so we fired them, because that's much better VR wise than saying that we have to do redundancy of 20% of our staff simply because as a management, we messed up, you know. So it's very nice and very cool scapegoat for every C-level person decision maker on layoffs to just use this as a storytelling. So that's just my observation that it's not necessarily AI.
Speaker 1:I absolutely agree, but I still believe the challenge stands. The challenge stands I agree, the challenge stands.
Speaker 2:So from that perspective, consider this. A few years ago and actually now, there was an amazing article. I need to dig it out. Because of where we live, right, and because of the geopolitical circumstances that we're in, you can't trust GPS anymore. Right, because there is some sort of the signal is being influenced and it's distorted. So there was a lot of cases where flights to Egypt were distorted and they ended up in over Jordan because 200 miles away or whatnot, because the GPS was lying to them.
Speaker 2:So suddenly a skill like cartography and reading maps is useful again. Right and this happened a lot in the human history that we gave up on something because suddenly you have a smartphone in your pocket with Google Maps so you don't need to know where the North is right and to navigate. And I'm not saying that we should suddenly start learning how to use Compass again, but encoding, gradually, building up your expertise in your career from junior to senior and it takes a couple or handful of years is still a valid pattern in my opinion. So there is no magic shortcuts as in two-year-old junior or year-old junior with an AI will not beat a genuine, really experienced 10-year-old, without 10 years of experience guy who is dedicated right, who is still caring and working and growing as an individual, not someone who got complacent and just you know 9 to 5 and doesn't really care, without an AI.
Speaker 2:Still, I still think that person without an AI will win because even your vocabulary and the possibility of what you tell it to design your system is much richer as a senior, and that is a huge advantage, even if they would both be using ChatGPT or whatever else. That's critical, I think.
Speaker 1:No, that's absolutely right and I totally agree with that. I think that what's still a huge question mark to me is that the path of your development starting from zero, so like day one, or when you start learning how to code to become senior this is what's going to get affected and, of course, it applies not only to the coders itself. We can talk about it in regards to education at all, like, think about the kids, how they're going to learn. Does it even make sense to learn some things for them? Uh, because if you for the first two years let's, let's oversimplify that if the for the first year or two, you as a developer or junior developer were actually you were learning how to write good code, right? So you would, you know, you would write some code, get some code review from the senior friend and then learn why this is a bad way of writing the code, and so on and so on.
Speaker 1:Now, when you ask ChatGPT, it will basically give you the perfect code. Let me oversimplify that it will basically give you the code which is considered to be a proper code. So I'm actually interested in how the learning curve will change, because now, if you don't actually have to care about how to write the good code because it's taken care of. I think you should still understand what's behind it and why this code is right and what's the bad code example. But this is why most of the companies used juniors.
Speaker 1:If you had a project for 500 people, you need 200 or 300 just to write this basic code and someone had to write it. So to me, this is very interesting. I still agree that actually, I think that this experience and thinking will be more crucial than it used to be right now, because you have to start using this way earlier than the old generation programmers. Because it's not about how to write the proper loop function, because you basically ChugGPT will give you the loop function. You're already starting a few levels above. Why do you actually need loop function and what's the business use case for this and how you can go further?
Speaker 2:I think those are great questions, but for starters, really quick, let's distinguish between AI in education and AI in support or coding of coders. Support of coders in the coding environment, because in education, I think this is a breakthrough and it's going to produce people with skills. Sorry for the term, produce people with skills, but you know, like, train people and allow them to train in any concept, in any area, in any specialty medicine, you know, military, whatever much faster Because, for instance, it can seek for the best methods for the individual to gain that knowledge or even assess their interests to, even at the school level and primary school level, immediately send people, you know, discover fast what their interests are and send them after their passions, and also do it in a very clever way. So, for instance, I'm a visual person. So for me, visualizing, you know, virtually visualizing any kind of concept immediately allows me to learn it faster. So if I would have tools like this in my primary school, that would be amazing. So I think we will start learning coding and all sorts of skills much, much, much faster because of AI, and that's a great thing.
Speaker 2:On a coding side, I think the current moment is a transition moment and it will never happen again Because, depending on like, if you start learning today and you know you have this, this chat, gpt, and you do not focus on understanding but you focus on outcomes, the chances are you will lose the bigger picture later on without understanding the building blocks. You see, I don't think modern engineers in car industry also understand all the software and hardware components in the cars. They can be designed externally right there are OEMs, basically but at the same time they know where to seek for that knowledge and they know what the purpose is of each element and they know how to get to there. If you, if we skip that part, the general understanding of all of those concepts and how they glue together, then we're not going to produce very um, useful programmers, in my opinion.
Speaker 1:Back to our context so I think that's where we're getting back to the original question. So, for example, how, as a cto, you, you approach this one, because this is happening anyway and, as you said you are, we are actually in the transition mode. So now we have this, uh, these people I don't know how about you, but for example, in in my companies, we don't. I don't want to say we gave up on the, we gave up on the code review, because that's not true.
Speaker 1:But definitely the code review has changed a lot, because before the code review was focusing most of like fixing this, like why this code was written bad, and so on. And now, because we put into our workflow that before actually submitting the code, you ask ChatGPT for the feedback, not because you want to give the best code, of course, that's one of the reasons but because we can actually offload the code review from our senior developers to ChatGPT. And, of course, in design, that looks perfectly and it works, as long as people approaching this they approach with the proper assumption, like you just described, right, that they are willing to learn and they are not blindly copying the outcome from ChatGPT, ignoring all the comments, right, but for us, we see a huge, huge impact on that and I totally agree that you are in the transition mode. But that definitely also impacts our recruitment plans for the future, because probably now we need to do the different math of how much different seniority of programmers can deploy the code within a week, let's say.
Speaker 2:True, and, to be honest with you, I would need way more than the hour that we have to dwell on this and think about it for myself. But I already have some thoughts about this, and it's all about processes and structuring these and then iterating them in a direction of improved learning process, but with an assumption look, use any tools you like, but you have to be able to explain where it came from and justify it. And we also try to isolate on our side. So I think, as a good leader, they should isolate the problem. So you know, if it's a one module with a handful of function and these are generated for a specific purpose, self-documented or through tests and whatnot, that's fine.
Speaker 2:But if you do not isolate and don't have a human eye to see an overview, we have seen a lot of cases where there was a unnecessary replication, because for the same input you may get a different output from chat, gpt or other code generator, and then we see entire libraries being created of people basically duplicating the same functionality with tests and everything. But it's just unnecessary, right, it's not even wrong per se, but then you know it's. It's good to have reusability in the code. It's a good practice, I guess. So it has pros and cons and we're learning as we go. Let me put it this way Various tools do it to a different degree. I think the key is to be responsible and aware of that, that these tools are not silver bullets, as you mentioned before. That's my opinion.
Speaker 1:Absolutely. I think we drifted a little bit into AI and it's difficult these days not to drift this direction.
Speaker 2:I love it, I love it.
Speaker 1:But maybe trying to come back to the original discussion, I think this is also giving. I mean, the AI is challenging the entire world and, of course, ctos are no exception from that right. I mean, this is also something which Brit brought a lot. And again, I remember the official statement from IBM CTO, who mentioned that they are firing like 8,000 people because AI will replace them, and this is, of course, his point of view. We can agree upon it or not, but these are the decisions you have to make as a CTO, right? Because, like we just discussed, you're looking forward and you need to make some bets, right?
Speaker 1:Absolutely and time will show whether the bet was right or wrong, absolutely.
Speaker 2:But if we follow that principle, we may end up in a situation where we just say to ChatGPT build me a company like this, right. I don't know if you heard the story of TikTok. Someone said the joke that now the TikTok will get forbidden in the US because it's a Chinese company. Maybe someone should just use ChatGPT to tell it hey, clone me a TikTok, figure out how to get all the existing user accounts and migrate them to my new system and launch it on day one. With one cent per user or something you know like, but I mean 30 minutes, you have multi-billion dollar company. I frankly don't think. I don't think we're just there yet and we might never be there.
Speaker 1:No, no that. However, this also reminds me of a very interesting story. I believe it's, you know, one of the banks I mentioned before. It's the European Bank and they, back in 2000,. I think 12, I don't remember exactly, but let's say 2012, like 15 years ago. Let's say, they decided they want to go and enter the North American market and they were so successful while launching there, and the reason behind it was that, you know, they started from scratch and, even though the brand was the same here and there, you know being cto of this, you know new startup, still backed up by the huge, you know company a lot of money.
Speaker 1:It's not like startup as we understand that they didn't have to figure out from scratch because you know they company a lot of money. It's not like startup as we understand that they didn't have to figure out from scratch because you know they just essentially had to copy whatever operation they had to the new market. But the thing is that they didn't have any legacy systems, you know. So one of the reasons why they were so successful was this also because they didn't have to deal with the existing technology, customers and so on and so on, Whereas the old bank was still using and supporting this old mainframe COBOL systems. The new bank, under the same brand, could use totally different technology. That's also very important to take into account, because it's pretty much the same, yet so different.
Speaker 2:Which also is an interesting challenge, because AI models are trained on the data. So if we do not have, because of a fact, when COBOL was created and how much of it is still around and how much of it is on GitHub or any other public repo for that matter, there's not a lot of it to feed into model training, on the contrary to, for example, java or JavaScript or some other modern technology. So maybe even the created product of the generated code will be different in quality depending on your language, right? So that's another thing. Absolutely Cool, David. This is amazing. You gave me a lot of food for thought and I think I would like to do another episode after this, you know, for another hour with you time flies.
Speaker 1:The pleasure was mine and thank you for having me again. I don't know if we, I don't know if we have conclusion. How would you? How would you summarize this?
Speaker 2:good question. My conclusion is that there's no job and no specific role in IT or otherwise that is not impacted by AI. That's number one, going from back to front. And also the CTO role is flexible as well. Role is flexible as well, and there's no clear definition of who CTO is by simply because there's a lot of different experiences and organizational cultures that define that.
Speaker 1:Yep, yeah, absolutely. So I would just plus one to this, and if I were to summarize with one, with one sentence, I would just quote on, uh, on ben horowitz, from the hard things about hard things, there is there are no silver bullets. Right, and I think this is also very, also important misconception from the cto that, um, I've seen some seeking for the, you know, ideal technology, the silver bullet, within the company. One rule, one technology, one idea, and I believe that doesn't work. You need to rather focus on smaller steps and crafting something which just works for you, because you can't simply copy-paste the same even from your competitors. There is no silver bullet that's what I believe Absolutely which just works for you, because you can't simply copy paste the same from even from your competitors.
Speaker 2:It will be really fun. There is no silver bullet. That's what I believe, absolutely, absolutely. David, before we sign off, where can our listeners connect with you online?
Speaker 1:I think the LinkedIn will be the best option and you will have the direct access to me. I'm handling this myself, no no AI, no bugs.
Speaker 2:Super. We'll put your link in the footnotes. Once again, thank you so much for coming on the show today and the foot for foot that you have given to our listeners. Thank you, david, and that's a wrap, for today's episode of the Dev is in the Details. David, huge thanks for joining us and sharing your wisdom on the CTO's evolving role. It's been fantastic having you here. Dear listeners, I hope you have enjoyed exploring the world of the tech leadership with us. Please subscribe for more insightful conversations in the future.
.png)
.png)