Managing People: A Data Scientist’s Perspective

Management

Life

Author

Eliott Kalfon

Published

June 8, 2025

Three years ago, I was promoted to a Team Lead position. I was 26 and absolutely clueless. Until then, I would have described myself as a technical person, passionate about solving problems with Machine Learning. People management was neither my expertise nor my concern. And yet, all of a sudden, I had to learn; and learn quickly.

This post will go through what I learnt over the first few years of my management career. It is the first of a two-part series. The second post will address Leading a Team, and focus more on “what to do?”, instead of the technical details of “how to do it?”.

Disclaimer: I have not figured it out yet. However, I still remember what it feels like to move from individual contributor to team lead from one day to the next. I still remember what it means to begin.

If you are into books, I found The Making of a Manager by Julie Zhuo and Managing Humans by Michael Lopp particularly useful.

If I had to sum up this post in one sentence, it would be the following: everyone is different (really), understand who your team members are, what they want, and give them what they need to get there.

Everyone is different

We all “know” this. We have a diverse team, we come from all over the world, and so on… As a beginning manager, I realised that whatever I knew was a gross underestimation.

People have very different:

Goals
Interests and desires
Communication styles
Desired autonomy and ambiguity levels
Skills

I would recommend any manager to begin by understanding who their team members are. I would always start with trying to figure out their long term goals and aspirations. Once this is clearly defined, everything else can be linked to these goals.

As an example, one team member, currently a Data Scientist, wants to follow a people leadership track. Another wants to become an expert in recommendation systems. There is no rule. The best way to understand it is simply to ask. Do you know your team members’ long term goals?

When I started out, I had a tendency to assume that people were interested in the same things as I was. That was, again, far from the truth. Some team members like ad hoc analysis and contact with stakeholders, others prefer working on developing new model architectures. Some even prefer engineering tasks to make sure that the services we deploy are as efficient as possible. Knowing what team members enjoy doing is key to allocating tasks and making sure that everyone has a fulfilling work life.

Communication style is a topic that is easily taken for granted. At first, I assumed that all of my team members would have the same communication style (i.e., mine). I was (very) wrong. Some people prefer asynchronous communication on Slack channels, others like to talk, either in meetings or over the phone in 1-to-1 conversations.

In my experience, team members enjoy and require very different levels of autonomy and ambiguity. I would define autonomy as the ability to define one’s own tasks, or when given a task, the freedom one would have to define their approach to solving it. On the other hand, ambiguity refers to how clearly defined a task is. Some team members enjoy the freedom to make their own tasks and come up with their own solutions. Others prefer clear step by step instructions.

Etymology of autonomy and ambiguity

Both words can be better understood through their etymology.

“Autonomy” comes from the Greek “autos”, the self, and “nomos”, the law. Autonomy is one’s ability to define their own laws or constraints. The terms also evolved to describe the broader concept of self-determination.

“Ambiguous” comes from the Latin “ambi-”, both ways, and “agere”, to drive or act. It refers to anything that is not clearly defined, that could be interpreted in different ways.

Lastly, people are naturally good at different things. When allocating tasks, you may want to take both efficiency and learning opportunities into account. In terms of efficiency, you should give tasks to people with the skills to do them successfully. However, considering learning opportunities, it also makes sense to give tasks to people who do not yet have the skills needed. This could also be a great mentoring opportunity for other team members, who could help this person learn and do the task.

Understand who your team members are

Initial one to one

It is never too early to get to know your team members. Before your first one-to-one meeting, I would recommend sharing a list of questions with your team members, to think about ahead of the meeting. Such questions could include:

What is your long-term career goal?
What did your previous manager do that you liked and would like to keep? What would you have liked to change?
What types of tasks do you enjoy? Think of examples from the last year
What types of tasks do you want to avoid? Why?
How do you like to work? More autonomy/ambiguity? Do you prefer clearly-defined tasks?
When do you prefer synchronous to asynchronous communication?
How frequently do you like having one-to-one meetings?

These are just examples to get you started. The more personal and relevant to the job the better.

During these meetings, I recommend taking notes. I generally keep one document per team member. I use it to take notes during our one-to-ones. This is good to keep track of tasks, performance, communications, feedback, etc.

Check-in regularly

I suppose this is no news, but people change. It is always a good idea to check the answer to these questions every few months. More on this in the feedback sections below.

Give them what they need to get there

Now that you know what your team members want, it is up to you, as a manager, to give them what they need to get there.

