Luca Fornaroli: Engineering Success - Insights on Building and Scaling Tech Hubs

This transcription of the podcast is AI-generated and may contain errors or inaccuracies.

Leszek

My name's Leszek and I will be talking with Luca Fornaroli about scaling teams through mergers and acquisitions. So let's start with your journey. What led you to your current role of Director of Engineering and board member at Scale Up A. Yeah.

Luca Fornaroli

So first of all, thanks for, for the, for the time and for the opportunity. My career was quite strange. What I mean is that I only worked in two different company. I worked for more than 10 years in Viva Ticket, that was a ticketing company and basically we were providing ticketing and admission system for Park Museum, I mean whatever needs it in order to be, in order to be admitted. I started there as a junior developer and then you know, I grew up until became the C, the CTO of, of the company. So you know, I really started from the very ground and then I reached the C level. The C level position was quite a fun journey because I was really, really young and the company was growing a lot.

So you know, it was really great opportunity to see a lot of different things in terms of new project, new market, working with different culture, you know, working in a very high demanding sector like ticketing. And so over there I learned how to run teams, run international projects and also how to scale team because when I was appointed as CTO, I had 250 people behind me in both tech, product, infrastructure, data. And so I needed to learn quite fast how to manage very big on the job. Yeah, yeah, for sure. I mean that, that was, that was fun because we were also growing a lot through M and A and basically we were adding a new company every year and was quite challenging and fun because you know, you need to start to understand how a new software works, what are the challenges that the company was having. And most, and the most important was try to understand how to consolidate everything together and how also to merge or sunset some product, but on the same time understanding how to move on, merge teams. So that one was a good school for me.

And then after 14 years I decided to leave the company because I was looking for something new. I was looking for new challenges because what I really love is to be sure that the company and the products and the team are growing and are becoming bigger and bigger and basically my journey over there was pretty much finished. And then I decided to join in a startup that is Scala Pay and we have a fintech that is active in the buy now and pay space. So basically we are allowing our customer to buy in three or four installments without interest. When I joined, Scalapi was a startup, but with clear path for becoming a solid company. I joined at the end of 2021 and the company became a unicorn in 2022. And so you know, I was hired basically to build the tech hub in Milan because one, because one of them, because the company was founded by two co founder, one Italian and one Australian one and the Australian is the CTO as well.

So at the very beginning the team was all the base, the inner in, in Australia while the 99% of our business was in south of Europe. So Italy, France, Spain and Portugal. And so the business really needs to have a developer on the ground and close to the business. And basically I was hired to create that kind of team and this new, and this new engineering hub and this was really, really good for me because as I told you before, what I really love is to be sure that, and to make the company grow, the team growing, product growing. And so for me was a sort of fresh start and I enjoyed it a lot because you know, you, you, I, I made a sort of step back at the very beginning because I was moving, you know, managing a lot of people all over the world to basically be the first tech person in Milan. But it was fun because you know, you need to start to understand the product, you need, you need to start to understand the market, the regulation. I mean I was never exposed to payments and basically I moved to a fintech that is a quite complex space and so that was fun and you know, I was able to create a very good team that now is working really, really close with the, with the, with the Australian office.

So was, I mean was a lot of fun to be honest. Little bit challenge, you know, due to the time difference between Milan and Sydney. But you know, in this case I learned really, really fast how to work offline, how to document everything, how to, you know, allow teams and people from two different places of the world to continue to work together. So that's my journey.

Leszek

Before we move on to your role, your accountability and the business scale up, I'd like to ask one follow up question to what you've said, which is what was the secret sauce for integrating that many companies in such a short period of time? You said you've added one acquisition a year and that must have been quite a challenge to actually make it successful. Is there any secret sauce that you can share in that context?

Luca Fornaroli

So my secret sauce was to be involved from the very beginning because you know, I was part of the team that was doing all the due diligence and so you know, was also trying to establish a relationship at the very beginning with the key, with the key stakeholders. And I was spending a lot of time talking and visiting the new offices. You know, try to stay together, meet people, talk, talk with people. And also what I learned is that if you want to convince people to work together, you have to explain the reason why and what are the benefits on changing some behavior or adapting or adopting some common, some common pattern pattern. Because you know, the, the really big challenge was that we were acquiring companies that were from other part of the world that were using different programming languages, that were following different business, that was following different business approach. And so you know, that one was the up part. So what I have done every time was okay, let's try to understand how they are working and if makes sense for them to move to a common pattern or if we can adapt our common path.

But you know, embrace that company and, and that team as well and try.

Leszek

To keep best of both. Sort of. Sort of best of both. Yeah, take the best of both.

