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.
- Be proactive: bias toward action to keep the team productive and shipping.
- Deploy often.
- Simple, well written and readable code.
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:
- Linear is the single source of truth. 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.
🎢 Workflow
We use Kanban (çś‹ćťż) (signboard or billboard in Japanese) to work. Think of it as pipeline process flowing from left to right, from concept to execution.
This workflow focuses on keeping things simple and nimble so when in doubt, take action and choose the simplest option.
We use Linear for our development workflow:
- Each product team has their own team space in Linear.
- No invisible work
- If you are working on anything, share it with your cross-functional team, especially your Product Manager and Team Lead. If the team doesn’t know what you are doing, you aren’t being a team player.
- Team spaces in Linear are the single source of truth on all engineering work we do at Remote. If it isn’t on a team space, it should not be happening (incidents are an exception). If someone is working on it (for more than an hour), it needs an issue that's visible on the team space, assigned to the person.