TL;DR: As a new data science leader, your technical expertise can become a trap when you default to hands-on work instead of leading. Break free by categorizing decisions into three levels: Strategic (must be you), Implementation (could be team), and Tactical (should be team). Start delegating tactical decisions first, giving clear guidelines while monitoring outcomes rather than processes. Your team will grow stronger, and you'll become a more effective leader.

I was knee-deep debugging our churn prediction model's latest performance drop when my manager called. Our VP needed insights on customer behavior patterns for the board meeting next week, and my manager wanted two of my data scientists (from a team of nine) to help.

'But everyone's tied up with critical work,' I replied almost automatically. They really were. Or so I thought.

What happened next still makes me cringe. My manager scheduled a quick team check-in, and it turned out half of my entire team was working on things that could easily wait. I was so absorbed in my hands-on work that I'd stopped closely tracking their workload. Many were simply waiting for guidance, unsure how to proceed.

That day I learned: being the technical hero wasn't just making me an ineffective leader - it was actively holding my team back.nWe allocated two data scientists for the behavior pattern analysis. And I decided I had to learn how to let go.

The Comfort Zone Trap

It's an anti-pattern I've seen play out countless times since that day. A brilliant data scientist gets promoted to lead a medium-sized (4 to 12 people) team, and their technical expertise - the very thing that earned them the role - becomes their biggest obstacle.

The logic seems sound at first: 'I'll speed up the team by helping out with the complex technical work.' After all, it's faster to do it yourself than to teach someone else.

You've spent years perfecting your feature engineering approaches. Your SQL queries are works of art. It makes sense you should shoulder the heaviest loads.

But here's what actually happens: Your team gets stuck waiting for your technical decisions and you become the bottleneck. What’s even worse, more junior data scientists don't get to tackle challenging problems (and grow) because you keep handling them yourself.

And worst of all, you're so busy being the technical hero that you miss the real work of leadership - setting direction, removing obstacles, and growing your team's capabilities.

This is the comfort zone trap: the pull of technical work is incredibly strong because it's concrete, familiar, and gives you that immediate satisfaction of solving problems. Leadership, in contrast, often feels messy and uncertain. There's no unit test to tell you if you're doing it right.

Looking back at that day with my team, I realize I wasn't just failing to delegate - I was actively avoiding the discomfort of my new role by hiding in the familiar territory of code. Each debug session was an excuse to postpone the harder work of learning to lead.

The Path Forward: Building New Leadership Habits

That debugging session was my wake-up call. I needed a systematic approach to shift from being the technical hero to becoming an effective leader. I needed to delegate work effectively. But to do so, I needed to first understand which work to delegate and which keep for myself.

I tried different approaches, but found the simplest one most effective: to split work into strategic, implementation and tactical, and then have specific delegation approach for each category.

While I'll outline these categories in detail below, remember that their exact scope will vary based on your organization. To adapt this approach to your context, spend a couple of weeks observing your team's backlog and discussing with your peers. This will help you draw boundaries that make sense for your specific situation.

Strategic Work (Must Be You)

These are foundational decisions that shape your team's technical direction and long-term success. They typically:

• Have long-lasting implications (6+ months)

• Impact multiple projects or teams

• Require broad organizational context

• Involve significant resource commitments

Some examples of strategic work are:

1. Technical Architecture Decisions - such as selecting core modeling frameworks (PyTorch vs TensorFlow) or designing data pipeline architecture

2. Standards & Processes - such as establishing model validation frameworks or defining coding standards and best practices

3. Strategic Planning - such as making build vs buy decisions or planning technical debt reduction

Implementation Work (Could Be Team)

These decisions require technical expertise but are more contained in scope. They typically:

• Impact single projects

• Have medium-term effects (1-6 months)

• Require good technical judgment

• Benefit from team input and ownership

Some examples of implementation work are:

1. Project Architecture - such as choosing modeling approaches for specific projects or planning model monitoring strategies

2. Technical Design - such as selecting algorithms for specific use cases or designing experiments

3. Resource Planning - such as estimating technical effort or identifying technical dependencies

Tactical Work (Should Be Team)

These are day-to-day technical decisions that should be fully owned by the team. They typically:

• Have immediate, contained impact

• Follow established patterns

• Build team expertise

• Benefit from quick iteration

Some examples of tactical work are:

1. Implementation Details - such as writing and optimizing/debugging code

2. Model Development - such as feature selection and engineering or hyperparameter tuning

3. Operations - such as monitoring model performance or data pipelines health

Making It Work

Once you have the categories sufficiently fleshed out, it’s time to actually put it in use. As mentioned, you should always be involved in strategic work. But the other two categories you can definitely delegate.

Start with tactical work first and later move to implementation work. You should:

• Agree clearly (with examples) on what is the work that you are delegating

• Agree clearly on when they should escalate to you

• Step back

Plan for about 6-8 weeks at least for each category. It might seem long, but remember - you're not just changing processes, you're building new habits and trust with your team1. And that is a long game. The key to success? Having clear guidelines for when and how your team should involve you in their work.

Building Trust Through Smart Escalation

As you delegate more work, you'll need a systematic approach to building trust. This means getting crystal clear about when your team should involve you in decisions.

Many new managers worry this might feel like micromanagement - after all, aren't we trying to make them more independent? But here's the counterintuitive truth: clear escalation guidelines actually build more trust than a complete hands-off approach.