Luca Fornaroli

Yeah. And also try to keep everyone updates about the company progress and the reason behind any decision that the company was made. I mean if you are clear and if you are open and transparent with people, this will help us a lot when you need to integrate people, teams and products as well.

Leszek

I'd like to discuss, sort of dive into your role and I'm curious about your responsibilities, your accountability and maybe a follow up question. How do they compare to a CTO role?

Luca Fornaroli

Yeah, so as I told to you before, now I'm appointed as director of Engineering here in Scala Bay. And my responsibility basically is to be sure that all the teams deliver what the business wants and also to collaborate with the CTO in order to shape up the. About that and tech roadmap. So basically what I'm doing on daily basis is I need to be sure that my team has crystal clear what they need to do. And there are no, and there are no blocker. And also try to give as much accountability as I can to the team because the way in which I love to work is that we, I want to have the team that are responsible for a particular part of our flow like you know, payments, checkout, whatever is it. And then I'm working with them, try to, and challenge them on taking the full accountability of that part in terms of requirement, gathering, development, reliability, keep KPIs.

So this is my main responsibility. As I told you, the CTO is basically from the other side of the world. So part of my duty is also to be sure that if there is a technical issue or if the business needs some technical answer, I, I will do it. I mean if I can, I will do it. Otherwise I will wait for him to, to, to, to wake up. But basically I'm doing a software shield from him because you know, the business is really, really demanding and we are really trying to be as much as independent as we can from the day by day activity from him. Because the real difference between my role and the CTOI role is that my role is to be sure that teams are working deadline, maintain platform is, is, is available.

So you wish is more an execution while the CTO role at the moment is more also a strategical one for two main reasons. The first one is that he's one of the, of the two co founders who of course is part of the big strategy of the company, but also because he's also acting like the chief Product officer. And so basically he is the one that is more involved with the business in order to understand what are the next feature or what are the new changes or new products that we want to launch into the market. Basically I have the full responsibility for the two tech up, the Italian one and the Australian one. Plus I'm working really, really close with the Director of Product and the director of the offer infrastructure, while QA is basically part of my every responsibility.

Leszek

Okay, and how do you organize their teams? There are a couple of them. How do you make them work together, how do you align them? How do you basically orchestrate all those teams to work together towards one goal?

Luca Fornaroli

Yeah, so the way in which we work is that we have a lot of small cross functional team that are composed by a product owner, a tech lead, one or two developers depending on the domain, and a QA guy. And basically they are in charge of managing a single vertical of our platform. So there is a team dedicated to payments, one dedicated to checkout, one dedicated to risk, one to marketing. And basically that team has the full ownership of his domain. So the product owner is working with the, with the, with the business in order to figure it out and ship up the work. And then the product owner is working with the tech lead in order to craft the solution design. And then once this is agreed that the team is in power of building and deliver what was agreed between the business and the technical lead.

Of course there are a lot of teams that are connected together because if you want to launch a new feature that maybe is presented on the checkout, you need to talk with the payment team or with the service team. So the way in which we are working is that we are planning six weeks in advance and basically every team is providing a list of activities that will be delivered in each week. And before committing it, we are sharing this board with all the team and each team can erase all the dependencies, all the of the missing points or all the connection that are made not only between teams, but also maybe in infrastructure or with data team. So we are really trying to make the connection and interaction in a visual way. So we are using a mirror board with a Zwim line for each team and basically there are arrows that are going from a team to another one in order to say, okay guys, if I need to deliver this in week three, then I need from these other teams something in week two. Okay, if you need this, then I need this piece of infrastructure amid. And so, you know, we are spending a lot of time on the first week in order to figure it out, everything that we need.

But then the team have five weeks in which they are really, really focused on deliver, on delivering because everything is crystal clear and each team knows exactly what you need to deliver in order to not block any other team. From the technical standpoint, we are also, we created a sort of committee that is approving or declining the new, the new feature from the technical standpoint. So once that team approves the solution, then the team is empowered to deliver it and no one from other team can say, guys, I don't like it or why you have done in, in, in in that way. This is something that we implemented last year because you know, was happening a lot of time that people were not happy with the solution. And so basically the team was spending a lot of time in delivering and then they were, they were challenged on the solution at the end. And so we decided to stop this kind of way of, way of working. And this helped us to speed up the delivery time by a lot because you know, we can design approved means okay, no other changes are allowed.

And so everything became much more easier for us.

Leszek

I've got two follow up questions as to that. So who's in the committee and what is sort of the North Star for making those decision? Is it business, revenue, user, technical feasibility? What's kind of the, you know, the way that describes how they make those decisions?

Luca Fornaroli

