Break Free from the Individual Contributor Mindset. You Are a Manager Now.

Author:Murphy | View: 28192 | Time: 2025-03-22 19:22:45

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 5 areas where new data science managers often stumble during their transition from IC to Leadership. My goal is to:

Highlight "Stop doing" scenarios
Explain why these stop doing scenarios can be a pitfall for you and the team.
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.

Let's dive into the 6 STOPs.

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 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.

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:

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.
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?
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.
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.

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.
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?

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.

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.
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."
"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 of paternity leave + 32 days of annual leave. When my second son was born, I literally disappeared for a good chunk of that time. When I returned, I found that, aside from a few strategic decisions not being taken, everything had run smoothly. Delivery was on track, and targets were met. Honestly, that should be the goal of every team lead. Here are 2 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.

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.
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.
Senior members could lead entire project streams or direct collaborations with other departments, empowering them to make decisions and handle challenges independently.

3rd STOP: Stop trying to be the best at everything

Any curious individual would like to stay on top of every technical skill. As a manager, you will be no different. In fact, you have built your career as an IC by mastering complex problems, and you may feel that your knowledge keeps the team moving forward. But in my experience, trying to keep up with everything is no longer sustainable (maybe, simply not even possible).

For starters, your time is more limited now. We have talked about this in the stop coding section. But it also applies to learning the latest techniques in recommender systems.Even if you approach it with a positive mindset – wanting to learn to help your team – you'll soon find that you're spreading yourself too thin.
Being the best is about getting hands-on, not just reading books. Sure, you can read 10 O'Reilly books (I myself tend to read 2 technical books per year…), but until you don't apply what you read, you will not master concepts. And going back to the point of limited time… you don't have it. See the problem?

What to start doing?

Prioritise quality over perfection. Let go of the need to know every technical detail in favour of ensuring that outcomes meet standards. Quality can be achieved by establishing review processes, encouraging peer feedback, and setting clear expectations for the team's work. Your value now comes from enabling quality rather than from being the sole quality enforcer. For example, you can establish a process where PoCs can be coded up in notebooks, but the moment the PoC drives value, you required all the code to migrate to a version controlled environment like Github.
Learn from your team! Shift your focus from learning everything yourself to helping your team members learn. If someone wants to dive into recommender systems, support them by providing resources, connecting them with other experts, or setting aside time for them to experiment and grow. And after this, get them to share knowledge back to the team!

4th STOP: Stop relying on technical expertise to deliver value

You need to be very careful that technical expertise (coding, problem solving and theoretical knowledge) becomes your comfort zone, your safe space. As a manager, continuing to derive your primary value from technical skills alone is like trying to win a chess match using only pawns – you're limiting your potential impact.

I won't focus much on what to stop doing, as we have covered a few of them in the 1st, 2nd and 3rd STOPs. Instead, I want to challenge you on thinking what should you do more of to grow as a manager.

What to start doing?

Be comfortable boasting about team wins. Yes, you read that right. Build your's and your team's ego up. Learn to translate technical achievements into business value. If you don't talk about these, even though you might be adding a lot of value, only a few people will know about them. Make it a priority to communicate your team's value. At my current company, we have a what-we-shipped slack channel, and we make it a priority to appear there at least once per quarter. In addition, we have Tribe town halls every month, and even if it is a 10 minute presentation, we are always eager to get a slot.
Enhance your communication toolkit. I am not saying you don't already do this, but as a manager, the number of presentations you lead on exponentially increases. Learn to adjust your communication style for different audiences. Understand how can Confluence be as effective as Powerpoint and viceversa. Storytelling should become your new superpower.
Start playing Littlefinger (from Game of Thrones). Build relationships with stakeholders (don't forget about non-technical departments). Practice negotiating for resources and budget. Set yourself a goal of growing the team by 3x. What would senior stakeholders need to be convinced about this?

5th STOP: Stop assuming your team knows the full context

Remember when, an as IC, the project you were working on would keep getting delayed or not given top priority? Now, you are on the other side of that equation, and it's crucial to recognise that your team is experiencing the same information gaps you once did. If you are doing one of the things below, it's time to rethink your approach.

Mentioning something once in a team meeting means everyone understood and remembers it. Information often needs reinforcement. Repeat the message in daily standups, 1–1s and sharing sessions. Over-indexing on communication is completely fine.
Assuming your team can read between the lines of leadership decisions. If leadership makes a decision that seems counterintuitive, your team may not see the larger strategic picture, potentially leading to frustration or misalignment. It's a manager's role to bridge that gap by providing clarity and ensuring that everyone is on the same page.

What to start doing?

Practice radical transparency (within reason). This doesn't mean sharing every detail of every leadership meeting, but rather:

Regularly explain the "why" behind decisions, even if it seems obvious to you. A decision that feels self-explanatory to you may not be obvious to the team. For example, if resources are being reallocated, explain how this aligns with broader business objectives or recent market changes.
In 1:1s, explicitly check for understanding. "How clear is our team's priority shift to you? What questions do you have about why we made this change?" Sometimes the team does not want to ask these questions in an open forum, but 1–1s are a great space to open the circle of trust.
When priorities shift, walk through the full context. For example, I remember how mid-quarter, we were told that there was a big gap in our Hotels vertical target metrics. Whilst we were focusing on Flights, the decision was to shift resources to Hotels. I explained the context and the goal, and the team all rallied to help, leaving behind their current ideas for what they were working on.

Summary

You might be thinking "well, all of this is easier said than done". True, but if you don't stop doing, I can guarantee that your role as a manager will not be meeting expectations in the long run. Remember the learning to drive analogy? Apply it to your growth as a manager: be aware of what you are not comfortable with and keep practising. Do it step by step.

1st STOP: Stop coding
2nd STOP: Stop solving all the problems yourself
3rd STOP: Stop trying to be the best at everything
4th STOP: Stop relying on technical expertise for value
5th STOP: Stop assuming your team knows the full context

Keep the 5 STOPs I talked about in mind, and you will see a positive change over time.

Stay tuned!

If you want to get notified when I release new written content, feel free to follow me on Medium or subscribe to my Substack newsletter. In addition, I would be very happy to chat on Linkedin!