From 0 to 9-Figures ARR: Scaling Tech Without Losing Focus
[Music] Welcome to CTO Insights where we unpack the strategies behind high performing engineering teams. I'm your host Katarina and today I have the pleasure of welcoming Julian Lavin to Kate, a CTO with extensive experience scaling tech teams and products. In this episode, Julian shares his insights from scaling Zoe from early stage to 9 figure startup. We talk about the different challenges at different growth stages, balancing structure without overdoing it with processes, introducing platform teams and process automation. Stay tuned and don't forget to subscribe for more insights into creating high performing teams and standout products. This episode is brought to you
by Adiva, a global network of top developers connecting businesses with worldclass talent. Whether you need to scale your team or bring an idea to life, Adiva empowers you to increase your engineering capacity without the overhead of traditional hiring, visit adiva.it to learn more. Julian, welcome. Thank you for joining me today. Hi Kina, it's fantastic to be here. Thank you for
having me. To kick it off, let's start with your journey like leading a company from zero to 9 figure AR. That that must have been quite a journey and quite some challenges under way. Can you tell us
what you learned? Yeah, of course. Yeah. So to give a bit of context, so I used to be CTO of a company called Zoey, which is a a nutrition health tech in the UK. And indeed, I joined a time where there was no product, no revenue. So we're running medical studies and based on that we managed to build this kind of very successful product and very successful brand here in the UK and a bit in the US. And uh as you can imagine
uh as a technical leader, that meant having like a very small team at the beginning and growing that to way larger team. The company went from about 30 people to 450 peak. The tech team went from kind of seven to 100. So I had the chance and the challenge associated with it of kind of growing this team and try to make it you know as high performing as possible and therefore kind of my role changed so many times over the years. So it was very very exciting. We'll go into the details a bit later. And now first they want to focus on the foundations. And a lot of times
especially when a leader from a more established company joins a startup they focus too much on the process at the beginning on documenting everything and more often than not it just becomes a burden for the team. How could we balance this? What's the what's the best way to approach it to stay lean at the beginning but still you know laid the foundation so that you could grow later on? Yeah, that's a great question and that's actually something that I'm reexperiencing right now because I've joined a different company just a month ago uh called called Loti and it's a way smaller company and therefore I'm also here to kind of put a bit of structure but actually really to enable teams to to to go faster and and I think what um what you're describing I think is very very sure at least when I talk to other leaders a lot of people kind of go through that they kind of hire an exec from big company and they come very very heavy uh with processes and my my approach to that is actually quite different. is like actually can we almost kind of you know relax some of the constraints sometimes those company are not very mature you know at for example there's a lot of fantastic things but we have some processes that when I arrive I'm like this is processes that should be like for company like five times our size and on the other hand we've got things are like like quite missing there is a big amount of work trying to find what um what what matters or not and the way I'm kind of thinking about it is that you know you can have like the best strategy in the world but if you cannot execute it does not matter what do you need to put in place to have your tech team, your cross functional team hopefully if not that's something to to tackle first. how can
you get those cross functional teams to uh go as fast as possible and actually if you go down to the basics in general you don't need that many things I mean obviously you need to have like the right people and the skills but you know you need to have the clarity as to what are you trying to build what is your goal kind of next week the week after and and sometimes this is kind of surprisingly absent in the sense you can either have like very big process like oh let's do scrum by the book and sprint planning and etc the team members get lost in that because they just see like a list of tickets and they don't really understand or a total absence of process where it's just like people kind of you know picking something more or less randomly and without any kind of consistency. So can we just you know come back to the basis and have like very clear kind of weekly goal blyeekly goal where are we going you know 3 months in the future like all the rest of some extent like matters a lot less like if you don't have that then it's going to be very very difficult do we know how to write software properly uh which like no process is going to help you do that obviously you can there's lots of practices that help but can you go back to the basis like how do we iterate very fast in our codebase those days even more we've done uh with AI this is not going to be solved by having like a fantastic OKR process or anything of the sort. This is not going to be solved by having a growth framework. So
you need to really go back to hey you know how do we kind of build software in very small increments so that we go fast we learn it's it's the the fun of of writing software as part of of a high performing team to a large extent. Nice. And now back to the challenges different stages different growth challenges how did you deal with them? What were some maybe if you remember milestones or points in the company growth where you need you needed to to switch the approach or to drastically change. Yeah. So as as a leader some of the main inflection points you can think about is when you start adding layers. So you know you may be at a point where actually everybody reports to you. Everything is simple the information flow quite quite easily. Then you reach a point where maybe you have like 15 people in your team and you need to split into two. There's just no other
way. otherwise you just cannot be everywhere. So you start having like team lead, managers, whatever uh you want to call them and then suddenly you become a bit more removed from from the day-to-day stuff and like every time you had a layer this is even more true. So
you know you have your managers at first and you can have like engineing directors and now suddenly you have no idea what is happening on the day-to-day of of a team and every time that happens you need to come up with like the good structures to start having the information flow back to you the problems and more importantly once you've got the signal how you going to kind of influence your organization toward whatever you think is the most important thing that you need to do. So typical example is running product reviews and so how do you get your teams to report on a regular basis the status and then they come to you with what are the biggest problem or challenge that they have or what are the options on the table so that the senior leadership team can really get provide input early and help steer the the team in in the right direction. So that's something to to to bring. Another very different aspect is
that whenever you start scaling especially when you start having managers at some point you need to have this uh growth framework you need to provide people with more clarity as to how do they grow in the organization how will they become you know senior engineer staff engineer whatever um you know you have in in in your own structure and all those things are important personal experience is that a lot of people kind of oscillate between bringing those like super late and it's like total chaos or actually sometimes too early and I would say kind of the nice spot is that you want to feel the pain before you introduce those things but obviously not too much pain you should not go like toward toward chaos but do not bring those things too early like let the organization actually feel the problem before before you start introducing any um any of those things and for example you can very much go uh in a similar direction with like when is the right time to build a platform team definitely not on day one have like very much kind of product engineering teams and then at some point you have like two three teams and they start like doing the same thing over and over again and maybe they you know contribute in some kind of guild or community or practice but you can feel that it's becoming harder and harder that you need to put the responsibility on someone well at this point it's probably the right time to hire just one person maybe the platform team will be one person not four not five and and kind of iterate from from there so at least that's kind of the approach I've always taken toward building and structuring the or I love And it's completely focused on not solving problems you don't have. Right? So you just wait for it to become a problem and maybe it never even becomes a problem to be solved. Correct. And like maybe an interesting anecdote is when I joined Zoe. So the company was
two years old or something like that. We had exactly like one monolithic piece of software running on the back end and I join and there is a project to deploy that piece of software on communities. And I was like why on earth do we need to introduce communities at this point in time like in the grand scheme of everything we could do this is not the priority. So we were kind of trying to anticipate for this world of kind of microservices and etc. And don't get me
wrong I love communities it's a fantastic technology and you know eventually we're very h very happy to have it but that was just not the biggest problem and not what we should have focused on at first. You mentioned the platform team and I I want to go there because it kind of touches on what you were uh talking about right now. So both hiring and promoting from within like you mentioned the the growth of the engineers and the rest of the team and then creating the layers within the company. What was your strategy there? Uh did you focus on you know growing the team the engineers that you had into managers or did you want to hire more externally? So I think this is something that is extremely contextual to what is your starting point and you know what's also what is accessible to you as a leader at the beginning or not. I'll give you quite different examples.
Before Zoe I was actually an engineing manager in in a hedge fund in London and eventually kind of all the people I promoted below me to being engineering manager themselves. I mean all the people that ended up reporting to me were all promoted internally. there was like zero external hires and what made that possible was that we had a very high bar like everybody knew what great looks like. Therefore, it was a lot easier to kind of get the interal contributors to become the engine managers because like the standard was at the right level and therefore they were kind of getting ready. Um, if you have like more kind of diversity in terms of talent and skills in your company, it's going to be harder to kind of promote the people internally because people will have a harder time understanding what what are the expectations, what is great, what know they may not have seen what is great uh outside and so at this point it's interesting to start bringing some people from the outside because actually those people will help you raise the bar because you cannot be uh everywhere. So at Zoe we had actually quite a balanced uh view of that. We promoted internally.
We've hired some people from the outside that came up with some great ID both at the engineing manager side and both at the engineing director level. It it was a mix and it was like really really good mix in the sense we really had some people that brought so much to the organization. Would have been like nearly impossible to have this this degree of talent density by just promoting from from the inside. And in terms of the team velocity and you mentioned introducing the platform team when we spoke initially you also said that you had a separate analytics team but that came later on um not at the beginnings as well because everything was dispersed between the various teams at the company. How do you structure this properly so that the team is productive at every stage of the way? when is the right time to introduce separate teams or hire new people or focus on different areas maybe developer experience and things that are more that should bring more results later on. So
the way I like to think about that is that something needs to be standardized and one way or another you need to make that happen and at some point just having this kind of distributed into each of the kind of product engineering team is just becoming becoming too hard. For example, my my approach building platform is very similar to um you know what I think Netflix called like the golden path or the paved road which is um you want people to fall into the pit of success. Whatever is the thing that they're going to do is the right thing like at least 95% of the time so they don't need to think too much about it. It's like oh we need to create a new service. Well, there is a template for that and that template comes up with like everything that you will ever require for at least getting the the basics right. Like there's going to be authentication, there's going to be observability like there's going to be like a standard dashboard where you can see whatever metrics from from your uh from your service and like you do not reinvent the wheel. Um you can build
some of that easily at first when you're not too big with just having different people kind of coordinating across uh across teams. At some point your organization become too big. those people are always kind of um going to air towards kind of building feature for you know the domain they maintain with their teams and this is this just become too much tension. So at this point uh it start to make sense to bring some some expertise and more importantly to kind of regroup the ownership of that into a small team. This team should be very product minded but like towards the rest of the engineering organization because that's a very classical failure scenario that I've experienced myself where sometimes you've got a team like this that just start building a platform just for the sake of building platform. They don't even know what problem they're solving. Uh they think they're solving a
problem but definitely not everyone else problem in the organization. So they should be very very product minded really build the you know the platform as a product which is an interesting um there's an interesting tension because the people that tend to be also very much building platform they're not necessarily always the more kind of product minded so you need to find the right leader for for this part of the organization but yeah as I said at some point just start to breaks it's very obvious and the cost of not solving that problem means that everybody diverge and it becomes incredibly difficult to you know go from one team to another to understand the state of the system because everything starts to be very very very different. So suddenly your engineers they do not want to move into this other team because they feel that there's going to be like too much pain too many things to to learn or sometimes this other team is just going to have like so different approach to everything that it becomes I'm a bit afraid of what I'm going to find out whereas I'm kind of quite comfortable and you find yourself like solving problems are actually not very important for your growth and product market feed such as hey you know we're building the platform versus actually building a product. So for me this is kind of really the the state you want to avoid and therefore there's always a tension because you don't want to to build everything but you need to constantly iterate in that platform and at some point have some people but to give maybe an idea of the ratios I think at Zoe at big we had maybe four or five people building the platform including the security for about 100 people in all of the technology so engineering machine learning and data analyics group so it's like a small percentage like it's not like 10 or 20% like I've seen in some um in some place analytics is slightly different in the sense everything I've said you can try to apply to analytics but the one big caveat with analytics is that one of the worst thing that can happen to your business is having every single department have different numbers so the classical problem is like oh how many sales did we do yesterday and then you go access to operation to marketing to engineering everybody tells you like a number that is plus or minus 10%. What happens then is that no senior leader believe any of the numbers and it's becoming also kind of callous. So that's
one of the things where you want to be very very strict in one way or another about what is the source of truth and have like a very clean data warehouse. What I have found is that if you do not centralize the analytics team under one leader, if it's just like totally distributed and you know people just kind of coordinate, there is no forcing function for that and each of the leader they're like they have their own number. They're okay. It's only when all the
kind of leaders kind of gather and like the CEO or someone else start asking question that you can start seeing the cows erupting. It's like I don't understand did we do like a thousand sales or 900 sales yesterday because it's not exactly the same. So that I think we did very late at Zoe and that was like a mistake and the second we actually started centralizing had like a whole category of problem that just disappeared and I really felt it was significantly better. Those people can still be kind of detached in different teams right that doesn't mean they're just like by themsel in centralized team but at least they have this one leader they report to that just kind of ensure the consistency. Are there any other
strategies, structures that you've implemented to ensure that the team keeps the agility as they grow and stays productive and keep the velocity at some consistent level? So my my deep conviction that I developed over time is that there are actually very different models that can work and sometimes people are very much ah there's just one way and and and no other way. And I'll give you a quite extreme example from earlier in my career where we did something that I used to call continuous routing where every quarter uh we were putting 50 engineers in a big room and we're like these are the priorities for the quarter go and figure it out and go and figure out meant literally go and resemble teams to achieve the goal. And what was happening in practice is that there were some stability in the teams because most of the priorities were kind of continuing continuation of what we were doing before. So it was not like
it's like this totally new things but sometimes there were some project that were just actually fundamentally different and so we needed to kind of extract people from different teams to to make that happen. But more often than not the solution that the group of people was finding was actually quite different from the solution I would have thought about because suddenly they could start thinking about a lot more things than I could. So you know who has the domain expertise one thing oh how do we balance the team in terms of kind of seniority that's probably a thing I would have thought about. What do people want to do is is another one. How do they want to kind of grow their skill when you're doing that at scale like 50 people becomes like impossible to all this information in your brain? And one of the thing that is the most fascinating that I found actually when we're doing this exercise is that some people would start with there is no way I would work on X because whatever reason it's like you know crappy piece of software I don't want to touch it etc. And then at the end of the day they
were like actually I've self- selected and I'm going to work on X. Why am I going to work on X? because I realized this is the biggest problem for the company and actually I hate this piece of software and I'm going to make it disappear by kind of writing a new thing. There would have been no way this would have been less a successful conversation between me and that person if I were kind of trying to uh to move them. So where I'm going with that I'm I'm not saying people should necessarily do that. I believe there are some context where it can work, some context where it would not work. But what what I
found is that sometimes like people have like very strict ideas about what great look like such as our team needs to be stable for next two year. We should never change a team. I'm like maybe maybe not. What I found are the things that really really help is like having a very very clear direction as to where you're going. You can take like a very high performing team but if they've got like five stakeholders kind of pulling them in different direction in my experience not much going to happen. And
so that definitely matters. You need the skills in the team. You need kind of the right level of motivation. You need people to really focus on I have this very simple rule for teams is like on Monday morning think about what would great look like next Friday like I don't care about your long list of tickets but tell me what would make a fantastic week and you should be able to give me like one sentence ideally and if you do that then suddenly you have like a high degree of self-organization where people just jump in to try to help each other and all the rest to a large extent matters uh a lot less and you know you You can see that for example happening in hackathon. Hackathon like team just
assemble uh just out of like random people. More often than not it works because they have the clarity as to what they want to build. And then the other thing is kind of iterate on your on your processes. So don't just take whatever is there and accept it as it has to be that way. Just keep keep improving keep
thinking about what can be uh better. If you improve 1% or 2% every week it compounds very very very fast. I love this. It's not so conventional and I guess that's what makes it working you know for your context and for just keeping the company keeping the teams agile as as the company grows because it's difficult to to do that if you have a fixed structure. Um in terms of scaling challenges scaling the team hiring new people what were the the main challenges that you faced with as the team grew and also how did you solve them? So in the grand scheme of know everything that went well and everything we could do better at Zoe I would say we managed to ride that wave reasonably well and part of it was very early on when I joined really kind of increased the bar in terms of what people were hiring and what were how we were testing the people. So our interview process become very standardized pretty much on the day one when I joined. This is what
we want to do. At first I was doing every interview from screen to coding to system design to BVO not because I wanted to but because basically I was bringing people in the call with me. they were shadowing me and this is this is what I want right and on some of the things like very quickly I kind of extracted myself but it was like a very important part of the process to make sure that we're aligned on what great look like and so we had this process where basically you could not become an interviewer without you know shadowing and reverse shadowing and so for example that's one of the things that we did uh I would say kind of reasonably well that help us having the right people in the organization the other thing we did which was a deliberate choice that not everybody has to do the me cho the same choice is that we hire uh you know we index very very high for product minded people for people that were fundamentally quite passionate about our mission and we kind of structured also the rest of the organization um around that. So maybe we had slightly less technical people than some some other organization but at least we kind of optimized for we want those kind of team spot whatever you want to call it to really understand what uh what they're working towards and like very high collaboration with the PM and designer and and not everything was uh was perfect of course but I would say that that is something that worked well and then when you scale the organization a big part of the challenge is like how do you keep the standard kind of consistent across teams so you know if you look at big tech it's quite standard what everybody is doing but you know you need to have your performance review you need to have like calibration performance reviews maybe something where my views over time uh kind of evolve from maybe I don't know if it's one extreme for another but in particular everything that is related to growth framework I went from hey it needs to be quite detailed to now I'm more like towards actually a lot less details are necessary because with all the positive intent in the world about you know we're going to provide what great look like on all those kind of micro things you always end up with massive amount of gaps and I found that actually what you're really looking for is a mindset and not like a very very specific set um of skills. So that's
something where maybe we're indexing too high on one side and now maybe on the other side of the spectrum and then I'm sure I'm going to do the pendulum and be somewhere in the middle in the next uh in the next few years. But yeah, everything that is related to calibration and having your engine managers like really discuss what makes a great engineer, how do you make sure that the great engineer on the right side is equivalent to great engine on the left hand side really matters a lot because otherwise you start to have like this kind of subcultures that develop and that's just not not good at all. And maybe another thing that I found always super interesting for scaling is like being very very deliberate about your system of work. How do you want people to work together? I'm in general very flexible about how a team work inside but how team interface with each other is where I have like quite strong opinions. It's like you know APIs uh versus kind of internal of service. in general service can be written in whatever programming language. It's
going to be you know totally totally abstract to the rest but actually the interface we we do care about it and and that's another thing where whenever you kind of scale your organization you need to put a lot of thoughts into it and a lot of leaders are probably not spending enough time designing the system. There's one thing that you mentioned aligning on what great looks like and I also noticed it before when you were talking about what every team member should think about like what would great look like at the end of the week and I just love it you know how it inspires people to to focus on this is the standard this is what we want to achieve and everyone is on the same page. Yeah, absolutely. And like for me, it's all about the inspiration. It's like the the ability to tell you at the end of the week, ah, we've done that thing. It's
amazing. And I like to tell my team, you know, this is your internal goal. You don't need to necessarily kind of communicate it to the outside. Like it's not necessarily like commitment that, you know, if you don't make it, something's bad is going to happen. Just
be ambitious. Like, you know, try to try to stretch yourself. Try to make the thing that really matters happen. Like,
no one cares about the 62 tickets that you've uh, you know, shipped this week. This is not how we merger progress. Yeah. For me, it's just important to have always this kind of thing in front of me like if we achieve that, then I deserve a nice glass of wine. That's amazing. Let's talk a bit about uh
automating. Uh you mentioned what we were discussing before before this podcast. Customer support, scaling it, improving the product so that customer issues are reduced and it could improve the self-service of the product itself. How could all of this support the team performance? How could it release the team from a lot of unnecessary challenges they're facing daily? Yeah.
So, this is something where I felt there was kind of a lot of tension at Zoe in terms of what do we think is the right approach and maybe going back um a bit in the past. I think the tension is coming from do you want to have like all your technology engineering product capabilities very much kind of geared towards everything you need to do to find product market fit or do you want them to work more on kind of efficiency and by making for example customer support way more efficient actually you kind of create more more capacity for yourself down the line and it is fundamentally a conversation about what kind of time or reason are you optimizing for because if you're pretty much optimizing for the short term, you forget entirely about efficiency. Just let's try to find more product market feed. We'll do the tickets, we'll do the
support. If you're optimizing for the very long term, you realize that over time more and more of your capacity just goes into this kind of black hole of customer support. At least if your business scale and maybe this is kind of the inflection point, which is if your business does not scale, then you should probably not worry too much about doing customer support kind of improvements. But as as you say, there's many different way you can tackle the problem. In an ideal world, your product is so great that no one will ever need customer support. But there's such a
long tales of problem that actually it's not very practical unless your product is extremely simple. So if it is fantastic, good job. We were not in that world at Zoey in particular because our product was a mix of digital app, so mobile app that you interact with and physical products. So we were asking people to wear a CGM continuous glucose monitor which is a device you put on your arm to measure blood glucose. So many things that could go wrong here.
Another part for example is that we had we're asking people to ask to eat cookies. Like we literally had this question one day in customer support from someone. The question was so should I remove the packaging before the cookies? Yes or no? And like that sounds very obvious what the answer is. And still you have some people asking you that. But that's a fantastic example of
the long tail like okay you can put that in your FAQ. No one will read your FAQ about whether you should remove the the cookies from um from that. So maybe maybe we could have a better product where we say explicitly remove uh the cookie from the packaging. Probably we did uh I don't remember probably we did not put it like with a big red cross that this is something people should be um should be aware of. But I guess my
point is that you just end up spending ages trying to optimize those um those edge cases. And so you have to be quite deliberate about what's uh what's okay or not okay. Obviously in recent years what we're able to do and a lot of company are doing is automate a lot more kind of the customer support side with a product like intercom uh that you know provide AI agents and kind of answer some of those questions automatically for you. But even there at least in the case of Zoey there are quite serious limitation because in my case of cookies we really don't want the model to hallucinate and say oh yeah that's fine just go and eat the packaging. So there
was kind of always some big trade-off here like the starting point for those things is very obvious is like can you measure it and I think this is something where we're quite late to the party in particular because the tooling we're using for customer support was actually making measuring all that stuff extremely hard and so if you can actually understand where you spend your time you can start being more deliberate about about it but I do think we've made a mistake in the sense we should have done a lot more kind of early on because going back to your question if you weigh too much and especially when you start scaling that means you just have like a constant streams of uh you know problems you need to deal with and you know your customer support team is probably not capable of kind of self-s serving all of that uh themselves. So at some point some of that kind of reach uh your engineing team and you find yourself 10 20% of your bandwidth just doing things that are not adding significant value to to to the business. So you need to try to course correct quite fast or some companies have pretty much a policy was like oh no we're just going to never end up in this situation automate everything from the beginning which I think is fine if you got very very strong product market fit from the very beginning if you don't like it's uh it's quite risky I would say did you do any uh product changes that majorly impacted uh reducing the customer issues and customer support tickets we did over time many of those I mean funnily one that I can remember was not a change on the digital experience was a change on the physical experience but the it's it's actually quite interesting to think about it. So one of the thing we're asking people to do is like take a small blood sample and the way we're doing that is doing some kind of finger prick where you have to pick like with a needle your your fingers and like this goes wrong so many times. People just really struggled with that. It's actually quite hard to get blood flowing in your hands for like a big category of the population. And so like people just
kept coming back like does not work. What do we do? And for us like we had like tons of software on the kind of fulfillment the logistic side of resend whatever was necessary to redo the test. And then actually we did um work with another company that was doing some R&D where they started building a device that you were the same thing kind of putting into your arm. it was just kind of sucking the blood and suddenly we had a lot less people uh complaining about that because it was just like a lot more kind of smooth. May maybe my point here
is that sometimes not always thanks God but sometimes you need to be quite creative and actually solve the problem not just like the immediate problem in front of you but actually go back to is there a fundamentally better way to tackle this and we had an operation teams that kind of led this project did fantastic work and yeah that really kind of helped in one part of the experience I would say that's amazing looking back are there any decisions you'd approach differently uh anything any mistakes that you can recall that you would definitely fix if you were in the same position again? So the the way I think about that is that I'm never going to be 100% correct and actually a lot of things we're just going to try see what happens and iterate. I think you need to be, you know, there's there's one way door, two-way door decisions. One way door, you want to be like super cautious about them. Two-way door. I would default towards acting fast and then assess and change your your your direction. But maybe the things where we struggle the most of the time is that with all kind of positive intent in the world, it's quite difficult to not end up in a situation where there's just so much work in progress. people are
pulling in so many direction and you don't have like the good systems in place to just like very quickly go back to you know this is the only thing that that we do I think at so in particular we had a set of kind of two co-ounders and no kind of real tiebreaker for many years and I I remember pretty much on first months when I joined like this is the thing that's going to be hard and yes this was the thing that's was going to be uh that ended up being being quite quite hard so I think for me maybe like the big takeaway the big things I would like to do differently and I'm trying to differently today is just be a lot more strict with all the thing in the sense just go at the root kill stuff as quickly as possible let's not work on this let's be super clear basically even more than I was probably saying no and more importantly really teaching everybody at every level of the organization to say no we're focusing on that this is the thing that matters sure we're going to spend like 20% of our time always whatever doing but fix and small thing that's fine but Let's agree on what's the right percentage and let's stop being dragged constantly in conversations about things that do not matter and I think all the companies are scaling very very well are probably very very good at that and then a lot of company just really struggle and you can you can feel it in the in the overall velocity of the organization. I love it. Thank you Julian. It was a great pleasure to talk to you today and you've shared some amazing insights. I hope everyone takes away some interesting findings from all of this. Thank you, Katina. It was great to be here. Thank
you for the great questions and speak to you soon. CTO Insights is brought to you by Adiva. To learn more about how we support innovative tech teams, visit adiva.it. Don't forget to subscribe to CTO Insights on YouTube, Apple Podcast, Spotify, Substack, or wherever you listen to podcasts. Thanks for tuning in.
2025-05-19 06:55
