How we work

This is the day-to-day of Flagon: how work actually moves, not the poster on the wall. Like everything here, it changes when we learn something better.

Ship when it's good, not when it's due

We don't ship to a date for its own sake. We ship when the thing is actually good, and we work in pieces small enough that "good" is reachable in a reasonable amount of time.

That's not permission to polish forever. Small batches force the question early. If you can't get a piece to "good" in a couple of weeks, the piece is too big, and the fix is to cut it down, not to lower the bar. A deadline can be a useful forcing function. It's a bad master.

Small batches, always

Big releases are where quality goes to die. They're hard to review, hard to reason about, and when something breaks you're left bisecting a month of changes.

We default to small: small pull requests, small decisions, small bets. A change you can hold in your head is a change you can get right, and it keeps us close to a working state. The cost of being wrong is one small thing, not a quarter of work.

Default to open

Work happens in the open unless there's a specific reason it can't. That means public channels over DMs, written docs over hallway context, and git history over tribal memory.

Ask whether a new person joining tomorrow could reconstruct why things are the way they are just by reading. If the only answer lives in someone's head or a private thread, we haven't finished the work. There are real exceptions. Anything about a specific person's pay, health, or performance is private, full stop. Almost nothing else is.

Write it down

We're a writing company before we're a meeting company. A short doc beats a long call, because a doc can be read whenever the reader is ready, argued with in the margins, and still be true next month.

Writing also does something meetings don't: it exposes fuzzy thinking. If you can't explain a plan in a paragraph, you probably don't understand it yet. The paragraph is cheaper to fix than the shipped feature. More on the mechanics in communication.

Idea to shipped

There's no elaborate pipeline. Roughly, a piece of work goes:

• Someone has an idea and writes it down, a paragraph or two on the problem and why it matters. Not a spec, just enough to think against.
• It gets kicked around in the open. People poke holes, add context, or say "not now." It's cheap to kill an idea here and expensive later.
• Someone owns it and cuts it to a small first slice. One owner, not a committee: see how decisions get made.
• It gets built and reviewed in small pieces, in public.
• It ships when it's good, and we say so: what changed, and why.

That's it. If a step stops earning its place, we drop it.

Async first

We're async by default. Async gives you long stretches of uninterrupted time, which is the only thing complex work actually needs, and it keeps us honest about writing things down, because async communication is writing.

Real-time still has its place: a hard disagreement, a fast-moving problem, or just getting to know each other. We reach for a call when the back-and-forth is genuinely faster live, and then we post the outcome so the people who weren't there aren't left out.

No process for its own sake

Every rule here exists because a specific problem earned it. We're suspicious of process that shows up "just in case," because it quietly taxes everyone forever to prevent something that might never happen.

We add process reluctantly, and we delete it happily. If a ritual has stopped paying for itself, say so and we'll kill it. The handbook is the bug tracker for our own operating system: when a page is wrong, fix the page.