Principal Engineer Matthew, taking his dog Ollie for after-work walkies in Wānaka
How we think about distributed working at Vital
![Rafael Fonseca](/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fbi0rqogg12lc%2FwQwfUAQAmF1t105sIXkM2%2F430e1fe8f0f50c4066645191987cd54f%2FRafael_Fonseca.jpg&w=3840&q=75)
We get a lot of questions about what distributed working means at Vital and we’ve worked really hard to get things working well for us here, so we wanted to share a little more about what it means to live your best distributed life at Vital.
We’re proud to encourage and support distributed working and the (many) benefits it brings.
Although not fully distributed (at the start), Vital has always been remote-friendly. The move to a fully-remote working environment in March of 2020 proved that our initiatives, implemented in the months and years leading to the pandemic, empowered our team to work more efficiently.
When it became apparent that this way of working would become our new normal, we also noticed that being distributed suited our teams better – fewer office distractions and meetings meant more focus time, and flexible working hours meant folks got to spend more time with family as well, in what certainly were unprecedented times.
So, we made the decision to cancel the lease on our permanent office space in Auckland, and go all in on the remote-first life. And now, months later, we're sharing our lessons from this experiment so that those outside of Vital can get an idea of what we’re doing, what’s worked for us, and what hasn’t.
Note: There are plenty of other resources around that provide a more comprehensive guide to remote-work, including those who have done this for much longer than us & on a much larger scale. We’re still learning & improving every day.
How we ‘do’ distributed working
To us, distributed working doesn’t mean ‘working from home’. It means working from wherever you feel you can get your best work done - whether this be your home, the bach, a shared office space, the public library, etc. As long as you’re in a (mostly) NZ-friendly timezone & your internet is stable, we’re location-agnostic.
Our engineers span a large area across Aotearoa New Zealand. Vital team members are (currently) in Auckland, Wellington, Nelson, Christchurch, and Wānaka. We also have a great team spread across the US, with our Data Science team based on the East Coast.
Everyone who joins us has the ability to choose how they like to work, and we wrap a support package around that. Want to be 100% based at your home office? We’ll provide you with the gear you need to get set up and ready to go (essentials like monitors, peripherals and a top-spec MacBook Pro are included, plus some nice to haves like greenery 🍃).
Do you prefer to work from a shared space? If you’re in the same region as another Vital team member, chances are you might like to hang out in the same shared space as your co-worker from time to time. But even if you aren’t, we’ll cover your shared office costs, plus your gear.
But distributed working is not just about where we are and where we are not. It’s also about the wider systems that govern the way that we actually work. The hardest change was adapting the way we communicate.
![Vital](/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fbi0rqogg12lc%2F3lqlzQ18hhYyxfgg4UzSAf%2Fe08db8dce18cd675a866bed116a9ba8a%2Fblog-distributed-working-1.jpeg&w=3840&q=75)
Asynchronous Communication & our Code of Conduct
When we transitioned to remote-first, we quickly adopted the hallmarks of asynchronous communication. Today, we rely on its tenets along our own Code of Conduct, both at the forefront of everything we do.
This means (amongst other things) that when we send a message internally, we don’t expect an immediate response. In fact, we encourage you to turn on Slack's ‘Do Not Disturb’ feature if you need to power through some deep work.
In practice, this means we document everything very well & do a lot of planning up front.
If a question is asked of anyone, it’s answered - but any relevant documentation is also updated on the appropriate part of our wiki, so that the answer to that question is available again to someone else who might need to know the same information.
We use tools like Loom frequently to support our comms, meaning that a lot more of what we do and how we do it is available transparently for everyone to use and access. It’s been great for our culture, and, coincidentally, really helps with onboarding new team members.
When we ask questions internally, we provide all of the context we have, and all of the tools that they need, to be able to answer the question when it is most convenient to them, without a lot of backwards and forwards.
ASAP requests are reserved for things that truly require it.
This approach better supports distributed teams because it provides looser coupling between its members, and, frankly, is a much nicer way of working too.
I think I’ve found an issue
Bugs or weird behaviour are constants in the software development world, and we’re bound to find them in our code as well. To ensure others can get to a solution as quickly as possible, our engineers give the team as much context as they can in writing and/or screen capture. Our internal documentation even provides examples of great and not-so-great approaches, like the ones below, used to raise attention to a bug discovered by an engineer.
Instead of this:
❌ You start a Zoom call via Slack in the project’s channel and discuss the issue during the call. Later, you capture the decision made on the call, without any of the context around it, in a Jira ticket in the backlog.
We prefer this:
✅ You write up the entire context of the issue in a Google Docs document, and then send a link to it via Slack to the Quality Engineering team and/or your manager.
This approach to working asynchronously is highlighted during our incident response process too. Commonly, teams that work closely together in synchronous ways struggle to assemble themselves around an ongoing incident. By providing the right tools, context, and environment where async is the default form of working, we cleared the way for the teams to focus on what matters: mitigating and resolving the issue.
Because the tools and process we use are the exact same we use on a daily basis, there’s no surprise, confusion or hesitance. More confident team members lead to better outcomes during incidents.
When Asynchronous Turns Synchronous
As with everything in life, moderation is key. There are still a number of ways we leverage synchronous communication tools, too. Everyone in the team has a 1:1 with their direct manager using 15Five and Zoom. We meet once a month for a company all-hands. We have regular social meet ups online via Zoom, most recently writing an epic novel playing Out of Context.
Donut is our friend, and frequently pairs us with others around the world for a social, no agenda chat every couple of weeks.
And, when safe to do so, we travel frequently to be together, whether this be for work purposes, or to get together to celebrate the end of a busy year. We recently had a new starter join from Christchurch, and he travelled to meet with our Wānaka-based Principal Engineer for onboarding. One of our implementation team members has also recently travelled around the US, meeting a number of her teammates for the first time in person.
Sometimes we hang out in person, too. This snap was taken when the whole company (US and NZ team included) joined forces for an offsite in the beautiful Tāwharanui Peninsula of New Zealand
![Vital](/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fbi0rqogg12lc%2FNEqdR2kANTbde3nPpIlvJ%2F68d1aeff58e73c693500502dbf07a3c6%2Fblog-distributed-working-2.jpg&w=3840&q=75)
If you’re looking for an interesting and meaningful technology challenge in an inclusive and flexible work environment, or you’re just curious to find out more about what it’s like to work at Vital, you can find out more on our careers page.