people-manager: manage people well, week by week

---
name: people-manager
description: Helps a manager do the weekly work of managing people well. Use to prepare a 1:1, give feedback, delegate, set expectations and goals, run a team meeting or retro, or spot someone overloaded or unheard, as in "prep my 1:1 with my report", "how do I say this to him", "help me hand this off", "set goals for my team", "run our retro", "is anyone overloaded", "I have to have a hard conversation", "I'm a new manager". Reads the project's record (what each person did, what waits on them, open notes, what they wait on from you), writes feedback as situation, behaviour and impact, delegation briefs with the outcome, limits, authority and check-ins, and agendas that end in decisions and owners. Names common management mistakes once, never scores or ranks people, and keeps 1:1 notes and feedback private to the manager unless they choose otherwise.
license: MIT
metadata:
  source: https://alcoven.co/skills/people-manager
  version: "2"
---

People manager: the team's output is your output

A manager's output is the output of their team and of the teams they influence (Andy Grove, High Output Management). So the hours that count most go to what lifts the whole team: a 1:1 that surfaces a problem while it is small, feedback given while it still helps, work handed over with the authority to finish it, a meeting that ends in a decision. The person asking is often a founder or a new manager with fifteen minutes before a conversation, afraid of being unfair, of the hard conversation, of losing a good person, of becoming the one everything waits on. Do the work they ask for, check it against what good managers do, and say once what you see. They decide.

What you need

• Who: their role, how long they have done this kind of work, what they look after.
• The record since the last 1:1 or meeting: what they did, their open and past-due tasks, notes asking them that nobody answered, what they wait on from the manager.
• What was agreed before: last 1:1 notes, written expectations or goals, the team's plan.
• For anything formal: the organisation's policy, and who in HR or which adviser to involve.

If you can only see the conversation, ask who it is about, what happened, and what the manager wants from it; say what you could not see.

Size the work

The jobs

Prepare a 1:1

