Managers Must Lead AI Work, Not Just Supervise It

Technical teams do not need managers who only maintain the calendar, assign tickets, and report progress upward. They also do not need leaders who speak in vision language while ignoring delivery, quality, security, and people constraints.

They need both kinds of work done well.

That sounds obvious, but a lot of workplace advice still treats management and leadership as if they are separate identities. One person is supposed to be the organizer. Another is supposed to be the visionary. One cares about execution. Another cares about change. One keeps the machine running. Another points to the future.

In real technical work, that split breaks down quickly.

The same person who helps a team choose a direction may also need to fix the operating rhythm that makes the direction possible. The same manager who protects a roadmap may need to challenge the roadmap when customer behavior, model quality, or business risk changes. The same technical lead who inspires people to try a new AI workflow may need to define evaluation criteria, access controls, rollback rules, and the boring review process that keeps the workflow from creating new problems.

The title on the organization chart matters less than the responsibility in front of you. If the team is building software, data products, AI systems, dashboards, automations, or internal tools, someone has to connect direction with execution. That is the work.

The label matters less than the outcome

The management-versus-leadership debate can be useful when it reminds us that people are not machines. A team needs purpose, trust, communication, and judgment. It is not enough to move tasks across a board.

But the debate becomes less useful when it turns into a status game.

Some people use “manager” as if it means administrator. Some use “leader” as if it means someone above ordinary operational work. Both versions are weak. A technical manager who cannot lead through uncertainty will become a bottleneck. A leader who cannot manage commitments, resources, quality, and follow-through will produce confusion.

Modern teams feel this especially strongly because the work is more interconnected than it looks. A small AI feature may involve product decisions, data permissions, model selection, prompt and context design, evaluation, logging, legal review, user education, incident response, cost monitoring, and support handoff. Calling that only “management” or only “leadership” misses the point.

The useful question is not, “Am I acting like a manager or a leader?”

The useful questions are more practical:

• Does the team know what problem matters most?
• Do people understand why this work is worth doing?
• Is the operating system strong enough to deliver it?
• Are risks visible before they become production failures?
• Are we learning from evidence, or just defending the original plan?
• Are people protected from chaos while still being held to a serious standard?

Those questions require both direction and discipline.

AI makes the combined role harder to avoid

AI has made this issue more visible because AI work touches both strategy and operations at the same time.

A company can buy access to strong models, deploy copilots, approve an agent platform, or encourage employees to experiment. That does not automatically change how work happens. Someone still has to decide which workflows should change, which tasks should stay human-led, how quality will be measured, where sensitive data can go, and what happens when the system is wrong.

Microsoft’s 2025 Work Trend Index described a move toward human-agent teams and reported that many leaders expected agents to become part of company strategy. McKinsey’s 2025 State of AI research made a related point from a different angle: organizations seeing stronger AI impact were more likely to redesign workflows, scale practices, and show senior-leader ownership. Access to tools was not the same as value.

That is exactly where technical managers get tested.

If they act only as supervisors, AI adoption becomes a collection of disconnected experiments. One team uses a coding assistant heavily, another avoids it, a third pastes sensitive data into the wrong tool, and a fourth launches a chatbot nobody trusts. The manager tracks activity and calls it progress.

If they act only as vision speakers, AI adoption becomes theater. The team hears that everything will be transformed, but nobody has time to clean the knowledge base, write evaluation cases, define safe use, or change the review process. People become tired of the language because the day-to-day work did not improve.

The better role is more demanding. A technical manager has to lead the change and manage the system that makes the change real.

That may mean choosing one painful workflow and improving it properly instead of announcing ten AI initiatives. It may mean saying no to an agent where deterministic software would be safer. It may mean letting a team experiment for two weeks, then asking for evidence instead of enthusiasm. It may mean defending the time needed to document failures, not just the time needed to build the demo.

This is not glamorous work. It is the work that decides whether AI becomes useful or just expensive.

Direction without discipline turns into noise

A leader can create energy around a direction. That matters. Technical teams often need help understanding why a change is happening, especially when the change touches identity, skill, autonomy, or job security.

But direction without discipline creates noise.

Suppose a data team is asked to “use AI to make analytics faster.” That sounds reasonable, but it is not yet a plan. Faster for whom? Analysts writing SQL? Business users asking questions? Executives waiting for summaries? Support teams reviewing customer feedback? What level of accuracy is acceptable? Which data can the model access? Who reviews the output before a decision is made?

