Engineering 1:1s Anchored in Delivery: Fewer Surprises

Engineering 1:1s anchored in delivery use source-control artifacts—pull requests, commit diffs, and deploys—to structure conversations, reduce guesswork, and focus on outcomes. The key benefit is predictable coaching rooted in what shipped, not subjective status. Vibe-led 1:1s drift into rehashing standups or opinion sparring; anchoring to Git activity creates shared evidence: PR titles, descriptions, review cycles, and merge timelines. The approach is read-only and designed for non-invasive visibility. With a summary of recent merges, open PRs by age, and deploy notes, managers can ask targeted questions, celebrate concrete wins, and unblock specific work. It also helps teams defend focus—by spotting churny branches or long-running reviews—without surveillance. For distributed teams, a code-derived summary acts as a common timeline that documentation rarely captures. If you manage multiple squads, the same lens scales: you enter each 1:1 prepared, avoid context-hunting across tools, and reserve more time for growth, not status. The result is a weekly shipping rhythm that compounds, aligned with customer value and fewer surprises.

The core problem: 1:1s drift without shared evidence

When a manager arrives with only Jira tickets or recollections, the conversation skews to “how do you feel this sprint went?” rather than “what changed in the repo and why.”

Stale tickets rarely reflect what merged yesterday or what’s blocked in review today, and aging review queues quietly accrue risk while nobody opens them.

Why vibe-based 1:1s miss the work

• Review latency hides until it bites delivery. Small latency variances compound across dependencies, and multi-day review tails are common on busy repos.
• Meetings sprawl to compensate. Without code context, 1:1s expand into status theater.
• Hidden review queues create silent risk. Two stuck PRs can anchor an entire feature behind untested interfaces.
• Fragmented evidence (tickets, chats, doc notes) dilutes coaching into generalities instead of commit-specific feedback.

The fastest path to fewer surprises is to sit down with the exact pull-request titles, diffs, and release notes that shaped the last week.

That means walking in with a delivery report that lists:

• PRs opened, merged, and still awaiting review older than 24/48/72 hours.
• Commits touching high-churn files or critical paths.
• Release tags with linked issues and post-merge fixes.

When 1:1s begin with the artifacts, coaching becomes concrete:

• “This PR refactors payments retry; why did review take 3 days?”
• “Two commits post-release suggest test gaps; what failed in staging?”
• “These three files are frequent touchpoints; who else should review?”

Why burndown charts and dashboards miss the point

Burndown charts compress reality into a slope that hides the exact moments where review bottlenecks and merge gaps form.

Velocity and story points are aggregates; they tell you where time went, not why it stalled. A 20-point sprint can “look green” while one PR blocks five others for three days.

PR latency beats velocity for 1:1 coaching

What you coach in a 1:1 lives in the deltas: time-to-first-review, time-to-merge, and the handoff gaps between commits and approvals. Those are concrete behaviors you can improve this week.

• PR review latency: the faster the first review, the sooner problems surface while context is fresh.
• Merge cadence: small, frequent merges reduce batch size and rebase pain; long-lived PRs erode confidence.
• Review distribution: if one reviewer handles most approvals, the team is brittle; vacation equals gridlock.
• Rework indicator: a high reopen/force-push rate flags unclear scope or late review.

Generic dashboards can’t pinpoint who needs what help. A manager can’t coach “velocity” but can coach “PRs wait 2 days for first eyes; here’s how we slice changes and request targeted reviewers.”

Bring delivery artifacts to the 1:1

DeployIt reads Git activity through a read-only connection and turns it into per-engineer context tied to real code, not feelings.

• Weekly report: “3 PRs merged, 2 waiting more than 24h for first review, average PR size up.” (Illustrative example.)
• Pull-request title cues: “Refactor: auth middleware extraction” arriving late in sprint implies scope creep; ask about slicing.
• Production in dev-days: delivered work estimated in dev-days (one dev-day is roughly five focused hours), so you can discuss output without counting commits.
• AI-agent visibility: commits and PRs co-authored with Copilot, Cursor, or Claude Code are attributed by name, so agent output becomes a coaching topic instead of invisible noise.

For demo hygiene, bring the same artifacts to sprint review—our play shows how to build clear demos straight from Git history: /blog/sprint-review-from-git-history-clear-demos-fast.

DeployIt’s angle: a Monday delivery report, read-only

DeployIt compiles a delivery report from pull requests, commits, and releases, pulled read-only from your Git provider. It lands by email every Monday morning—with monthly and quarterly versions for board or client reviews—and the same data stays live in the real-time activity dashboard.

