Measuring Technical Managers by Team Success

Hello again. In the previous lesson, we separated the ongoing accountability of a technical manager from the more bounded accountabilities of an IC, technical lead, and project lead. The central distinction was the manager’s sustained responsibility for a team’s ability to succeed across work, not merely for one design or delivery initiative.

This lesson develops the consequence of that distinction: a technical manager is primarily evaluated through team outcomes, not through their own volume of code, tickets, or individual technical heroics. That does not make technical judgment irrelevant. It changes where it is applied: toward creating clarity, capability, healthy execution, and reliable results through the team.

---

Change the unit of success

As an engineer, it is natural to connect success with artifacts you personally created:

• a Node.js service you shipped;
• an AWS deployment pipeline you improved;
• an incident you diagnosed;
• a difficult migration you completed;
• a design decision you made correctly.

These remain valuable contributions. They are simply no longer the main unit of success once you manage people. A technical manager’s unit of success is the team system: its ability to deliver valuable work reliably, make sound decisions, learn, collaborate, and sustain performance.

A useful contrast is:

Role orientation	Primary question
Individual contributor	“Did I deliver a high-quality contribution?”
Technical lead	“Did we choose and execute a coherent technical direction?”
Project lead	“Did this initiative achieve its agreed outcome?”
Technical manager	“Can this team repeatedly achieve valuable outcomes in a healthy, reliable way?”

This does not mean a manager can take credit for every team achievement, or blame the team whenever something goes wrong. Team outcomes are influenced by product strategy, organizational constraints, dependencies, staffing, and market conditions. The manager is accountable for recognizing those conditions, improving the ones within the team’s reach, escalating the ones outside it, and making trade-offs visible.

The practical test is revealing:

If you spend a week personally fixing a difficult production problem, the service may improve.
If you establish clear ownership, develop diagnostic capability, reduce recurring operational friction, and help the team prevent recurrence, the team improves.

The first is sometimes necessary. The second is managerial leverage.

This shift can feel uncomfortable because it replaces a direct, visible link between your work and the result with an indirect one. Your work is often coordination, coaching, decision clarification, staffing, feedback, expectation-setting, and obstacle removal. When done well, it may be less visible than writing a major feature, yet it raises the performance of several engineers over time.

A manager can still be technically credible and, in a small team, may still write code. But personal coding should be evaluated against its opportunity cost. If writing a feature causes missed one-to-ones, unclear priorities, delayed feedback, or unaddressed team conflict, it is not “extra” work; it is displacing the manager’s core work.

---

What counts as a team outcome?

A team outcome is an observable result achieved collectively, rather than a tally of individual activity. It connects the team’s work to a customer, product, operational, or organizational need.

For an engineering team, manager-relevant outcomes usually appear in four connected areas.

Area	Examples of team outcomes	What the manager is responsible for
Customer and business value	A capability reaches customers, adoption improves, a risk is reduced, or a product commitment is met	Aligning the team to the purpose, priority, and constraints of the work
Delivery performance	The team can move changes through development and release predictably	Making bottlenecks, dependencies, capacity limits, and decision delays visible
Quality and reliability	Changes are safe, production failures are reduced, recovery is effective	Ensuring ownership, appropriate standards, learning from failures, and risk-aware trade-offs
Team capability and health	Engineers grow, retention is healthy, knowledge is distributed, on-call load is sustainable	Developing people, addressing performance fairly, hiring, and creating a functional working environment

Notice that none of these say “manager has the highest commit count.” A manager may use technical evidence to understand the team’s environment, but should avoid confusing activity with outcome.

For example:

• Number of commits can rise because code is fragmented, not because value increased.
• Number of pull requests can rise because a team split work into smaller pieces, not because it is necessarily more effective.
• A rapid backlog burn-down can conceal quality problems, burnout, or work that did not matter.
• A lower deployment count may reflect a genuine bottleneck, but it may also reflect a deliberate period of platform stabilization.

Metrics are therefore signals for inquiry, not verdicts about individuals.

DORA makes this distinction especially clearly: its software-delivery-performance model is concerned with teams collectively changing and operating an application, rather than attempting to measure individual developer productivity.

Outcomes versus activity: a practical example

Suppose your backend team is responsible for a set of AWS-hosted APIs supporting account creation.

Here are two ways a manager might describe success:

