Making feedback count

Async-friendly organizations like ours work in total transparency. At Slite, 99% of company information is available to anyone. It’s a lot - our team of 35 creates 700 documents per month, on average. When you jump into a doc, you’ve probably already missed a few iterations or conversations.

People who are most successful in async work are proactive and motivated - and work to influence decisions outside of their core responsibilities. These "drivers" are really valuable to the team – unless they bring more noise.

Think about a typical work in progress. Maybe it’s a job description, or a product roadmap. You're jotting down thoughts in a document, leaving yourself time to think. It's early in the morning. You don't want to keep it in your private files, because everyone should be able to know where things stand. You leave to get a cup of coffee and then - Oh no - someone’s commented all over your document. Getting feedback at that moment can be frustrating, since it can divert and distract you. At worst, it discourages you from completing the job.

We believe unsolicited feedback is a bias for companies where over-communication, detailed documentation and equitable knowledge sharing is valued. That's why we put a few systems in place to prevent it:

• Use clear nomenclature: In the title, at the root or top of your doc, add a clear [WIP] or 🚧  emoji. For transparency's sake, coworkers can still read, but they'll be less likely to comment.
• Make doc ownership explicit: Name owners and participants, and invite the contributors you need to make the discussion move toward a decision. It's not a rule that forbid others from contributing, but it clarifies who's indispensable.

We’ve noticed over time that a lot of unsolicited feedback comes from new team members eager to make an impact. We’ve added a "Slite writing guide to our Handbook so that everyone knows, from onboarding onwards, how we work, and how we communicate.

But we shouldn’t always fight the urge to give feedback. Open, constructive and relevant feedback, even unsolicited, will always be better than poor feedback that’s solicited. And by adding more context within the doc's structure (naming owners and contributors, assigning due dates ) and contents (titling the document, noting where comments are welcome), unsolicited feedback will improve, and team synergy as well.

Instead of jumping into a doc without context, you can see the whole history – even if you haven’t been a part of every step.

Temptation to contribute to working docs is obviously huge. When you see a good idea, expressed in writing, it’s hard not to want to chime in. But the goal of feedback is to move the conversation forward, not slow work down.

Have any feedback on this one?