When your team knows exactly which decisions need your input, they become more confident making all other decisions independently. It removes the anxiety of "should I check with my manager on this?" and replaces it with clear ownership.

Here's a helpful way to think about it: It's a bit like deploying a model to production. You don't just push straight to production and say "I trust the code, it will behave well at all times." You build guardrails first - unit tests, validation checks, monitoring alerts. These aren't bureaucratic obstacles - they're tools that let you go hands-off while being confident that you will be notified when you're needed.

The same principle applies to delegating decisions. When you build proper escalation guidelines, you're not restricting your team's independence - you're creating the infrastructure that enables real trust. Clear escalation points become the guardrails that let you delegate with confidence, knowing you'll be involved when truly needed.

It's not possible to provide a one-size-fits-all escalation guideline, so I would advise thinking through what could work for your case. But to help you get started, here's a list of some common escalation scenarios where it could be a good idea to involve you:

1. Stakeholder Misalignment. When stakeholders show signs of misalignment or dissatisfaction. Early intervention can prevent small misunderstandings from derailing projects.

2. Resource and Timeline Risks. When there's a growing gap between commitments and team capacity. Having this discussion early helps avoid missed deadlines or quality compromises.

3. Dependency Issues. When deliverables from other teams are delayed so much that it might impact your team’s work. Having manager involved can unblock dependencies or at least help readjust expectations about deliverabales.

4. Unexplained Model Behavior When models show patterns that the team can't fully explain. Unexpected model behavior often indicates deeper issues that need broader investigation.

5. Unresolved Technical Debates When technical disagreements between team members aren't getting resolved through team discussion. A manager's facilitation can help the team reach consensus without letting tensions build.

6. Scope Changes When project scope starts expanding beyond initial agreements, even through seemingly small additions. These incremental changes can significantly impact delivery if not managed early.

Remember: the key is not just to set these escalation points, but to explain the reasoning behind them. The aim is for your team to develop better judgment over time, rather than just following rules.

Managing Up

Now that you understand what to delegate, you might be eager to start. But here's something I learned the hard way: before making any changes, you need your manager firmly in your corner.

Even if you execute this transition perfectly, there will be moments of slower delivery and occasional setbacks. That's not a failure of delegation - it's a natural part of building a more capable team. You understand this, but your manager needs to also be onboard.

Your manager needs to understand that you're not stepping back because you're disengaged or avoiding work. You're doing it because it's the only way to build a team that can operate without being blocked by you.

Have this conversation early. Explain what you're planning to delegate, what safeguards you're putting in place, and most importantly - why this is better for the team in the long run. You don’t have to be shy about it: a good manager will not only support it wholeheartedly, but also have great advice on how to execute the transition well.

Your Journey

Where are you in this journey? Have you struggled with stepping back from technical decisions? Which delegation category - tactical, implementation, or strategic - do you find most challenging to hand over? Share your experiences in the comments.

Next in this series: "Managing Former Peers in Data Science Teams" - we'll explore how to transition from peer to leader while maintaining team dynamics and trust. Subscribe to get notified when it's published.

Subscribe now

TL;DR: Moving from data scientist to data science manager requires a profound identity shift. This post provides two practical checklists to gauge your progress: one for overall managerial mindset (are you transitioning from doing to enabling?) and one for technical leadership (are you letting go of hands-on work?). Bonus: specific action items to fix any red flags you discover.1.

I’m not a big sports person, but if I had to pick one, it would be football. And in decades of casually following the sport, I’ve noticed something interesting: It is very rare for star players to successfully transition into being great coaches. One notable exception - unsurprisingly - is Zinedine Zidane.

Why is this transition so rare? What made Zizou different? And why am I talking about football on a data science leadership blog?

Because transitioning from a star individual contributor to an effective manager is just as challenging in data science as it is in football. And the reasons are surprisingly similar.

The Core Identity Shift: Doer to Enabler

On the field, Zidane was magic. He could single-handedly turn a match with a moment of brilliance - a impossible pass, a stunning goal, a game-changing play. His individual performance was core to his identity. Success was measured by his personal statistics, his individual moments of genius.

But coaching demanded something entirely different from him. Suddenly, success wasn't about what he could do, but about what he could make possible for others. His role shifted from being exceptional on the field to assembling a team of exceptional people, having them play well together and removing obstacles so that they could be at their peak performance.

As a fresh data science manager coming from being a star individual contributor, you have to undergo the same transformation. Where you once were the one developing elegant ML models, you now become the architect of a team that can consistently deliver breakthrough solutions. Your success is no longer measured by your personal technical output, but by your team’s collective capability.

Yes, there are a lot of new skills to be learned and that’s a challenge. But the real hard part is this: it’s a profound mental transformation. You move from being the person who directly solves problems to being the person who removes obstacles, provides clarity, and enables others to solve problems at scale.

Putting in Practice: Managerial Mindset Checklist

But how can you actually tell if your mindset shift is really happening? Here’s a quick way to check if you’re truly transitioning from star player to great coach. Many new managers default back to their IC comfort zone - this check will help you spot when that's happening. You should need no more than 15 minutes every Friday to honestly assess these areas. No overthinking - your first instinct is usually right.

The exercise is simple, go through these questions and count how many greens, yellows and reds you get.

