Why You Shouldn't Encourage Heroism In Your Team | Ítalo Vietro, Head of Engineering, Parloa
This week, I spoke with Ítalo Vietro, Head of Engineering at Parloa. Over his career, he’s led engineering organizations of 100+ people across companies like Babbel, Urban Sports Club, and N26.
At HelloFresh, he led the transformation from monolithic PHP to cloud-native Go services while scaling the team to over 100 engineers.
Takeaways
Hero cultures where brilliant individuals consistently save the day destroy team learning. Teams stop taking ownership of incidents because they trust the hero will appear.
Junior engineers often handle failure better than seniors. Juniors stay curious and learn quickly, while seniors can struggle when their established beliefs get challenged.
Engineers at Parloa are no longer the primary producers of code. LLMs write the initial code, making engineering judgment about validating output the key differentiator.
Shadow on-call pairing costs more but forces knowledge sharing across domains. Former heroes become mentors when rotated through different incident response roles.
Yassine: Back in 2018, you wrote about staying technical as an engineering leader, saying “I truly believe Engineering Managers should stay in touch with coding.“ As your leadership progressed through larger orgs at Urban Sports Club, Babbel and Parloa, does that 2018 advice still hold? Or did something break as you scaled? Is there a point where a leader staying technical actually becomes a problem?
Ítalo: If anything, that belief has only gotten stronger. There’s a big shift happening in our industry right now, and having EMs who are genuinely technical is more valuable than ever. But it’s important not to confuse being technical with making all the technical decisions. That doesn’t scale, and it creates an unhealthy dynamic for the team.
It’s very common for new EMs to fall back into being the most senior engineer in the room. It feels safe. You can jump into the code, make the call, save the day. But real leadership requires something harder: hiring engineers who are better than you, leaving your ego behind, and building a team that can operate without you. That’s where the magic happens.
For me, an EM has three core responsibilities: People, Delivery, and Technology.
People is coaching, hiring, and helping individuals play to their strengths.
Delivery is how you help the team actually ship value to customers consistently.
And Technology is about being technical enough to challenge your team when needed, ask the right questions, understand trade-offs, but also trust them to make the decisions. You don’t have to jump in and solve the problem yourself. In fact, letting the team figure it out often teaches you something new.
And now with AI and LLMs changing how we build software, being technical as an EM is even more important. You need to understand what this new paradigm means for your team, how it can accelerate them, and where the risks are. You can’t guide a team into an AI-driven future if you don’t understand the terrain.
So yes, “engineering” is in the job title for a reason. Your role is to bring the value of engineering into the room, to connect people, process, and technology in a way that lets the team shine. You’re not the hero; you’re the conductor who trusts the orchestra to play brilliantly.
Yassine: In your Designing for Failure talk, you explored systems designed to run on essentials when failures happen. Do you think about designing engineering teams the same way? What’s the team equivalent of “multiple batteries” or “running on essentials”?
Ítalo: Absolutely. A healthy engineering team should keep running smoothly even when people are on vacation, sick, or facing unexpected challenges. But building teams that can do that doesn’t just “happen”, it requires being intentional about who you hire, how you coach, and how you define the purpose of the team.
For me, everything starts with purpose. A team needs to know why it exists. Teams that understand their role in the product and how they create customer value behave differently, they make better decisions, they collaborate more effectively, and they’re simply more enjoyable to work with.
I’m also a big fan of Team Topologies as a framework. It helps us think about team boundaries and interactions in a way that actually solves organizational problems rather than creating new ones. And if you look closely, this is just Conway’s Law in action: our systems reflect our communication structures, and our communication structures shape our systems.
“Any organization that designs a system will produce a design that mirrors its communication structure.” — Melvin Conway
When I think about the “multiple batteries” analogy, I translate it into two qualities for teams: reliability and resilience.
A reliable team consistently delivers customer value, improves over time, and is predictable. You know what to expect from them, not because they work harder, but because they work smarter and communicate clearly.
A resilient team doesn’t rely on a single superstar. Success comes from a balanced group of skilled individuals who can step in for each other and keep things moving during tough times. That’s the real marker of a mature engineering organization.
Yassine: When you’re interviewing engineers, what tells you: “This person will handle failure well and learn from it” versus “This person will be defensive or burn out when things break”?
Ítalo: This is something you rarely know after a single 60-minute interview. It usually takes a few conversations to really see how someone thinks about failure.
What I’ve seen over the years is interesting. Junior engineers often handle failure surprisingly well, they’re curious, open, and quick to learn. Senior engineers sometimes struggle more because they’ve built strong beliefs and may get frustrated when those beliefs are challenged. Not always, of course, but enough to notice a pattern.
The best approach I’ve found is to go deep on situational questions. I ask candidates to walk me through real examples of project failures, production issues, team conflicts, and I dig until I understand how they processed it, what they learned, and how they changed their behavior afterward. You can learn a lot from how someone tells that story.
And then there’s communication, which is massively underestimated in engineering hiring. I want engineers who can explain complex topics simply, who can articulate what went wrong and how they fixed it, and who can do that calmly even when things break. Strong communicators almost always handle failure better because they know how to externalize the problem rather than internalize the stress.
Finally, culture fit is not a cliché, it’s real. I’d rather pass on an extremely strong technical candidate who brings the wrong attitude than hire someone who fits our culture, collaborates well, and grows fast. Skills can be taught. Culture is harder to fix.
Yassine: You also mentioned moving from “ad-hoc heroics” to “transparent goals and steady, compounding gains” at Urban Sports Club. That phrasing suggests you had a pretty clear picture of what needed to change. What did “ad-hoc heroics” look like in practice, and what did you build, like actual rituals or frameworks, that gave people a different way to win?
Ítalo: 100%. When I arrived, there were a few brilliant individuals who would jump on every problem or incident and save the day. For the business, that looked great, low MTTR, fast resolutions. But for the teams, it was terrible. Knowledge didn’t spread. People lost curiosity because they knew someone else would eventually jump in and fix it. Some teams even stopped taking ownership of active incidents because they trusted the “hero” to appear… and honestly, they were right. That’s exactly what kept happening.
I’d seen this pattern before, and I didn’t want that culture again.
One of the first changes I made was pairing on-call shifts, also known as shadow on-call. Yes, it’s a bit more expensive, but absolutely worth it. It forces knowledge sharing and helps people build confidence in areas they wouldn’t normally touch. We also introduced a proper incident-response process with clear roles, Incident Commander, SME, scribe, comms, so people could be trained and rotated. And here’s the fun part: the former heroes didn’t always get to be the SME anymore. Sometimes they had to be the IC or the scribe. That shift alone started breaking the cycle.
There’s honestly no better way to onboard yourself into a new area than stepping into an active incident where you know almost nothing about the domain but you do know how to keep a system operating. Coordinating an incident forces you to learn the essentials very quickly.
And those “heroes”? They eventually became mentors instead of firefighters. But it didn’t happen just because we changed a few processes, old habits stick. We needed real coaching. We needed these people to understand their value in a new way: not as the fastest problem-solvers, but as multipliers. They started running post-mortems, hosting knowledge-sharing sessions, and helping level up the entire team. Some loved that shift, some didn’t, and that’s just part of changing culture in a larger organization.
Every company’s hero culture has its own flavor. What worked for us might not map perfectly to another place. But a good starting point is always the same: identify who the heroes are, understand why the heroics happen, and figure out whether they’re enabling others or unintentionally holding the whole team back.
I talk about that in a podcast I used to host with four other colleagues of mine called the Critical Channel. The episode name is, Just Call Superman. Give it a listen!
Yassine: You recently joined Parloa, a “mission-critical AI” company, as Head of Engineering. What surprised you most during your first two quarters? What assumption from “traditional” software engineering just didn’t apply?
Ítalo: What surprised me most?
Honestly, how quickly Parloa managed to feel like the most impressive organization I’ve worked at so far. Not just because of what we’re building, but because of how we’re building it, and the people doing it. The team is incredibly strong, open-minded, and genuinely willing to experiment.
It reminded me of that feeling many of us had when we first started programming: the thrill of discovery, the satisfaction of learning something new every day, trying things, failing fast, adjusting. Parloa has that same energy, but now amplified by the power of AI.
The biggest “traditional engineering” assumption that didn’t apply?
That we are the primary producers of code. We’re not. A huge percentage of our system is built through us, but not by us, LLMs sit at the core of our development process. Everything from PRDs to ADRs, from defining epics to breaking work down into meaningful value chunks, all the way to writing the initial code, is fundamentally different from any environment I’ve been in before.
Here’s how our workflow actually looks. It all starts with a product idea. That becomes a PRD, usually refined with the help of an LLM. From there, the team creates an ADR to outline the architecture. Then everything moves into what we call the Kitchen, a set of crafted Claude skills orchestrated through multiple agents.
The Kitchen handles nearly everything: making sure commits follow our conventions, generating PRs, enforcing hexagonal architecture, adding observability, maintaining operational excellence, and many more things we’ve built to make our engineers’ lives easier. Agents take an epic, execute on it, and open PRs.
Those PRs go through an AI-first review stage focused purely on finding issues. Then humans step in and do the first real review, which must be thorough, because our expectations are high. And of course, we still keep strong quality gates, just like in the pre-LLM world.
Fun fact: we call our engineers Chefs. You “earn your Parloa branded hat” once you’ve either built something great with our skills or contributed to the Kitchen and shared your learnings in an internal event we call “Show Me How You Cook.”
The next step for us is bringing these agents into production. We want them not only observing systems at scale, but also self-healing them when necessary. And we’re getting close.
LLMs are powerful, but they don’t replace engineering fundamentals. If anything, they make those fundamentals even more important. You need to really understand software engineering to get the most out of this new agentic world. We can’t blindly accept what LLMs produce, we have to use our judgment to guide them, correct them, and multiply our impact.
Yassine: Does leading engineering at an AI product company change your non-negotiables when hiring? Are there traits or qualities that you used to be “nice to have” that are now absolutely essential, or things you used to require that don’t matter as much for you anymore?
Ítalo: Not really. I still look for engineers who understand the fundamentals of software engineering extremely well, distributed systems, reliability, concurrency, data modeling, the stuff that doesn’t magically disappear because we now have LLMs. These foundations matter even more in an AI-driven environment.
In the past, we often optimized for engineers who had deep expertise in a specific language or tech stack. That mattered because rewriting or migrating systems was expensive. Today, that’s less relevant. You still need to understand how your language works, of course, but LLMs can fill in a lot of the mechanical details. If you really know the fundamentals, the language becomes just a tool, and honestly, a much cheaper one. Rewriting a service is no longer the multi-week ordeal it used to be.
Our hiring process reflects that. We explicitly encourage candidates to use AI during the interviews. We want to see how they approach problems, how they collaborate with an LLM, how they question its output, and how they refine their reasoning. That interaction tells us far more than watching someone manually implement an algorithm on a whiteboard.
And of course, communication still matters, maybe now more than ever. You need to be able to explain what the LLM produced, why it makes sense, or why it doesn’t. Being able to think clearly, validate assumptions, and articulate decisions is becoming an essential skill, not a bonus.
So in short: the fundamentals are still non-negotiable, but the way you apply those fundamentals, especially in collaboration with AI, has become the new differentiator.
Yassine: In light of all ongoing conversations around AI in engineering, what aspects do you think we are not talking about enough?
Ítalo: It feels like most discussions today swing between two extremes. On one side, you have people saying engineering won’t change much and AI is just another hype cycle. On the other, you have people predicting we’ll all be out of jobs in five years. Neither of those really get to the heart of what’s actually happening.
What we’re not talking enough about is that we’re shaping the future of engineering for the next generation. If you pause and think about it, that’s a big deal. The same way Margaret Hamilton and her peers defined what software engineering meant for our generation, we’re now laying the foundations for how software will be built for decades to come. This is not a tooling shift, it’s a generational one.
And with that comes responsibility.
We move fast with AI, but governance and good judgment still matter a lot. Hallucinations still happen. Cost matters, both economically and environmentally. LLMs are powerful, but they’re not cheap, and we can’t pretend compute grows on trees. Until we figure out energy consumption at scale, there’s always going to be this tension we need to navigate.
At the same time, I think there’s an enormous opportunity here. We can make software engineering more fun, more creative, and more accessible than ever before. If we guide this transition well, we’ll end up with a generation of engineers who are not only capable but inspired, people who use AI as leverage, not a crutch.
And personally, I’m grateful to be part of shaping that future.
📚 Ítalo Vietro’s Go-To Resources:
3 people you follow and recommend:
Lena Reinhard - A great leadership coach with lots of experience. (By the way, you can check out my interview with Lena here.)
Pedro Gil Carvalho - A dear friend of mine who shares his insights about engineering leadership.
Gergely Orosz - The creator of Pragmatic Engineer.
A podcast I make time for:
The Infinite Monkey Cage - I have a fascination for space and honestly like to listen to Brian Cox explain it for hours.
Newsletters I rarely skip:
Books that shaped my thinking:
The Culture Map - Being an immigrant, dealing with multiple cultures and being in a leadership position is not easy. This book helped me understand how other people think and work.
Thank you Ítalo for your time and insights!
This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.