5 mistakes I see new managers make in their transition into leadership roles.

Break free from the individual contributor mindset. You are a manager now.

Photo by Jose Aragones on Unsplash

You have been working for years as data scientist, going from junior to senior. Over the course of these years, you have a great delivery track record, you tend to solve the biggest problems and you are trusted member of the Data Science discipline when it comes to technical solutions. There is an open position to lead one of the Data Science teams, and the business has identified you as a candidate to lead it.

You feel it is an exciting opportunity! You have actually been reading a lot about management lately and believe it can be an area you can grow in. Not only that, but you have been lucky to work for 1 or 2 great standout managers, who have become inspirations for the leader you hope to become. You even feel you understand some of the trade-offs this transition will require.

Yet, despite all the preparation, no amount of reading or inspiration can fully convey what it feels like to move from individual contributor to manager. Many new managers — and even seasoned ones — underestimate just how different this role is.

Becoming a new manager is like learning to drive: you may have watched your parents or friends drive for years, and you may know what all the signs mean, but once you’re at the wheel, it is a complete new world.

In this blog post, I will cover 6 areas where new data science managers often stumble during their transition from IC to leadership. My goal is to:

1. Highlight “Stop doing” scenarios

2. Explain why these stop doing scenarios can be a pitfall for you and the team.

3. Suggest an alternative “Start doing” approach that better aligns with effective management.

I hope this post helps you with a clear checklist of do vs not-do’s for your first few months in your new manager role. As I said before, your first few driving trips are stressful, but with the right tips, driving will become natural. Let’s hit the road!

Before getting started: team size matters, but not that much.

There is no denying that being a manager of 2 and working with 1 or 2 projects is not a massive shift to what you were doing as a senior data scientist. You probably just need to account for a bit of extra time for 1–1s, do some admin stuff, focus more on planning the weekly and quarterly work and have a bit more interaction with stakeholders on behalf of the team. But aside from that, plenty of time to keep doing what brought you success as an individual contributor…

I have managed small teams of 2–3 people, and also led 2 Data Science squads of 8 individuals each. On top of this, I help lead a Data Science discipline of 50+ data scientists. So believe me when I tell you that, even though you think having only 2 direct reports won’t change things too much, in the long run it does change things.

If you don’t shift your mentality to being a coach, your 2 or 3 direct reports will not grow. And if they don’t grow, you will still be the bottleneck in terms of delivery. And, if you are the bottleneck… guess what? You won’t be able to prove value at scale, which in turn, will make it really difficult to increase headcount. Your team’s and your own growth can become stagnated.

(I actually wrote a blog about the common misconceptions new managers had when stepping into the role. You can read about it in the link below)

Are you sure you want to become a Data Science Manager?

Think of this mentality shift as climbing a mountain. Early on, you can carry all your gear and keep going on your own. But as you reach higher altitudes, you need a team, and a strategy for helping each other up. If you keep climbing solo, you’ll eventually reach a ledge you can’t pass. Shifting to a management mindset allows you to set up ropes, delegate tasks, and work as a team to reach new heights together.

Image created with dall-e

1st STOP: Stop coding

When you are transitioning to a manager role, it is tempting to hold onto the technical work that brought you success as an IC. After all, you those built models, fine-tuned the ETLs and achieved amazing results. You know you can accomplish certain tasks 50% faster than your direct reports, and you likely feel that your contributions will be more impactful if you continue to "jump in and do the work" yourself. But here’s the reality: coding can quickly become a trap that prevents you from fully stepping into your new role.

Image generated with Dall-e

Look, even in the best case scenario, where you can actually take on all your new management tasks plus what you did as an IC, I think you are overlooking the long term impacts of continuing with your IC contributions. Let’s see some examples of why the coding zone can work against you and your team:

1. By definition, you have less time than before. Even those tasks that you feel don’t take a lot of time (the 1–1s, admin tasks, etc), when combined, do add up to a block of time you cannot devote to writing code and building ML models. Either you work more hours, or you cut corners on quality. The reality is that you simply have less than time than when you were an IC.