1. Are You Still Playing or Starting to Coach?

   1. 🔴 Still deep in the code (>40% non-handover2 coding time). You’re effectively a senior IC with direct reports.

   2. 🟡 Getting there (20-40% coding time). The balance is better but not quite there.

   3. 🟢 You’ve made the shift (<20% coding). Your value now comes from enabling others3.

2. Do you know the priorities of the business orgs you're working with?

   1. 🔴 You can’t immediately name your org’s top priorities.

   2. 🟡 You know them but would stumble explaining why they matter.

   3. 🟢 You can explain priorities and connect them to your team’s work.

3. Do you know what projects your reports are working on and how they are going?

   1. 🔴 You’d struggle to give a quick summary of anyone’s work and capacity.

   2. 🟡 You know the projects but details are fuzzy. Better than red, but definitely not good enough.

   3. 🟢 You can give a 30-second rundown of each person’s situation, complete with their achievements, struggles and blockers.

4. Do you know how your stakeholders are feeling about the projects your reports are engaged in?

   1. 🔴 You haven't initiated any stakeholder conversations in over two weeks.

   2. 🟡 You're in regular contact with some stakeholders but have gaps in others.

   3. 🟢 You have clear visibility into all stakeholder priorities and satisfaction levels.

5. Are you tracking your direct reports' professional development? Have you agreed on and are you monitoring their development plans?

   1. 🔴 Missing career goals or haven’t checked progress in a month.

   2. 🟡 Career goals exist (at least on high-level) with most reports and you have discussed progress with most of them in the last month.

   3. 🟢 Clear picture of where everyone’s headed, how they’re doing and how you can help them. You have at least monthly syncs with everyone to discuss this.

6. Do you have a clear idea about team health for your direct reports?

   1. 🔴 A team issue (conflict between team members, motivation issues, severe miscommunications, etc.) blindsided you more than once during last quarter.

   2. 🟡 When issues arise, you mostly are aware of them, but their severity sometimes still catches you off-guard.

   3. 🟢 No surprises - you see issues coming and handle them early.

Count your colors every Friday. If you have 4 or more greens, congrats, you’re going strong along your managerial journey. Having 1-2 yellow items is acceptable—perfect is the enemy of good. And reds need immediate attention.

Keep in mind that this is a journey, not a destination. You might be doing well this week in any given area, but let your attention slip next week and fall behind. This checklist is meant to regularly make you aware of your standing in each dimension.

As said above, reds require your immediate attention. Here’s your next step for each:

1. Still Coding: Block off time to delegate those coding tasks you’re holding onto.

2. Business Blind Spot: Get coffee with your business leads this week.

3. Team Confusion: Clear your calendar for focused 1:1s.

4. Stakeholder Sync: Schedule all key check-ins before EOD.

5. Growth Gap: Block time next week to update career plans and/or have check-ins.

6. Missed Conflict: Create extra team touchpoints until you’re back in sync.

Fifteen minutes every Friday. That’s all it takes to stay honest with yourself about how you’re transitioning to a managerial mindset.

From Shining to Letting Shine

While the shift from individual contributor to manager is challenging across all professions, data science presents a unique wrinkle that demands deeper exploration.

As a data scientist, you've likely spent years honing your technical expertise - mastering complex algorithms, developing elegant solutions, and being recognized for your technical brilliance. In fact, it's probably this technical excellence that earned you the promotion to management in the first place.

But here's the paradox: the very technical mastery that got you the management role is what you now need to (partially) let go of. This isn't just about time management - it's about fundamentally redefining your relationship with technical work. Instead of being the technical expert who implements solutions, you need to become the enabler who creates an environment where others can develop and demonstrate technical excellence.

Putting in Practice: Technical Involvement Checklist

Let's see how well you're navigating this transition with another 15-minute Friday checklist - this time focused specifically on technical leadership and enabling others. This is again a quick test that you can use to gauge if you’re becoming the enabler for your team.

1. How hands-on are you with project technical details?

   1. 🔴 You’re deep in implementation details in every project. You could sub for a report when they’re out sick.

   2. 🟡 You’re balancing between strategic and tactical, but still too hands-on. You can clearly explain details of most implementations.

   3. 🟢 You’re focused on architecture and strategy, team handles implementation. You don’t need to know all the details.

2. How does your team handle technical decisions?

   1. 🔴 Team constantly asks for your input on technical decisions and you often are the bottleneck in the process.

   2. 🟡 Team knows what they can decide but often seek unnecessary validation for their decisions from you as a form of insurance.

   3. 🟢 Clear framework exists, team confidently makes decisions at their level and knows when to escalate to you.

3. How is technical knowledge shared in your team?

   1. 🔴 You’re the go-to person for technical knowledge, since you were recently the star individual contributor and you know everything. No significant documentation exists.

   2. 🟡 Some documentation exists but you still get requests for knowledge sharing almost daily.

   3. 🟢 There is complete documentation for all the important processes and systematic knowledge sharing practices are in place. Sometimes weeks go by without anyone asking you for knowledge sharing.

4. How does your team handle technical emergencies like downed production system?

   1. 🔴 You’re called in for every case, nothing happens without your involvement.

   2. 🟡 Basic protocols exist for who should be involved in what, but team still relies heavily on you to guide them in emergencies.

   3. 🟢 There are clear guidelines for emergency handling and escalation, and the team mostly handles emergencies independently.

