Fast forward to today, and this newsletter just keeps growing. 3,000+ readers in just 8 months. Thank you for being part of it! To make it even more special, we have a guest this week:
(Senior Data Science Manager at Skyscanner) sharing hard-earned lessons on leadership, growth, and impact.At Skyscanner, he explains how choosing between management and the staff IC path comes down to where you get your energy, enabling people vs. scaling through technical leverage. He shares how rebuilding an underperforming personalization team led to their first big win in years, proving leadership is often about people, not tech.
But enough from me. Here are Jose’s answers from our conversation.
1) If you’re a Senior Individual Contributor deciding between pursuing a Staff path or moving into management, how do you recommend making that choice? How did you personally recognize which path was right for you?
For me, the choice between management and the staff or principal path comes down to what gives you energy. You cannot really do both.
If you go into management, your impact shifts away from coding and more into coordination, planning, and people development. You still need to understand the technical details, but you will not be in every pull request or every brainstorm. You also stop getting the same kind of feedback you used to as an individual contributor, but, you don’t miss it. You actually feel proud when your direct reports get strong feedback, because you know you have created the conditions for them to thrive.
Another part is growth. A promotion or lateral move does not just happen. It takes months of planning and shaping opportunities. You are not doing the work yourself, but you are guiding the narrative, and when it comes together it is incredibly rewarding to know you played even a small part in someone’s journey.
On the principal IC side, the impact looks very different. You are solving higher-level technical problems, setting architecture, unblocking teams. You might design a framework that entire departments depend on, or connect the dots across multiple squads. You do not always carry things through to the end, but you know your judgment is multiplying other people’s work.
Of course, you give things up. You are not embedded in a single team anymore, and you may miss the satisfaction of building side by side and shipping something directly. But what you gain is that ripple effect: knowing your technical decisions shape dozens of projects, and that without you, whole streams of work might stall. That is the kind of impact that makes the principal role rewarding.
2) How do promotions typically work for engineering managers (e.g. M1 -> M2, M2 -> M3)? Is it valuable to explicitly express your aspiration to advance to your manager like in IC roles?
At Skyscanner, we do not really label roles as M1, M2, M3, but there are equivalents. For data science, it is more like Manager → Senior Manager → Director. Beyond that, Senior Director and VP levels do exist, but they are rare in smaller disciplines like ours (we are around 60 data scientists in total).
The general pattern is the same though: scope and complexity increase with each step. A manager leads a single team, focusing on delivery, hiring, and wellbeing. A senior manager oversees multiple teams or managers, and spends more time on cross-team alignment and stakeholder relationships. A director is operating at an org level, shaping strategy across domains.
What is unique in our discipline is how you get there. All of our data science managers started as individual contributors. You had to be an excellent IC before moving into management. But that transition can feel strange at first because, where you were a strong individual contributor, now you are suddenly a junior again in management, relearning a whole new skill set.
It is also rare that we hire managers externally. Culture is very important at Skyscanner, and managers set the culture for their teams. Get that wrong, and the whole group can suffer. By moving people internally, we have much higher confidence the culture will remain strong.
Finally, timing matters. For someone to move into management, there first needs to be a spot — either an existing vacancy or a new team being built in the next 6 to 12 months. Then it can happen in 2 ways: sometimes individuals raise their hand, other times existing managers spot potential leaders and start conversations to explore willingness and fit.
3) Describe a difficult people-management case. How did you diagnose root causes, what actions did you take (including HR involvement), and what were the measurable results?
One of the toughest situations I faced was when I was asked to support and step-in our Hotels Personalisation team. The team had not shipped a successful model in more than a year, and credibility with stakeholders was very low.
When I audited the team, the biggest issues were on the people side. The manager was not really managing (no structured one-to-ones, no planning, no stakeholder relationships). The senior data scientist was technically brilliant — she could build PyTorch models in her sleep — but she could not diagnose what problem needed solving. She was solving the wrong things, and that meant we were never going to win.
The outcome was painful but clear. After aligning with my director, we made the call to rebuild the team. We let the existing group go and brought in new hires internally who could both lead and focus on the right problems. At the same time, we simplified the technical system to give them a clean foundation.
6 months later, that rebuilt team shipped the first big win in hotel ranking in years. The lesson for me was that sometimes it is not about technical. And as a manager, you need to recognise when the people you have are simply not a fit for the challenge in front of them.
4) With AI tools making it easy to solve Leetcode-style problems, how do you see technical interviews evolving at Skyscanner?
At Skyscanner we actually do not use Leetcode-style problems for data science roles. What we do instead is much more about testing how people think.
The first stage is usually a short technical screen in Python or SQL. But the goal is not syntax. The idea is seeing how candidates translate a question into code, even if it is pseudo-code. We want to see reasoning, not memorisation.
The second step is a business case. We pick a problem we have solved before, so we know the trade-offs and decisions involved. What we look for is whether they naturally ask the right questions, form reasonable hypotheses, think about feature importance, and outline a plausible approach. Because we went through the real journey, it is easy to see who is thinking in the right direction.
We sometimes add an A/B testing case too. The interviewer plays the role of a product owner (often a deliberately difficult one) who pushes for bad testing decisions. The candidate’s job is to design the experiment properly, analyse results, and hold their ground. It tells us a lot about how they balance technical rigour with stakeholder pressure.
Could AI tools help with some of this? Maybe (or probably). We have seen people try. But it is usually obvious when someone is repeating what an AI told them instead of actually thinking through the problem in the room. In fact, generally, those who get everything right are treated suspiciously because we have seen great candidates not nailing every single question. Reasoning, communicating, and applying judgment is very hard to fake.
5) If you were starting your engineering career today, what would you focus on to build a strong foundation for long-term growth?
If I were starting my career today, I would still build the foundation in two layers: timeless fundamentals, and adaptability.
On the fundamentals side, I would still do something like Andrew Ng’s classic machine learning course: the basics of modelling and statistics have not gone away. But I would go further: I would deliberately put myself into data wrangling work. Volunteer for the ETL tasks, learn how to build a star schema database, debug data logs. Everyone wants to build models, but the reality is that without clean, reliable data, those models are useless. Being the person who understands both the data engineering and the modelling makes you indispensable.
On adaptability, I would take advantage of the fact that AI now lets you learn by doing at an incredible pace. Fifteen years ago it was much harder to build something end-to-end on your own. Now you can. So I would consume courses, but then I would immediately put them into practice: build dashboards, spin up an MLops pipeline, try a simple mobile app, train a deep learning model. The point is not to be perfect, it is to learn by building.
And finally, I would invest early in communication. The people who grow fastest are not just the best coders, but the ones who can explain trade-offs to stakeholders, collaborate across disciplines, and influence decisions. That combination of technical breadth, adaptability, and communication is what sets you up for long-term growth.
Thank you Jose for sharing these lessons!
If you found this post useful, let me know in the comments or with a like. It’s the best feedback I could get. I’ll keep bringing more industry leaders to my newsletter.
Until next time,
Adlet
Connect with me on LinkedIn, just use the button below. I read every message. Cheers!
 | A guest post by
|
Great reading Jose!!