Engineering-driven tech companies

Engineers have the right resources and tooling to ship code every day.

Founded by engineers, Qualia’s priority has always been to develop truly great products. We’ve fostered a culture of high autonomy and alignment, enabling our engineering team to lead innovation and build products from the ground up.

To ensure our engineers have what they need to move fast and ship high-quality code, we also have powerful internal libraries and tooling to help our team explore options and solve problems quickly. For example, one of the many tools used by our team, Reval, (which lets you see front-end changes in real time as you make changes to code), was built by one of our co-founders, Lucas Hansen.

While the team has evolved over time, maintaining our core values has remained our top priority even as Qualia has continued raising funds (our Series D in late 2020), growing well beyond a $1B valuation. Our engineering team still sits center-stage, and we provide the tools and support needed in order for them to drive product development and guide the roadmap.

We are all responsible for working with a hammer-in-hand.

As engineers at WorkOS, we lead product development, so it is our responsibility to talk to users and think critically about the product while building it. We are also involved in all other aspects of product development, from design, to marketing and telling the story of each feature.

We ship high-quality, polished, product features often. When something looks off, we fix it. We do the small things that make the product, the website, the response to our user, the email, the tweet, or our company better. The work can be toilsome at times, but there is deep satisfaction in the final result.

At the end of the day, we are all doers and practitioners. There is no room for someone to just stand around and supervise. Pointing out problems without doing anything to fix them is the anti-principle. We are always willing to pick up a hammer, or broom, or email, or pull request.

We’re on a mission to remove all of the friction from employee leave.

When our co-founders first started learning about different types of leave and what a huge problem it was, they were baffled – how could something that seems so incredibly common be so painful? After hearing countless stories, however, such as one friend being wheeled into a C-section while simultaneously trying to fill out disability paperwork on her laptop, they knew something had to be done. Whether it’s taking parental leave, caring for a sick family member, or dealing with a personal medical issue, Cocoon was founded to make what has traditionally been a cumbersome, bureaucratic process easy and stress-free for both employers and employees.

We’re not building software for software’s sake. Rather, we’re leveraging technology to have a direct, positive impact on people’s lives. The empathy we share for our users, and our passion for what we’re building, inherently puts the product at the center of everything we do. Engineers play a large role in defining our product roadmap and obsess over the details – whether that’s writing code, supporting marketing of new features, or working with customer support to better understand users’ pain points. It’s safe to say we’re a team of doers who are excited to roll up our sleeves, dive into the nuts-and-bolts of how things work, and thrive on having a high level of craftsmanship.

Engineers are a majority of the company.

Delta knows how to fly people around the world, Priceline knows how to market travel, but we know software. More than half of our employees are engineers, so you’ll influence the roadmap as soon as you walk in the door. Devs are empowered to ship code often, choose the tools they need, and own everything from ideation to extending a feature once it’s live. The only way to reduce the friction in air travel that has been normalized is to write modern, sophisticated software. We’re relentless about innovation and responsiveness so we can make air travel better for everyone. Given our expertise in software and domain knowledge of air travel, our global travel partners see us as a trusted partner.

We place a large amount of trust in our engineers.

As an early hire on our Space Communications team, you’ll have a large impact in determining what we build and how we work. Our leadership team does a great job at communicating our vision, but since we’re building an entirely new platform, there’s no rulebook or ‘one right way’ to execute. To that end, we place a large emphasis on hiring smart, motivated people, and trusting them to get the job done. You’ll have the autonomy to hit the ground running and the tools needed to confidently and easily test and release code multiple times a day.

As we grow, engineers will be responsible for mentoring more junior talent and continue to have a large say on our roadmap. It’s an exciting time to join the team, as we’re looking to triple in size by the end of the year!

Engineers have a large influence on the product roadmap.

Since we intend to be here for the long haul, we’re intentional about finding simple solutions. Not only are they easier to understand, but they’re also safer to change as we grow. We think long-term about the software we develop and we’ll never ship if we feel we’re risking the user experience. At the same time, we don’t spend time on features if we don't need them. Engineers are empowered to ship code often and choose the right tools needed to build the best product possible. For instance, in order to cut costs and help scale our infrastructure, we migrated from a 3rd-party vendor to our own in-house GCP infrastructure solution.

Both of our founders bring industry expertise.

Julianna (co-founder and CTO) was previously an engineer at Plaid and Strava, and a product manager at VGS. Reed (co-founder and CEO) was a product manager at Plaid. Together, they bring invaluable insights into our customers’ pain points. What’s more, two thirds of the team is engineering, product, and design.

At Stytch, product requirements are largely led by engineers. In fact, for the first year and a half since we were founded we didn’t have any product managers. Senior engineers defined product requirements in addition to the technical specs. As we build out our product management function, engineers will continue to play an important role in defining products and setting the roadmap. After all, we are building tools for developers!

At its core, our company is engineering-driven.

Both of our founders come from technical backgrounds: Matt has a software/hardware background and Will has a hardware/mechanical engineering background. We approach biotech by asking ourselves, “How can software or hardware make this way better?” We build our reactors from the ground up. We’ve designed the entire system in-house. We write all of the software and build all of the hardware. In doing so, we’re revolutionizing the way biotech is done through an engineering perspective.

Because engineers here have a ton of power, autonomy, and responsibility, we also try to instill a culture of service and helping others. Case in point: Our recurring meeting with the bio team is called, “What Can Software Do For You?”. We view it as a privilege and an obligation to be able to make other team members’ lives easier. The same is true for our customers: one of our main goals is to allow our customers to spend less time in the lab and more time in their living rooms, saving them time, money, and resources.

When you join the team, you can expect to spend roughly 50% of your time on planned work that’s on our roadmap (and that we share with our exec team), 30% for the grab bag of things we want to pursue (putting our own ideas toward company and team goals) or requests from customers, and 20% for tech debt and bug fixes (we care a lot about our own dev flow and improving that over time.)

We’re truly people over process – there’s no scrum masters here (though we’d welcome you if you are one). We believe in building a process that works for engineers and one that helps us be productive, not one that acts as a mechanism for control or replaces the trust between management and engineers.