2. Creating an unnecessary dependency. Continuing from the point above, if you continue to code with less and less time for it, then you might suddenly become the team’s bottleneck. If you are the only one who knows how to build and maintain a PyTorch model, what would happen if there is an error in production?

3. You might be sowing resentment from the team. Staying deeply involved in coding can send an unintended message to your team: that you don’t trust them to handle the work themselves. They can feel micromanaged or deprived of the autonomy they need to grow on areas they haven’t explored. I know you are not doing this intentionally, but it can be something you are brewing without being aware.

4. Missing the big picture. I completely understand what is means being “in the zone” of solving technical problems and running deep analysis. But, the more time you spend in that zone, the less time you spend understanding how the team’s work aligns with the company objectives.

What to start doing?

I will never tell you to not code ever again. If you are starting your manager role with few direct reports, there will be a transition period where you will still code. But, my suggestion is to change your “coding” focus as soon as possible.

1. If you really need to code, choose specific tasks or moments. For example, pick up some boring tasks like running reports or improving documentation. For you to still do a good job on these less critical tasks, you will need to still know what the code is doing. Another idea is to plan hackathons or discovery weeks. You can go back to being an IC for a week where the whole team gets to contribute on something new.

2. Ensure that the quality for ML models and data insights is high by asking questions. Instead of reviewing code line-by-line, try questions such as “How will this model perform under different data conditions?” or “What risks do you see with this solution?” Questions like these help your team think critically.

2nd STOP: Stop solving all the problems yourself

As an IC, you've likely been immersed in the finer details of your projects. But as a manager, trying to stay involved in every detail of every project can quickly backfire. Don’t get me wrong - if you are in the detail of everything, you, as an individual, will be better equipped to help on specific issues. The question is, are you better equipping your team to deal to handle these moments?

Hermione’s time turner

I can think of 3 reasons why trying to be in the detail of every single project can become a problem in the long run.

1. You can’t be everywhere at once. It is a matter of physics. You don’t have Hermione Granger’s time turner. You can’t be in all meetings. As the number of projects and the team grows, your role should be to decide which critical meeting you should really attend, whilst ensuring clear processes are in place so your team can take the reins.

2. Helping too much can lead to junior folks not stepping out of their comfort zone. If you’re always the first to tackle issues, your team may become overly reliant on you and stop exercising their own problem-solving muscles. I often tell new managers, “Give your junior folks space, and you might be pleasantly surprised at how much they step up.”

3. “Heroic management” = burnout. Constantly swooping in to save the day can quickly become exhausting. Beyond burnout, this also creates an expectation that you’ll always have the answers.

What to start doing?

Think about how can you shift your focus towards cultivating a team of independent problem-solvers. Think of it like this:

How confident are you that your team would perform seamlessly for 3 months if you were gone?

I can tell you from experience that this is achievable. In Spain, we have 5 months paternity leave + my holidays. I literally disappeared for a good chunk of that time. When I returned, I found that, aside from a few strategic decisions, everything had run smoothly. Delivery was on track, and targets were met. Honestly, that should be the goal of every team lead. Here are some ideas I use in my day-to-day.

1. Start with the destination in mind. When your team encounters a challenge, describe the desired outcome rather than giving step-by-step instructions. For example, “We want to increase model accuracy by next quarter. What approaches would you suggest?” or “Wouldn’t it be amazing if we were able to predict competitor’s prices? I know this is difficult, but what could we try to do?” This sets clear goals and encourages team members to think creatively about solutions.

2. Delegate ownership, not just tasks. Ownership can take many forms, from leading small projects to managing recurring ceremonies.

   1. Junior team members could own roles like facilitating reading groups, running retro sessions, or handling alerting and monitoring. These tasks build confidence and help them practice leading discussions or managing ongoing responsibilities.

   2. Mid-level contributors might be tasked with owning a subcomponent of a larger project, like model validation, data monitoring, or implementing a testing framework for your models. This allows them to grow in areas that directly impact the team’s success.

   3. Senior members could lead entire project streams or direct collaborations with other departments, empowering them to make decisions and handle challenges independently.