Guides

How Engineers Can Make Their 1:1s More Efficient

How to walk into a 1:1 already knowing what your own delivery data says, instead of reconstructing the last two weeks from memory on the spot.

Most 1:1s spend their first five minutes on recall: what did I actually ship the last two weeks, what got stuck, what am I forgetting. That's five minutes not spent on the conversation you actually wanted to have — about the stuck PR, the messy on-call handoff, or whether it's time to bring up that you want more review load, not less.

The fix isn't a status doc nobody updates. It's having your own delivery trends already in front of you before the meeting starts, so recall isn't the first task on the agenda.

Know your own trend before the manager brings up theirs

Commit, PR, and review activity over time is the thing you'd otherwise have to reconstruct from memory or a scroll through your own GitHub activity feed. Having it already visible means you walk in already knowing what the data says — which matters most when it says something you didn't expect. A slower cycle time over the last month is a very different conversation when you can immediately point to "yeah, that's the auth migration, it touched four services" versus finding that explanation live, mid-meeting, while your manager is looking at you.

This cuts both ways. If your manager opens with a number, you're not starting from zero — you already know whether it lines up with what you remember, or whether it's worth a "wait, let me look at that" before agreeing with it.

Use team context, not a ranking, to explain your own work

Seeing team and service health alongside your own activity is useful for exactly one thing: context, not comparison. If the service you work in had a rough month — flaky CI, an incident, a dependency that kept breaking — that's relevant to why your own numbers look the way they do, and it's a much better use of 1:1 time than re-explaining it verbally every time it comes up.

This is deliberately not a leaderboard. Nobody signed up to have their PR count ranked against teammates, and a tool that does that turns a coordination signal into a source of quiet dread before every 1:1. The point of team context is knowing whether "my cycle time went up" is a you-problem or an everyone-problem, not knowing where you rank.

Bring up review health early, not defensively

Review load and turnaround time are two of the easiest things to lose track of day to day and two of the most useful things to raise proactively. If you've quietly become the person reviewing every PR that touches a specific service, that's worth surfacing in a 1:1 as a workload conversation — before it shows up as your own output looking lower than it actually is. Repo health for the services you work in helps here too: a flaky pipeline you've been fighting for two weeks is worth a sentence in the 1:1, not a slow-burning frustration nobody upstream knows about.

What actually changes in the meeting

None of this replaces the conversation — it changes what the first five minutes of it are for. Instead of reconstructing the last two weeks, you're confirming or correcting what the data already shows, and spending the rest of the time on what to do about it: redistributing review load, flagging a rough sprint before it becomes a review-week surprise, or just having the receipts ready when it's time to talk about what you want next.

If your team's already connected, your own view should already be scoped to exactly this — no ranking, no cross-teammate comparison, just your own trends in context.

See your own delivery data in it

Connect one repo and we'll backfill 90 days of history so you can compare before you commit.