Field Notes - Agentic Delivery
Finding where work actually waits
Agents make one lane of the software factory cheap - usually generation. They do not make my job simpler. They make finding the truth harder, because everyone can point at a fast upstream metric while work still piles up somewhere I am not looking.
Agents accelerate code, tests, docs, and dashboards on the programs I lead. The work I care about as an engineering manager is not "enable AI." It is research the line, find where throughput actually stops, and change the operating model once I have an answer I can defend - not once I have a vendor slide that says review is the bottleneck.
What I publish here are field notes from that job: short, dated, anchored to git - written while I am still investigating, not after I have polished the story.
Here's what this piece covers: what the EM job becomes when agents widen the first lane, how I research where the constraint moved, what I do with the answer, and three habits I use before I invest in the wrong fix.
If you only remember one sentence: my job is to find where the line stops - then elevate that station, not the one that already looks fast.
1. The job is investigation, not acceleration
I spend time on queues, staffing, and "why did this release slip?" Agents did not replace that work. They changed what I have to investigate.
The easy story is always upstream: more PRs, more lines, more demos. The honest story is downstream: where do changes wait after they leave the fast lane? Review? Validation? A release train? A product call nobody can make? If I optimize the wrong step, I feel busy and throughput does not move.
Manufacturing calls this the Theory of Constraints: one slow station caps the whole line. AI researchers call what happens next constraint migration - the scarce step moves when generation gets cheap. I do not need the paper to see it in standup. I need it to stop guessing.
Wrong: "We 10x'd engineering - look at PR count."
Right: "Generation sped up. I am tracing where work batches before I fund another codegen tool."
That is the engineering manager job in an agentic world: researcher of the line, then designer of the fix - not cheerleader for the station that already won the headline metric.
A tiny probe I keep reusing - dwell time after a step looks "done":
from collections import defaultdict
from datetime import timedelta
def dwell_by_station(events):
"""events: iterable of (change_id, station, entered_at, left_at)."""
totals = defaultdict(timedelta)
counts = defaultdict(int)
for _, station, entered, left in events:
totals[station] += left - entered
counts[station] += 1
return {
station: totals[station] / counts[station]
for station in totals
}2. How I research where the pile-up is
I treat this like a lead doing field work, not like a strategist reading hot takes. The line has visible queues and hidden ones. Review backlogs are visible. "Pending deployment" batches and manual verification everyone accepts as normal are often hidden - a point The New Stack makes well about mistaking review for the constraint when work still accumulates afterward.
My research kit is boring on purpose:
| Question | Where I look |
|---|---|
| Where do changes wait longest? | MR age, column time, release calendar |
| Where do batches grow after a step looks "done"? | Post-review queues, staging dwell time |
| Does faster output change idea → prod? | Deployment frequency, change failure |
| Who is saturated - and doing what work? | Walk the floor; ask QA, release, support |
| Do our metrics lie? | Reconcile definitions before staff meeting |
The batch-size question is the one I keep coming back to: if I speed step n, does work flow through step n+1, or does it stack there? If it stacks, n was not the constraint. Industry data backs the pattern - faster code output, flat lifecycle delivery in many orgs - but my answer has to come from my line this month, not a survey.
When generation accelerated on my program, the first hypothesis was "review." I traced batches. Proof and integration work saturated before trust scaled. The answer was not one role. It was the line was never designed for machine-speed input - and I only knew that after looking, not after assuming.
Creation is cheap. Finding where trust breaks is my job. I am not paid to celebrate the fast lane. I am paid to find the answer and change how we work once I have it.
3. What I do once I know where the line stops
Research without action is another unread doc. Once I believe I know the constraint, I run a loop I stole from Goldratt and adapted for software:
Exploit might mean: stop flooding the slow station with unverified bundles. Subordinate might mean: cap WIP until validation keeps pace. Elevate might mean: mechanical gates, shift-left validation, specs agents must meet before merge - whatever makes trust scale at the station that actually limits us this quarter.
The manager role shifts with that loop - less "unblock typing," more operating-model design:
| I spend less time on | I spend more time on |
|---|---|
| Velocity proxies that lie | Queue health and idea → prod |
| Funding the fast lane again | Elevating the station I found |
| Hero review at the end | Judgment at intent; mechanical proof at volume |
| Announcing AI adoption | Naming what "green" means in one place |
Humans on judgment. Agents on volume. Machines on conformance. That division only works if I researched which station needs elevation first - not if I copied someone else's bottleneck story.
4. Three evidence streams - how I keep finding honest answers
I keep three kinds of evidence because an EM who guesses from one dashboard is just doing speed theater. I need something I can re-check when the constraint moves again:
| Evidence stream | Question I am trying to answer |
|---|---|
| Program truth | Can we prove integration before we argue about dates? |
| Delivery metrics | Is throughput up - or only output? |
| Agent methodology | Do agents work under human merge authority? |
Agents help me build the instruments faster. I still own whether the answer is true - reconcile the metric, walk the end-to-end path, merge the spec. I call that engineering-led, agent-accelerated: agents accelerate the research artifacts; humans retain architecture, priority, and what counts as evidence.
This blog is one output of the same job: when I find something checkable about where the line stops, I publish a field note - one screen, git-anchored, while the investigation is still live.
5. Named pattern: follow the constraint
The phrase I reuse:
Follow the constraint - research where work waits, elevate that station, research again when it moves.
Anti-pattern: answer hunting - funding review because the queue is visible, never asking where batches grow after review.
Anti-pattern: speed theater - PR count and demo velocity while idea → prod and change failure tell the truth.
6. What I'd do as a lead
Three habits - steal one this month:
- Research before you fund. Sketch generate → review → validate → deploy. Mark where work accumulates this week. Talk to whoever owns the next station. Do not buy tooling for the fast lane until you can name the slow one.
- Ask the batch-size question. If we speed step n, does step n+1 absorb it or stack? If it stacks, your constraint is downstream. Invest there.
- Publish what you found, briefly. One field note with a date and an anchor beats a wiki nobody updates. The point is not volume of writing - it is a record of the answer while the line is still moving.
Agents widen the first lane. I research where the line stops, change the model, write down what I found. Each post here is for engineering managers who need answers, not another story about transformation.
Further reading
- Constraint migration (Zenodo, 2026)
- The bottleneck has moved (Jim Grey, 2026)
- AI hasn't shifted the bottleneck to code review (The New Stack, 2026)
- Harness engineering (OpenAI, 2026)
