Our principles
- Keep it simple: maximize productivity and reduce waste.
- Small, iterative changes: we move more quickly and reduce risk.
- Quality over quantity: ship 1 issue well rather than ship 2 poorly. We don't ship “broken bicycles”.
- Be proactive: bias toward action to keep the team productive and shipping.
- Deploy often.
- Simple, well written and readable code.
- Outcomes over output: we measure impact, not features shipped - we double down on what works and stop what doesn't.
- Everyone builds: roles are areas of strength, not ownership boundaries. PM, Design, and Engineering all ship - in different ways.
- A PM might ship a working prototype or a Claude-assisted plan, not just a written spec.
- A designer might ship production-ready components and flows, not just mockups.
- An engineer might shape product and design decisions, not just implement a ticket.
- AI tooling lowers the cost of crossing these lines, so we expect people to build the thing - not just describe it - and to lean on each other's strengths instead of waiting for a handoff.
Async first
Working asynchronously also means you don’t need to wait for other people to assign you work. There will always be a backlog of work and if there isn’t you should use your better judgment and pick up whatever you think has the most impact/benefit. If there isn’t any work planned you should bring it up with your Product Manager, there should always be a plan.
As all work should be written down in issues, if you’re doing something out of your own volition and no one shared a spec (tech or product) with you, then create an issue for it before you get going.
Working async first also means:
- Discussions on Slack can be helpful, but async discussions in Linear are better. At minimum, make sure takeaway from discussions always get reflected in Linear.
- Issue descriptions should always be up to date. It's not efficient to need to read through a comment thread or Slack conversation to be fully up to date on what we need to accomplish in an issue.
Documentation and Discussions
There are two types of documentation: Permanent and Transient.
Permanent Docs
Documentation that exists for the purpose of informing users or operators of our platform/company of how things are done.