How to Evaluate Your Manager on a Technical Team

“Is my manager actually good, or do I simply get along with them?”

That question is harder than it sounds. A friendly manager can still leave a team without direction. A demanding manager can help people grow, or merely normalize exhaustion. A technically brilliant manager may struggle to develop others. A nontechnical manager may create excellent conditions for technical judgment. Personality matters, but it is a poor measurement system.

For engineers, analysts, data scientists, product people, and AI practitioners, the useful test is not whether a manager matches an ideal personality. It is whether their behavior improves the environment in which consequential work gets done.

That distinction is increasingly important. Technical teams now work with AI assistants, agents, faster code generation, uncertain requirements, security constraints, and constant pressure to deliver more. Microsoft’s 2025 Work Trend Index found a striking capacity tension: 53% of leaders said productivity needed to increase, while 80% of the global workforce reported lacking enough time or energy for their work. A manager’s response to that tension tells you much more than their preferred leadership slogan.

Here is a scorecard for evaluating that response.

Do not score this after one unusually good or bad week. Look for repeated behavior across deadlines, disagreements, planning cycles, incidents, and one-to-one conversations. Management quality is a pattern.

1. Direction should survive a busy Tuesday

The first test is simple: can team members explain what matters now?

This is not the same as remembering a roadmap or reciting quarterly objectives. Direction is useful when it helps someone make a tradeoff without waiting for another meeting. If an engineer has time to fix either a recurring reliability problem or a cosmetic issue requested by a senior stakeholder, does the team have enough direction to choose? If an analyst discovers that the requested metric is built on weak data, can they pause and investigate? If an AI prototype produces impressive answers but fails basic evaluation cases, is the priority still launch speed?

A good manager turns broad strategy into a small number of operating choices. They explain which outcome matters, which constraints cannot be ignored, and what the team is deliberately not doing. When circumstances change, they update the choice and explain why.

A weak manager treats direction as a mood. Monday’s priority is replaced by Tuesday’s executive request, which gives way to Wednesday’s customer escalation. The team stays active, but nobody can tell whether the activity compounds.

Ask yourself:

• Can I name the top two or three outcomes my manager is protecting?
• When priorities conflict, do I know which principle resolves the conflict?
• Does changed direction come with an explanation, or only a new deadline?
• Can the team decline work that does not fit?

If the answers are mostly no, the issue is not merely communication style. The team lacks a decision system. How AI Teams Protect Important Work From Daily Noise offers a more detailed outcome filter for this exact problem.

2. Context is more valuable than constant supervision

Managers often possess information that individual contributors do not: commercial commitments, budget limits, political sensitivities, customer history, regulatory concerns, and dependencies across teams. Their value is not in hoarding that information. It is in translating the relevant part into context people can use.

Suppose a data team is asked to rebuild a forecasting pipeline in six weeks. Useful context includes why six weeks matters, which users depend on it, what error is tolerable, which legacy behavior must remain, and whether the date is fixed or negotiable. Without those facts, the team cannot make responsible design choices. It can only guess and hope.

AI-assisted work makes context more important, not less. A coding assistant can produce an implementation quickly, but it does not automatically know the organization’s threat model, maintenance burden, customer promises, or appetite for operational risk. An agent can execute a workflow, but someone must define its permissions, approval points, and failure boundaries. Managers do not need to dictate every prompt or architecture choice. They do need to make the business and risk context available.

Look for a manager who answers “why” before monitoring “how.” They should share enough information for the team to exercise judgment while protecting genuinely confidential matters. Late disclosure is a warning sign, especially when it makes previous work obsolete or turns an ordinary delivery into an emergency.

3. Autonomy should expand with evidence

There are two easy ways to manage technical people badly. One is to prescribe every step. The other is to call neglect “empowerment.”

Healthy autonomy sits between them. The manager defines the outcome, constraints, review points, and decision rights. The person closest to the work chooses the method where their knowledge is strongest. As capability and trust grow, the review burden can shrink. When risk rises, oversight should increase without becoming personal.

Consider three different tasks:

• Drafting an internal meeting summary with an approved AI tool may need only human review.
• Changing a production data pipeline needs tests, peer review, and a rollback plan.
• Giving an agent permission to update customer records needs explicit access limits, logs, evaluation, and human approval for consequential actions.

Using the same management style for all three would be careless. Good managers calibrate control to consequence, reversibility, and the person’s demonstrated capability. They explain the calibration so that review does not feel arbitrary.

This also means allowing more than one sound technical route. A manager may have written production code for years and still need to let another engineer choose a different framework. Their role is to challenge assumptions and protect constraints, not reproduce their own career through everyone else’s hands.

The counter-test is important: when you ask for help, does the manager engage? Autonomy is not being left alone with an impossible dependency, an unresolved stakeholder conflict, or authority you do not actually possess.

4. Prioritization must remove work

Many managers are good at ranking tasks. Far fewer are willing to reduce commitments.

That difference matters because a numbered list of twenty urgent items is still overload. Real prioritization changes what people do. It postpones a feature, narrows a launch, assigns a different owner, renegotiates a date, or stops an experiment whose learning value has run out.

The manager does not control every demand, but they should make the capacity problem visible and use their authority to force tradeoffs. “Do your best” is not a decision. Neither is encouraging people to use AI so that an impossible workload appears plausible.

AI can reduce effort in parts of a workflow, but local speed often creates new review, integration, and governance work. Generated code must be understood and tested. Automated analysis needs source and definition checks. An internal assistant needs permissions, evaluation, monitoring, and ownership. Microsoft reports that managers expect AI training and upskilling to become a larger team responsibility; that capability building also consumes real capacity.

