Flagon: We build software in the open.

Feedback is how a small company stays sharp. When there are only a handful of you, there's no layer of management to catch problems or polish rough edges, so the quality of the work depends on people telling each other the truth, kindly and often. Most teams say they want honest feedback and then flinch every time they get it. We'd rather build the habit for real. This page is how.

Kind and direct, at the same time

The trap most people fall into is thinking kind and direct are opposites, so they pick one. Pick kind and you get vague reassurance that helps nobody. Pick direct and you get someone who's technically right and exhausting to work with. The skill is holding both: care about the person enough to tell them the actual thing.

Kind and direct means you say the real problem plainly, and you say it because you want the work and the person to be better, not because you enjoy being right. The tone is warm, the content is honest, and you don't dilute the content to protect the tone.

Timely, specific, about the work

Feedback has a shelf life. The best time to say something is close to when it happened, while the details are fresh and the person can still do something with it. Feedback saved up for weeks and delivered in a batch lands like an ambush, and half of it is stale anyway.

Be specific. "This section is confusing" is more useful than "great job," and "this section is confusing because it introduces the API before explaining what it's for" is more useful than both. Keep it about the work, not the person. There's a real difference between "this function is hard to follow" and "you write confusing code." One is a fixable observation about a thing on the screen. The other is a verdict about a human being, and it makes people defensive instead of better.

Good vs bad, concretely

Bad: "Honestly this whole approach is kind of a mess." Good: "I got lost around the third step. Could we split the validation out so the happy path reads top to bottom?" Both are critical. Only one tells the person what to do next.

How we receive it

Getting feedback well is a skill too, and it's the one that makes the whole thing sustainable. If people get punished for speaking up, even with a sigh or a defensive rebuttal, they stop, and then you're flying blind.

When you're on the receiving end, assume good intent. The person took a risk and spent effort to help you, so start from the belief that they're trying to make the work better, because they almost always are. Ask questions if it's unclear. You don't have to act on every piece of feedback, but you do have to actually hear it. Thank people for it, sincerely. "Thanks, that's a good catch" costs you nothing and keeps the door open for the next person.

Praise in public, criticize in private

Praise is better with an audience. When someone does good work, say so where others can see it, in the channel, in the review, in the notes. It's genuine, it's contagious, and it tells everyone what good looks like here.

Criticism is the reverse. The correction itself lands better one to one, without a crowd, where the person can absorb it without also managing how they look in front of everyone. The exception is technical critique of shared work, a design or a pull request, which lives in the open by nature. Even there the rule holds: the comment is about the design, not the designer.

Feedback is part of working in the open

We build in the open, which means our disagreements and our course corrections are visible too, in review threads and issue discussions and the communication we keep public. That's not a bug. Watching people give and take honest feedback in public, and stay collegial doing it, is one of the more useful things an outsider can learn about how we work. It only works if the feedback is real. A handbook full of nice words about candor, contradicted by comment threads full of "LGTM," would fool no one. We do the actual thing, in how we work and everywhere else.