Activity-centered framing	Outcome-centered framing
“I reviewed 80 pull requests and wrote the deployment automation.”	“The team reduced the time needed to release safe changes, while distributing deployment knowledge and reducing reliance on manual approvals.”
“I fixed the worst incident this quarter.”	“The team improved incident ownership and follow-up so that repeat incidents became less likely and recovery no longer depended on one person.”
“I assigned all tickets for the launch.”	“The team met the launch commitment with clear ownership, known risks, and a sustainable workload.”

The right-hand statements are stronger because they identify a lasting team capability. They also make room for individual contributors to own the technical work rather than placing the manager at the center of every accomplishment.

---

Measure performance at the right level

An engineering manager still needs evidence. “My team feels productive” is not enough for responsible management or a convincing interview answer. The goal is not to avoid measurement; it is to measure at the level where the manager can improve the system.

One useful structure has three layers.

1. Start with the intended outcome

State the result in language that matters beyond engineering.

For example:

Enable customers to receive account-verification updates faster without increasing production risk.

This is better than:

Implement asynchronous processing.

The latter may be a reasonable technical approach, but it is not the result the organization ultimately needs.

2. Choose a small set of evidence signals

For the outcome above, the team may track evidence such as:

• time from approved change to successful production deployment;
• failure or rollback trends following changes;
• customer-facing processing delay;
• support tickets related to delayed verification;
• operational load placed on the team.

The exact measures will differ by context. What matters is that they are examined as trends for a service or team, with enough context to interpret them responsibly.

3. Inspect the conditions producing the result

A manager should ask what within the team system is helping or limiting performance:

• Is work arriving with clear priorities and acceptance criteria?
• Are code reviews, test environments, or release approvals creating queues?
• Is critical knowledge held by one engineer?
• Does the team have the skills required by the roadmap?
• Are cross-team decisions waiting without an owner?
• Is on-call pressure reducing capacity for planned work?
• Are engineers able to raise risks early?

This third layer is where management happens. A metric does not improve because it appears on a dashboard. It improves when the team identifies a plausible cause, tries an appropriate intervention, and learns from the result.

GitLab’s published engineering-manager description offers one concrete organizational example. Its wording that the manager sees the team as their “product” is a useful mental model, while its performance indicators show that formal manager measures can include team flow, staffing, and retention rather than personal code output. These particular indicators are not a universal scorecard to copy; they are evidence of the level at which managers are commonly assessed.

Do not turn team metrics into individual quotas

A common management mistake is to start with team-level data, then rank engineers by a superficially similar individual count.

For example, if deployment lead time worsens, it would be poor reasoning to conclude that the engineer with the fewest commits is the problem. Their work could be blocked by:

• a long review queue;
• unclear requirements;
• a dependency on the platform or security team;
• a difficult operational issue;
• an unfamiliar area where they need support;
• too much work in progress across the team.

This is not an excuse to avoid individual accountability. Individual performance still matters, and managers must address it when expectations, support, and evidence are clear. The sequence matters: first understand whether the system is creating the observed pattern; then determine whether there is an individual expectation, skill, motivation, or performance issue to address. Later lessons will make that diagnosis more precise.

---

Use outcome mapping to connect management work to results

A manager needs a way to avoid two opposite errors:

1. focusing only on a distant business goal while ignoring the operational conditions needed to reach it;
2. focusing only on process improvements without being able to explain why they matter.

Outcome mapping links these levels. It begins with a desired result, identifies its benefits and obstacles, and then proposes concrete next steps.

The image’s key idea is that a manager should not start with a preferred solution such as “introduce a new CI tool.” Start with the outcome, examine the system constraints, then select an intervention.

Consider a simplified example for a backend team.

Desired outcome

Reduce the time from an approved code change to a safe production deployment for the account-verification service.

Benefits

• Faster feedback from real usage.
• More responsive delivery of product changes.
• Less uncertainty around launch commitments.
• Fewer large, risky batches of changes.

Likely obstacles

• Manual production approvals with no stated service expectation.
• Flaky integration tests.
• One senior engineer acting as the default reviewer for all risky changes.
• Deployment knowledge concentrated in the DevOps specialist.
• Too many parallel initiatives competing for the same people.

Possible managerial next steps

• Give one engineer ownership of mapping the release flow and its wait states.
• Establish a team agreement for review responsiveness and escalation.
• Protect capacity for stabilizing the most failure-prone tests.
• Pair engineers on deployments until ownership is distributed.
• Bring evidence of approval delays to the stakeholder who owns that dependency.
• Review the trend after an agreed interval and decide whether the intervention helped.