5. How do you maintain technical quality standards?

   1. 🔴 You’re reviewing all big technical decisions.

   2. 🟡 Standards exist but you have to micromanage whether they are observed.

   3. 🟢 Team maintains quality through clear standards and peer review without your involvement.

As above, you can feel good about your progress if you score 3+ greens weekly, 1-2 yellows are okay and you have to work on fixing reds immediately. Here’s your next step for each red area:

1. Technical Deep-Dive: Document the decisions you make this week and create delegation plan.

2. Unclear Authority: Draft and share decision-making framework with the team.

3. Knowledge Bottleneck: Set up systematic documentation and knowledge sharing practices.

4. Crisis Management: Define what constitutes an emergency and document escalation paths.

5. Quality Control: Create clear quality standards and review processes, then step back.

The Long Game

You might be looking at those checklists thinking "I'm in the red everywhere." If you're feeling overwhelmed - that's normal. Like Zidane, you're facing that jarring shift: one day you're on the field scoring impossible goals, the next you're trying to orchestrate an entire team's success.

The good news is that the hardest part is making that mental switch from performer to enabler. Once you internalize that shift, the rest becomes a matter of practice and persistence. Do you know how long it took Zidane to evolve from world-class player to Champions League-winning coach? Six years.

So don’t be hard on yourself. Run those Friday checks, keep score of your progress, and trust the process. You've got this.

Your Leadership Journey Matters

Which checklist item hit closest to home for you? Share your biggest struggle in the comments - I'll respond with targeted strategies I've seen work in similar situations.

Next week we'll deep-dive into some of the challenge areas. I’m thinking of starting with technical delegation. Which area would you like to see discussed next?

Welcome! This is an index page that links to all articles in my series about becoming a data science leader. Each article shares practical insights and strategies learned from real-world experience.

Series Articles

• From Doing to Enabling: The Data Science Leadership Transformation

• Your Notebooks are Holding You Back: A Data Science Leader's Guide to Letting Go

This series is regularly updated with new articles exploring different aspects of data science leadership.

We all know culture’s important. It’s been mercilessly drummed into leaders everywhere. As a DS org leader, it’s your duty to actively shape one too. But with so many ways to go about it, what do you focus on?

Sure, all of the usual wisdom applies. Champion taking ownership, adaptability, being humble, listening well, being frank, eating last... And for the love of all that’s holy, getting some sleep. But for DS teams there’s one aspect of culture that I would argue needs extra care and attention from the leader: delivering value.

It’s not Me, It’s You

You see, data scientists are tinkerers at heart. Some love thinking about coding tools, some about modelling techniques, some about efficient implementations… But I’ve yet to see a data scientist in his or her natural state who loves thinking about delivering value for the company. It’s just not something we are bred for. And that, if left unchecked, can lead to unintentional, but very real problems.

They say 87% of data science projects never make it to production. And while that infamous quote has (thankfully) been tried and found wanting, it still touches a nerve: an unsettling proportion of data science projects do never make it to the stage where they actually become useful to the wider organisation.

Now, this can have a lot of reasons as to why, but the one I’ve seen most frequently in the wild is this: data science teams are laser-focused on technical excellence, but they lose sight of the value their work is adding. They don’t course-correct based on business context and find out too late that their (often genuinely good) technical solution does not generate any value for the stakeholders.

And so the vicious cycle begins:

1. Data scientists don’t understand what they’ve done wrong and failure to adopt their product demotivates and disengages them

2. Business in turn blames the data scientists for not being focused on delivering useful solutions

3. This attitude disheartens both parties and so puts the projects that come after at the heightened risk of failing

4. Because of this, some (or most) of the following projects fail

5. A cynical attitude spreads and people from both sides of the fence start to believe that no amount of honest effort they put into data science projects will lead to success, and that there is something wrong with their counterparties

With this, the cycle is complete and you’ve arrived at the unhappy station of self-fulfilling prophecy: projects fail because everyone thinks they will.

Breaking the Spell

Before discussing how culture of being value-focused can help here, let’s get some housekeeping out of the way. The projects should solve real business problems, project teams should include heavy business competence, business sponsors should be fully engaged in the project, and all that. If these are not taken care of, no amount of orienting data scientists towards value will help.

But once these fundamentals are in place, you need to make sure that your data scientists get excited by not only clever technical solutions - sure, that’s a must, but they don’t need your help there - but by building actually useful solutions.

It’s not easy - data scientists become data scientists because they mostly get excited by building cool stuff. Their whole training further reinforces that: all the university courses, bootcamps and Kaggle competitions preach that once you have the perfect model, it’s all smooth sailing from there. The discussion about importance of actually delivering value through data science (even if sometimes through really dumb models, or even just well thought out business rules) is nowhere to be found. And the end result might be not unlike that Sherlock Holmes joke - you build something that is very cool, and very useless.

So, how do you get your data scientists excited about the value they can create through their work? There’s no one recipe, but I would recommend tapping into one of the strongest intrinsic motivations any of us have: to be doing work that affects others positively.

