Prepare a 1:1 with a developer

I have a 1:1 coming up with someone on my team. I want to show up prepared: knowing what they shipped, what got in their way, and what I should be doing for them. ## Context - Developer: [name or login] in squad [squad] (use List Players to resolve the login) - Period: [last 30 days], compared with the 30 days before it - What I already know: [vacation, on-call, new to the team, led a big project, nothing special] - This is for a supportive conversation. None of it goes into a performance review, and none of it is a ranking. - If I left anything in [brackets], keep what reads as a default (a period, a number of days, the first of several options) and ask me for the rest in one go, before pulling any data. - Write everything, the deliverable included, in the language of this prompt. ## Pull this data from DevStats (both periods) 1. Player Metrics for the squad — to see this person inside the squad's range, not to rank them 2. PR List filtered by this player, fields title, url, repository, size_total, cycle_time_coding, cycle_time_pickup, cycle_time_review, review_count, merged_at 3. Code Review filtered by this player — the reviews they gave 4. Issue List filtered by this player, fields key, summary, issue_type, project, cycle_time_formatted, resolved_at 5. Daily WIP filtered by this player — how many things they hold open at once 6. Activity Heatmap filtered by this player — only to spot sustained evening or weekend work ## How to analyze - Compare the person with their own previous period, not with teammates. A drop after a steady run is worth a question. A steadily low number is often just the role: people who review, unblock and mentor merge fewer PRs. - Count the reviews they give next to the PRs they author. Someone reviewing a lot and merging less is carrying the team's review queue. Recognize it and ask whether it is sustainable. - Long pickup time on their PRs means the team is slow to review them. That is something I owe them, not something they owe me. - Many branches and issues open at once means they are being pulled in several directions. The question is who is interrupting them. - Weeks of mostly bugs and hotfixes is a growth problem, even when the numbers look great. Ask if that is the work they want. - Large PRs are a coaching topic about slicing, not a complaint. - Sustained evening or weekend activity is a wellbeing flag. Raise it as care. Never praise it. - Use the context I gave. Vacation and on-call explain dips; do not turn them into findings. ## Deliver A one-page 1:1 guide: 1. **Recognize** — two specific things worth calling out, naming the actual PRs or issues. 2. **Ask about** — three open questions, each with the observation behind it, phrased as curiosity: "I noticed X, what is going on there?" 3. **What I owe them** — things the data says the team or I should fix for them: slow reviews, interrupt load, unclear priorities. 4. **Growth topic** — one, tied to the kind of work they have been doing. 5. **Leave out** — numbers that look odd but are explained by context or are too noisy to mention.