The manager is not necessarily the person automating the release pipeline. They are responsible for ensuring that the team has a meaningful outcome, clear ownership, enough capacity, support for the work, and an escalation path for obstacles outside the team.

This approach also prevents a subtle form of micromanagement: treating a manager’s preferred method as the outcome. An engineer may solve the release-flow problem differently from the approach you would have chosen. If the solution meets the agreed constraints for safety, operability, cost, and maintainability, that is often a success. The manager should set appropriate boundaries and challenge weak reasoning, not dictate every implementation detail.

---

Accountability is not control

A first-time manager can overcorrect after learning that their success is team-based. They may become passive:

“The team owns the delivery, so I should stay out of it.”

That is not the role. Accountability means actively shaping the conditions for success without taking ownership away from the people doing the work.

A technical manager should be able to say:

• “The team owns the technical implementation.”
• “A named engineer owns this decision.”
• “I own ensuring that the decision has the right context, expertise, time, stakeholder alignment, and escalation support.”
• “I will intervene when risk, unclear ownership, unsustainable load, or repeated blockage threatens the outcome.”

This is a balance between delegating work and retaining accountability for the team’s ability to perform.

The distinction becomes clearer in a delivery review. Suppose a service’s change lead time rose from a few days to two weeks.

An individual-output-focused manager might:

• request more status updates;
• push engineers to produce more code;
• personally approve every design;
• take over the most difficult tasks.

A team-outcome-focused manager would investigate the delivery system:

1. Confirm the trend, scope, and service affected rather than reacting to one delayed item.
2. Ask the team where work waits: refinement, review, testing, approvals, dependency handoffs, or release windows.
3. Identify whether the bottleneck is technical, organizational, capability-related, or caused by excessive work in progress.
4. Agree on one or two owned changes that address the most plausible constraint.
5. Revisit the evidence and decide whether to continue, adapt, or stop the intervention.

The manager may still need to make a difficult decision, negotiate scope, or escalate a blocked dependency. But their contribution is to improve the team’s capacity to solve the problem repeatedly, not merely to rescue the current release.

---

Turning this into an interview-ready management perspective

For technical-manager applications, avoid positioning yourself as the person who will personally solve every hard technical problem. That may reassure an interviewer that you are technically strong, but it can leave doubt about whether you understand the managerial transition.

A stronger answer has three parts:

1. State the principle.
   “I see a technical manager’s success primarily in the team’s ability to deliver valuable work predictably, safely, and sustainably.”

2. Explain how you would measure it.
   “I would look at customer or product outcomes alongside delivery and reliability trends, then use those signals to identify system constraints rather than treating activity counts as individual productivity scores.”

3. Show how you would act.
   “My role is to clarify outcomes, create ownership, develop capability, remove obstacles, and escalate cross-team risks. I stay technically involved enough to ask good questions and understand trade-offs, but I do not become the default implementer or decision bottleneck.”

Your project-lead experience can support this honestly. For example:

“In project coordination, I learned that delivery improved when ownership, dependencies, and risks were visible early. In a formal management role, I would extend that from one project to the team’s long-term capability: developing engineers, distributing knowledge, managing capacity, and using outcome trends to improve the system.”

That framing neither overclaims formal people-management experience nor reduces your experience to task coordination. It demonstrates that you understand the direction of the transition.

---

Key takeaways

A technical manager is successful not because they personally produce the most technical output, but because their team can achieve important outcomes repeatedly and sustainably.

Keep these principles in view:

• Measure at the team and system level. Delivery performance is a collective property, not an individual productivity ranking.
• Connect engineering measures to meaningful outcomes. Metrics should illuminate customer value, delivery flow, quality, reliability, and team capability.
• Use data with context. A weak-looking individual measure may indicate review delays, unclear priorities, dependency friction, or an unmet support need.
• Manage the conditions, not just the dashboard. Clarify outcomes, create ownership, develop capability, remove obstacles, and make trade-offs visible.
• Retain accountability without taking over. Delegate technical work and decisions appropriately while remaining responsible for the team’s ability to succeed.

Next, you will apply this role understanding to a job description: separating the requirements that define the real technical-manager role from preferences, title inflation, and unrealistic combinations of expectations.