Facet Engineering is a fully distributed, remote-first team. Being remote offers tremendous flexibility and a literal world of talent, but there are inherent challenges. How do you coordinate plans without crushing productivity with too many meetings? How do you empower for speed, but ensure quality and architecture consistency? How do you stretch a small team across independent initiatives but never leave anyone struggling in isolation? While I don’t believe there is just one right way to solve these problems, below are 3 practices that are working for us.
1. Make architecture part of the regular schedule
Anytime you divide a system into separate development efforts, you must coordinate plans, making design tradeoffs with intention, or you tend to end up with an accidental architecture and a mess of tech debt. In this case, the term architecture is used somewhat loosely to describe a broad range of decisions around implementation details, but it gets the point across. Initially we held separate architecture discussions, but as this overloaded the schedule, we tended to save conversation for only the bigger decisions. So now we include these discussions as part of the regular schedule. Instead of feature leads grooming their epics in isolation, we groom as a team. It takes longer initially, but then everyone is aware of the implementation plan, even if they won’t be doing the work. One side benefit is more thoughtful code reviews as engineers are more aware of the whole system and better able to make meaningful comments. We are on a two week sprint, with retros on the last Friday. We reserve time on non-retro Fridays for technical discussions. These are open discussions where anyone can raise a topic. These can be used to get help on a tricky problem, talk about tools that may be useful, etc. If there are no topics, we can cancel, but that has not been common.
2. Synchronous daily stand-ups!
Nearly every article written on managing remote engineering teams recommends skipping the daily standup in favor of asynchronous daily chat messages. We did the same, for months, using Slack to send daily one-liners on status to the rest of the team. But nuance gets lost in these quick messages, and this small, 15-minute commitment to be on video with the team each day has already saved us countless hours of extra work. Nearly every day some offhand comment leads to a couple of engineers syncing offline to talk about a faster or easier way of getting something done. Stand-ups must be kept short and on point, rigorously holding side conversations for later, but the payoff is real. The proof is really in the actions. We recently implemented No Meeting Wednesdays to give engineers more dedicated heads down time, and the team unanimously voted to keep their standup on Wednesdays, despite no requirement to do so. It does take sacrifice with time zones from Portland to Lithuania, but that few minutes is time well spent.
3. Assign work in pairs
We are a small team, so in the spirit of divide and conquer, it is easy to end up with a single engineer working in isolation on a new feature or integration. While we have a team full of smart, self-starters, this is still not great practice, for the engineer or the company. Every engineer is better with a sounding board, and for continuity more than one person should know every part of the code. To prevent this level of isolation, we attempt to assign all work to at least a pair. And where that is not possible, we specifically assign one other person to help with code reviews and bugs so that there is more shared knowledge and just someone else to talk to!
The challenges we have faced are by no means exclusive to remote teams. Remote just made it more difficult to recognize the problem, and the tendency was then to overcorrect with too much collaborative time. It is a bit of a Goldilocks situation to find the right balance, and we are far from done, but increasing commits per day, better quality code reviews, and confident opinions expressed on more than just one part of the code are all positive indicators.