Building Teams That Scale. With Luca Fornaroli, CPO at Compri (TLP-52)
On other platforms: Web, Apple Podcast, Amazon Music, YouTube.
The content is in Italian, but here is the transcript of the conversation translated in English using AI
Luca: Today's guest is Luca Fornaroli, CPO at Compri. Luca, welcome!
Luca Fornaroli: Hey Luca, great to be here — and a big hello to all your listeners!
Luca: Thank you so much for joining. Would you like to introduce yourself and share a bit of your background?
Luca Fornaroli: Sure. I wouldn't say I was born passionate about computer science — it developed over time. But once it did, it really shaped my path. I have a degree in computer engineering, and right after graduating I joined Viva Ticket, a multinational company in the ticketing and access control space. I came in as a junior developer — truly entry-level — and stayed there for 13 years.
Luca: Wow.
Luca Fornaroli: I started as a developer, became Tech Lead for one of the international teams, and within two and a half years I was already CTO — very fast growth. By 27 I was effectively running both product and tech. I stayed there for 12 years total, 8 of them as CTO, so I saw everything: team building, product development, M&A. I ended up managing very large teams across multiple countries — Italy, France, the US — which also meant navigating the complexity of different cultures and team dynamics.
Luca: Sure.
Luca Fornaroli: After 12 years I wanted to change and find out whether I'd just been lucky or actually good at what I was doing. So I left and joined Scalapay — a fintech in the Buy Now Pay Later space — when they were still small. I was hired as the first tech person for the new hub they were building in Milan, with the challenge of building out the tech team. I stayed four years, going from being the only tech person to leading a team of around forty — developers, product, data. After four years I was ready for a new challenge, because what I truly love is making teams and products grow from scratch. So in September 2025 I left Scalapay and joined Compri as, let's say, Chief Product. Compri is a startup in the procurement space — we're building a B2B SaaS that automates the work of purchasing and compliance offices. It's an AI-native system that builds agents to support buyers and compliance officers, who today still work manually with Excel files and emails. I made the move to Chief Product because I genuinely believe technology and product need to work hand in hand. I always say: there's no product without tech, and there's no tech without product. I've always been a fan of cross-functional teams with product owners embedded within them. So yes, I do product — but it's deeply technical product. That's a bit of context on why I shifted roles.
Luca: CTPO, depending on how you look at it. But I get it — I agree that in companies where the product is the technology, the two roles are deeply intertwined. Makes total sense. So Luca, today's main topic comes directly from your experience: it's clear you know how to build teams, and that's exactly what we're here to talk about. Do you want to introduce the theme?
Luca Fornaroli: Sure. As I mentioned in my story, the thing I've realised I'm good at and genuinely enjoy is building teams. I think it looks different depending on the company, but I've developed a real feel for it in the startup and scale-up world. My belief is that the skills you need in a team shift depending on the company's stage. In a startup or scale-up, the people you bring on board — whether on the product or tech side — need to have ownership of what they do. Otherwise you'll never get out of the weeds. You're usually working with a small group, and the "few but great" rule applies. And for me, "great" isn't just technical ability — yes, you need to know what you're doing, know the programming languages — but soft skills matter enormously. The two soft skills I believe are essential in a product-tech team are ownership and the willingness to step outside the pure tech world. You need to understand the product, what it's trying to do, and learn to talk with customers — whether B2B or otherwise. These two things are very hard to find. Especially today with AI, the developer who understands the business is becoming more and more essential.
Luca: Absolutely.
Luca Fornaroli: Using AI as a tool to move fast — perhaps less "purely technical" but more business-oriented. The real challenge is that it's very hard to find people like this — not because they don't exist, but because it's hard to design a selection process that actually surfaces these qualities. Assessing technical skills is easy: you give a case study and you either know it or you don't. Assessing ownership is much harder. What I've found works well for me is asking people to walk me through a project they're currently working on. From that conversation, you can really tell whether they understand it, whether they know how its value is being measured. That's my little secret recipe for figuring out if someone has true ownership. For me, an owner is someone who understands what they need to do, how to do it, and why — not just in terms of features, but in terms of business value and KPIs.
Luca: So it's really about understanding the business impact of what they're building.
Luca Fornaroli: Exactly — and being able to challenge what they're doing. Sometimes the business asks for things that aren't clearly defined. If when you talk to someone they can push back and respond to your challenge with data and KPIs, that's something I value very highly. And as I said, you can teach technical skills far more easily than you can teach ownership. Well, you can teach ownership too — but you need a team that already has it. Once your foundation team knows how to measure things, how to talk to the business, you can bring in people who are less strong on this and develop them. But those first two or three hires really need to have it. Otherwise you risk building a culture that's very hard to change later.
Luca: Right — so it comes back to mentorship, where the people already on the team play a key role when you bring in someone new who isn't yet established.
Luca Fornaroli: That's a great point. Once you have your core group — let's say a couple of developers who will eventually become your tech leads — it gets easier, because you grow by extending those teams. For example: you hire two people, each working on different modules of your app, then you hire two more, so instead of having four individuals you have two teams of two. Working together, seeing how things are done, how you communicate — that helps a lot. I also think the engineering manager role has changed significantly. You need to be good in the weeds, but you also need to be able to explain the why to your teams. And if you have ten teams, you need to explain the same thing ten times in a consistent way. That creates clarity and a kind of shared ownership. The other critical thing for an engineering manager or director is setting common standards across teams — because teams change frequently, and you need people to be able to move from one team to another on completely different domains and still be productive immediately. Same pipelines, same boilerplates, same languages where possible. Even if the stack differs — say, between a frontend team and an AI team — the ceremonies and ways of working should be consistent: stand-ups work the same way, tickets are written the same way, everything is on the same tool. This plug-and-play capability is increasingly important given how fast things need to move today.
Luca: How do you handle these reorgs effectively? Because you mentioned that team structures need to change fast to match current needs — and with AI accelerating things, that can create some anxiety for people who aren't used to being moved around.
Luca Fornaroli: Honestly, there's no single right answer — it depends a lot on the company's culture. What I always do is set expectations from day one, even during the interview process. I tell candidates: this is how we work — we have small, fluid teams that are born, grow, change, and evolve. If you're clear about that before someone even joins, it's much easier. You make it a condition from the start. The second thing is having plenty of cross-team interaction: teams shouldn't work in isolation, not knowing what others are doing. If you have small teams that also function as part of a larger whole — through shared ways of working, through guilds like a frontend guild or a backend guild — people get to know each other, they talk, and everything flows more easily. And again, if as a manager you can clearly explain why a change is happening, most people will get on board. If the change makes sense and you can articulate that sense, it's hard for someone to genuinely disagree. Sure, they might prefer working with one colleague over another — but that's the reality of work. And knowing that change is frequent actually makes it easier to handle with equanimity.
Luca: Fair point — we're all professionals, we adapt. How do you measure team health? Because sometimes you can sense something's off. How do you spot that and address it?
Luca Fornaroli: I'd say there are two legs: quantitative and qualitative. On the qualitative side, I talk to my tech leads — and really the whole team — a lot. I'm very open: tell me what's not working, what can we do better. I never wait for the quarterly or semi-annual performance review. I live with the team. I need to understand how I can help you move faster — what are the blockers? That kind of ongoing conversation unlocks honest feedback in both directions. Obviously, as teams grow to dozens, this becomes harder, but you scale it: you bring in engineering managers to handle that layer, and you stay on top. On the quantitative side, I use team-level scorecards — delivery metrics, velocity, and so on. But not to label teams as "good" or "bad" — rather to go to a team and say: "You're struggling a bit here. Look at how Team A handles it — they're doing well on this. What can you learn from them?" Teams learning from each other is the real goal. And it feeds back into the reorg question: if you've done a good job leveling standards and encouraging cross-team interaction, moving between teams isn't as jarring because you already know people and the way of working is familiar. Retrospectives also help a lot — not just at the team level, but cross-team. Every month and a half or so I like to run a retrospective with all the tech leads together, because even if each team is autonomous, there are points where they interact, and it's healthy to sit around a table and ask: how can we do better? Did something block you last time — how do we prevent that? I think developers are actually quite well-suited for retrospectives. From day one as a junior, you're writing code that gets reviewed and critiqued. That builds you up, gives you thicker skin for giving and receiving structured feedback.
Luca: True — and also talking across teams, because sometimes a team works well internally but when they work with other teams there's friction. Having that cross-team conversation to smooth things out is really valuable. I have one more question — about building teams at different scales. You mentioned that early on you need people with strong ownership, and later they can help instil it in new hires. What are the most important aspects of team building at different stages — from zero, to a bit more established, to a larger company?
Luca Fornaroli: At the very beginning — startup or early scale-up — ownership and seniority. If you bring on juniors, you'll be spending time teaching them, which you can't afford. You need senior people who can also serve as sparring partners, who challenge you. Early on, you need people who are smarter than you, or at least capable of telling you: "Luca, I hear you, but I'd do it differently." A senior does that. A junior might push back but can't articulate why in a way that moves things forward. You need speed, so: senior, owner-minded people. As the team grows, you need diversity of profiles. You can't have all seniors who all want to become managers — someone needs to actually do the work. So as you scale, you assess: given who you've already hired, what's missing? If you have individual contributors, maybe you need someone with management potential. If you have a manager, maybe you need someone happy to write code for the next few years. Always look for coachability — people who want to understand how the company thinks and works, who come with their own perspective but are genuinely curious to absorb and adapt. One thing I've learned: when you move to a new company, spend the first few months understanding how that place thinks. Arriving and copy-pasting everything you did before almost never works. I look for that curiosity during interviews — when candidates ask not just about the stack, but about rituals, ways of working, how things go to production, how they're tracked. That combination of bringing your own ideas while genuinely wanting to understand the existing setup is what I look for. And once someone is in and has ideas about what to change — I'm the first to want to hear them. Teams and companies should be improving every single day; otherwise you stagnate, burn out, or fall behind. We've seen this very clearly with AI: it's far easier to adopt AI in a new team than to bring it into an established team that has never used it. Where I am now, we're AI-native from the start — much simpler. At previous companies we tried to bring it in later, and it required changing workflows, which meant some of the people you'd hired for their technical depth were suddenly a less perfect fit. AI helps enormously, but it's also a challenge — people have to adapt, and not everyone wants to, especially if they were hired as deep technical specialists and now the nature of that work is shifting.
Luca: We're all adapting to this new way of working, more or less — but I think it's inevitable.
Luca Fornaroli: It's a lot like what happened with the cloud. Companies that were born cloud-native had a straightforward path. Those that had to migrate from on-prem found it very hard. I see the same kind of difficulty in moving from non-AI-native to AI-native.
Luca: Exactly — every major technological shift that changes the way you work requires time to adjust. But I think very few people truly dig in and refuse to adapt. The market eventually makes it inevitable. Luca, I'd like to close with one final question that draws on your personal experience: what's the one mistake you should absolutely never make when building a team?
Luca Fornaroli: It's something I actually did — so this is hard-won advice.
Luca: Even better.
Luca Fornaroli: Early on at Viva Ticket — maybe because I was young, maybe because I never had a mentor — I struggled to hire people who were better than me. I was afraid to. And that, I think, is the single biggest mistake I ever made. You should absolutely put people alongside you who could potentially do everything you do, and do it better. When you make that mental shift — when you commit to hiring people who know more than you — you grow faster, and you get better. At Scalapay I did exactly that: I hired people smarter than me from day one, and everything moved so much faster. It also frees up your time. As a lead — whether on the tech or product side — you need time to think, to jump between different tables, to work with the business, to do a hundred things. If you have people around you that you trust completely, people who you know will do their job better than you would, you can focus on the rest with a much lighter heart. That's the advice I'd give to my 26-year-old self, when he started building his first team.
Luca: That's a great point — and it makes sense that when you're younger you have a bit more insecurity, which makes it harder to internalise this. But it's genuinely excellent advice. Luca, thank you so much for sharing your experience. It was really fascinating to hear how you think about building teams and what the key ingredients are.
Luca Fornaroli: Thank you Luca, and thank you for having me — and a big hello to everyone listening!