In Part 1, Fabrizio Romano shared his journey with Python, talking about the language’s strengths, its limitations, and how it continues to evolve across tools, ecosystems, and developer mindsets. In this second part of our interview, we turn to his experiences as a software development leader—from his transition into management to his team culture, decision-making, and coaching philosophy.
Development Manager at Sohonet and long-time Python programmer, Fabrizio brings more than two decades of experience to software engineering leadership. While many know him as the author of Learn Python Programming, Fabrizio's approach to management is rooted in empathy, communication, and personal growth.
Q: What led to your transition into a leadership role?
Fabrizio: I had been working as a developer for a long time, and after a point, writing code didn’t give me the same satisfaction it once did. I found myself more drawn to helping people grow. Even before I formally became a development manager, I was leading teams and mentoring developers.
The experience that really shaped me happened years ago when I was teaching mathematics. A young student struggled with adding fractions. Everyone had given up, assuming she just couldn’t get it. But when I explained it using apples and bananas, she finally understood. That experience taught me that people learn differently, and you have to find the right explanation for each person. I try to lead with that same mindset today.
Q: What are the biggest non-technical challenges you’ve encountered in software teams?
Fabrizio: The real challenges in software development aren’t technical. At Sohonet, we work on cutting-edge tech for the media industry, and yes, some parts are complex. But most of the work—APIs, platforms, saving data—is not the issue. It’s the people side: miscommunication, mismatched expectations, and lack of shared process.
If 11 people on a team all have different understandings of how our process works, then we waste time. I might move a task in a certain way that interrupts someone else’s workflow. These things accumulate. So I work hard to make sure everyone shares the same mental model of how we operate.
Q: You've said you prefer values over rigid processes. What does that look like in practice?
Fabrizio: I’ve seen teams run with strict rules, lots of constraints, and it can work for some. But not mine. I set up a process that’s flexible and based on values—things like being open, respectful, committed, courageous. When you're unsure what to do, you can use those values like a litmus test.
This is similar to how spiritual disciplines work. In Reiki, for example, there are five principles—don’t get angry, don’t worry, be grateful, work hard, be kind. If you ask yourself, “Will this action make me more angry or more grateful?”, it helps guide behaviour. In teams, the same logic applies: let values shape your actions instead of just checking boxes.
Q: How do you help your team handle stress and emotional setbacks?
Fabrizio: Stress is universal. Everyone’s always trying to deliver faster, and that pressure builds up. One of my jobs is to pay close attention—to what people say, how they act on Slack, their body language in meetings. If I notice something’s off, I check in.
I’ve taught half my team meditation techniques and worked with many of them one-on-one. When people are upset or angry, they activate the sympathetic nervous system—the fight-or-flight response. That leads to tunnel vision, shallow breathing, and poor decision-making.
Some think that accepting a frustrating situation means passivity. But acceptance isn’t surrender. It’s choosing to remain calm and then respond intelligently. A relaxed mind is a creative mind.
Q: How do you see AI tools like GitHub Copilot affecting developer workflows?
Fabrizio: They're very helpful. I got everyone on my team Copilot licenses. It’s especially good for repetitive tasks—like hardcoding test cases or writing boilerplate.
But I always tell my team: don’t let it replace your thinking. Part of our job is smashing our heads against tough problems. That’s how you develop creativity, problem-solving, and memory. Copilot can assist, but you need to stay sharp. Use it, learn from it—but don’t let it think for you.
Q: What’s your view on tooling and tech stacks? Are you opinionated about what teams should use?
Fabrizio: No, and I think strong opinions can be dangerous. If you only know one tool, every problem starts to look like a nail. That’s not effective.
I want my team to find the best idea, not my idea. We debate things—FastAPI, Django, Flask—and decide what’s right for the context. The diversity of viewpoints leads to better solutions. A developer should choose tools based on what the problem needs, not what they’re comfortable with.
Q: What advice would you give to developers considering a leadership path?
Fabrizio: Don’t do it just because it’s the next step. Leadership isn’t about being a senior developer—it’s about people. And people aren’t machines. If you’re not passionate about helping others grow, you’ll struggle.
You can train as a mentor or coach, but you need that core desire to help. I always say, “People don’t leave companies—they leave managers.” So if you’re thinking of moving into leadership, ask yourself: do I want to support others first, before anything else?
To hear the full conversation—including Fabrizio Romano’s reflections on Python’s evolution, its strengths and trade-offs, as well as his insights on leadership, mentorship, team dynamics, and the role of AI in modern development—you can watch the complete video interview here.