How we communicate

Communication is most of the job. Software is just the residue of a lot of people understanding each other well enough to build the same thing. Here's how we try to do it.

Async first

We default to async. Not because we dislike each other, but because async is how you get long, uninterrupted stretches to do real work, and how you include people across timezones without making anyone set an alarm.

Async also means most of what we say is written, and writing is a feature. A written message can be read carefully, replied to when someone's actually ready to think, and found again in six months. A meeting evaporates the moment it ends.

Writing over meetings

When in doubt, write it down. A short doc or a clear message beats a call for almost everything, because it scales to people who weren't in the room and to a version of you that's forgotten the details.

Good writing here is short, specific, and honest about what you're unsure of. You don't need to be a stylist. You need to make the reader's job easy: say the point first, then the reasoning, and don't bury the actual ask three paragraphs down. See how we work for why we lean on this so hard.

Public by default

Talk in the open. Public channels beat DMs, comments on the doc beat a private aside, and the GitHub org beats a conversation nobody else can see.

The reason is selfish as much as principled: public conversation is searchable, and someone you've never met might have exactly the context you're missing. A DM helps one person once. The same message in the open helps whoever hits the same question next month. Keep private only what's genuinely private: pay, health, performance, and anything about a specific person that isn't theirs to broadcast.

When to actually talk

Real-time isn't banned. It has a narrow, real use. Reach for a call when:

• A disagreement has gone three rounds in writing and isn't converging.
• Something's on fire and the latency of async is costing you.
• The conversation is emotional, delicate, or just easier said than typed.
• You're new, or working with someone new, and need to build some human rapport.

When you do talk, write down the outcome afterward. The call was for the people in it; the notes are for everyone else. A decision that only the attendees know about isn't really a decision the company made.

Kind and direct

The tone we're after is kind and direct, not one at the expense of the other. Direct without kind is just being a jerk with extra steps. Kind without direct is a slow way of wasting someone's time.

Say the true thing, plainly, and assume the other person can handle it. Skip the compliment sandwich; people can smell the filler, and it makes the real feedback harder to find. How to give it well, and take it well, is its own page: giving and getting feedback.

Handling disagreement

Disagreement is a feature. A team that never argues isn't harmonious, it's just not paying attention. We want the argument: early, in the open, about the work.

The rule is that you fight about ideas, not people, and you fight to find the right answer, not to win. Argue your case as hard as you honestly can. Then, when a call gets made, get behind it even if it wasn't yours. That's the disagree-and-commit norm, and it's covered properly in how decisions get made. Sulking after a decision isn't principled; it's just slow sabotage.

The community

Discord is where we talk with the people who use and follow the work. It's not a support queue or a marketing channel, but a room where the company happens to be legible.

Talk to the community like you'd talk to a colleague: kind, direct, and honest about what you don't know. If you don't have an answer, say so. If something's a bad idea, say why. People can tell the difference between a company that's listening and one that's performing. Come find us at the Discord, or email hey@flagon.io if you'd rather not do it in public.