Unless your data scientists are complete sociopaths (in which case delivering value should be the least of your worries), in the long-run they care that their work makes lives of their colleagues and clients better. So make sure you answer that question loud and clear and as often as you can. Show your data scientists how their work benefits others, show the positive response from the people their work is affecting, let them taste the intoxicating feeling of doing meaningful work, and they will naturally start to concentrate on how to do that more. They will concentrate on delivering value for their stakeholders.

Subscribe now

Yes, but How?

So how do you actually do that? It’s obviously a never-done process and I haven’t personally tried out all the ideas listed here, but here’s some food for thought.

Keep Value Top-of-Mind

To build a culture of value, you have to keep it front and centre. Beginning of any well-run project is formulating the business problem and very explicitly sizing the opportunity. And the biggest mistake at this point is to not involve your data scientists every step of the way because “they’re more focused on the technical side of it” or that “we want to save their time”. In my experience, the initial hint of hesitance data scientists exhibit on those meetings is quickly replaced with enthusiasm and once they see first-hand how business thinks about a problem in terms of value, they get motivated to help as much as they can.

Another way to keep value on everyone’s mind is to develop an executive dashboard which tracks value of all projects through time and use every excuse to bring it up in any remotely relevant conversation with your stakeholders. Sure, they’ll stop inviting you to parties pretty soon, but can you really put a price on creating a value-first culture?..

Create spaces for celebrating success

Once you’ve cemented the culture of thinking about value at every step of the project, it’s time to reward your champions. Celebrate success at every point, and use every opportunity to show how your data scientists help their coworkers and clients through their work.

It could be all sorts of things from a simple recognition of good work on team retro to organising a huge get-together where business and data science come together to celebrate achievements.

Whatever the format, be sure to do several things:

• Make a point of talking about the good work yourself - praise from a leader means a lot

• Be a megaphone for your team’s good work with your management and find ways to have them personally thank the team

• Organise meetings where senior business stakeholders will detail how the work your team is doing is helping them in their day-to-day

If you can do so, symbolic titles can also be a very profound way of recognising work: I’ve heard of an European telco that gives out “legend” titles to the most productive (as measured by delivered value) data scientists during their annual get-togethers with business. Can you imagine what would it do to your motivation if your stakeholders called you a legend for your work?.. Exactly.

Connect your work to a higher purpose

Lastly, some of the most powerful motivation can come from the most overlooked of places: talking to your data scientists about the company mission and impact.

See, the problem is that data scientists usually don’t get much exposure to what the company is doing outside the narrow project scope that they are working on. I myself have continuously bumped into data scientists not knowing the most basic facts about the products or major processes of the companies they work for.

This is not data scientist-specific: all business support functions (ahem, developers) face the same problem. This is why great companies like Shopify put all their new employees through a rigorous onboarding which helps them learn about the company mission and products. They even have their developers build real online stores!

So, it could be a good idea to put together some content that shows your data scientists several things very clearly:

• Your company’s products

• History, mission and values

• How their work contributes to the mission

This might seem a bit out of JD for a data science leader, but if the result can move people to tears and let them feel connected to their work, then surely that’s worth a try.

How do you approach the challenge of connecting work with value in your data science teams? Share your experiences in the comments. Your insights might just save a fellow leader from reinventing the wheel - or at least give them a better blueprint for it.

If there's one thing that sets data science projects apart in the broader IT or "technical" space, it's the spirit of experimentation. And with experimentation comes an inherent risk of failure. When setting out to build value-generating ML solutions, success is rarely guaranteed.

Adapting the famous adage: in data science project almost everything can go wrong, and so almost everything will go wrong.

• Sometimes you can’t trust your data

• Sometimes your model will just not have the predictive power

• Sometimes you’ll find the business process cannot accommodate your brilliant technical solution.

• Oh and sometimes, just as you’re putting buffed out solution in production, a market condition (looking at you, regulators) will change, render the whole solution useless and leaving to to start from scratch.

So how do we deal with this?..

The Zen of Failure in Data Science

I’ve found that seasoned data scientists often develop a zen-like attitude towards failure. They don't just accept failure; they expect it, prepare for it, embrace it when it happens, and - most importantly - learn from it. This mindset is so crucial that I’m convinced it's one of the defining features of a truly mature data scientist.

However, this skill isn't easy to acquire. As a data science leader, don't simply wait to see which team members naturally develop this ability. Instead, actively help your data scientists train and develop this skill, just as you would support them in mastering data manipulation or modelling techniques.

Here are some strategies to help your team embrace failure:

1. Hire for resilience: During the hiring process, thoroughly inquire about candidates' experiences with stress and setbacks. Make resilience an important factor in deciding who to hire.

2. Lead by example: When failure occurs, avoid pointing fingers. Instead, rally the team and focus on developing solutions together.

3. Implement “post-mortems”: Encourage your team to document why failures occurred and how they might be avoided in the future. Create a repo of failures and encourage everyone to consult it whenever necessary.

4. Celebrate learnings: Discuss insights gained from failures during team meetings. Praise team members who contribute valuable lessons learned from unsuccessful projects.

Balancing Failure and Value Delivery

When implementing the above, it is very important that you don’t accidentally glorify failure. That can definitely create an unhealthy fallback for when value is not delivered (“We botched a year-long strategic project, but hey - failure is okay!”) The key is to constantly stress that the good thing (or saving grace, really) about failing is only the useful learning that comes out of it. So, I would suggest stressing two points:

