Written feedback in remote teams sounds like the easy option: you type two sentences, hit send, and nobody has to look anyone in the eye. Yet that very convenience is what keeps me thinking. In a remote team almost everything is text, so almost every piece of feedback ends up in chat. And that is exactly where a friendly hint can quickly turn into a small sting.
This article therefore tackles a simple question with many shades of grey: when is a message enough, and when should you pick up the phone instead? You also get a template, before-and-after examples and a checklist to run through before you hit send.
In short
Text carries content well and tone poorly, which is why written feedback often lands harder than intended. Praise and small pointers work fine in chat, while criticism of behaviour and conflicts belong in a call. When you do write, a structure of situation, behaviour and impact plus a genuine question at the end helps a lot.
What you will learn in this article
- Why text messages often land harsher than you meant them
- How to decide whether feedback belongs in chat or in a call
- An SBI template for written feedback with before-and-after examples
- A pre-send checklist and ideas for feedback rituals in remote teams
Why does written feedback feel harsher than intended?
In a conversation you send much more than words. Your voice softens, you smile, you pause for a moment. In chat, all of that disappears. What remains is the bare sentence, and the other person reads it in whatever mood they happen to be in.
There is a study on this that I like to cite precisely because it is uncomfortable. In 2005, Justin Kruger, Nicholas Epley and colleagues ran five experiments on how well people convey tone by email. The result: writers clearly overestimated how well their intention came across. The authors attribute this to egocentrism. While writing, you “hear” your own irony or warmth, but your reader does not.
The gap usually gets filled with the less kind reading
I cannot back the next point with numbers, but I see it often enough to treat it as a rule of thumb. When tone is missing, people tend to fill it in sceptically rather than generously. A “Got a minute?” from the team lead makes many hearts beat faster. Likewise, a terse “ok.” with a full stop reads colder than it was meant. A difference in hierarchy amplifies the effect, too. Anyone who depends on you reads your message more closely and more suspiciously than you wrote it.
Timing adds to this. You write at 5 p.m. between two meetings, and your colleague reads it alone in front of her laptop the next morning. She cannot ask what you meant; she can only ruminate. So you can still give written feedback. It just takes more care than a quick remark in the office corridor.
When should you give written feedback in remote teams, and when should you talk?
My rule of thumb is simple. The more emotion, relationship or uncertainty is involved, the more the topic belongs in a call. Conversely, the clearer, smaller and more positive the message, the better text works. The GitLab Handbook, which many remote teams use as a reference, takes a similar line. Async is the default there, but not a dogma, and it explicitly recommends a video call when you are stuck.
What works well in chat
- Specific praise for a piece of work, ideally soon after it happened
- Small factual pointers, such as a missing link in a ticket
- Feedback that someone explicitly asked to receive in writing
- Summaries after a conversation, so both of you record the same thing
What belongs in a call
- Criticism of behaviour, for example how someone treats others on the team
- Conflicts between two or more people
- Topics that come up for the first time and affect you emotionally as well
- Anything that could have consequences for someone’s role, project or contract
Write or talk? Three questions lead you to the right channel.
The two-round rule
Sometimes you only notice along the way that text is not enough. For this I use a rule of thumb. If a misunderstanding is still hanging in the air after two rounds of messages, I switch to a short call. For example: “I think we’re talking past each other. Do you have ten minutes for a call today?” That is not a failure. It saves you both a third and fourth round, in which positions usually just harden.
How to give written feedback in remote teams without it backfiring
For structure, I use the SBI model from the Center for Creative Leadership (CCL). SBI stands for Situation, Behavior, Impact. I covered the basics and the conversation itself in my guide to giving feedback. Here, the focus is on writing. According to CCL, SBI lowers anxiety for the giver and defensiveness for the receiver. In text that effect is especially valuable, because you have no facial expression to soften things.
CCL also adds a fourth step to SBI: asking about intent. The reasoning is plain and hits the mark: “The only way to know what someone intended is to ask them.” For written feedback this is gold. A genuine question at the end turns your message from a verdict into an invitation.
The template to copy
// written-feedback-template.txt
Reason: Say briefly what this is about and why you are writing.
Situation: When and where exactly? (meeting, ticket, channel)
Behaviour: What did you observe? Facts only, no interpretation.
Impact: What did it cause for you, the team or the customer?
Question: How did you experience it? / What was your thinking?
Offer: If you would rather talk, just give me a call.
The SBI template for chat: four building blocks from CCL, framed by a reason and an offer to talk.
I added the reason and the offer for everyday remote work. The reason spares the other person the question “Why is she telling me this now?”. The offer makes clear that text is not the final word. Both cost you two sentences and often save someone a sleepless night.
Before and after in three examples
Picture a fictional team building the booking app for a bike rental shop. The following messages are made up, but the patterns behind them are typical.
| Before | After |
|---|---|
| “Great work!” | “Your demo of the new return feature in today’s sprint review was really good. You started with the real flow at the rental terminal, so the product owner immediately understood why we need the rework. Thank you!” |
| “The ticket is incomplete.” | “Quick note on the ticket for the price display: I can’t find the link to the design draft. Without it, Jonas spent an hour searching yesterday. Could you add it? If I’ve missed it, just let me know.” |
| “You keep interrupting people in the daily. This has to stop.” | “I noticed something in today’s daily that I’d like to talk to you about. It’s about how we let each other finish. Do you have 15 minutes for a call tomorrow? Nothing dramatic, I just want to understand how you experienced it.” |
In the third example, the actual feedback is deliberately not in the chat. Criticism of behaviour belongs in the call; the message only prepares it. What matters is that it roughly names the topic. A bare “We need to talk” leaves the other person in the dark until the meeting, and that is the unkindest option of all.
Which checklist helps before you hit send?
Whenever I want to give written feedback, I quickly run through these points first. It takes a minute, and in that minute more than one message has ended up back in drafts.
- Is text the right channel at all, or does this belong in a call?
- Am I calm enough right now, or am I writing out of annoyance?
- Does it name a specific situation instead of “always” or “constantly”?
- Am I describing behaviour rather than judging the person?
- Is the impact understandable and not exaggerated?
- Does the message end with a genuine question or an offer to talk?
- Would I say exactly this out loud, with the person in front of me?
- Is the timing right, so not Friday evening and not just before their holiday?
- Is it the right place, meaning a direct message rather than the team channel?
Point seven paraphrases the GitLab Handbook. It says you should not send someone anything on Slack that you would not also say to their face. To check, I read my message aloud once, half under my breath. If it sounds like an accusation, it isn’t finished yet.
Praise in public, criticise in private?
The old rule applies even more in remote teams. A team channel is a stage with a permanent archive. Criticism posted there stays visible, gets forwarded and resurfaces in search weeks later. The GitLab Handbook is unambiguous here, too: negative feedback happens one-to-one, while thanks can go into a dedicated public channel.
Public praise needs tact as well
Not everyone enjoys applause in front of the whole team. Some people love a thank-you in the big channel, while others find it awkward. That is why the GitLab Handbook advises managers to consider each person’s preferences. So simply ask in your next one-on-one how someone likes to receive recognition. It also pays to look at the distribution. If you always praise the same three people in public, the others will notice.
And feedback in pull requests?
Code reviews are a special case, because criticism of code has to be public and written there. That works well as long as it targets the code and not the person. However, once tone, attitude or recurring patterns become the topic in a review thread, it should move out of the pull request and into a conversation. I explain how to phrase review comments themselves in my article on code review feedback.
Which rituals make feedback easier in remote teams?
Feedback gets easier when it doesn’t only happen in exceptional situations. Someone who receives a few positive messages every week will also read a critical pointer more calmly. A ritual builds exactly that habit.
- Weekly kudos: A dedicated channel where anyone can say thanks at any time. On Fridays, the team lead or Scrum Master links the week’s posts in the team channel.
- Kudos in the retrospective: Five minutes at the start in which each person thanks someone else for something specific.
- A feedback question in one-on-ones: “What should I do more or less of as your team lead?” This way, the team practises giving feedback upwards.
You will find more rituals for distributed teams in my article on leading remote teams. One tip from my side: keep kudos specific. “Thanks everyone for a great week” is nice, but nothing sticks. In contrast, “Thanks to Mira, who found the bug in the deposit refund and documented it cleanly” does.
How do you handle time zones and response times?
Asynchronous feedback has a built-in catch: hours often pass between sending and replying. The GitLab Handbook states clearly that nobody has to respond outside their own working hours. For you as the sender, this means factoring in the wait from the start.
- Don’t send critical feedback at the end of your day if it arrives at the start of theirs and they then can’t reach you for eight hours.
- Say whether and when you expect a reply, for example “No rush, let’s talk about it in our one-on-one on Thursday”.
- Use scheduled sending so your message arrives during their working hours and doesn’t pop up on their phone at midnight.
- Respond quickly yourself when someone replies to your feedback. Silence after a critical message is particularly wearing.
How much overlap a team needs depends heavily on how it is distributed. If many hours separate you, the two-round rule quickly becomes a two-day rule. In that case it pays even more to raise sensitive topics in your next shared time window.
Why you should follow up after written feedback
If you give written feedback in remote teams, you are not done once you hit send. You simply don’t know how it landed. A thumbs-up emoji can mean “Thanks, got it”, but it can just as well mean “I want this off the table quickly”. That is why I follow up in the next conversation on anything beyond a small bit of praise.
It can be very light: “I messaged you on Tuesday about the ticket descriptions. How did that land with you?” Your regular one-on-one is the natural place for this. How to set it up so it is more than a status meeting is covered in my article on recurring one-on-ones.
When following up, listen for undertones. If someone hesitates or changes the subject immediately, the message may have been sharper than you thought. In that case, an open “If that sounded harsher than I meant it, I’m sorry” helps. The follow-up is also the moment when you get feedback on your feedback. Over time, you learn how your messages land with individual people.
My take
For me, “people first” means one thing above all on this topic: the most convenient channel for you is not automatically the best one for the other person. A call costs you some courage and a calendar slot. A misleading message may cost the other person an evening of brooding. It is worth doing that maths honestly.
At the same time, I see no point in demonising written feedback in remote teams. Well-written praise can be kept and reread, while spoken praise fades. Text also gives introverted people time before they respond. That is a real advantage that some call enthusiasts underestimate.
Where I push back is a common reflex: giving criticism in writing because it feels safer. It is safer for you, but usually not for the other person. If a team already has little trust, the effect gets even stronger. I describe how to work on that fundamentally in my article on psychological safety for team leads. My goal is a team in which a short message doesn’t set off alarm bells, because there is enough trust.
FAQ
Is it okay to send critical feedback via Slack or Teams?
Small factual pointers, yes, in a direct message and following the SBI structure. However, criticism of behaviour or anything with conflict potential should be discussed in a call and only summarised in writing afterwards.
Do emojis make feedback come across as friendlier?
An emoji can soften a sentence a little, but it won’t fix harsh content. Also, people and cultures read emojis differently. Rely on clear, friendly words and a genuine question instead.
What should I do if someone doesn’t respond to written feedback?
Don’t read silence as agreement or rejection. Raise it openly in your next one-on-one and ask how the message landed. Often the person simply didn’t know whether a reply was expected.
How long should written feedback be?
As short as possible, but with situation, behaviour and impact. Three to five sentences are usually enough. If the message gets much longer, that is often a sign the topic belongs in a conversation.
Your next step
This week, pick one person on your team and send them specific praise using the template, with situation, behaviour and impact. Notice how they respond, and compare it with a quick “Well done”. Now I’m curious: what kind of feedback in chat has ever landed completely differently than you expected? Share it in the comments.
Sources
- Center for Creative Leadership: Use SBI (Situation-Behavior-Impact) to Inquire About Intent
- Kruger, Epley, Parker, Ng (2005): Egocentrism over e-mail. Can we communicate as well as we think? Journal of Personality and Social Psychology 89(6)
- GitLab Handbook: Asynchronous communication
- Communication guidelines in the GitLab Handbook
- GitLab Handbook: Guidance on Feedback
This post was created with AI assistance.
👉 Next step: Preparing a first one-on-one? My question cheat sheet puts the best questions on one printable page.
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (0)