How to improve team delivery performance

Improving team delivery performance starts from a specific, counterintuitive fact that Asana CPO Arnab Bose names directly: individual engineers are often already shipping faster with AI, while the team around them, per his read of the data across Asana's own customer base, is not.

You need a baseline that measures the team's end-to-end delivery, not any single engineer's output, and a way to distinguish real acceleration from more activity that doesn't actually ship. Without both, the steps below will look like they're working when they aren't.

Arnab Bose, Chief Product Officer at Asana, names the trap directly, from watching it happen across the customers his product serves.

"The individual within companies is now able to produce more work, and probably higher quality work. But overall, when you take a look at a workflow that a group of knowledge workers have to build out end to end, those workflows are not actually being accelerated by AI as yet."

— Arnab Bose, Chief Product Officer at Asana, on Dev Interrupted, Why AI gains are unevenly distributed in your engineering team

Individual acceleration and team acceleration are different skills, and each requires its own deliberate work. That's the gap every step below is aimed at closing.

PR velocity flatters exactly the failure mode this page is trying to fix, because it rewards individual output regardless of whether that output turns into something the team actually delivers. Bose is specific about the alternative his own team uses.

"We are trying to look at things like end-to-end cycle time for projects. Does the end-to-end project getting delivered faster quarter over quarter, month over month, for projects of similar size and complexity? So cycle time is interesting versus just pure PR velocity."

— Arnab Bose, Chief Product Officer at Asana, on Dev Interrupted, Why AI gains are unevenly distributed in your engineering team

He pairs this with a caution worth sitting with: a team can look like it's improving on paper while that improvement is hollow.

"You shipped 40 features this month versus 20 features last month. But 20 of those features are sitting on the shelf... not meeting your quantitative or qualitative success metrics."

— Arnab Bose, Chief Product Officer at Asana, on Dev Interrupted, Why AI gains are unevenly distributed in your engineering team

Switch the team's primary delivery metric from PR or feature count to end-to-end cycle time on comparable work, before anything else on this list.

Nik Sudan, engineering operations lead at Kraken, describes the structural reason teams plateau after collecting metrics: they stop at the first layer instead of building the full chain that turns a number into a decision.

"Raw metrics are step one, data ingestion... core metrics, throughput, cycle time, review time... This is the part most teams are doing right now. But the context part, this is the second part, derived from the foundation... Metrics will tell you how fast your engine's moving, but context tells you are we going in the right direction."

— Nik Sudan, engineering operations lead at Kraken, on Dev Interrupted, How Kraken finds hidden bottlenecks across thousands of engineers

Most engineering teams have the first layer, raw metrics, already in place. Delivery performance improves when you build the next two: context (what were people actually working on, and why), and insight (what does the pattern in the data actually mean). Only once those three are in place does action become reliable.

The reason individual AI gains stay individual, in Bose's framing, is that the context an engineer builds up while working, what the team decided, why, and how it was reviewed, usually lives in that one person's head or chat history and nowhere else.

"If you have an AI teammate... and it's getting feedback on the work that it's doing from you or somebody else on your team, when a third person comes and uses that AI agent, it will remember all of the nudges and the feedback that it's received from everybody... The gains aggregate as a team rather than accruing to one person's private chat history."

— Arnab Bose, Chief Product Officer at Asana, on Dev Interrupted, Why AI gains are unevenly distributed in your engineering team

The mechanism generalizes past any one tool: whatever context your team builds up about how work gets done, patterns, decisions, review standards, needs to compound across the team rather than reset with every new AI session or every new hire. If context is trapped with individuals, individual gains are the ceiling.

The clearest signal is end-to-end cycle time on comparable work falling quarter over quarter, alongside a stable or improving rate of shipped work that actually gets used rather than shelved, rather than any single engineer's individual metric moving.

Teams stop at the first layer, raw metrics, and mistake that for the whole job, per Sudan's framing. Or they optimize the metric that's easiest to move (PR count, adoption percentage) rather than the one that actually reflects delivery, which is exactly the trap Bose's "40 features, 20 on the shelf" example describes. Both failure modes produce a dashboard that looks like progress and a team that doesn't feel any faster.

Why can individual engineers be faster while the team isn't?

Because individual and organizational AI enablement are different problems. An engineer working solo with AI accelerates their own output; a team accelerates only when the context and decisions behind that work are shared and compound, not trapped with one person.

What's the single best metric to replace PR velocity with?

End-to-end cycle time on comparable projects, tracked quarter over quarter. It captures whether the whole workflow sped up, not just one engineer's typing speed.

Do we need new tooling to build the data-context-insight-action chain?

Usually not. It requires deliberately building the second and third layers, context and insight, rather than stopping once raw metrics are in place. Most engineering teams already have the first layer.