There is a caveat though, to foster a sense of agency, before sharing your ideas on how to help your team members reach their goal, I would recommend asking them the simple questions: So you want to become a recommender systems expert, what can you do about it? And leave them the time to come up with ideas.

Task allocation

Task allocation depends on the type of industry you are working in. In the tech world, it is common to have a number of tasks associated with a certain priority. All need to be done, and your job as a team lead is to allocate them properly. More on this in the Leading Teams article.

I always prefer to involve team members in task allocation, as I do not believe in centralised planning or in the idea of a centralised intelligence. Ultimately, the team lead is responsible, but individual team members can play an active role in the process. One way to allocate tasks collectively is to share a list of tasks to be done and let volunteers take them.

This is very much an ideal case scenario, as you may have to be more directive in the following scenarios:

Urgency and high priority
Task could be a good learning opportunity for one team member
Two or more people want to work on the same task
No one wants to work on this task

Let’s tackle these one by one.

First, urgency and high priority. If a task needs to be done well and quickly, I would recommend allocating it to the team member that is best suited to the task, and freeing them of their other commitments. For instance, there is an important production incident on one of the deployed services you manage - you would want your best Machine Learning Engineer on the case.

Then, when a task seems to be a good learning opportunity for one of your team members, it makes sense to give it to them directly. I would usually pair them up with another team member who is an expert in this area. As an example, if one of the Data Scientists wants to improve their Deep Learning skills, I would ask them to research a new model architecture, with support from more senior team members.

When two or more people want to work on the same tasks, a tricky situation arises. I always try to come up with creative solutions to this issue. I do so by asking myself the following questions:

Can both team members work in parallel?
After individual research, can we go with the highest performing option?
Can this task be divided into individual components?
Can I create a hackathon out of it?

If all of the above fails, and you have to assign the task to one or the other, I would recommend taking into account: previous tasks, career goals, and the good old “first come first served” heuristic. Joking aside, it is also good to be transparent with your decision process.

But what happens when no one wants to do a given task? There, I experimented with different options:

Benevolent dictator: simply assign task to people, mentioning reasons if needed
Transparent rotation system: for routine task, it could be a good idea to use a rotation system
Lead by example: take it on yourself, it is good idea to keep a foot in the practical side of a job

Feedback

I could write an entire blog post on feedback, and many have already been written by more experienced managers. Here is my take.

Unstructured/spontaneous communication

I try to keep this as a manager. I take note of everything that comes to mind. Depending on the preferred communication style of my team member, I would either share feedback immediately on Slack or mention it in a meeting. I generally prefer informal communication instead of waiting for one-to-one meetings.

In terms of leading teams, public praise of positive behaviour is something I find very important. I generally avoid giving negative feedback in public, unless the quality of work is far below our standard. Even then, I would always phrase it as an opportunity for improvement.

Structured communication

One-to-one meetings are a key component of feedback exchange. I schedule them either weekly or biweekly. With a team of 7 people, this represents an important time commitment, but as a manager, these are some of your most impactful meetings. I am sure we have all experienced this, one-to-ones that leave you energised. I have had brilliant managers and after our one-to-ones, I felt ready to take on the world. I try to live up to this example.

There are several questions I keep for one-to-one meeting:

Is there anything in particular you would like to talk about?
What are your current tasks?
How do you feel with your tasks? What do you want to do more or less of?
Do you feel like you are on your trajectory to reach your long-term goal? If not, what could we do differently?
Are you currently satisfied with the way in which we work as a team? Feedback for me?

When talking about current tasks, I like to stay very high level and keep task-relevant details for our team meetings. This makes sure that the one-to-one meeting is centred on the team member.

End of year Feedback

I always tell my team members that in my view, a successful end of year feedback session is a session with no surprise on either side. What I mean by this is that they should not discover anything on their performance that we would not have mentioned before in our one-to-ones. On the other hand, I should not discover any feedback they would not have mentioned to me before. If that is the case, it just shows that I have not done a good job of creating a safe enough environment for this feedback to be shared.

Final Thoughts

Please take all of the above as notes taken through my management journey. I will certainly revisit them over the next few years. I am already looking forward to enriching them with the many things I will learn. In the meantime, let’s remember the main message:

Everyone is different (really), understand who your team members are, what they want, and give them what they need to get there.

With that being said, I wish you all the best in managing your teams! If you think I missed something, let me know.

PS: This blog post did not mention anything about hiring, an art I am still working on.