1. It’s okay to fail, but not okay to not learn from it.

2. If you have to fail (and as a data scientist, you do), fail early and fail often.

The second point is that while embracing failure is crucial, it's equally important to deliver value to stakeholders. Here's how to strike that balance:

1. Structure projects strategically: When starting a project, aim to deliver quick value before you go into experimentation which might yield nothing. This way you have some value to show if the experimentation does not pay off.

2. Contain the fallout: Do as small experiments as you can so that if they blow up, they don’t blow up the whole project.

3. Communicate effectively: If you’re going to experiment at any meaningful level, it falls on you as a leader to consult all stakeholders and have their buy-in in taking risks. This way you stress-test your ideas and have a shared responsibility about the outcome.

4. Measure and report: Develop metrics to quantify (even if not very precisely) the value of failed projects. For example:

   1. Knowledge gained: e.g., number of new insights about data or business processes

   2. Process improvements: e.g., identification of weak links in project process that leads to increase in future project success rate

   3. Future cost savings: e.g., avoided expenses from identifying non-viable approaches early

Conclusion: Embracing Failure for Innovation

In the fast-paced world of data science, failure is not just inevitable—it's a crucial component of innovation and progress. By cultivating a team culture that views failure as a stepping stone to success, you'll be better equipped to tackle complex challenges, push boundaries, and deliver truly transformative solutions.

Remember, it's not about avoiding failure; it's about failing fast, learning faster, and continuously improving. The most innovative companies in the world, from tech giants to cutting-edge startups, have embraced this mindset. They understand that in the realm of data science, where we're often venturing into uncharted territory, failure is not just an acceptable outcome—it's often a necessary step on the path to groundbreaking discoveries.

As you lead your data science team, consider how you can create an environment where failure is not feared, but respected as a valuable teacher. How can you encourage your team to take calculated risks, to push the boundaries of what's possible, and to view setbacks as opportunities for growth?

How does your team handle project failures? Share your experiences and strategies in the comments below. Let's learn from each other and build more resilient, innovative data science teams together!

Data science work in commercial companies sits at a nexus of IT, data, ML/statistics and business. There are a lot of moving parts, and to consistently deliver successful data science projects, you need to get multiple things just right. And it’s not that easy.

So, what does it take to make a data science project successful? I'll share three of my biggest learnings below.

Don't Fight Windmills

