At our recent Leadership Lessons AMA, we sat down with Leandro Fernandez, Engineering Manager at Meta, formerly of Uber, and a software leader with 16 years of experience across traditional enterprises and Silicon Valley-style big tech.
Leandro joined us at 3am from San Francisco (yes, really) to share what he's learned about the transition from developer to manager, building resilient teams, and navigating the AI shift in engineering.
🎥 Watch the full conversation on demand - or dive into the highlights below.
You've said there wasn't one single 'shifting moment' into leadership, so what did the path actually look like?
I think particularly in tech, there's not a clear distinction between being a manager and being a leader. Some of the best leaders I've seen were individual contributors. What I can say is that I always had this impulse to own more and more responsibilities, it's one of my toxic personality traits, I guess. I like being useful.
The shift from IC to manager was a different story. In more traditional companies, management felt like a necessary step for growth and you'd see a lot of unhappy managers as a result. When I moved into big tech and saw the 'Y-shaped' career path where you can grow technically without ever becoming a manager, it changed how I saw the role entirely. That's when I started to think: maybe this is actually for me.
Many engineers fear losing their technical credibility when they move into management. How do you stay technically grounded?
The fear is real. I think most managers feel it to some extent. My approach, which is far from ideal, is to compensate by doing coding interviews. I try to do at least a couple a week. It keeps me in contact with code, and I have to solve the problems myself before I can fairly evaluate someone else on them.
But the more important thing is staying sharp at a higher level of abstraction and understanding systems, how they relate to each other, how they solve business problems. You need to be able to ask meaningful questions, understand the trade-offs being made. You don't need to be the person who knows the most on your team. You can rely on your tech leads. But you do need to engage meaningfully.
Can you share a project that didn't go as planned, and what you took from it?
Early in my career, we spent months on a large infrastructure rewrite. We were convinced it was necessary, the code wasn't in great shape, new use cases would be hard to support. But when we presented it to a senior director I really respect, she pushed back hard. Not on the design itself, but on the 'why'. We couldn't clearly articulate the business benefit. We were solving for a future that was uncertain, with trade-offs we hadn't even tried to measure.
Looking back, dropping the project was the right call because the situation we were designing for never came. The lesson I carry today: be wary of early optimisations, and be very conscious of work you can't justify. If you can't clearly articulate the benefit, that's a big smell.
Did imposter syndrome show up for you — and what did you do about it?
It's been there, and honestly it intensified as I became more successful, which doesn't make sense on the surface. The external world is validating you by giving you more opportunities, but internally you're interpreting it as more pressure, more reason to doubt.
The way I deal with it is to first acknowledge it and identify its patterns. Being self-aware is a super powerful tool. Then I try to anchor myself in objective reality: if people around you – people who have watched you over time – keep giving you opportunities, that's a signal you can trust. You can't fool everyone, every time.
What does good leadership look like to you?
Above all, I value empathy and cool-headedness, the ability to perceive human life in all its complexity. How a leader behaves in stressful situations, how they communicate under pressure. It's not about being naive, it's about maintaining composure and transmitting that to the people around you.
But empathy on its own isn't enough. One of my managers at Meta taught me how to balance that warmth with the right level of rigour and urgency and to do it in a way where you're asking people to sign up to a challenge rather than imposing something on them. If you're working with people who care about their careers and want to solve hard problems, they actually appreciate being pushed. That balance of keeping people's humanity intact while driving real results is what I try to live by.
What's your biggest piece of advice for teams adopting AI coding tools?
Here's the mindset shift I think teams need to make: in some companies, over 90% of code being produced is now written by AI. That means the main actors on your codebase are no longer humans, they're AI systems. So we need to stop designing systems for humans to work on them, and start designing systems for AI to navigate them.
A concrete example: leaving rich markdown files in your codebase that explain the architecture. When I've seen teams do this well, the quality of AI-generated code improves dramatically. But that's just one manifestation. The bigger challenge is for teams to ask: what does an AI-friendly codebase actually look like? That's the experiment worth running.
And for engineers worried about being replaced by AI?
I have full empathy for the concern because it's a valid one. But I'd invite people to see this moment as an opportunity. Every major revolution in business has rewarded those who embraced it early. And I don't think our profession becomes irrelevant, far from it. The most critical work engineers do isn't writing code. It's making technical decisions, understanding systems, ensuring things run reliably. AI isn't close to replacing that. So if you can be one of the people making the most of these tools, there's a tremendous opportunity waiting.
Want to hear more from Leandro? Watch the full Leadership Lessons AMA on demand, including live audience Q&A on imposter syndrome, managing teams through uncertainty, and how engineering manager roles might look one year from now.