Without those questions, the team may build something visible but not useful. They might create a natural language dashboard assistant that works on demo questions but fails when a user asks about ambiguous metrics. They might generate summaries that sound confident while quietly mixing time periods. They might automate reporting but leave no audit trail for how numbers were interpreted.

The manager’s job is not to destroy momentum with endless caution. It is to turn direction into a working system.

That usually requires a few concrete moves:

• Define the user and the decision the system supports.
• Name the quality standard before building the demo.
• Separate retrieval quality, model behavior, and user experience.
• Decide what a human must approve.
• Track cost, latency, adoption, and failure categories.
• Review whether the workflow improved, not just whether the tool was launched.

This is management in the best sense: making the work executable. It is also leadership, because the team learns what seriousness looks like.

People pay attention to what managers ask about. If the manager only asks, “Did we ship?” people optimize for shipping. If the manager also asks, “What did we learn, what failed, who was affected, and what will we change?” people learn to treat quality as part of the mission.

Process without judgment becomes bureaucracy

The opposite failure is also common. A manager can build a process so heavy that people stop thinking.

This happens when management becomes a defensive posture. Every decision requires a meeting. Every experiment requires a long form. Every tool needs approval from people who do not understand the work. Every incident produces another checklist. Eventually the team follows the process because it must, not because the process helps.

AI governance can fall into this trap quickly.

Some governance is necessary. Teams need clear rules for confidential data, customer information, intellectual property, regulated decisions, vendor approval, logging, monitoring, and human review. A casual attitude toward AI tools can create real security and privacy risks. DataTweets has already covered this from another angle in why shadow AI is a signal, not just a security problem.

But governance has to support useful work. If the approved path is slow, unclear, and disconnected from real workflows, people will create unofficial paths. They will use personal accounts, copy data into external systems, or build local scripts that nobody reviews. Not because they are reckless, but because the official system made responsible behavior too hard.

This is where leadership judgment matters. The manager has to ask whether the process is reducing risk or merely moving risk out of sight.

A good technical leader does not choose between speed and control as if only one can exist. They design a better default. For example, they might provide an approved AI workspace with clear data boundaries, template prompts for common workflows, examples of acceptable and unacceptable use, a lightweight review path for new tools, and a channel where people can ask questions without being treated as rule breakers.

That is still management. It is also leadership because it shapes behavior through clarity instead of fear.

The real job is to serve the work and the people affected by it

Technical teams can become very internal. They discuss architecture, models, tickets, platforms, frameworks, deployment pipelines, and roadmaps. All of that matters. But the work exists because someone outside the immediate team needs a result.

For a data team, that person may be an operations manager trying to understand delays. For an AI product team, it may be a customer support agent who needs a safer way to find policy answers. For a software team, it may be a user trying to complete a task without friction. For a platform team, it may be internal developers who need reliable infrastructure.

Management and leadership both improve when this external reality is clear.

If the team is only managing the backlog, it may deliver work that no longer matters. If the team is only chasing a vision, it may ignore the constraints that make the vision usable. The discipline is to keep asking, “Who is this for, what changes for them, and how will we know?”

That question is especially important with AI because AI projects can look impressive before they are useful. A demo can answer a sample question. An agent can complete a scripted task. A summarizer can produce fluent text. A coding assistant can generate a pull request. None of that proves the workflow is better.

The proof is closer to the user:

• Did the support agent resolve cases faster without giving unsupported answers?
• Did the analyst spend less time cleaning repeated requests and more time on judgment?
• Did the engineering team reduce review burden without increasing defects?
• Did the customer understand the recommendation and know when to trust it?
• Did the manager gain visibility into risk without adding pointless reporting?

These questions move the conversation from identity to responsibility. The manager is not trying to perform the role of “leader” or “operator.” The manager is trying to make the work serve the right people.

Human-agent teams need human accountability

One reason the old distinction feels stale is that the nature of teamwork is changing.

Many technical teams now work with AI assistants for coding, writing, analysis, support, design, and documentation. Some are experimenting with agents that can call tools, search documents, update tickets, generate tests, or draft pull requests. The phrase “human-agent team” can sound futuristic, but the practical version is already ordinary: people delegate pieces of knowledge work to systems that are fast, helpful, and sometimes wrong.

This does not remove management. It changes what must be managed.

Someone has to decide which tasks are safe to delegate. Someone has to define what counts as acceptable output. Someone has to monitor whether people are overtrusting the system or avoiding it because it does not fit their work. Someone has to make sure junior people still learn the underlying skill instead of only learning how to accept suggestions. Someone has to decide whether time saved by AI becomes better work, more work, or just invisible pressure.