Yeah, so the committee is composed by myself, the cto, the two engineering manager, the one that is managing the Italian hub and the one that is managing the Australian one, the principal engineer and two people from the infrastructure. And basically that that committee is reviewing the solution design that the tech lead are obliged to show to us. Before writing any line of code basically on, on a new, on a new feature. And what we are looking for is to be sure that, you know, we are using a common pattern between different things. That we have taken care about database in terms of naming convention, in terms of scalability, in terms of interaction, that we have taken care about observability and also that we are taking care about test and KPI. What I really ask every time is okay guys, it's okay. But how can we measure if what we are delivering is bringing the value that we are expecting?

And what are the dashboards that we have in mind to craft in order to continue to monitor this new feature or this new piece of infrastructure for the future? So these are the kind of aspects that we are taking care on. And also, you know, that committee is also in charge of deciding if a new technology or a new service or a new tool can be incorporated into our, into our code base. So just to make you an example, last month we decided to introduce OpenSearch as a database because we did not have a sort of index in our toolkit. The team was then one that was in charge to. Okay, understanding if makes sense, if not, what are the common way in which we can bring it inside our code base? Who from the Infra team is responsible of implementing it, maintaining it, monitoring it?

So that team is really the core of our development and software development lifecycle as well.

Leszek

Cool, thank you for that. And just one follow up question to that, which is always interesting for me. Why did you choose six weeks? Did you try with different sort of time boxes and this one particularly works for you or it's happened by chance? Can you give us the sort of rationale behind.

Luca Fornaroli

Yeah, so the, the overall idea was that six weeks are more than enough for a feature to be delivered from the very start to the very end. And so we started with that and we found that was the correct timing. And also, you know, that it, it could seems a little bit longer. And the reality is that is true is a little bit longer, but this, you know, allow us also to take care of the tech depth or to, or to take care also to all the side tasks that are associated to a feature because you know, maybe in three weeks and then we have the additional two or three in order to create the dashboard, to check the analytics, to do the right documentation. And so this is the reason why we choose the six weeks. Cool.

Leszek

Can you give us a little bit of insight what it's like to manage and lead a company like this, which is a Growing company at the same. It's in a space that is highly regulated. What's it like to lead engineering teams in such an environment?

Luca Fornaroli

Yeah, this is a good question. And on top of this, there is also the fact that we became a regulated entity only one year ago. And so we have also the shock of moving from a completely unregulated way of working to a fully regulated one. And so basically, to answer to your question, to your question, it's quite fun because, you know, we are trying to follow the OKR way of working and so we are crafting OKR for each quarter. But the business is really, really fast. And so happens a lot of time that, you know, OKR are changing or are adapting if you wish. And so it's a challenge time for the teams because as I told you before, we are trying to plan in advance.

And so, you know, when the business change their mind, we need to understand what to do. I mean, do we need to complete what we're doing? Do we need to, you know, start and jump fresh on a new project, how to explain these to the developer? And so that one is the challenging part. I think that, you know, everything is related to the kind of people that you bring, that you bring on board. I mean, our team is quite young and so there are a lot of talented people that are also angry if you wish. And so, you know, it's also easier for them to say, okay, this is not working, let's move to the next project, or okay, guys, we work at the mini miniab in order to deliver this.

But, you know, now we saw a different business, business opportunity. And so I think that our team is quite used to do it now. At the very beginning was a little bit harder, especially because the company started to grow a lot more in the last year and half and basically the team were a little bit stressed and stretched as well. And so, you know, I think that part of my job is to again explain to the team the reason why. And once you are able to explain exactly the reason why, then it's easier for them to jump on board and to, you know, move to a different project. And also what works really, really well, at least for me, is to show to them their results of the world. There is what I'm trying to say is that I'm challenging them a lot during the development phase in order to be sure that what they are doing is somehow measurable and it's easier to craft KPI on the feature.

And so, you know, when they move to a different project and then they deliver the, the, the project and you can show to them guys, take, take, take, take a look with the, to the result that you achieve. Then it's easier the next time to move them into, into a different, into different projects. So in short, try to explain the reason why because every time that we change the plan there is a reason why. Then could be a good reason why or a better reason why, but at least there is a reason why behind it. And show once the project is finished the real benefit that it bought. So that one helped a lot. Moving from a non regulated environment to a regulated environment was a challenge.