You walk into 1:1s with a shared answer to: what moved, what’s pending, and where review time is accumulating.

What the report contains

The report is organized by project and contributor, showing:

• PRs merged this week with the original pull-request title, author, reviewers, labels, and linked issues.
• PRs awaiting review with current reviewer list, age, and last-updated timestamp.
• Delivered work estimated in dev-days, readable by non-technical stakeholders.
• Activity from AI coding agents (Copilot, Cursor, Claude Code…), attributed by name—including agent PRs merged without human review.

Each item links back to the source artifact, preserving a read-only audit trail—no write scopes, no status changes, no surprise pings.

How managers use it in 1:1s

• Start with merged work: “Two PRs shipped—‘Optimize billing retries’ and ‘Add webhook retries.’ Any post-release follow-ups?”
• Move to pending review: “Three PRs awaiting review, oldest at 3d 6h. Do we need a second reviewer or smaller slices?”
• Address release impact: “Release v2.3.4 bundled 14 commits. Any risky hotspots for the next rollout?”

How to run a delivery-anchored 1:1 in 25 minutes

Use this 25-minute agenda to keep coaching grounded in code, not recollection.

Prompts that target flow and quality

Use these targeted questions while you have the diff open.

Tactical tips to keep momentum:

• Keep the diff visible the whole time; avoid switching to ticket threads.
• Prefer time-bounded “ask for review on X function” over abstract goals.
• If the PR is stale, co-author a clarifying comment in the session.

Handling edge cases: low commit weeks, pair work, and spikes

Some weeks show atypical code footprints—research spikes, deep refactors, or shared authorship—so 1:1s need an artifact plan that keeps outcomes front and center.

Start by anchoring to the shared weekly report. If output dips, review what moved: PR reviews written, design docs linked, experiments run, and blockers removed.

For pair or mob work, attribute intent and impact, not lines. List co-authored PRs and capture who drove design, tests, or rollout.

When spikes dominate, swap “what shipped” for “what de-risked”: a branch, a failing test, or a throwaway prototype that proves or disproves an approach.

Conversational scripts that keep outcomes first

• Low commits: “What decisions got unblocked? Point me to the PR reviews or design comment threads that advanced the release.”
• Pairing week: “On PR ‘Improve cache invalidation,’ what part did you own—algorithm choice, test scaffolding, or rollout plan?”
• Research spike: “Show the branch or snippet that invalidated Option B. What did we learn, and what’s the next commit that uses it?”
• Risk surfacing: “Which PR titles in the report hint at hidden scope? Where should we request early review?”

If the sprint demo missed context, pull from Git history to shape the narrative. See: /blog/sprint-review-from-git-history-clear-demos-fast

Next steps: pilot with one squad and measure signal lift

Two-week pilot plan

Pick one active squad and limit change scope. Keep HR/PII out of tooling and keep outputs read-only.

• Day 0–1: Connect DeployIt to the squad’s GitHub repos with least-privilege, read-only OAuth. The dashboard is live immediately; the first weekly report arrives the following Monday.
• Day 2–3: Define success thresholds and a shared glossary for “ready for review,” “blocked,” and “risk.” Publish it in your team doc.
• Week 1 1:1s: Use a live queue of PRs grouped by pull-request title and reviewer. Ask only artifact-backed questions: “What’s blocking PR-542?” “What changed between commits a12f… and b44e…?” (PR numbers illustrative.)
• Week 1 end: Run a 15-minute retro. Capture hotspots—files or modules touched again and again.
• Week 2 1:1s: Add release notes to discuss “shipped vs. slipped.” Tag risks directly on PRs, not people.
• Week 2 end: Compare baselines, decide go/no-go for broader rollout, and keep the notes for your next planning cycle.

Metrics that matter

Track a small set of delivery signals and keep them team-level.

• PR review time (median, 75th percentile).
• Merge cadence per squad (count/week).
• Time to first review comment.
• Open-to-merge ratio for large PRs.
• Rollback/revert count per release.
• Work-in-progress PRs older than 5 days.
• Risk aging: PRs tagged “blocked” more than 48 hours.

As an illustrative target—not a benchmark—aim for a visibly shorter review tail (fewer PRs older than 48 hours) and one extra merge per engineer per week without raising the revert rate. What matters is the trend against your own baseline, not an industry number.

On cost: DeployIt is free during early access, with paid plans opening in January 2027 at $19 per active human developer per month—versus the $80–150 per seat common for Swarmia- or LinearB-class platforms. Nothing is billable today.

For the wider habit this pilot builds toward, see how to track engineering progress without micromanaging.