What Should a Data Science Manager Actually Do? The Role Transition from Executor to Enabler

A Real Dilemma: "What Am I Supposed to Be Doing?"

Recently, a candid post from a data science manager on Reddit struck a chord with many. This DS manager at a mid-sized company described his daily routine: weeks filled with meetings, while all the actual data science work was handled by his reports — even Sprint management was run independently by the team. His question cut right to the core:

"So what exactly am I supposed to do? My calendar has tons of free time and I don't know how to fill it. I feel like a spectator watching a movie."

Sprint is a core concept in the Scrum agile framework, referring to a fixed timebox (typically 1–4 weeks) during which a team completes a set of predefined tasks. In data science teams, Sprints usually involve phased deliverables such as data exploration, feature engineering, model training, evaluation, and deployment. When team members can manage Sprints on their own, it means they've developed the maturity to break down tasks, prioritize, and self-coordinate — what agile practitioners call a "self-organizing team," which is actually the ideal state that the Scrum framework strives for.

This question might seem like a personal career crisis, but it actually reveals a role identity misalignment that's common among those transitioning from technical expert to manager. Many newly promoted data science managers still measure their value through an "executor" mindset — and when they're no longer writing code or running models themselves, they experience a powerful sense of uselessness.

A Manager's Value Isn't About Being "Busy" — It's About "Leverage"

If a DS manager's team can independently manage Sprints and complete technical work on their own, that's actually proof that the manager's prior team-building efforts were successful. The highest form of management is creating a system that runs efficiently without constant personal intervention.

From "Doing Things Yourself" to "Amplifying Team Output"

The value of engineers and data scientists is linear: output is directly proportional to how many analyses one person can do or how many models they can train. A manager's value, on the other hand, should be leverage-based — multiplying value by improving the output efficiency of every person on the team.

This concept was first systematically articulated by former Intel CEO Andy Grove in his classic book High Output Management. Grove argued that a manager's output equals the output of the organization they're responsible for, not the work they personally complete. He used the concept of "managerial leverage" to measure how much each management activity amplifies total team output. For example, a high-quality one-on-one conversation might help an engineer avoid weeks of misdirection — that's a high-leverage activity. A manager personally fixing a bug, on the other hand, has extremely low leverage. This philosophy profoundly shaped Silicon Valley's management culture and provides a theoretical framework for data science managers to reassess their own value.

When you feel "idle," the real question isn't "What specific task should I be doing?" but rather "What can I do to improve overall team effectiveness by 10%?" These two questions reflect fundamentally different ways of thinking.

Four Areas Where Data Science Managers Should Actually Invest Their Time

1. Advocating Externally for Resources and Expanding Influence

The value of a data science team often needs to be "translated" for business stakeholders and senior leadership to understand. One of a manager's core responsibilities is serving as the bridge between the team and the rest of the organization:

Securing more budget, compute resources, and headcount from leadership
Helping business units understand data science's capabilities and set realistic expectations
Proactively identifying high-priority projects that can genuinely create business value

That "free time" should be spent building relationships with cross-functional leaders in product, business, and engineering to create more meaningful work opportunities for the team. This cross-departmental communication skill is often called "Technical Evangelism" in many organizations. It not only increases the data science team's visibility within the organization but also ensures the team's work direction stays aligned with the company's core business objectives.

2. Looking Ahead: Strategic Planning and Technical Direction

While direct reports focus on "how to do the current task well," managers should be thinking about "where should the team be heading in six months or a year":

What technical capabilities should the team build? Is it time to explore LLM, MLOps, or other new directions?
Will the current data infrastructure become a bottleneck in the future?
Which repetitive tasks can be eliminated through tooling and platform development to free up the team's energy?

The judgment around new technical directions deserves further elaboration. LLM (Large Language Models) represent the most transformative AI technology in recent years, with GPT, LLaMA, and Claude as prominent examples. For data science teams, adopting LLMs means mastering an entirely new skill stack including prompt engineering, Retrieval-Augmented Generation (RAG), fine-tuning, and model evaluation. MLOps (Machine Learning Operations) is the engineering practice framework for machine learning, covering model version management, automated training pipelines, model monitoring and drift detection, A/B testing, and more. An organization's MLOps maturity directly determines whether a data science team can reliably transform lab results into production systems that run continuously. Both represent critical capability upgrades as data science teams evolve from "doing analysis" to "building systems."

