Hiring is perhaps one of the most difficult endeavours for a company. It’s impossible to cater for every conceivable candidate and not every company culture and set of values will fit a candidate’s preferences. After two years of hiring engineers we now have a firm understanding of what works and what doesn’t at Vital. When you finish reading this document, you will know how we work, what we value and how you can be successful at Vital.

We value people who care about product and delivering the best possible experience to our customers. We start from that point and walk backwards. This doesn’t mean we will hack our way towards a solution, or that we don’t care about proper engineering - quite the opposite. It means that tech is a means to an end, not the end itself. In contrast with many other companies - small and big - we don’t have product managers. Engineers are the driving force behind initiatives. While a product mindset is an optional trait elsewhere, at Vital is a requirement. Besides implementing features, an engineer needs to understand its value and how it ties to the business. They are expected to challenge assumptions, flows, priorities and what it means for an initiative to be successful.

We work in four weeks cycles, with one week of cooldown in-between. We start by discussing what we would like to work on. This can be a mix of existing customer requests, new prospects and on-going engineering work. With our existing team, we typically work in two to three initiatives per cycle. We don’t work with estimations, rather we time-box work for those 4 weeks. Engineers are responsible for managing the necessary effort for a feature to come to fruition within that time-frame. This can mean cutting scope, or adjusting the amount of people working on that initiative. An engineer is therefore present from an initiative's inception, until it’s in the hands of our customers. They are also responsible for managing communication within the team and with customers. It’s common for customers to ask how we are progressing with a feature they depend upon. Engineers need to be comfortable with having direct contact with customers. We value personal time and a good work-life balance. But it’s important to mention that we are a small startup and there’s an inherent intensity to this environment. It can be chaotic with conflicting priorities, but also rewarding since individuals have full ownership over their work.

We value async work and long periods of deep work. The best work comes when people have enough headspace to think about it, instead of being constantly pulled and interrupted. We have roughly two to three hours worth of meetings per week. We treat people like adults, so they are free to manage their schedule as they see fit. We have people working early in the morning, while others late in the evening. We value written over oral communication. We want people to be aware of what’s happening within the company, without forcing them to attend a meeting. We prefer push communication, over pull. We push communication to everyone, instead of people having to pull information from individuals.

We value kindness and empathy towards one another. We often pair program to help and learn from each other. We are in the same ship and it’s pointless if one’s successful while another team mate is struggling. Lone wolves, or egocentrism, doesn’t work at Vital. Everyone helps when needed.

A successful Engineer at Vital is therefore someone that:

  1. Is driven. Wants to work in a place where things move fast. Wants to ship code into production on a daily basis. Wants to own entire features.
  2. Knows what a good product is (e.g. linear.app). Seeks to create equally great customer-centric products.
  3. Values work-life balance but isn’t afraid to work outside normal hours.
  4. Wants to deliver outstanding results and is accountable for delivering on their commitments.
  5. Is curious and wants to work on every part of the engineering stack.
  6. Is kind and patient with their teammates.

Thank you for taking the time to read this document.