Tasks per Code Engineer

Maximizing task throughput per engineer because volume is the truest measure of velocity!
Tags:

Tasks per Code Engineer measures the number of discrete tasks each engineer completes during a single Convoy cycle. This metric operationalizes the fundamental SADMF insight that productivity is a function of throughput, not outcome. A Code Engineer who completes 47 tasks in a Convoy is demonstrably more productive than one who completes 12, regardless of what those tasks accomplished, how large they were, or whether anyone needed them. Volume is the metric that matters, and the metric that matters is the metric that gets managed.

SADMF Metric — Throughput Volume
Tasks per Code Engineer
FORMULA TpCE = Count(Tasks Closed by Engineer within Convoy window)
Owner Role
DOUCHE
Cadence
Weekly + Per Convoy
Source
Release Tracking Sheet
Unit
Tasks Closed / Convoy
How the Count Is Calculated
1
Task Registration
Every work item in the Release Tracking spreadsheet is registered as a discrete task. The [Feature Captain](/roles/feature-captain/) validates that each ticket represents a single, countable unit of work — ideally the smallest decomposition achievable without losing ticket identity.
2
Decomposition Validation
The DOUCHE reviews task granularity at Convoy start. Features that could be delivered as a single task should instead be decomposed into 15 to 20 subtasks — each generating its own ticket, its own status update, and its own completion event. This is not overhead; it is visibility.
3
Velocity Baseline Established
The DOUCHE calculates each engineer's personal rolling average from prior Convoys. This baseline determines the expected completion rate. A drop below baseline triggers weekly review; a sustained drop triggers Tribunal referral. All tasks count equally — difficulty is not a variable.
4
Convoy Totals Compiled
At Convoy close, all completed tasks are tallied per engineer and ranked fleet-wide. The Mandatory Status Synchronization protocol ensures every task transition was reported upward through the chain of command in real time throughout the cycle.
5
Forecast Input Submitted
Historical task completion rates feed directly into Precise Forecasting and Tracking, determining how many tasks each engineer is assigned in the 8-quarter planning horizon. High performers are assigned more work, ensuring they remain high performers. This is the virtuous cycle.
What Good Looks Like

A high-performing engineer maintains a task count well above the team median across consecutive Convoys, demonstrating a sustained commitment to decomposition discipline and completion velocity.

  • A task count consistently 30% above the team median qualifies the engineer for increased capacity allocation in the next Convoy — rewarding demonstrated throughput with more demonstrated throughput
  • Zero in-progress tasks at Convoy close — every task either complete or correctly not-started — signals planning discipline that the DOUCHE tracks as a positive signal
  • A rising task count trend that tracks alongside a rising Lines of Code score confirms the ideal two-dimensional productivity profile
  • Engineers who express concern about the task count metric are referred to the Psychological Safety guidelines, which explain that feeling overwhelmed is a natural response to being valued

The metric works in concert with Lines of Code per Code Engineer to create a two-dimensional productivity profile. An engineer with high LOC but low task count is writing too much code per task and needs to decompose further. An engineer with high task count but low LOC is completing trivial tasks and needs to take on more substantive work. The ideal engineer produces both high LOC and high task counts, demonstrating that they are writing significant amounts of code across a large number of discrete work items. This dual optimization ensures that no engineer can game one metric without being caught by the other.

The DevOps Usage & Compliance Head Engineer (DOUCHE) reviews task counts weekly and flags any engineer whose velocity drops below their personal rolling average. A sustained decline in task velocity triggers a formal review at the Tribunal, where the engineer must explain the decrease. Acceptable explanations include illness (documented) and jury duty (documented). Unacceptable explanations include “the tasks were harder this sprint,” because task difficulty is not a variable in the model. All tasks count equally, and all tasks are expected to be completed at a consistent rate.

See Also