One-on-One Meeting Template: Leave With Decisions, Not More Tasks
Use a free 30-minute one-on-one agenda, an employee preparation checklist, and a completed example to discuss priorities, blockers, and development.
A useful one-on-one meeting template gives you space to discuss priorities, obstacles, feedback, and development, then records what each person agreed to do. Put routine updates in writing before the meeting. Use the conversation for the questions that need a manager's judgment, support, or decision, rather than reading your task list aloud.
The agenda below is designed for an employee meeting with their manager. It is an original working template, not a formal performance-review form or a requirement to fill every minute.
Table of contents
- What should a one-on-one meeting cover?
- What is the copyable 30-minute agenda?
- How do you prepare as the employee?
- What does a useful conversation sound like?
- How do you follow through when meetings slip?
- Frequently asked questions
What should a one-on-one meeting cover?
Cover the work and working conditions that need a conversation between you and your manager. Start with the most consequential unresolved issue, even if it does not fit neatly into a recurring agenda.
GitLab's public one-on-one guidance uses an ongoing agenda and includes career development conversations. The transferable idea is continuity: you should be able to see what you discussed and what happened afterward.
Keep three kinds of material distinct:
- Updates: information the manager can read without discussion.
- Conversation: a question, obstacle, feedback topic, or development need.
- Agreement: a decision or action with an owner and a follow-up point.
A list of completed tasks belongs mainly in the first category. “Two deadlines conflict; which outcome should I protect?” belongs in the second. “Jordan will confirm the priority by Tuesday” belongs in the third.
Your one-on-one is also a place to raise a concern before it becomes a crisis. You do not need a polished solution to every problem. Bring enough context to help the other person understand what support would be useful.

What is the copyable 30-minute agenda?
Use a short check-in, one substantial topic, and a clear closing record. Treat the time allocations as adjustable guidance, not a stopwatch you must obey.
Download the plain-text one-on-one template, or copy these headings into your usual document:
| Time | Topic | Prompt |
|---|---|---|
| 0–3 minutes | Check-in | What needs attention before we talk about tasks? |
| 3–8 minutes | Priorities | Has anything changed about what matters most? |
| 8–20 minutes | Main discussion | What decision, obstacle, or feedback needs our attention? |
| 20–25 minutes | Development | What am I learning, and what support would help? |
| 25–30 minutes | Agreements | Who will do what, by when, and when will we check? |
Above the agenda, record the date and link to any routine update. Below it, keep an action table with four fields: action, owner, due date, and status. Carry unfinished agreements forward visibly instead of copying every old paragraph into a new meeting.
If a difficult topic needs most of the half-hour, use the time for it and schedule the remaining discussion. A complete conversation is more valuable than racing through five headings without resolving anything.
For ordinary progress reporting, consider an asynchronous update. Atlassian's weekly-update practice describes using written or recorded updates to reduce status meetings. That leaves your one-on-one available for the work that benefits from dialogue.
How do you prepare as the employee?
Choose one outcome you want from the meeting and gather the minimum context needed to discuss it. Preparation should sharpen the question, not become another large deliverable.
Use this five-question check:
- What changed since we last spoke?
- Which commitment is most at risk?
- What decision or support do I need?
- What have I already tried or considered?
- What would make the conversation useful by the end?
For a workload issue, bring the deadlines and consequences. “I am overwhelmed” is worth saying, but “The launch review and customer audit both need my Thursday afternoon; which should move?” is easier to act on.
For development, bring an observed task and a specific question. GitLab's career-conversation guidance includes discussing strengths, skills, and development opportunities. You might ask to observe a planning session, receive feedback on one presentation, or take on a bounded piece of work.
Add your main question to the shared agenda beforehand. Avoid surprising your manager with a complex decision they could have prepared for. Also avoid burying the question under a long chronology: lead with what you need, then supply the context.
What does a useful conversation sound like?
A useful conversation makes the choice and its consequences visible. It ends with a shared understanding of the next step, even when the answer is not the one you hoped for.
This fictional example shows a priority conflict:
Maya: I can finish the customer audit by Thursday or prepare the launch walkthrough to the current scope. Doing both means neither gets a proper review. I recommend keeping the audit deadline and reducing the walkthrough to the core flow. Which outcome should I protect?
Jordan: Keep the audit deadline. I will tell the launch team we are narrowing the walkthrough.
Maya: Then I will send the audit draft Wednesday afternoon, and you will confirm the reduced walkthrough scope today. Is that right?
The exchange produces two owned commitments. It does not magically remove the work; it makes the tradeoff explicit.
Use meeting notes to record the decision, not a transcript. If you struggle to name a capacity limit, the saying-no-at-work guide offers ways to describe what you can do and what must change.
The same approach works when your manager disagrees. Ask which assumption differs: the effort estimate, deadline, quality requirement, or priority. That gives you something concrete to resolve.

How do you follow through when meetings slip?
Keep the action record current and ask for a replacement time when an important conversation is canceled. Do not let repeated cancellations silently become the working arrangement.
A short message is enough: “I understand today no longer works. Could we find another slot this week? I need a decision on the audit deadline before Thursday.” Separate the urgent decision from topics that can wait.
For routine follow-up, check the last action table before creating a new agenda. Mark completed items, explain blocked ones, and identify anything that no longer matters. GitLab's guidance treats follow-through as part of development conversations; the document should show movement over time.
If recurring meetings produce more commitments than your week can hold, ask what the new work replaces. Then move the agreed priorities into a daily planning template. Your calendar should reflect the actual decision.
Do Only 3 Things a Day adds the Choose, Protect, Do, Review loop, a daily card, and a seven-day start. It helps turn a good conversation into a day you can execute without treating every new request as equally urgent.
Frequently asked questions
Who owns the agenda?
Both people can contribute. As the employee, bring the concerns, decisions, and development questions that matter to your work. Agree on how far in advance to add topics so neither person has to guess.
How often should we meet?
Choose a rhythm that matches the work, your support needs, and the manager's availability. Weekly or fortnightly can be starting options. Revisit the frequency when the role or project changes rather than treating it as permanent.
What if I have nothing to discuss?
Check unresolved commitments, priorities, feedback, and development before assuming there is nothing. If those are genuinely covered, agree to shorten or reschedule. Inventing updates to fill the slot helps neither person.
Should the document be shared with the team?
Usually keep the conversation record limited to the appropriate participants. Share work decisions separately where teammates need them. Do not place sensitive personal or performance information in a broadly accessible project document.