One-to-Ones That Matter, and Handling Conflict

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:

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.

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

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.

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.

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

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]