A challenge, you know, because you need to. So our core, our core KPI at the before becoming a regulated entity was okay, let's grow as fast as we can and maybe let's sacrifice a little bit the data quality or the you know, the kind of checks or how strict we were. While when you became a regulated entity you need to take care about the data quality. You need to be sure that all the box are checked in terms of compliance, in terms of identity verification and so on. And this at the very beginning stopped our growth a little bit simply because you know, there were a part of the company that was still pushing for the growth while there were another part of the company that say okay, it's okay to grow but we really need to think about this because otherwise will be a biggest problem. So we went through that journey in the last basically one year in half. Now it's much better.

And again what changes was that we start to explain better the reason why some check are there, why the data quality is so important and so on. So my responsibility in that case was again let's align everyone on while we are doing this, let's extract some KPIs and metrics and then let's discuss with the cleanerness of that.

Leszek

Okay, but thank you for that. I've got one follow up question which is it's easier for me to imagine driving the alignment via OKRs in the environments or context that is easier to measure. For example, I can imagine that it's easier to set KPIs related to infrastructure that are either lead time uptime, reliability metrics or whatever. But it's harder, usually harder to establish KPIs related to the product itself because one of them is usually lagging. I mean the results that you observe, for example from delivering a feature, it takes time before actually you see the you can basically have samples that are relevant. And secondly, before it actually makes it takes time for the data to Come in. And for me those product metrics being sort of embedded in okrs and being, you know, digestible, making them digestible by the teams is actually really hard.

And I was wondering how you sort of embed product KPIs for the engineering team, you know, okrs so that it works, they're understood, they reviewed an appropriate time frame, etc.

Luca Fornaroli

Yeah. So I think that we found a good, a good, a good balance. So what happened is that our leadership team is crafting them objective like you know, increase the number of active customer, increase the number of monthly active customer by 10% or you know, find a new monetization project for X amount of million. And so that one is the kind of objective that the leadership team is giving. And then each team is empowered of understanding what to do in order to reach that objective. So the team is the one that is crafting the key result related to that objective. Now the way in which we are doing it is quite easy.

What I mean is that we are doing a lot of of experiments in order to validate our our, our idea. So let's say we want to increase the number of monthly monthly active customers. So the team say okay, I want to test these, I want to test these and want to test this. So we put, we put in place very simple experiment and then we start to allow to a percentage of of our customer base and then we see results based on these experimental results. Then we can say okay, this seems to work and these are the uplift that we are expected. While okay, this is not working so let's park it or okay, we run this experiment that give us a software result that we are not expecting. So let's dig on this.

So basically is the team that is creating the key result. Of course there are also some KPIs that are more technology related like you know, up uptime of the platform or the cost of the platform or whatever is it so that one are handled in a different way. So we as an engineering team we are setting up this kind of KPI and we are reviewing on weekly basis saying okay guys, this is our target. Let's see in our scorecards where where, where where we are. And basically if one of them is lacking then it will be part, it will became something to add into the next season. That is the collection of of this week that we were talking about for a particular team. So this is the way in which we are approaching very interesting and six weeks period.

Leszek

So can I like so to link those two concepts which is the six week Cycle and the experimentation driven sort of product development. My understanding is that some of these objectives for those six weeks are just implementing and releasing actually experiments, sometimes one, sometimes couple of them, and then retro and then just looking at the results from the previous experiments by making those results sort of transparent for the team to understand, did I get it right or correct?

Luca Fornaroli

And basically when we are deciding what are the experiments that make sense to a man, what we are also doing what, what we are also doing is, okay, we want to run this experiment to validate these hypothesis. And so we are collecting data in order to see if our hypotheses are correct or not. And also we are understanding what will be the impact on the full customer base if we transform that experiment from an experiment to aerial to aerial three feature. So what we allow the teams to do is to maybe be a little bit faster in doing, in running the, in running the experiments. And so, you know, there is not all the process that I discussed with you before, like, you know, the software architect committee and all this kind of stuff because, you know, we really want to go, to have the experiment go out of the door quite fast, faster, capture data and then decide if makes sense to implement it in the correct way or not. So this allow us to run a lot of experiment, maybe Also, you know, 10 per season, but then decide, okay, we run this 10, we saw that two of them make sense for us to become a real feature. And so the team, the week, the season after is focused on implementing that two plus running additional experiment to understand the next phase of our work.

Leszek

Nice. I think the only thing I can add to this, actually. Congrats. I don't think you mentioned it's sort of easy or simple. I don't think it's actually. I don't think it's as simple to actually run company like this. It's sometimes counterintuitive.

I know there's plenty of books and podcasts and, you know, sources that describe this idea, but I actually think it's easy to implement. So congrats on that. Thank you. I've got one more question to structuring teams. I was wondering how your approach to structuring them evolve over the years. Has it changed dramatically or maybe there were some key turning points along the way?

Luca Fornaroli