1. Read the record since the last 1:1: what they did (for a specific thanks), what is open or past due, unanswered notes asking them, and, first, what they wait on from the manager.
2. Read the last 1:1's notes: what was promised, by whom, and whether it happened.
3. Draft the prep. Their topics come first: the 1:1 is their meeting, with their agenda (Grove). Then one specific thanks, two or three open questions, what the manager owes them, at most one piece of feedback, and a question about load if the record suggests it.
4. Match the support to their experience with this task (Grove's task-relevant maturity): new to it means meeting more often and talking through the how; experienced means agreeing goals and stepping back.
5. After: a few lines on what was decided and who does what by when. Private to the manager unless they choose otherwise. Open the next 1:1 with those lines.

Write feedback

1. Situation: when and where. Behaviour: what they said or did that anyone present could have seen or heard. Impact: the effect on the work, a teammate or a customer (the Center for Creative Leadership's Situation-Behavior-Impact model).
2. Then ask for their view of it, and end with a request or a question.
3. Cut every label ("careless", "rockstar", "bad attitude") and every guess at motive.
4. Praise the same way: specific, sincere, and more often than criticism. Suggest the manager asks for feedback on themselves first (Kim Scott, Radical Candor).
5. Give it within days. Criticism in private; praise where the person likes to get it.

Delegate a piece of work

Write a brief with: the outcome and why it matters; the limits (date, budget, what must not change, who must be consulted); the authority, in plain words ("you decide and tell me after", from Jurgen Appelo's seven levels); the context and people to use; the check-ins, set by their experience with this kind of work; and who reviews the result. When an AI agent does part of the work, name the person who answers for it and who reviews it before it counts as done. Then add the task, with a due day.

Set expectations and goals

1. Write what the role owns, the decisions it makes alone, and what good looks like, with an example.
2. Set a few goals, each an outcome with a measure and a date, tied to the team's goal. For OKRs and roadmaps, use the product-strategy skill if the project has it.
3. Ask the person to say it back in their own words, then agree it in writing and set a date to look at it again.

Run a team meeting or a retro

• Team meeting: an agenda shared ahead with an owner per item, written updates read beforehand in place of a status round, time for blockers and decisions. It ends with decisions, owners and dates, written where the team will find them.
• A meeting to decide something: name what it must decide and who decides. For the decision itself, use the decision-making skill.
• Retro: start with the last retro's actions. Then set the stage, gather what happened, find the causes, choose one to three changes with owners, and close (Esther Derby and Diana Larsen). Frame it so nobody is blamed for doing their best with what they knew.

Read the team's health

Look for the signals in references/practices.md: past-due tasks piling on one person, unanswered notes, one person deciding everything, a folder only one person changes, agent work nobody reviewed, someone gone quiet. Give each to the manager as a question to ask in a 1:1, with its source, and never as a score.

Hard conversations and underperformance

1. Check the expectation was clear and written. If not, fix that first; the gap may be the manager's.
2. Raise it early, in private, in situation-behaviour-impact form, as the gap between what was expected and what happened.
3. Ask for their view and look for the cause: unclear goals, load, skills, tools, something outside work.
4. Agree in writing what good looks like, the support, and a date to review.
5. If nothing changes, follow the organisation's policy and bring in HR or an employment adviser before any formal step. Local law applies; this skill gives no legal advice.

Onboarding a new member and career conversations are in references/practices.md.

Common mistakes

Name one when you see it, once, with the evidence and the fix.

1. Doing the work instead of growing the team. Faster today; then the team stops learning and everything waits on one person. Instead: hand it over with support, and coach (Grove; Julie Zhuo).
2. Skipping 1:1s, or filling them with status. Moving them says they matter least; status crowds out what the person needed to say. Instead: keep them, status in writing, their agenda first (Camille Fournier).
3. Saving feedback for the review. The moment is gone and the review is a surprise. Instead: within days, as situation, behaviour, impact.
4. Vague expectations. "Own the launch" means different things to each side. Instead: what done looks like, by when, what they decide alone, in writing (clarity is one of the five team dynamics in Google's Project Aristotle).
5. Handing over the task without the outcome or the authority. The person checks every choice, and the manager takes it back. Instead: outcome, limits and authority named.
6. One style for everyone. The expert feels watched; the newcomer feels left alone. Instead: support set by experience with this task.
7. Avoiding the hard conversation. Kindness that withholds the truth (Kim Scott's "ruinous empathy"). Instead: early, specific, private, with help offered.
8. Praise only in general. "Great job, team" teaches nothing. Instead: who, what exactly, what it made possible.
9. Meetings with no decision or owner. The same topics come back each week. Instead: each item ends with a decision, an owner and a date, written down.
10. Being the bottleneck for every decision. Work queues behind one calendar. Instead: say which decisions the team makes alone.
11. Feedback about a person where the team can read it. It shames, and they hear it second-hand. Instead: one to one; private notes stay private.
12. Agent work nobody answers for. Output lands unreviewed. Instead: every agent's work has a named person who answers for it, and a reviewer.

Speaking up

• Once, with the evidence and the cheapest step. "Before you send this: it says 'careless' but not what happened. Want me to rewrite it as what you saw on Tuesday and what it caused?"
• Credit what is already good before the gap.
• Match their pace. Right before the meeting, one line. Never repeat a point they have heard and decided on.
• Then do the work they choose, and note the risk once where only they will see it.

What you never do

• Score, rate, rank or compare people. You describe work and behaviour; judging people is the manager's.
• Put 1:1 notes, feedback or a judgement of a person where anyone else can read it, without the manager's explicit say for that place.
• Guess at someone's health, private life or motives. Describe what happened.
• Give legal advice, or recommend a warning or a dismissal. Formal steps follow the organisation's policy and HR.
• Send anything to the person being managed, or to the team, without the manager's yes.
• Invent what someone did. Every fact has a source.

In Alcoven

Pass the project's slug and cite by § address.

1. open_project: who is on the project, their roles and what each looks after.
2. what_changed with who: "everyone" and since: the last 1:1 or meeting: what the person did, their notes, what they agreed to.
3. numbers with source this project, measure tasks past due (or open tasks), by: "person": to spot overload, never to rank. task_context on a task you will discuss; my_tasks for what waits on the manager.
4. task to delegate: for the person, due, the brief in details, and stands_on the § addresses it builds on. add_note with to to ask one person a question on a document.

1:1 prep and feedback stay in this conversation by default. If the manager wants them kept on the project, check the folder with who_sees first, and write there only on their yes for that place. Change who sees a folder only when the manager asks.

Elsewhere

Read the task tracker, the shared documents and git log --since=<date> --author=<name>. Ask the manager to paste last 1:1 notes or goals. Keep prep and feedback in the conversation, or in a private file the manager names.

Files

• references/practices.md: the frameworks in more depth, team health signals, onboarding and careers, remote teams and agents, and the sources.
• references/templates.md: the templates for each job, and a worked example.

Management practices, in more depth

The frameworks behind each job in the skill, in our own words, with where each comes from. Sources at the end.

The manager's output

Andy Grove's rule: a manager's output is the output of the team they run plus the teams they influence. A manager's own time therefore goes furthest on activities that change many people's work at once (a clear goal, a well-run staff meeting), that change one person's work for a long time (a piece of feedback, teaching a skill), or that supply a decision or a fact at the moment others need it. Grove singled out training as one of the most effective things a manager can do. The reverse also holds: a late decision or meddling in detail slows everyone below it.

Julie Zhuo puts the job as improving purpose (why the work matters, what success looks like), people (the right people, growing) and process (how the team works together, which needs more structure as it grows).

1:1s

• The report's meeting. Grove: the agenda and tone are theirs, and they bring a short outline. The manager listens, asks, and teaches. When they seem finished with a subject, ask one more question; the real issue often comes after.
• How often: set by the person's experience with their current work. Someone new to it gets them more often; someone experienced, less. Grove argued for an hour at minimum so that hard topics have room. Camille Fournier suggests weekly to start, then adjusting.
• What for: Fournier names two purposes, a human connection and a regular private place to raise anything. Status belongs in writing.
• Keep a running document both people add to, with what was agreed and who does what. The manager follows up at the next one.
• Never cancel; move. A 1:1 moved twice in a row tells the person where they rank.

Questions to rotate: What is on your mind? What is in your way? What should I start or stop doing? What are you proud of since we last spoke? How is your load?

How closely to support someone

Grove's task-relevant maturity: how experienced a person is with the specific task, which sets how closely to manage them. It belongs to the task: a senior designer new to running client calls is new at that.

Handed-over work still needs follow-up in proportion to the stakes, at the agreed points.

Delegation levels

Jurgen Appelo (Management 3.0) names seven levels of authority for a decision area:

Name the level in the delegation brief in plain words. A delegation board lists the team's main decision areas (hiring, pricing, tools, design choices) against the levels, so everyone knows who decides what before it matters.

Feedback

• Situation-Behavior-Impact (Center for Creative Leadership): when and where; what was said or done that could be seen or heard, without labels; the effect. CCL adds a fourth step, intent: ask what the person was trying to do, which turns it into a conversation. CCL reports that the model lowers the giver's anxiety and the receiver's defensiveness.
• Lara Hogan's feedback equation: an observation, its impact (pick the impact the receiver cares about most), then a request or an open question.
• Radical Candor (Kim Scott, 2017): care personally and challenge directly, at the same time. Care without challenge is "ruinous empathy"; challenge without care, "obnoxious aggression"; neither, "manipulative insincerity". Scott's order: ask for feedback on yourself first, then give specific, sincere praise, then kind, clear criticism. Her later book, Radical Respect (2024), covers bias, prejudice and bullying at work.
• In practice: praise often and specifically; criticism soon and in private; one thing at a time; anything hard in a call, never only in writing.

What makes teams work

Google's Project Oxygen studied what its best managers do; the list grew from eight to ten behaviours in 2018. In our words: coaches; gives the team room and does not micromanage; builds an inclusive team and cares about each person's success and well-being; is productive and focused on results; communicates, listens and shares information; supports careers and discusses performance; has a clear vision and strategy for the team; has the technical skill to advise; works well across the company; makes decisions well. Google reports that teams with highly effective managers got better results, were happier and had lower turnover.

Google's Project Aristotle found five dynamics of effective teams: psychological safety (the most important), dependability, structure and clarity, meaning, and impact. Factors such as colocation, consensus-driven decisions, team size, seniority and workload were not significantly connected with effectiveness at Google.

Psychological safety, in Amy Edmondson's words: "a shared belief held by members of a team that the team is safe for interpersonal risk taking." In The Fearless Organization (2018) she gives leaders three moves: set the stage (say why the work matters and that it is uncertain, so speaking up is needed), invite participation (admit what you don't know, ask real questions, make a regular place for input), and respond productively (thank people for raising things, treat honest failure as learning, act on clear violations). Right Kind of Wrong (2023) separates basic, complex and intelligent failures: prevent the first two where you can, and welcome the third.

Mentor, coach, sponsor

Lara Hogan (Resilient Management, 2019) describes four modes: mentoring (giving advice from your experience), coaching (questions that help the person find their own answer), sponsoring (finding stretch work and putting your name behind them), and feedback.

Her manager Voltron: no one person can meet all of someone's needs. Help each person build a small group (a peer, a mentor outside the team, a coach) and stay the one who gives what only the manager can.

Core needs (Paloma Medina's BICEPS, used in Hogan's book): belonging, improvement, choice, equality (fairness), predictability, significance (status). A strong reaction to a small change usually means one of these feels threatened: name which, then address it.

Team size

Will Larson (An Elegant Puzzle, 2019) suggests six to eight people per manager in engineering teams: fewer pulls the manager back into doing the work; more leaves time only for problems.

Meetings and retros

Grove's two kinds of meeting: process-oriented (regular, for sharing what people know: the 1:1, the staff meeting, the operations review) and mission-oriented (called to produce one decision; the chair knows what it must produce, keeps it small and sends a written summary of decisions and actions). Cancel a regular meeting whose agenda is empty.

A retro in five stages (Esther Derby and Diana Larsen, Agile Retrospectives, 2006): set the stage, gather data, generate insights, decide what to do, close. Norm Kerth's Prime Directive frames it: assume everyone did the best they could with what they knew, their skills, the resources and the situation. Remote teams can gather data in writing first, then meet to decide.

Team health signals

Counts describe the record, and much good work leaves no trace there (a call, coaching a colleague, thinking). Use them to ask, never to rank, and never show per-person counts to the team.

Onboarding and careers

A new member: before day one, access, a written welcome with the brief and who is who, and a buddy. First week: one small real task finished, and a first 1:1 on how you will work together. First month: expectations in writing and feedback both ways. End of the first quarter: look at the goals together. In a shared project the newcomer reads the brief and the decisions on record first; an AI can brief them from the record, with sources.

Career conversations (Radical Candor, building on Russ Laraway's work): three conversations, separate from performance reviews. Their life story (the choices they made and why), their dreams (where they want to be at their peak), then a plan (what to learn now, from whom, and how the current role can change to get there). Sponsor them toward it.

Underperformance

• Separate "can't yet" (skills, clarity, load) from conduct (a rule broken). They follow different paths in most organisations' policies.
• Informal first: the expected standard in writing, the gap in situation-behaviour-impact form, support, a review date, a short note shared with the person.
• Formal steps follow the organisation's policy and local law (in the UK, for example, the Acas Code of Practice on disciplinary procedures applies to formal steps toward a warning or dismissal, including for poor performance). Bring in HR or an adviser before them.

Remote teams and agents (what changed, 2023 to 2026)

• Written by default. Remote-first companies such as GitLab write decisions and the conclusions of calls into one shared place, use writing as the starting point, and keep meetings for what writing can't do. Written weekly updates replace status meetings; 1:1s stay live and at a steady time.
• People now direct AI agents. Microsoft's 2025 Work Trend Index describes every worker coming to manage agents. The management rules carry over: brief an agent like a person (outcome, limits, what it may change, check-ins); every agent's work has a named person who answers for it; it is reviewed before it counts as done. Reviewing agent output is real work: count it when you look at someone's load. Feedback is about the person's choices (what they asked for, what they checked), never about the tool.

Sources

All read 2026-10-22.

• Andrew S. Grove, High Output Management (1983; 2nd ed. 1995). Summary: getlighthouse.com/blog/high-output-management.
• Google re:Work, team effectiveness guide (Project Aristotle): rework.withgoogle.com/intl/en/guides/understand-team-effectiveness; the research behind great managers (Project Oxygen): rework.withgoogle.com/intl/en/guides/following-the-data-the-research-behind-great-managers.
• Nextgov, "Google Is Expanding Its List of What it Takes to Be a Great Manager" (Feb 2018): nextgov.com/digital-government/2018/02/google-expanding-its-list-what-it-takes-be-great-manager/146314.
• Amy C. Edmondson, "Psychological Safety and Learning Behavior in Work Teams" (1999); The Fearless Organization (2018); Right Kind of Wrong (2023).
• Kim Scott, Radical Candor (2017); Radical Respect (2024); radicalcandor.com/our-approach.
• Center for Creative Leadership, on Situation-Behavior-Impact and intent: ccl.org/articles/leading-effectively-articles/closing-the-gap-between-intent-vs-impact-sbii.
• Lara Hogan, Resilient Management (2019); "Feedback Equation": larahogan.me/blog/feedback-equation; "Manager Voltron": larahogan.me/blog/manager-voltron. Paloma Medina on BICEPS: designmuseumfoundation.org interview.
• Julie Zhuo, The Making of a Manager (2019).
• Camille Fournier, The Manager's Path (2017).
• Will Larson, An Elegant Puzzle (2019); "Sizing engineering teams": lethain.com/sizing-engineering-teams.
• Jurgen Appelo, Management 3.0 (2010); Delegation Poker: management30.com/practice/delegation-poker.
• Esther Derby and Diana Larsen, Agile Retrospectives (2006); Norm Kerth, Project Retrospectives (2001).
• GitLab Handbook, "How to embrace asynchronous communication": handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous.
• Acas Code of Practice on disciplinary and grievance procedures (UK), as summarised by UK employment advisers, e.g. davidsonmorris.com/managing-poor-performance.
• Microsoft, "2025 Work Trend Index: The Frontier Firm is born": blogs.microsoft.com/blog/2025/04/23/the-2025-annual-work-trend-index-the-frontier-firm-is-born.

Templates and a worked example

Fill each template from the record, with a source for every fact. Leave out a line that has nothing in it. Templates marked private stay with the manager unless they choose a place for them and who sees it.

1:1 prep (private)

# 1:1 with [name], [date]

Last 1:1: [date]. Their agenda: [their topics, if shared].

## I owe them
- [what they are waiting on from me, with source]

## Thanks
- [one specific thing they did, what it made possible] ([source])

## Ask
- [two or three open questions, from what the record shows]

## Load
- [open and past-due tasks, unanswered notes asking them] ([source]). Ask, don't assume.

## One thing to raise (if any)
- [feedback in situation, behaviour, impact form]

## From last time
- [what was agreed, who, done or not]

## After (fill in at the end)
- Decided: ...
- They will: ... by ...
- I will: ... by ...

Feedback

Situation: [when and where]
Behaviour: [what they said or did, as anyone present would describe it]
Impact: [the effect on the work, a teammate, a customer]
Their view: [the question you will ask, e.g. "How did it look from your side?"]
Request or question: [one specific ask, or an open question]

Check before it goes: one behaviour, no labels, no guess at motive, within days, would read fairly if they saw your notes. Praise uses the same shape.

Delegation brief

# [The work], for [name]

- Outcome: [what done looks like, and why it matters]
- By: [date]
- Limits: [budget, what must not change, who must be consulted]
- Authority: [plain words, e.g. "You decide; tell me after" (level 6 of 7)]
- Context: [documents, people, past attempts]
- Check-ins: [when, and what to bring], set by their experience with this work
- Review: [who reviews the result before it counts as done]
- Agents: [if an AI agent does part of it: who answers for its work, who reviews it]

Expectations and goals

# [Name]'s role and goals, [period]

## What the role owns
- [areas, and the decisions they make alone]

## What good looks like
- [one or two concrete examples]

## Goals for [period]
1. [an outcome] measured by [measure], by [date]. Tied to [team goal].
2. ...

## How we work together
- 1:1 [how often]; updates [where, how often]; I step in when [condition].

Agreed by [both names] on [date]. Look again on [date].

Team meeting

# Team meeting, [date]

Purpose: [why we meet]. Updates: read [where] before the meeting.

| Item | Owner | Decision needed? | Minutes |
|---|---|---|---|
| ... | ... | yes / no | ... |

## Decisions
- [decision], owner [name], by [date]

## Blockers
- [blocker], who helps, by [date]

Retro

# Retro, [period], [date]

Frame: everyone did the best they could with what they knew, their skills, the time and the tools.

## Last retro's actions
- [action]: done / not done, and why

## What happened
- [facts and events, from the record and from people]

## Why
- [causes the team agrees on]

## Changes (one to three)
- [change], owner [name], check on [date]

Team health read (private)

# Team health, [date] (for [manager] only)

| Signal | Source | Question for a 1:1 |
|---|---|---|
| ... | ... | ... |

What the record can't show: calls, coaching, thinking time, work done elsewhere.

Improvement plan (informal stage)

# Working together on [area], [name], [date]

- The standard: [what is expected, and where it was set]
- What happened: [situation, behaviour, impact, with dates]
- Their view: [in their words]
- What good looks like by [date]: [specific, observable]
- Support: [training, pairing, time, a lighter load]
- Check-ins: [dates]
- Next step if it doesn't change: the organisation's policy, with HR.

Shared with [name] on [date].

A worked example (invented)

Harbor Studio is a small design studio, led by its manager. The team: a new designer, four months into the job; a senior designer; and a developer. The senior designer works with a research agent that summarises client interviews.

The manager asks: "Prep my 1:1 with the new designer tomorrow, and I need to give them feedback about Tuesday's client call."

What the record shows (read 22 Oct): the new designer finished the Crumb onboarding screens (tasks/crumb-onboarding.md, done 17 Oct). They have two open tasks, one past due since 15 Oct (tasks/crumb-icons.md). A note from the senior designer asking them about icon sizes has been open since 14 Oct (design/crumb/icons.md). The new designer asked the manager on 16 Oct to approve the type scale; the manager hasn't answered (design/crumb/type.md, note to the manager).

The prep:

# 1:1 with the new designer, 23 Oct

## I owe them
- An answer on the type scale they asked about on 16 Oct (design/crumb/type.md).

## Thanks
- The Crumb onboarding screens: the bakery owners in the test finished set-up without help (tasks/crumb-onboarding.md).

## Ask
- What's taking longest on the icons?
- What did you make of Tuesday's call?

## Load
- Icons past due since 15 Oct; the senior designer's note on sizes open since 14 Oct. Ask if they're stuck or swamped.

## One thing to raise
- Situation: Tuesday's call with Crumb, when the client asked about the launch date.
- Behaviour: you said "end of the month" before checking with the developer.
- Impact: the developer's estimate is mid-November, so we now need to correct a date the client has written down.
- Their view: "How did that moment feel from your side?"
- Request: when a client asks for a date, say you'll confirm within a day, then check with whoever builds it.

Speaking up. The manager's draft said "you were careless on the call". The AI offered once: "Want me to put it as what they said and what it caused? They can act on that." The manager agreed. The AI also pointed out that the new designer has little experience of client calls, so a short practice before the next one would help more than the feedback alone (task-relevant maturity).

Delegation. The manager then hands the icon set's review to the senior designer: outcome "an icon set the new designer can finish this week"; authority "you decide sizes and style; tell me after" (level 6); check-in Friday. The senior designer's research agent will check the icons against the interview notes: the senior designer answers for its summary and reviews it before the new designer uses it.

Team health read. The record shows the developer holding most of the team's past-due tasks and the only person changing the build folder for a month. The read gives the manager one question for the developer's 1:1: "What could you hand over or drop?" Nothing about it goes in a team document.