As with so many things in life, data science project success is not primarily what you do (even though that's very important), but rather what you avoid doing. And the first thing you should avoid doing is inventing projects yourself. It's the quickest way to shoot yourself in the foot and set the whole team up for failure.

No, what you've read in a very exciting blog post somewhere is not going to work at your company. No, you cannot use that idea from that great talk you heard at that conference. And no, the project you want to do because you've always wanted to try out that cool modelling technique is not going to be successful.

Believe me, I'm talking from painful experience.

Your inspiration about problems that are worth solving should come from one source and one source alone: your business stakeholders. They're the only people with knowledge of pain points that you should be working on.

Here's another tip: they don't talk data science jargon. So read the quarterly business review numbers carefully, familiarize yourself with their KPIs, catch your stakeholders in lunch lines in the cafeteria (preferably in the middle of the queue, so they can't run away) and just talk to them about the problems they are facing. You'll be amazed at the number of useful data science project ideas you can generate out of those conversations.

It's not Data Science, It's Business Transformation

At first glance, it might seem obvious that a data science project should be run by the data science team. However, this common assumption is actually misguided.

Data science projects are usually very intimately connected to business. They are typically about making a certain process in business smarter or automating some decisions. For example:

• If you're modelling which clients will go to a competitor because of dissatisfaction (and what might persuade them not to), you're automating part of the work the customer experience department is doing.

• If you're predicting how much product you have to buy to keep your FMCG company's stock balanced, you're affecting inventory managers' day-to-day work.

And guess what? These business departments own the processes you're trying to change. They know best how to change them and have the proper authority to do so. They are the ones who should use your shiny product in the end. It was their domain before you came to do the project, and it will be their domain when you leave for the next big thing.

So, take a deep breath and repeat after me: It's not a data science project with a business component. It's a business transformation project with a data science component.

Once you make this mental shift, it becomes obvious: business should own the project and you should run it with them. This will involve them deeply in the project, shape the project so that it actually solves a real pain point, will make the whole thing more fun for you and the rest of the data science team, and deliver results.

Oh, and you won't be stuck with the impossible task of making a whole business transformation happen (to just implement a data science product) with no competence of the business or the authority to make changes happen.

Have a Really Multi-disciplinary Team

We all know you need data scientists and data analysts on the data science team. If you're up against a tough enough technical challenge, a data engineer or even a software engineer is warranted. And to be honest, this composition looked multi-disciplinary enough for me for way too long.

But having a strong technical team is only one half of the equation. If you've read through to here, you can probably guess where I'm going with this: if you're dealing with a business transformation, you need to have very strong business competence on the team. Otherwise, your brilliant technical solution might never deliver actual business value.

The typical way I've seen of incorporating business competence in a data science team is through two positions I'll outline below.

1. Data Science Delivery Manager

This person is the lynchpin of your operation. They know what data science can be used for and - no less importantly - what it cannot. They know the stages of a data science project and how to drive each one with maximum efficiency (or minimal drama). They can sniff out a brewing problem or an obstacle a mile away and prepare mitigations. They know who to involve at what point and in what capacity. And they're laser-focused on delivering value.

They are your orchestrators.

In my experience, they're also the hardest competence to find on the market. We've come to a point where data scientists are not that hard to come by - they even give out very high-quality bachelor’s degrees for that stuff these days. But DS delivery managers are - again in my experience - still a rare breed.

The obvious way to get them is to take a good IT project DM and retrain them in data science project delivery. Smart business analysts can also pivot into the role relatively easily. And I've heard of several companies that have full-blown internal academies to train people in this competence en masse.

2. Analytics Translator

As mentioned above, data science teams do not usually know much about the business they're working with. It becomes very easy to build a great solution to the wrong problem or worse, build a great solution to the right problem that cannot be deployed because some nuance in business process was not taken into consideration. So it's very important to have a very significant business competence represented in the team.

This role has evolved in recent years and has been called everything from analytics translator (which I like the most, to be frank) to connector. But the mandate is broadly similar everywhere: to understand the business context and the place of analytical solution in it, and use this knowledge to help shape the business processes and the solution in a symbiotic way.

There are many paths to analytics translator role, but in my experience it works best if this person (the more senior and experienced, the better) comes directly from the business you're working with. They leave their permanent post only temporarily for the duration of the project and will spend the majority of their time - preferably even 100% - on the project. They:

• bring the knowledge of the current business processes

• advise on the constraints your analytical product will have to be built around

• design the new business process that will incorporate your analytical product

• own and run the new business process once you're done with the project.

For example, if you want to build and effectively deploy a model that predicts call centre loads (to plan the workforce needs adequately), you want to get someone senior from the planning department. They will:

• Show you around and help you understand where they're having problems with planning and of what kind and where you could have the largest impact

• Give you clear directions of what the solution should look like (e.g., tell you that you need to predict loads in 30 minute chunks over the next two weeks cause this is how the operators' schedule is built every day)

• Define a "good enough" solution and validate the results of your model against it

• Help integrate the predictions in the planning process and train the planning department staff in the new process

• Own and monitor the performance of model-based planning and alert you if something goes wrong and needs attention

Conclusion

So there you have it: let business define projects, understand that you're doing business transformation, and bring a multi-disciplinary team with both technical and business competence to tackle the problem.

Have you bumped up against these challenges? How did you go about solving them? Share your experiences in the comments below, and let's learn from each other!

There is a step in every data scientist’s (otherwise mostly smooth) career that feels more like a profession change than a career progression, and it’s moving from data scientist to a data science manager. In my experience, it’s also the most dreaded level-up: I’ve guided a dozen people into this role by now and can only remember maybe a couple cases where the person embraced this change without serious doubts.

And no wonder. The skillsets for data scientists and data science managers are so intensely different that it does feel like you changed career and are now starting at the bottom of a new field with no experience and a whole lot of rookie mistakes to make. With real people now looking to you to take care of their careers. And your stakeholders holding you accountable for results. Oh, and no pressure.

So I’ve decided to write up some pointers on how to do it right. Or at least how to not mess it up completely.

Are You Sure You Want It?

As with most things in life, success in this transition depends on avoiding big pitfalls. And here’s the biggest one in this situation: stepping into the manager role solely because it’s the next step in your career, only to find out that you’ve exchanged doing what you’re great at and love for something that you’re not good at and don’t really like.

Don’t get me wrong, the role can be great. Heck, I’ve been doing it for 6 years now and love it. You get to:

• Develop as a leader and learn people management - a very interesting skillset in and of itself

• Work on data science strategy at a level you definitely would not be able to as a data scientist

• Lead, develop and nurture a lot of people and take part and joy in their success

• Work on a very wide range of problems (admittedly at a much more shallow level than before)

But hey - with rain comes some mud too. And here’s the mud of data science management you have to consider before taking the role:

• Zoom and Outlook will become your main tools: or put it another way, you’ll spend most of your time in meetings (and planning meetings), not actually coding solutions.

• You won’t be able to be hands-on anymore: if you manage over 10 people and you’re still meaningfully (>30%) hands-on day-to-day, you’re probably doing something wrong.

• You’ll have to network a lot more: As a data science leader, you’ll constantly have to be in the spotlight. On meetings with stakeholders, on corporate events, on conferences, with vendors… you name it.

• You’ll be responsible for career development of your reports: Suddenly you’re in charge of humans with very different temperaments, abilities and aspirations. And there’s no library you can download to abstract away this complexity. You’ll find out pretty quickly that we’re not an easy bunch to manage.

• You’ll have much wider responsibility for business success: You’ll be the face of your teams and solutions in the wider company. That means that a lot of times, you’ll have to take and absorb the heat from stakeholders, so that it does not reach and affect the team.

• You’ll have to have some tough conversations regularly: Sometimes you’ll have to let stakeholders know they’re overstepping boundaries, other times you’ll have to deny promotion requests, at times you’ll even have to let people go.

How About Becoming a Staff Data Scientist?

Before we talk about your transition to data science manager role, I want to cover an important point: let’s say you looked at all the pros and cons of this move and have decided that you don’t like it that much. Are you stuck?

Fortunately, you are not. Most sophisticated companies offer a staff data scientist (or similar) role, which is a more technical leadership role compared to data science manager role. As a staff data scientist, you’ll get to:

• Remain hands-on: Not only will you have the opportunity to stay mostly hands-on, but be expected and required to do so. After all, it’s in everyone’s best interests to employ your immense technical expertise for solving problems.

• Tackle the hardest problems: In this role you’re basically the navy seal of your data science org - you’re called to work on the hardest problems and are expected to deliver quality solutions.

• Be a leader: You’ll get to mentor and lead data scientists on a very personal level, all the while being free from people management and admin work.

• Have the same compensation opportunities: salaries for staff data scientist and data science manager roles are virtually identical, so you can be sure that you’re not missing out on compensation by staying in a more technical role

In short, staff data scientist role is every bit as important (and senior) for a mature data science org as data science manager role is. What’s different between them is the focus: staff data scientists mostly work on solving problems, while data science managers are mostly busy with managing people, stakeholders and strategy.

Making the Transition

And now to the main part of this post: you’ve found (or have been offered) a data science manager role, you’ve looked at the tradeoffs, decided that this is the right fit for you and are ready to dive in.

How do you set up yourself for success? It’s obviously an endless topic, but here are some big things to get right.

Network, network and then network some more

One of the largest new responsibilities you will have will be aligning your new team to business value. To do that, you will need to do two things.

Firstly, you should learn as much as you can about how your company works: how it makes (and loses) money, what are the biggest pain points, what’s the business development strategy for next three to five years, etc. The more knowledgeable you are about these matters, the better you can align with business strategy and enable your team to deliver results and earn them a good name inside the company.

Secondly, develop great relationships with your stakeholders. I mean be-the-biggest-hit-at-their-wedding kind of relationships if you can, but regular coffee sessions will do too. Your team’s success depends on how much business trusts you personally, so make sure you have them covered.

Learn People Management

If you’ve come this far, you’ve already read this a couple times, but this bears repeating: don’t get fooled by the fact that you’re formally “just stepping up to next level”. As already said, this is more like changing a profession than just stepping up. And you’ll need to learn tricks of this new trade from scratch.

Here are some ways to get ahead:

• Take leadership courses (Coursera is always a not-too-bad option) for general sense about what leadership is and how you should go about managing people.

• Find and use leadership development tools (such as Know Your Team) for more tailored approach and community you can ask questions to.

• Delve into psychometrics (like PrinciplesYou) to understand basic types of people, how to approach them and what are your strengths and development areas

• Read like there’s no tomorrow: there’s no shortage of great books on leadership and I won’t list them here since you can find endless great lists online, but I’ll mention one very unlikely book that is a great primer for new leaders: How to Talk So Kids Will Listen & Listen So Kids Will Talk

And last but definitely not the least…

Find a Mentor

Having a mentor is generally a really good idea, but it is especially important in the context of transitioning to people management: since there are a lot of unique situations you might have to deal with, there is only so much you can learn from formal courses (or online resources). Most of your people management skills will come from on the job training and if you’re not careful, it’ll mostly be learning-from-big-mistakes kinda training.

So, it’s especially important to have someone experienced you can discuss your unique people management situations with, get advice and bounce ideas. Ideally, this would be someone in your org. If you have a born-to-be-a-mentor type of manager, count yourself very, very lucky. But if not, try to find someone whose people management skills you really admire and consciously cultivate a mentor-mentee relationship with them.

Conclusion

Stepping up into a management role can look daunting, and it is. You’ll be given more power than you’re ready to handle, and certainly much more responsibility than you’re comfortable living with. You’ll make mistakes, and sometimes those mistakes will painfully affect people you care about. The professional world is full of stories of horrendous managers. One can’t help but ask: what if I slip into being one?

But it’s also a role that gives you the opportunity to be a positive force in a lot of people’s lives. The professional world is also full of stories of great leaders whose vision and care have been absolutely key to success of their people. So the real question you should be asking is this: what if you could become one?

Good luck on this journey.

Hey There!

Do you get this overwhelming urge every once in a while to start writing down what you’ve learned? You know, to clear your thoughts, to shape what you’ve picked up here and there into a coherent story, to share something useful to the world.

Happens to me like clockwork. So I’ve decided to give in and try.

I’m Mikheil (pronounced just like Michael), I’ve spent 10 years in data analytics at this point - pretty much all of it in financial industry - and currently lead a 80+ people team at Bank of Georgia, the largest bank in Georgia (the country!).

Leading data analytics teams is many things, and a lot of them start with “super”: super-fun, super-intense, super-rewarding, super-frustrating…. You get the idea.

It’s also super-uncharted. Ok, maybe not so dramatic, but it’s still respectably hazy. Technology is evolving at warp speed, talent is pouring in from all professions with wildly different experiences, businesses are as hyped as it gets but mostly don’t know how to actually squeeze value out of it, and good leadership in the area is scarce. It can feel overwhelming trying to run this freak show.

Of course it’s not that doom and gloom. A lot of voices have emerged and are bringing sanity to the field, but it’s still early in the game. This is why I’d like to contribute whatever I can.

So here’s my plan: I’ll write periodically about what I’ve learned leading data science teams over the years. It’ll definitely help me understand my own learnings better. And hopefully it can help you avoid some costly mistakes I had to suffer through. Or get some fresh ideas and perspective. Or commiserate.

Either way, hope this will be fun for all of us.