Yeah. To answer to your question, at the very beginning, the company was a real startup. So basically there was only one team composed by a couple of people that basically was taking care of everything from development to QA to deployment, infrastructure and so on. And you know, also our code base Was was, was different. We started with a monolithic approach because we wanted to go fast and ship as fast as we can. Then when we decide to open the Milan tech hub, we decide also to change our, our way of working. Because you know, if you want to scale the team, you need also to scale that this the way of working.

And basically we started to structure different teams and also we started to split the monolithic into different microservice and business logic as well. And basically that allowed us to craft and to create different teams that are taking care of a single vertical of our platform because they are also owning the particular a repository as well. So the payments team on the payment as a domain, but also the repository that are taking care about payments. And so that one was the biggest change that we have made when we decide to scale our our team. Something that we change in the last couple of months was also to not having single person dedicated to the qa. But we are empowering and we are enforcing developer to run the test as well. This because it will help in two different way.

I think the first one is that the developer can grow because in my opinion Aerial Full Stack developer should also understand and take care about test. Not only unit, but also, but also end to end. And also it's speeding up a lot the development time. Because you know, having a single person responsible of testing in a team, it means that okay, developer is developing, then when it's finished it needs to explain everything to the QA and then QA can start. While if you empower and enforce development, they can start to take care and things about test during the implementation phase as well. At the very beginning also we were looking at team as a sort of static, in a static way. Meaning that okay, if you started in the payment team, you will stay in the payment team forever.

But I'm not a huge fan of that. So I started, you know, to try to have a sort of movement inside team every couple of months. And this helped as well because you know, the more you know the platform, the better it is because when you need to develop something, if you have a clear idea on how the platform is working, then you can start to code it in a way that is already extensible, that is, you know, easy for users or easy to consume from other. Of course we are not changing all the people because, you know, the payment skill are really, really hard to get. But you know, at least one person every couple of months may change things. And this also, you know, allow me to, to create and, and enforce the company Culture because you know, you, you are working with multiple people. We are working with different stakeholders, different product owner, different aspect of a fintech world.

So this allow me, you know, to be sure that all the team are working together and are working well together simply because maybe in the past they were in the same team, so they shared something and it's then easier to collaborate together.

Leszek

5%, 100%. Couldn't agree more. My final question is what's your approach to leadership? I think you gave us a little bit of sense when we were talking or referring to M and A activity. You mentioned, you know, being transparent. You mentioned knowing the people and understanding the other side. But I think that was maybe some reference to that.

But I still like to get out of you, your approach to leadership. Maybe some key lessons learned in that space that occurred along the way.

Luca Fornaroli

Yeah, sure. So my kind of leadership is a leadership by example, if you wish. And also I really love to empower people. So what I'm trying to do is I love to be updated on what the team is doing, but at the same time I try to give them as much responsibility and ownership as I can. And so, you know, a developer and also tech lead really love this because, you know, they feel like they are trusted and then they are the one that are coming to you when they have some idea or some doubts or need some help. And so, you know, these helped me, you know, to have time for everyone because I'm not 100% involved in coding on decision. I mean, I try to stay and to an upper level, but on the other side what I can see is that the people are really growing because they feel like they are owning what they are doing.

And so these are bringing a lot of new ideas and also helps with the retention of talented people. I changed my way of working a little bit. I mean, especially at the very beginning when I was appointed as a cto, I was really, really young. And so, you know, I was, how can I say, a little bit scared of people that knows more than me. Now it's the opposite. I mean, I try to bring on board people that has a very good knowledge that they can do things that I'm not able to do. And so, you know, this is a, this was a really changing part for me because, you know, I start to learn from people and I start to allow also other people to grow. And so, you know this when I started to craft the teams in Scala pay, every time that I was doing an interview I was asking myself, is this guy is able to do something that I'm not able to do if in the US if the answer was yes, okay, he is the kind of person that I would like to have in, in, in, in, in the team.

And once you have this person in the team, it's easy because you know, you have to trust them because they know more than you. And so you need to trust them. Of course, you need to challenge them. You need to, you know, be sure that they understood that they have the clear picture. And so that one is the other part of leadership that is okay, understand what the leadership team wants and let's try to translate in a language that the development team can understand and get and then let's have them drive and let's shield them as much as you can, because if the people are trusted and are empowered, they can come with solution that are fantastic in my, in my opinion. So this is my approach to the leadership.

Leszek

Go well. Luca, thank you very much for, for your insights, for your wisdom and spending time for me with me today and having this discussion. Thank you very much.

Luca Fornaroli

Than entry. Thank you.

Leszek

Follow Matt and Leshek on LinkedIn.

‍