Regarding data infrastructure bottlenecks — this is the most common systemic obstacle data science teams encounter as they scale. Typical symptoms include: data warehouse query speeds degrading sharply as data volume grows, lack of a unified Feature Store causing redundant work across projects, absence of data quality monitoring leading to "garbage in, garbage out," and poor compute resource scheduling resulting in GPUs sitting idle while jobs queue. Modern data teams typically need to invest proactively in lakehouse architectures (such as Databricks Lakehouse, Snowflake), real-time data pipelines (such as Kafka, Flink), and feature platforms (such as Feast, Tecton). These infrastructure decisions are precisely the kind of strategic matters that require a manager to drive and decide on.

This kind of strategic thinking rarely makes it onto a calendar, yet it's what determines the team's long-term competitiveness.

3. Looking Inward: Talent Development and Team Building

This is perhaps the area technical managers most easily overlook, yet it offers the highest return on investment:

One-on-ones: Regular deep conversations with each team member to understand their career aspirations, obstacles, and growth needs
Career development planning: Helping high performers map out promotion paths and building a pipeline of future technical leaders
Removing obstacles: Proactively identifying and eliminating process, tooling, or collaboration issues that hinder the team's work

When team members feel they're growing and supported, both retention rates and output quality improve significantly. In today's fiercely competitive data science talent market, where hiring cycles for senior data scientists and machine learning engineers can stretch on for months, the ROI of developing and retaining existing talent far exceeds that of constantly recruiting new hires. Every investment a manager makes in talent development builds organizational capabilities that can't easily be replicated by competitors.

4. "Meta-Work" That Elevates Team Quality

Even without writing code personally, a data science manager can still ensure quality at a higher level:

Establishing and optimizing standardized processes for code review, experiment design, and model deployment
Participating in technical architecture discussions for key projects, using experience to help the team avoid detours
Building the team's knowledge base and best practices to reduce the cost of repeated mistakes

The term "meta-work" here refers to investments that don't directly produce business results but systematically improve the quality of all future work. For example, establishing a standardized experiment tracking process (using tools like MLflow or Weights & Biases) gives the team a reliable reference during model iteration, avoiding the maddening chaos of "what were the parameters for that model that worked well last week?" Similarly, creating a clear model deployment checklist — including data distribution checks, bias audits, performance baseline comparisons, and rollback plans — transforms individual experience into an organization-level quality assurance mechanism.

Beware the Trap of Micromanagement

It's worth emphasizing that feeling idle does not mean you should start "stealing" your reports' work. When a manager gets anxious and re-inserts themselves into hands-on technical execution, it usually backfires — undermining the team's autonomy while pulling the manager away from their proper value position.

Micromanagement is defined in organizational behavior as a pattern where managers excessively control and intervene in the details of subordinates' work. Research from Harvard Business School shows that micromanagement significantly reduces employees' intrinsic motivation and creativity, with particularly damaging effects on knowledge workers. In data science, tasks like model design and feature engineering are highly dependent on individual creative judgment, and excessive intervention causes team members to regress from "proactive thinkers" to "passive executors." Self-Determination Theory in psychology identifies autonomy as one of the three core needs driving human intrinsic motivation — and micromanagement fundamentally destroys this need.

The truly healthy state is: Your team can operate normally without you present, and you invest the freed-up energy into high-leverage matters that only a manager can handle.

Redefining "Valuable Busyness"

This Reddit user's dilemma is, at its core, an opportunity for a role identity upgrade. Shifting from "Am I not doing anything?" to "Am I creating more space for my team?" is a mental leap that every technical manager must make.

This transition has a classic analogy in management theory: from "chess player" to "game designer." A chess player focuses on what move to make next, while a game designer focuses on whether the rules are fair, whether the board is large enough, and whether the participants have the skills they need. The role evolution of a data science manager works the same way — you're no longer the one playing the game, but the one ensuring the entire game is played brilliantly.

If you've ever felt lost in a management role, remember this: When your team is running efficiently and you feel idle, that's not a sign of failure — it's an opportunity to do more important things. Great data science managers never measure themselves by how much code they personally write, but by how much further and more steadily they help their entire team go.