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

Girl Molding Clay | Quino Al on Unsplash

This post is part of the "Becoming a Data Science Manager" series, where I explore the nuanced journey from individual contributor to data science manager, sharing insights and strategies for success learned from the trenches.

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

1. I should mention that this is not a one-size-fits-all: to not overcomplicate the framework, I’ve so far portrayed the whole team as a monolith. But your team members will for sure have different levels of professional maturity, so your approach to what work can be safely delegated can vary from person to person.