Make Friends on the Ship: Working Happily With Colleagues
Misreading a short reply or correcting a senior in public keeps you a guest on the team. Build trust in small, repeated acts: public thanks by name, ten-minute help, and corrections made privately first.
Key takeaways
- A fast, one-line answer from a busy colleague is help, not dislike: judge what people do, not how they type.
- Help that costs you ten minutes, like a quick review or a pairing session, adds up week after week.
- Give credit in public and by name; it costs nothing and people remember it.
- When you find a colleague's bug, tell them first and fix it with them, then thank them in the pull request.
- Teams where people feel safe to speak up do better work; you add to that safety every time you respond kindly to a question.
Contents
FAQ
How do I point out a senior colleague's mistake?
Privately and first, with the evidence and an offer to help: "I think test_checkout fails one run in five because of a timing wait; want to pair on it?" Fixing it quietly or raising it in a meeting first both cost trust.
Does a one-line reply from a colleague mean they are annoyed?
Usually not. Look at what they did: a fast, correct answer to someone they barely know is help. Thank them by name in the channel; that tells you more about the relationship than their writing style.
Sources
Only you and the owner see your answer and rating. Send private feedback
Enjoyed it? Support fx-blog with a coffee.
Related posts
Build the Ship You Want to Sail On: Culture and Giving Back
If a team's good habits live only in its lead, it works only while the lead is in the room. Repeat a few habits weekly: specific thanks, a calm reply to bad news, sponsoring people for real chances, and handing on what you learned.
Manage the Team: Goals, Trust and Delivery
Eleven goals nobody remembers, and a red result found in week 12, cost a lead the team's focus and the boss's trust. Set a few measurable results with one owner each, send a five-line update weekly, and report red early with a plan.
One-to-Ones That Matter, and Handling Conflict
Skip one-to-ones and you hear about trouble when someone stops coming to standup. Hold them weekly with their agenda first; when two people clash, talk to each privately, then together, and end on a shared rule, not a winner.
Comments
Oldest firstNo comments yet. Start the conversation.
Part 2 ended with Pip unstuck and worried. Brock's answer was one line long, no greeting, no smiley. Is he annoyed? Does the crew like her at all? At lunch she finally asks Bun, who is busy filling bowls.
"Brock answered in one line. Did I annoy him?"
"He answered fast," says Bun. "That's his compliment. Dumpling?"
Dev Voyage: Calm Sea, in five parts:
Read what people do, not how they type
Some people write warm paragraphs. Some write
Node 20. .nvmrcand go back to work. Brock replied within minutes to a question from someone he had met twice. That's what a crewmate looks like when he's busy.Say thank you where everyone can see it
Bun's second piece of advice was to thank him in the channel. So Pip did:
Five seconds to write. Brock felt seen, and everyone else learned who knows the build. Brock's reply was "...anytime", which, from Brock, is a speech.
Public thanks is one of a handful of cheap habits that add up. Review someone's pull request and say what you checked. Offer to pair on the thing you fought with yesterday. Fix the broken docs link nobody owns, and mention it in one line. None of these takes more than ten minutes, and people remember who made their week easier.
Correct in private, first
In week five Pip found that
test_checkout, one of Brock's tests, failed about one run in five. She saw three ways to handle it.Fixing it quietly means Brock never learns the cause, so his next test has the same timing bug. Raising it in standup gets it fixed, and Brock remembers being corrected in front of everyone. Pip took the third way and sent a direct message:
They fixed it in twenty minutes. The pull request said "with Brock".
This is part of the job
It's tempting to file all this under being nice, on top of the real work. But when Google studied what made its own teams effective, in Project Aristotle, the strongest factor it found was psychological safety. Amy Edmondson's research, written up in Harvard Business Review, describes the same idea.
Every kind answer to a newcomer, every public thank-you and every private correction makes your team a bit safer to speak up in. You don't need to be senior to start.
Try it
This week:
By week seven Pip has a friend in Bun, a pairing partner in Brock, and the discount feature is nearly done. On Friday at 17:32, with everyone thinking about the weekend, she deploys it. At 17:38 checkout starts returning errors to real customers. Part 4, When You Break Something: Owning a Mistake Without Losing Trust, is Pip's next hour, and what Kit says when she tells him.
Read this with your AI