Most controversial rules in Arkency

In random order:

1. Don’t comment the code.
2. Don’t use branches. Commit to master, push often, don’t break stuff.
3. Let developers manage the project.
4. No refactoring sprints. Always refactor.
5. Don’t send private messages. Use channels.
6. Don’t @mention people unless it’s really worth it.
7. Estimations are often a waste of time, energy and trust.
8. Meetings are often a waste of time, energy and momentum. Especially true if they’re large, compulsory, regularly scheduled or not focused.
9. Got an idea? Ship it and prove it instead of asking for a blessing. Expect someone’s revert of indignation in worst case. Better to ask for forgiveness than permission.
10. Proactively and continually communicate your progress instead of asking questions only when stuck. Tell, don’t ask.
11. Avoid communication proxies.
12. Share communication with the whole team.
13. Share accesses with the whole team. Everyone should be able to do anything without asking others.
14. Best story size is 1.
15. There should be one backlog.
16. Don’t attach certain people to certain types of tasks. Always pick the first task from the top of a prioritized backlog. Always have 1 ticket assigned.
17. Don’t expect anyone to read or respond to your message immediately.
18. Avoid blocking (other people to wait on you - or - yourself to wait on others).

These guidelines happen to also be the:

• key reasons why people love to work in Arkency 💚
• key reasons why people love to work with Arkency 💚
• key ingredients that facilitate remote & async work

Wait, but…

Of course most of these rules have their own:

• rationale
• assumptions - we’re a small, cohesive team of experienced & responsible engineers
• exceptions - our internal weekly call is large and regular and unfocused - but it’s voluntary and everyone loves it
• alternatives - namely what do we do instead, for example: record & summarize meetings to let others skip them and remain on the same page
• costs - which we still choose to pay

Should we elaborate?

Do you find any of these rules particularly exciting, outraging or confusing? Let us know via email or twitter (you can reply to this tweet). We appreciate your input.

We’d like to keep elaborating on these points in coming blogposts. If you wanna stay in the loop subscribe to our newsletter. We believe these guidelines are very valuable and we’d like our prospective clients and teammates to be aware of the way we like to work.

We already covered most of these topics in The Book or in our 26 other blogposts about async/remote.