8VC Emerging Builders Spotlight: Ross Carter (Epirus)

In supporting the industry defining companies of the 8VC portfolio, we are fortunate to work with the brightest, most dedicated people in the world. We’re excited to feature some of the most promising engineering and product talent we have the pleasure of collaborating with, not only at 8VC, but within our broader network.

Today we are highlighting Ross Carter from Epirus. Ross Carter is a Senior Software Engineer and the Product Software Scrum Master at Epirus, with a specialization in embedded software development. He graduated from the California Institute of Technology in 2020 with a bachelor’s degree in Physics & Computer Science and joined Epirus immediately afterward. Outside of work, he enjoys making pottery, going to (mostly country/blues) concerts, and anything outdoors/active.

To those who might not know it, how would you describe what Epirus is building and what initially got you excited about it?

Part of what got me excited about Epirus was that it felt almost like science fiction.  My first pitch to people who aren’t familiar with what we do is to use some movie references. Matrix and Oceans 11 are the two that I like to toss out and work from there because they both have scenes that use directed energy.  From an engineer’s perspective Epirus is cool and new technology that no one else thought was possible. 

We’re building a defensive system, which is really important to me and the rest of the company. It’s a defense-first system that deters and neutralizes threats. Fundamentally, we are building intelligent power systems that are initially tightly coupled in a use-case for radiated directed energy. Right now we’re building a system that will help our country in conflict, but in the future the foundational technology can be applied to a lot of other domains. 

My background was that I majored in physics and minored in computer science, and I wasn’t always going to be on the software track. It’s nice working somewhere where the core principles I learned in school do end up applying. In the past I worked at places like Amazon Robotics where I proved out new robots that they wanted to demonstrate – more on the proof-of-concept side than a productionized model, but it was very interesting work. This is where I started to figure out that doing software that is related to some sort of hardware was exciting to me – not building software in the cloud or consumer technology. Embedded systems were fundamentally cooler. 

Epirus was the fusion of cool technology, hard problems, and working at a startup. When I joined the Leonidas product was still relatively nascent and the company was around 30 people. We were just scrappily figuring things out at a fast pace.

And how would you describe your day-to-day and the kind of work that you do right now at Epirus? 

Let me start by outlining the product and the stack that we currently operate with. There are currently two main product families that I touch. One is an airborne single board computer with hardware for power amplification, and the other is a distributed system for heterogenous compute. 

I’ve worked on mostly backend systems. Any software that is running on the board or the control plane is something that the team that I work on has built, including direct hardware control, statusing, connectivity, and bidirectional data synchronization. We have to deal with large distributed systems challenges – data can be incoherent or arrive at inconsistent intervals so we have to patch things together, as well as embedded challenges like constrained resources and limited network bandwidth. This is fun but hard embedded & distributed systems work. 

Having said that, my role has changed a bit over time. I joined when there were only three people on this team and I used to be more full-stack and got to touch our internal front-ends and other high-level product features. There were also targeting & ML features that I got to build out like maintaining logic on threat locations and models for increasing effectiveness in targeting. We got to go out into the field to support those features, test the system in a production setting, and do offline data analysis to make sure we incorporated that feedback. 

Across the two major products, one of the new things that we are considering is how to deploy over-the-air software updates. This gets into how we operationalize software and do DevOps in these complex settings – it’s a heterogenous mix of images that we need to deploy consistently across all of our nodes. 

How do you think about building culture at the early stages of an engineering team? What were some of the key learnings?

There are two important things about our current culture and how we got here:

1. There is transparency in the flow of ideas and communication across teams. We make sure that everyone who needs to know what is going on can do so effectively, and that all stakeholders can be productive and have access to context. 
2. Consistently conducting field tests and integration tests. Everyone is out in the field together and people want to get things done when we’re together – these are important shared experiences. That helps a lot with communication because you have a sense of camaraderie and real feedback in the field. Everyone can also directly see how their contributions map onto our shared mission.

In the past year I’ve transitioned into more of a leadership role, but that also has some challenges to it. I’m trying to find the balance between empathy and understanding but also holding people accountable and giving them ownership. In high performing teams, everyone has faith that when someone says “I will do X,” they will get it done with good communication, strong respect for others, and incorporate new & innovative ideas. 

You also need to have conversations to make sure people are working on what they want to work on and have the resources and support that they need. Our team has done a good job of growing in this direction especially as we’ve added more members. I’ve also been trying to focus on the idea of giving folks individual recognition. The team's accomplishment doesn’t always reflect a given individual’s accomplishment, especially as the team grows. While you’re still focused on your team’s output, you want to highlight the individual’s contribution towards your goals and make sure that external teams acknowledge hard work and domain expertise. 

And as a part of culture, how do you think about hiring? 

I’ve been heavily involved in the hiring process of everyone who has joined our team after me. One thing is that it is often challenging to pitch what we do to people who are not defense-minded. The challenge is in framing the problem space and giving people a reference point based on what they know.

Our system is very similar to a lot of other distributed hardware systems. Being able to talk in common ground is important for recruiting. We need to figure out what a potential hire is interested in and how they can get exposure to it within the company. We’re blessed in that we have ML, control systems, control theory, and distributed programming problems! You need to focus on the commonality within hard problems that people can solve together. 

What are some unexpected learnings from your time at Epirus? 

A lot came from the culture side of things – just watching the organization grow and figuring out what that meant for the team & how structure needed to change. 

The personnel part of a startup is not the part where most of the challenges are. When you’re in a 20 person startup you’re worried about the technology and delivering within timelines. As the organization grows you have to understand people and motivations and the value of interpersonal relationships. 

In parallel, I was also surprised with how Epirus fits into the larger ecosystem of weaponry and command & control systems that are in existence today. We need to consider how we fit into current deployments that the military uses and the systems that they work with, which has been eye opening. We’re also moving faster than the government is used to moving. Every 9 months we put out a new system. 

The last bucket of learnings come with the challenges in getting the 90% solution to the 100% solution. Building resilient and robust production solutions is difficult.  

What are some things on the product roadmap and 10 year visions that you’d like to opine on? 

We’ve done a bit of press about this already, but in the immediate future we’re taking a layered defense approach. We have different hardware that can activate at a variety of ranges. We also have many systems that need to talk to each other – for example the ground system needs to communicate with the airborne one and relay that information to the rest of the network in a connected deployment. There are a lot of synergistic effects here. 

We’re also thinking of different deployment modalities, or working in crowded environments, or steering directed energy. How do you work around obstacles and do path planning? This is where we can bring in top robotics talent. 

There are lots of adjacencies we can build into that can bring top talent from other fields on board. 

Any hot takes on defense and defense infrastructure?

A lot of defense systems are written in legacy codebases (e.g. Fortran). There is a bifurcation point on maintenance or bringing things into modern technologies, and there is massive bloat in defense. This is really worrying – if critical systems are written in languages without domain experts today or have tools that are no longer supported, what do we do? We need to modernize defense and bring faster iteration cycles to the industry without losing quality.