Building Our Engineering Culture at RADAR
Learnings from growing our team the past two years.
It’s been two years since the inception of RADAR. Since then, we’ve raised a Series A, brought two products to market (RELAY in September 2017 and ION in February 2019), and assembled a talented engineering team.
As we look ahead, continuing to grow our team is essential to RADAR’s success. We’re hiring, and investing in a healthy engineering culture allows us to attract and retain the best talent. It’s an ongoing project (and always will be), but we’re committed to putting in the work.
Here’s how we’re doing it.
Remote first
RADAR is headquartered in Denver, Colorado, and in addition to on-site engineers, we also have team members in London, San Francisco, and Argentina accounting for 62% of our engineering team. Our remote-first mentality has allowed us to attract a more diverse and talented team than we could have locally, and it enables individuals to choose their own quality of life.
There are plenty of arguments for semi-remote teams not working: employees end up feeling alienated and left out of key decisions that affect them when off-the-cuff discussions turn into bigger plans; on-site employees resent the relative freedom of their remote counterparts. But these types of stories have not been our experience at RADAR.
Even in our open workspace, we rely on a strong Slack presence to communicate (which is better for productivity); and if it’s not documented in JIRA or Github, it never happened. We make a concerted effort to plan our daily stand-ups and biweekly retros for times when everyone on the team can participate. This way there’s more transparency and access to decision-making. Also, having high-quality A/V setups in our conference rooms has made it easier to whiteboard and screen share together.
Optimize for deliverables, not hours
After we’ve hired and onboarded new team members, the best thing we can do is respect their commitment to getting work done. “Hours worked” is not, in itself, a goal. In fact, it’s not even a metric worth tracking. We promote personal accountability, one of our three core values here at RADAR, instead.
This is where we’ve found a sprint-based approach to project management most useful. Pulling in tickets that you commit to deliver on over the next sprint makes progress and accountability tracking seamless. In sprint review, each team member is given an opportunity to discuss their work accomplished (or not), which encourages team members to hold each other accountable.
An engineering culture focused on deliverables benefits everyone, and our team is able to thrive within this flexible arrangement. With this process one of our engineers just completed a tour throughout South America as a digital nomad. Instead of micromanaging individual hours, we focus on our primary goal: shipping great products.
Run the experiment
Through experiments or side projects, our team has often found creative solutions for new problems, and it’s been really exciting to see how this has played out. One of our engineers wanted to figure out how to add a Lightning node to a single-board computer. On his off-time he wrote up some great documentation and bash script to install and run LND in one command. We liked it so much we’ve used it to create personal nodes for our team.
At a recent Lightning event that we hosted, we needed to solve for getting 100+ participants access to the Lightning Network to try out applications firsthand. Our Director of R&D experimented with how to support many cloud-hosted Lightning nodes with one Bitcoin core instance and give everyone some sats (satoshis) to spend at the event. The setup was successful in reducing hosting costs and onboarding time such that an attendee could scan credentials on their phones at the door and get access to a node.
These were two successful experiments, but they came alongside many more that have failed. Part of encouraging ingenuity is creating a safe place for experimentation. There are no bad outcomes from an experiment that “fails”; if anything, we opt to fail fast and learn.
Contribute back
The Blockchain industry is built on open source software and the industry’s commitment to contributing back pushes us all forward. While working in this nascent developer ecosystem is exciting, it often comes with sparse and incomplete documentation and tooling. Through our development process we identify resources that could be useful for other developers and try to do our part in contributing back to the space.
This year alone we’ve released a front-end framework, example boilerplate app, and knowledge base. On RELAY, we developed a SDK (software development kit) that allows developers to pull RADAR RELAY liquidity into their own dApps or help enable new use cases like 0x contract fillable liquidity. Additionally, with ION we’ve released a popular TypeScript LND client wrapper. We will continue to contribute towards open source software when possible.
Promote individual growth
We actively support team members as they grow professional skills and identity. Anyone is welcome to write an On the RADAR blog post about a relevant topic of interest, and we support engineers who choose to compete in hackathons and contribute to the developer community. For instance, we’ve had participants at the ETHDenver hackathon for the past two years.
In the interest of hiring and supporting a diverse group of engineers, we seek out people with a broad range of backgrounds. You need to know the skills and use them well, but you don’t have to come to us with a computer science degree. (Our director of R&D, for example, came from a non-CS academic background and is a self-taught coder.)
All employees at RADAR have access to a yearly stipend that can be used on conferences, certifications, courses, or any other manner of professional development. It’s been interesting to see how this stipend has been used; for instance, one team member wasn’t an engineer and worked in more of a technical support role, but he was interested in engineering and came from a strong math background. We paid for him to take an immersive JavaScript course and he now works on engineering-related tasks.
In the day-to-day rush, it’s easy to put professional development on the back burner, but folding development plans into performance reviews has already yielded excellent outcomes and serves to reinforce RADAR’s growth-minded culture.
Follow best practices
Though we value moving fast, we also believe that best practices reduce error, keep productivity high, and return the most optimal results.
Here’s how we commit to producing quality code:
- Review on a tight loop. We require at least one review on every pull request before it gets merged into our codebase. We use GitHub as a communication tool as well as source control. Properly maintained documentation in each merge allows us to efficiently perform code reviews.
- Leave it better than you found it. I use an analogy of a scout going ahead of a caravan. The scout (one member of the team that changes depending on passion) works fast to build out an internal MVP or proof-of-concept, then the rest of the team follows behind to finesse quality and add more long-term sustainability to the project. Many of the codebases we collaborate with are fragmented, so with each feature we use, we aim to provide improvements (or maintain a fork) to contribute a better foundation for the next developer.
- Standardize wherever possible. We strive to standardize the language, tooling, and architecture that we use across products and services. This allows engineers to crosscut quickly and transfer from one codebase to another with little friction. Enabling pattern standardization reduces the volume of context switching and lets us focus on shipping efficiently.
Our engineering culture at RADAR will continue to evolve as the company grows. We strive to establish a strong culture and workplace environment where the team can excel while tackling new problems. All the other metrics by which we measure success are a natural byproduct of our commitment to making our company an ideal place to work.