Watch what happens when the team is full. Does your manager negotiate scope, or ask for invisible overtime? Do they protect reliability and documentation, or cut only the work stakeholders cannot see? Do they acknowledge the opportunity cost of a new AI experiment? Their answers reveal whether they manage a system or merely transmit demand.

5. Candor should be safe before it becomes expensive

Technical teams need people to say uncomfortable things early:

• The model is not reliable enough for this use case.
• The deadline assumes data we do not have.
• The new tool introduces a security risk.
• The metric does not measure the stated outcome.
• I made an error and need help correcting it.
• The team does not understand who owns this decision.

A good manager makes those statements easier to raise and harder to ignore. They do not promise agreement, but they separate the messenger from the problem. They ask for evidence, clarify the consequence, and decide what happens next.

The strongest evidence appears after someone brings bad news. Does the manager become curious or search for blame? Do they communicate the risk upward honestly? Do they later use the incident to improve the system, or use it to warn everyone against speaking freely?

Candor also runs downward. Employees deserve specific feedback, including difficult feedback. Vague reassurance followed by surprise consequences is not kindness. A capable manager names the behavior, its effect, the expected change, and the support available. They leave room for the employee’s evidence because managers can be wrong too.

This is not a demand for a conflict-free team. Productive teams disagree. The relevant test is whether disagreement produces a clearer decision or a quieter room.

6. Growth should appear in the work, not only the review form

Career development is often discussed annually and crowded out weekly. That is too slow for modern technical work, where tools and responsibilities can change within months.

The CIPD Good Work Index 2025 found that workers with more positive views of their line managers were more likely to feel effective and less likely to consider leaving. The report also noted improvement in manager support for learning and development. That relationship makes intuitive sense: growth becomes credible when a manager can connect future capability to present work.

Look for three forms of evidence.

First, feedback is timely. You learn what worked and what needs adjustment close enough to the event to act on it.

Second, assignments stretch capability with support. Someone who wants to lead may own a bounded cross-team decision. An analyst moving toward data engineering may take responsibility for a small production pipeline with review. An engineer learning AI reliability may build evaluation cases and trace failure categories rather than merely watch another course.

Third, invisible contribution counts. Documentation, mentoring, incident prevention, careful review, and simplifying a fragile system should influence how performance is understood. If promotion rewards only visible launches, the team will learn to neglect the work that keeps launches safe.

A serious warning sign is the competence tax: the most reliable person receives every rescue task and no protected growth. More responsibility can support development, but only when authority, recognition, learning, and workload change with it.

7. Accountability begins with the person who has authority

Managers operate inside imperfect organizations. Their own leaders may change priorities, deny resources, or make weak decisions. A fair evaluation must account for those constraints.

But constraint does not erase responsibility. A manager’s job is to convert organizational pressure into usable decisions. They should distinguish what is fixed from what can be negotiated, represent the team’s evidence upward, and communicate the final choice honestly. They should not pretend every poor decision originated elsewhere while claiming every success as leadership.

The clearest test is what happens at the boundary of authority. Does the manager make the decisions only they can make? Do they resolve ownership conflicts? Do they defend an agreed priority when a louder stakeholder appears? Do they admit when they made the wrong call? Do they give the team credit in rooms the team cannot enter?

This is where a merely pleasant manager and a useful manager often separate. Empathy without responsible action feels supportive for a while, but it cannot protect a team from chronic ambiguity. Authority without empathy may produce compliance, but it suppresses the information needed for good decisions. Technical leadership requires both.

For the manager’s side of this operating challenge, see The AI Manager’s Operating System for Better Teams and Why Middle Managers Matter More in AI-Heavy Teams.

Turn the scorecard into a conversation

The scorecard is not a personality verdict, and it should not be used to diagnose someone from a distance. Choose one repeated behavior that affects your work and bring a specific request.

Instead of “priorities are always unclear,” try: “We currently have three items described as urgent, but capacity for one. Can we decide which outcome wins and what moves?”

Instead of “you micromanage me,” try: “Can we agree on the constraints and review point, then let me choose the implementation?”

Instead of “I have no growth here,” try: “I want to become stronger at production AI evaluation. Which upcoming assignment could let me own a bounded part of that work, and what evidence would show readiness for more?”

Then watch the response over time. One awkward conversation does not prove a manager is poor. A manager may need clearer evidence or operate under constraints you cannot see. What matters is whether the conversation produces a decision, experiment, explanation, or follow-up.

You should also apply the tests in reverse. Are you giving your manager early information? Do you explain tradeoffs instead of presenting only frustration? Do you own agreed outcomes, ask for help before a deadline collapses, and make your growth goals concrete? Employees do not control the management system, but they influence the quality of information inside it.

If repeated, specific attempts produce retaliation, deception, unsafe demands, discrimination, or no meaningful change, the problem may be larger than a working-style mismatch. Document facts, understand formal escalation options, and assess whether transferring or leaving is realistic. No scorecard can repair an organization that punishes honest evidence.

Judge the environment the manager creates

There is no ideal manager for every person, team, and moment. A new team may need more structure. An experienced group may need more space. An incident demands tighter coordination than routine delivery. A manager’s technical depth matters differently in a research group, platform team, analytics function, or product organization.

The stable standard is the environment their behavior creates.

Can people understand what matters? Do they have the context to make sound decisions? Does autonomy grow with evidence? Are commitments reduced when capacity is full? Can risks travel before they become expensive? Does today’s work build tomorrow’s capability? Does the person with authority accept responsibility?

You do not need a flawless score. You need enough repeated evidence to decide whether the relationship can improve, whether the team remains a place to grow, and what conversation should happen next.

A good manager is not simply someone you like, fear, admire, or agree with. They make good work more possible—and make the conditions for that work visible enough to evaluate.