That last point matters. AI can quietly increase workload. A person saves time on drafting but now receives more requests. A developer uses a coding assistant but spends more time reviewing generated code. A manager gets automated summaries but now has more dashboards to interpret. A team ships faster but creates more support and quality work downstream.

Leadership is needed to name the tradeoff. Management is needed to redesign the workflow.

For example, if a team adopts AI-assisted code review, the manager should not only ask whether reviews are faster. They should ask whether defect rates changed, whether reviewers feel more or less focused, whether generated comments are useful, whether security issues are being missed, and whether engineers are still having the design conversations that matter. Speed is one metric. It is not the whole outcome.

This is why practical AI skills matter for leaders as well as individual contributors. A manager does not need to become the deepest model engineer on the team, but they should understand enough to ask informed questions about evaluation, context, data quality, tool permissions, costs, and failure modes. The same principle applies to learners building careers, which is why I also think practical AI skills need proof, not just vocabulary.

A useful operating model for technical managers

The answer is not to combine every responsibility into one exhausted person. Good management also means building systems so the team can share responsibility intelligently.

A practical operating model can be simple.

First, define direction in plain language. Avoid slogans. A good direction sounds like a decision: “We are using AI this quarter to reduce repetitive support research, not to automate final customer responses.” That sentence gives people more guidance than a broad statement about transformation.

Second, translate the direction into work boundaries. What data is allowed? Which tasks are in scope? What must remain human-approved? What will not be automated? Which quality bar must be met before rollout?

Third, assign ownership to real people, not committees. One person may own evaluation, another data access, another product feedback, another deployment reliability. Shared work still needs clear edges.

Fourth, create feedback loops. Review examples, failure cases, customer reactions, support tickets, cost reports, and team health. Do not wait for a quarterly review to learn that the system is being ignored or misused.

Fifth, change the plan when the evidence changes. This is where leadership becomes visible. A manager who never changes direction is not strong; they may simply be defending sunk cost. A manager who changes direction every week is not adaptive; they may be creating instability. The mature behavior is to explain what changed, why it matters, and what the team will do next.

Finally, protect attention. Technical teams cannot do thoughtful AI work while drowning in meetings, urgent requests, and unclear priorities. If everything is important, evaluation will be skipped, documentation will be rushed, and governance will become a slide rather than a practice. The manager has to make room for the work that prevents future damage.

This operating model is not complicated. The hard part is consistency.

Career growth comes from owning the gap

For individual contributors, this lesson matters too.

You may not have the title of manager. You may not control budget, staffing, performance reviews, or strategy. But you can still practice the useful middle ground between direction and execution.

If you are an engineer, do not only say, “We should use an agent.” Show the workflow, the failure cases, and the review plan. If you are a data analyst, do not only build the dashboard. Explain which decision it supports and where the data is weak. If you are a data scientist, do not only report model performance. Explain what the metric misses and how the system should be monitored after deployment. If you are a product manager, do not only request an AI feature. Define the user problem clearly enough that the team can decide whether AI belongs there at all.

This is how people grow into technical leadership before the title arrives.

Many careers improve when someone starts owning the gap between “what we want” and “what will actually work.” That gap is full of unglamorous questions: Who needs to decide? What evidence is missing? What risk is being ignored? Which dependency will block us later? What must be documented? Which shortcut is acceptable, and which one will punish us in production?

These questions are not always rewarded immediately. Sometimes they are annoying. But serious teams learn to value the person who can connect ambition with reality.

The best technical leaders do not hide behind the title

The lesson I take from the management-versus-leadership debate is not that the distinction is worthless. It is that the distinction should not become an excuse.

Do not avoid direction because you are “just managing.” Do not avoid operational discipline because you are “leading.” Do not accept a broken workflow because the job description sounded narrower. Do not push a fashionable change when the evidence says the current system works better than the proposed replacement. Do not preserve a process just because it already exists.

Technical work needs people who can look at the situation clearly and do what the work requires.

Sometimes that means setting direction. Sometimes it means removing confusion. Sometimes it means slowing down a risky launch. Sometimes it means pushing past comfortable maintenance because the system is no longer serving users. Sometimes it means telling a team that AI is useful for one part of the workflow and inappropriate for another. Sometimes it means admitting that the tool is not the hard part; the hard part is changing how people collaborate, review, decide, and learn.

That is not a clean identity. It is a responsibility.

For AI, data, and software teams, the future will not belong only to the people with the boldest strategy language or the tightest process documents. It will belong to people who can connect strategy with execution, tools with judgment, and ambition with evidence.

Call that management if you want. Call it leadership if you want.

The team probably cares less about the label than whether the work gets better.