Interviews in Space: Meet Luis Andani, VP of Engineering @ Hurdle.bio
Hey Reader,
I am excited to share a conversation with Luis Andani, VP of Engineering Leader at Hurdle, for this week's newsletter.
Luis is a highly experienced Engineering Leader with over ten years of expertise in scaling engineering teams and driving growth for companies. Most recently, he successfully led different engineering functions at HelloFresh through a hyper-growth phase, enabling the company to expand rapidly.
In the last year, he worked on setting up the Engineering function at Hurdle, a Diagnostic-as-a-Service tech company. He is passionate about technology, building teams, and... retro arcade games.
I've had the privilege to work closely with Luis for almost 1 year, and I am incredibly grateful he said yes to my Interviews in Space initiative.
Hey Luis, thank you for agreeing to this and supporting the Platform Space! Do you want to tell us a bit about yourself and your journey into Engineering Leadership?
I was born and raised in Spain, currently living in Berlin for the past seven years. As a child, I was fascinated with computers and video games, so I discovered programming by tearing computers apart and putting them back together in my early days. Usually, that was my mother's computer, so I think she wasn't a big fan of that!
I started my Engineering career as a teenager, freelancing and building websites for companies. Figuring out that's something I liked, I then took the traditional route, studied computer science, and became an engineer.
My first steps into leadership happened around 2013 when I joined a startup as the first engineer and stepped into a leadership role as the team grew. I enjoyed working with people, and based on the positive feedback, it looked like a natural progression for me.
Later, when I joined HelloFresh, I started again as an Engineer and grew into different leadership roles, from managing one team, to a tribe, to multiple tribes reaching a point of having around twelve teams during a hyper-growth phase.
This journey taught me the importance of natural growth but also taking advantage of opportunities as they come.
And when you look back at your career, particularly the last ten years, what do you think are the key qualities of an effective Engineering Leader? Let's say you have to pick the top three; what would those be?
It is challenging to pick only three; therefore, I will leave aside technical and strategy skills. These are still very important but more straightforward to learn. So instead, I will pick my top three soft skills.
A critical trait for leaders and managers is adaptability, especially when working with a diverse group of people who bring different perspectives, needs, and ways of working. Unlike working with computers and systems, which can be easily fixed, people are complex and don't need fixing, especially by a leader or a manager. What you need to do is create an environment that enables them to succeed and become the best version of themselves.
Empathy and strong communication skills are also crucial for effective leadership. Being able to clearly share your ideas, provide feedback, and listening will help you understand and motivate your team members, which will lead to better results.
Last, empowerment. All my leader role models have been always people that empower the people around them. Those leaders had the skills to provide the support, resources, and autonomy for other people to succeed, which created a culture of commitment and ownership.
Following from that, how do you approach building high-performance Engineering teams?
I take a pragmatic approach and avoid reinventing the wheel. There is enough research out there already to learn from. As an example, Google did some fantastic research on high-performing teams, known as Project Aristotle. Those learnings together with the science of Lean Software, DevOps and Agile, provide you with a lot of practices, capabilities and alternatives to test, measure the impact and learn (iterate over and over).
Taking the definition from Google, they define a high-performing team as a “group of goal-oriented professionals who are experts in their fields and responsible for planning, executing, and achieving outstanding results”. That's such a simple yet effective way to think about what high performance means.
Then, my approach is about empowering the teams to create an environment where I can give them control/autonomy. I’ll try to summarize some principles I follow to achieve this on the teams:
Set an empowered and accountable leadership for the team.
Making sure teams have all the competencies they need to be autonomous (cross-functional), if not, then work on building them.
Work on creating a culture of continuous learning where people develop and grow.
Provide clarity by having clear structure, roles, and goals.
Agree on how we will measure and show progress and performance in the team.
And last, supporting them on building a shared context with the rest of the department and organisation. Silos aren't helpful, and transparency is vital.
Speaking of cross functional, you've worked both as an Engineer and now as an Engineer Leader and interacted with many product folks. What challenges have you seen working with product managers in the past?
In my experience, the biggest challenge I saw and experienced has been misalignment. This happens when you have product and engineering teams working separately, not talking enough to each other, and wanting to go in different directions. For me, it's essential that all different functions (product, engineering and design) work together, present themselves as a team and avoid competing with each other.
The impact that I saw in the past from that misalignment was not having unified objectives, forcing each discipline to push and try to prioritise their objectives. This lead to conflicts, confusion and a lack of cohesion in the teams.
If I think about the moments when my teams were performing at their best, I can always recall that Product, Engineering and Design were working together as a team at all the levels.
I couldn't agree more. Building from that, what do you think the ideal collaboration looks like?
It starts by setting the right expectations and understanding how you will work together. It's important to share your values, ways of working and understand the values and ways of working of your colleagues. From the beginning, establish a relationship of trust and keep building on top of that. Then, efforts should be invested in maintaining this relationship and working well together.
Other elements of good collaboration are communication and alignment. Communicate as a team and ensure everyone is aligned and working towards the same goal. This will also positively impact the product itself, and the organisation will perceive that the team is working together as one group.
You’ve mentioned communication, what advice would you give product managers when communicating and engaging with Engineering Leaders?
Assuming that you have tried what I mentioned above about good collaboration; when communicating and engaging with Engineering Leaders, making sure that you are sharing the context and data behind your requests is essential. People want to know the why and have a full understanding, especially if there will be a need to make a decision, push back or prioritise a discussion.
Going back to adaptability; adapting your communication to the different individuals is key. Some Engineering leaders may be more open to listen than others, so it's important to understand their expectations and communication style. As a Product Manager, investing in building a great relationship with your Engineering counterpart or the Engineering Leader is always a good idea.
That’s great feedback, thank you. Communication is an area I often find challenging for a Platform Product Manager because you need to communicate effectively with technical and non-technical audiences. You have to adjust the level of technical detail based on your audience.
Changing topics a bit, but not far off from Platform, I want to ask you - What is your advice to Platform teams to approach scalability and performance issues on the Platform, and how should they factor it into product decisions?
First, having a solid foundation and understanding of your systems and infrastructure is crucial. It will enable you to identify issues, resolve them quickly and manage scale effectively because you can make better decisions about where to invest.
Therefore, prioritising Observability is a foundational step toward achieving this goal, in my opinion.
This includes having excellent monitoring, logging, alerting, and tracing capabilities to enable the teams to take ownership and identify/resolve issues efficiently by themselves, therefore being more autonomous.
Do you see Observability as a technical foundation for scale?
Yes, definitely. If the teams don’t have an excellent view of the health of their system, they won't know what's broken. You cannot necessarily build good Observability retroactively, so I'd include this as part of the Platform foundations. By providing good observability to the teams, you will also enable the Platform Team to focus more on innovation rather than supporting the teams to debug their services or applications. So yes, I am a big fan of good Observability.
As you touched base on Observability, how do you measure the success of Platform initiatives?
Metrics and defining how success looks like for an initiative are essential in general, but especially for the platform team. As enablers, they must understand how to support teams to move faster and put a lot of focus on developer experience, as I expect platform teams to be developer-centric.
If I’m an engineer, for example, measuring how autonomous and happy I am, doing my work, and how the Platform teams enable me, would be great metrics. Other metrics that should be considered are reliability and performance.
Thank you for not explicitly calling out the DORA metrics! Although we should have a good view of those too!
… finally, shall we try to settle the ultimate debate about how technical or non-technical a Platform Product Manager should be? What is your take on that?
I am going to bring up adaptability again! To answer your question, my experience working with different product managers in platform teams has shown that someone technical is often needed.
Technical knowledge can make things easier when collaborating with engineering leadership as well as with the team. However, working with someone who is not technical is still possible, as long as they have the potential to learn to adapt to a more specialised space, like Platform. You are a perfect example of a product manager who didn’t come from an Engineering background but demonstrates every day that can run technical initiatives independently.
So, non-technical individuals can be successful in this area if they have good self-awareness, the potential, are willing to learn and grow, can effectively leverage their skills, and have an environment that supports them.
In closing, I have asked Luis for recommendations of books, podcasts and newsletters that he likes/recommend:
I’m not that into Podcasts, but maybe thinking about Product Management in the Platform space, some books I would definitively recommend: (it’s always difficult to filter just 2-3):
Accelerate: Building and Scaling High Performing Technology Organizations + Team Topologies: Organizing Business and Technology Teams for Fast Flow - Matthew Zkelton, Manuel Pais
The Goal: A Process of Ongoing Improvement - Eliyahu M. Goldratt
The Five Dysfunctions of a Team: A Leadership Fable - Patrick Lencioni
And in general any book from Will Larson and Gene Kim.
In terms of Newsletters:
Thank you, Luis! As usual, it’s an absolute joy to talk to you about all things Engineering.
See you next Friday!