1. Over-communicate - distributed teams are amazing, as long as you can keep the communication going. Whether it's clarifying how something should work or letting people know where you've gotten to always lean towards over-communicating and over-clarifying. We love async comms, e.g. Slack but if you’ve gone back and forth a few times and there’s still not alignment, have a call.
2. Assume good intentions - we've worked hard to create an organisation of kind people who care about crafting great software. If something seems off, you can be pretty sure there's no malice or ill-intent involved. A combination of remote and text based comms can make this easy to forget. Jump on a call, have a chat, remember that we're all human beings who like each other.
3. Think like an owner - engineers at Sona are not people that implement features, they're the driving force behind the product. If ever you're working on something and think "I'm not sure why we're building this" or "it would be way quicker to do it this other way", stop and talk to the team about it.
4. Speak Up - Video calls should be interactive not lectures! It makes a huge difference if everyone consciously tries to actively participate and works to involve anyone who’s less confident contributing.
5. Disagree and Commit - we actively look to hire people with different experiences and perspectives on what we’re building. If you have a different perspective on how something should be approached, voice it, discuss it with your team, reach a conclusion. Once the team reaches a conclusion, commit to this conclusion, even if it wasn’t your preferred outcome.
6. Take small steps quickly - releasing small pieces quickly allows us to course correct and validate assumptions, be ruthless in looking for ways to break things down into smaller pieces and constantly challenge "it must do all of these things before it adds value".
7. Insist on high standards - (and be kind to your future self!) before putting in a PR, think "would I feel good working on this piece of code if somebody else had written it", if the answer is no, it could probably do with another look. This also goes for test coverage, writing documentation etc.
8. Incur tech debt consciously - knowing when to incur technical debt and when to pay it back is an essential part of building good software. If you're incurring it, make sure this is explicitly understood and accepted by your team.
9. If in doubt, teach - time getting somebody else up to speed on part of the codebase is always time well spent. If at the end of the day, you haven't written a single line of code but somebody else in the business understands a new part of the codebase, that should be considered a highly productive day. The same goes for writing and sharing documentation.
10. Ask for help - everyone has different areas of expertise, different parts of the codebase they know, don't be afraid to ask for a pairing session or some pointers on where to look.
11. Have a stab first - the flip side of ask for help is to put a little bit of effort in up front. Everyone should be happy to give time to help, but a few minutes of googling, reading the docs and reading through the codebase can make these sessions far more productive.
12. Embrace Ownership - we expect everyone to take a high degree of ownership for what they build. We build it, we ship it, we're responsible for it if it goes wrong. Don't ship something you're not going to be around to fix. Even though we have QA and On-call processes, when you ship something you're stamping it with your seal of approval and saying "I'm confident this does what it's supposed to do". We'll never penalise honest mistakes, but we'll also never tolerate laziness or sloppiness. Saying “Sure it’s broken but that’s not my job” is generally a red flag.
13. Bias for action - unless you absolutely need input in order to proceed, it's generally better to say "I'm doing X, let me know if any issues" rather than "I would like to do X, I'm going to wait for someone to say that's OK before I do it". Find reasons not to wait until tomorrow to do something rather than reasons to wait.
14. Don't panic - The Hitchhikers Guide to the Galaxy had it right. Whether it's your first time working on a new part of the codebase or you think you've just broken something, stop, take a breath, then work out who the best person to talk the problem through with is!