A month ago on the Sustain Podcast I touched on how my current employer, @elastic, handles its #distributed and #remote approach to software development and my thoughts on what we can learn from this when addressing the challenges of sustainable Open Source development.
As we kick off @SustainOSS tomorrow, I thought I'd start a thread with some afterthoughts (but bear in mind I’m representing myself here, not the company, and these are all based on my personal perspective).
Elastic’s distributed model is such that its Engineering department (and most other departments too) is entirely physically and temporally free.
By that I mean that every one of us is free to work in any location and any timezone in which the company can legally employ.
By that I mean that every one of us is free to work in any location and any timezone in which the company can legally employ.
I feel that this nicely echoes how community driven Open Source projects work, as they are often driven by a group of volunteers, with a shared interest, who work across timezones and rarely meet in person, striving to achieve a shared technical goal.
So my thinking is this:
What if the practices that make it possible for Elastic to do what we do were better understood and adopted? Would this improve the sustainability of OSS, lowering the barrier to entry by teaching these skills in mainstream working environments? Perhaps.
What if the practices that make it possible for Elastic to do what we do were better understood and adopted? Would this improve the sustainability of OSS, lowering the barrier to entry by teaching these skills in mainstream working environments? Perhaps.
Bellow is a quick brain dump of practices and working agreements that Elastic employs internally to facilitate its distributed model, and hopefully this can help kick off this conversation.
1. Recognise that real-time communication, while effective, has trained us to focus on our own needs without considering how the receiver might experience that communication.
It might seem weird to make this #1, but all other practices depend on us having empathy for each other.
It might seem weird to make this #1, but all other practices depend on us having empathy for each other.
2. In Elastic we have recognised that if a team at is not yet distributed across time zones, it soon will be. Many, if not the majority, of Elastic teams already span the globe — and a distributed team, means distributed communication.
To achieve this we bias towards Asynchronous communication in everything we do. This means that in an effort for continuous improvement, we try to ask ourselves whether we could achieved in an Asynchronous manner what we are currently achieving Synchronously. If so, we adjust.
3. Biasing towards Asynchronous means that we expect to consume information after it has been sent, with an understanding that this will happen in a timely manner.
This requires over communication, but it frees us up from having to “sync up”, which is the source of the vast majority of meetings we were used to attending in our previous companies.
4. This means that we treat any Synchronous communication as ephemeral, and hence as optional.
This means that you can never assume a conversation about technical implementations or future direction will be read by your teammate when they wake up, unless its Asynchronously
This means that you can never assume a conversation about technical implementations or future direction will be read by your teammate when they wake up, unless its Asynchronously
5. We consider instant messaging and video conferencing to be ephemeral, as opposed to email or Github (Issues & Projects) or Google Docs, which we consider permanent and Asynchronous.
This means that if you make a decision in a Synchronous manner, you can’t actually consider that decision as having been made until you document it in an Asynchronous manner.
I’ll emphasise through repetition:
A decision made on an ephemeral channel doesn’t count unless documented on a permanent channel.
If you have one take away, make it this one.
A decision made on an ephemeral channel doesn’t count unless documented on a permanent channel.
If you have one take away, make it this one.
6. Your immediate thought might be that making all decisions in long threads in Github issues or email must be hard, prone to misunderstandings and unsustainable and you’d be right.
We are heavy users of video conferencing, and while we treat calls as ephemeral, they can be recorded, which makes them permanent. If you’ve made a decision on a call, summarise it on an Asynchronous channel and link to the recording.
7. The archival benefit is immense, going far beyond enabling distributed teams. It ensures that decisions can be traced back to a conversation and rewatched when you’re trying to understand why they were made, two years after those who made them left the team to join the circus.
(This isn't to suggest we treat past colleagues like jokers -- its a reference to my favourite alternative to the Bus Factor)
I have a lot more thoughts on this topic, but I feel this thread is long enough already, so let me end with a parting message:
It’s interesting how a working environment that prioritises an the need to be home for dinner, and to live your life differently than your colleagues, is as applicable to commercial companies as to passion projects and open source endeavours, and I'd love to explore this further.
On that note, I’ll be attending the Sustain Summit in Brussels tomorrow and look forward to talking about this with the amazing people driving Open Source forward, so if you’re going too and want to chat - come find me.
