--- title: "One-to-Ones That Matter, and Handling Conflict" author: "Harry" published: 2026-10-31T04:50:50.458Z updated: 2026-10-31T05:08:37.105Z category: "Career & Teams" tags: [] canonical: "https://fxblog.dev/posts/one-on-one-meetings-and-team-conflict" --- # One-to-Ones That Matter, and Handling Conflict ## Key takeaways - A one-to-one is the team member's meeting: their agenda first, then yours, then the future. - Weekly and short beats monthly and long; a cancelled one-to-one tells someone they matter less than a meeting. - If the lead writes most of the agenda, it has become a status meeting. - Handle a conflict privately with each person first, then together, and end with a shared rule rather than a winner. - Code review comments are about the code, never the person; labels like question, suggestion and nitpick make the tone clear. > **TL;DR** Skip one on one meetings because standup "covers it" and you hear about trouble only when someone stops showing up. Hold them weekly, with the team member's agenda first. When two people clash, talk to each privately, then bring them together, and end on one shared rule instead of a winner. > > **Do this:** Book a weekly 30-minute one-to-one with each person, their items first. Part 2, **Hire and Grow Your Crew**, ended with Quill's first real pull request: fourteen comments from Brock, the last one "Why would anyone write it like this?". The next morning Quill skipped standup. Pip had also been "too busy" for one-to-ones since she became lead. That changes this week. **Dev Voyage: Uncharted Waters, in five parts:** 1. **From Best Engineer to First-Time Lead** 2. **Hire and Grow Your Crew** 3. **One-to-Ones That Matter, and Handling Conflict** (you are here) 4. **Manage the Team: Goals, Trust and Delivery** 5. **Build the Ship You Want to Sail On: Culture and Giving Back** ## The meeting that belongs to them Standup covers the tickets. It never covers the person quietly deciding whether they belong. GitLab's handbook is clear about the shape of a one-to-one. It's mainly for the team member. Both people add items to a shared agenda, and if the manager adds more than half, something is off. The manager should do about 20% of the talking, and cancelling is a last resort. Pip booked thirty minutes a week with each of her four crewmates, in a running document: ```text Theirs first - Mine - The future (every few weeks) - What do you want to learn next? Actions - [ ] who · what · by when ``` For the very first one, she borrowed Lara Hogan's questions: what makes you grumpy at work, how will I know, and how do you like to be recognised? ## "Were the other thirteen right?" Quill's one-to-one came first. For ten minutes he talked about anything but the pull request. Then he read Brock's last comment aloud, word for word. > **Note** > > **Quill:** "Why would anyone write it like this?" > **Pip:** Were the other thirteen right? > **Quill:** Yes. Most of them. It's that one. Both sides were true. Brock's review was right on the code: the rounding bug he caught would have reached customers. Quill's hurt was real too, and a junior who stops asking questions is a bigger risk than one rounding bug. A lead who picks a side loses the other person. ## Private first, then together ![Brock and Quill clash: Pip talks to each privately, then brings them together to agree one rule; picking a winner in public lets the conflict grow](https://fxblog.dev/media/01a1904b-98ef-74d0-85a9-c2d4e1ac7034/1600) _Private first, then together, then a rule_ 1. With Quill, alone: separate the fact (a real bug) from the feeling (the last line read as contempt). 2. With Brock, alone: not "you were mean", but the impact. "One line landed hard. He skipped standup." Brock went quiet. "I didn't mean it like that." 3. Together, briefly: Brock said the comment was about the code and read as being about Quill. Quill thanked him for the bug. 4. One shared rule, written down by them, not by Pip. Pip owned her part too. A newcomer's first pull request had gone, alone, to the bluntest reviewer on the crew. From then on, a newcomer's first few PRs got two reviewers, one of them their buddy. > **Warning** > > If the same clash comes back after the rule, or someone feels unsafe, it's no longer a style difference. Write down what happened, talk to your own manager, and involve HR if you have it. ## The rule they wrote Brock's version: "Comment on the code, ask the why." Quill's addition: "And I ask before I guess." Google's code review guide says the same: be courteous, and comment on the code, never the developer. The crew added Conventional Comments labels, so every comment says how much it matters. | Instead of | Write | | -------------------------------------- | -------------------------------------------------------------------------- | | "Why would anyone write it like this?" | "**question:** Is there a reason the rounding happens before the tax?" | | "This is wrong." | "**issue:** This rounds twice for discounted items; see the failing case." | | "Rename this." | "**nitpick (non-blocking):** `calc2` could be `applyDiscount`." | | (nothing, when it's good) | "**praise:** The zero-price test is a great catch." | ## Try it This week: 1. Book a weekly 30-minute one-to-one with each person, in a shared doc, their items first. 2. In the first one, ask how they like to work and how they like to be recognised. 3. If two people clash, talk to each privately before you bring them together. 4. Propose review labels: question, issue, nitpick, praise. Two weeks later Brock and Quill were pairing on the discount service, and Brock's reviews had started to include **praise**. Then Ollie dropped next quarter's plan on Pip's desk, due to the Admiral on Friday, with a blank line where the checkout crew's goals should be. Part 4, **Manage the Team: Goals, Trust and Delivery**, is how she filled it, and what she told the Admiral when one goal turned red. ## Read this with your AI ```text Read the post "One-to-Ones That Matter, and Handling Conflict". 1. Draft a first 1-1 agenda for a new team member, with four questions about how they like to work. 2. I'll describe a conflict on my team. Separate the facts from the feelings for each person. 3. Rewrite these review comments with question, issue, nitpick or praise labels: [paste] ``` > **Success** > > You can run one-to-ones that belong to your team, and resolve a conflict without picking a winner. Next: **Manage the Team: Goals, Trust and Delivery**. ## FAQ ### What should I talk about in a one on one with my team member? Whatever is on their mind first: blockers, worries, ideas. Then your items, such as feedback and context from above. Then the future: growth, goals, what they want to learn. A shared running document keeps it going between meetings. ### How do I handle conflict between two people on my team? Talk to each one privately first, listen, and separate the facts from the feelings. Then bring them together to agree one concrete rule for next time. Do not pick a side in public, and do not wait for it to fade on its own.