We believe that the highest performing teams combine hard work with downtime.
Engineers typically work 8 hours a day on a flexible schedule. As a company, we accommodate each person’s lifestyle and trust that they’ll choose which hours are their most productive ones. As a team, we push hard to meet deadlines, but we also take time to relax when things are slower. We start every morning with a quick (15-min max) 10 a.m. company-wide stand-up, and when we’re not working, we enjoy late night gaming, watching college football, playing in-office shuffleboard, and the occasional adult beverage.
We come to work, work hard, and then we go home. For example, Jake leaves at 5:30 p.m. twice a week to do Yoga, Ben attends Mandarin language classes, and family-man Gabe has a 2-year-old who he is already encouraging to learn how to code ;) Gabe and Greg both love snowboarding and are organizing a team trip to Tahoe. Exercise and nature is good.
For the engineering team, we don’t care how many hours you work, we only care that you deliver and have enough overlap with your teammates at the office. Working from home is fine from time to time, but as a small startup, it can be hard to work remote.
We want smart people who don't need to be micromanaged.
Each of us have different roles at Aero, but we are all chasing the same goal. We’re still a small team and are looking for people who not only want to own their own work, but are proactive and self-disciplined. When we do sprints, we want people to self-police. Our VP of Engineering, Gabe, likes to have ground rules but provide a lot of flexibility within that loose structure. Even if you’re going to be the only person working on a given part of the codebase, everyone should be able to find bugs wherever and fix them, regardless.
When asked about his management style, Gabe said, “Even though I’m a manager, I don’t like managing people. In the past, people have said that the best part about working with me is that I gave them so much freedom. In this way, I act more like an advisor than a manager, and I because I can hire people who are smarter than me, this is always the best way forward.”
We ship our product multiple times a day.
We are breaking down problems into smaller ones which are easier to solve and test. Not only are these more manageable, but it reduces risk and makes it easier to roll back changes. As a result, we spend less time worrying about deploying and have more confidence each time we push code to production. Typically, features only stay in staging for a couple of hours before going to production. Engineers are responsible for taking their own code to production, so if it breaks, you’re also responsible for fixing it.
High Quality Code Base
We believe in speed through writing maintainable and scalable code.
We don’t care just about “if it works.” It’s easy to make something work by hacking it together, but to write code that another person stepping in a year later can read and improve upon is much harder. We enforce best practices and avoid shortcuts, and our goal is to constantly think about scalability and maintainability.
When enforcing code styling we use Prettier TypeScript to keep the codebase more organized. By using more strict rules with TypeScript, it helps us maintain more consistency. We also use CI/CD to encourage small PRs and easier reviews, and we’re constantly deploying and testing our own code. We always schedule time to pay off tech debt. There’s a small amount of tech debt that you can have before it slows down your entire team/product/process, so we are always fighting against it.
Bonded by Love for Product
If you like traveling and flying, this will be a good fit.
Today, when people travel, they think about which airport they’re leaving from and which airport they’re going to. We want to change this. Travel should be about the starting point and the final destination, and travelers should not be constrained to large commercial hub airports.
We’re trying to find the most time-saving way for people to get where they want to go. For example, if you want to go from San Francisco to Tahoe for a ski trip, you can drive ~6 hours. Or you can drive an hour to SFO or OAK and fly to Reno, and then rent a car and drive an hour. However, you could also take a private plane and land right in Truckee. There’ll be no TSA, you can arrive 15 minutes before the flight takes off, and get to where you want to go in the most efficient way possible.
At Aero, we’re providing premium travel to users who are not price-focused. The concierge aspect of our product is to cater to every preference our users have, whether that’s your favorite in-flight beverage or a baby seat for your 3-month old. We want it to be a personal interaction. You shouldn’t feel like you’re interfacing with an airline, but rather a real human, someone who knows your circumstances and can offer you your favorite options. Ultimately, travel isn’t just when you’re in the air. For example, given that our CEO Garrett Camp co-founded Uber, we want our travelers to have a car service waiting for them when they touch down, ready to drive them to their final destination.
We believe it should be the golden age of aviation and want to make traveling and flying feel as premium and effortless as possible. If you love to travel, you understand the pain points of getting from A to B. We are looking for people who understand our customers’ needs and are passionate about Aero’s mission to meet them.
We rely on everyone contributing their ideas.
Ideas can come from anywhere at Aero, regardless of your title or department. As a company, we sit together and do standups together. As engineers, we probably learn more from our Community Manager and Operations team than they do us. For example, our VP of Engineering Gabe often sits with Greg, who is in Ops, so that he can understand what the actual daily routine is. By understanding what it required in the day-to-day for booking flights, we can then use technology to alleviate those pain points.
Ben also sits with Jamie to learn about Facebook and Google ad campaigns. We put an emphasis on sitting down with the person you want to work with, outlining an objective together, and tackling it as a team. We aren’t dogmatic at all about pairing, but there are certainly times when pairing is appropriate and a helpful practice when it’s needed. It helps us understand how we work.
As another example of how we collaborate, we recently did an exercise where everyone gathered in one room to brainstorm for an entire day. We discussed what the ideal customer experience should be and then voted on one another’s ideas. This helped us determine our product roadmap.
Trust and transparency are important when trying to move fast — everyone has access to all information.
We use software called Input which is like a forum or Slack. We use Input to share updates for the entire team to see. For example, when we asked our users to give us feedback about their latest flight experience, we shared both positive and negative feedback in Input. All other updates are communicated through this same forum: how many tickets have we sold? Are flights being canceled?
We have a dashboard that actually sit right above Jake’s seat which keeps display real time metrics about number of tickets sold and revenue. We also have a shared Google Drive and use Slack as a strictly professional form of communication. (We know how distracting Slack can get!) While information flows openly, we keep rather quiet so that people can work uninterrupted and with focus. If you ever want to sit down with another team member, you can. There is no formal process or boundaries based on title.
We want to build and fail fast.
The way we operate is scrappy. High-quality code is important because as a burgeoning startup, we don’t get everything perfect the first time. We won’t always get all of the pieces of the puzzle. At a bigger company, you might have to wait until you have finalized designs or consensus from the team. Instead at Aero, you decide what you can do with the time you have to move the company forward.
Move north, if you’re supposed to go northeast, you can course direct. Some people have a lot of trouble doing this because they want to be assigned a ticket before executing. We want people who feel comfortable doing work and experimenting. If you have downtime, think of something cool you can do and build it. We’ll test it and see how it’s received. Don’t stop and wait for permission or for someone to define something for you.