Engineering Team at Stytch

We have a bias for action.

Authentication is often a frustrating experience for both developers and users. When it comes to the traditional approach, passwords, 65% of users reuse the same one across different accounts. This poses a significant security risk and can create larger breach liabilities. At the same time, people often forget passwords and have to reset them. It can be such a headache that it prevents users from completing an online transaction, costing businesses money and users. While working together at Plaid, co-founders Julianna and Reed realized there had to be a better way to solve this problem. Thus, Stytch was born, with the mission of transforming the space by building a developer platform for passwordless authentication.

We’re growing quickly and believe in learning by iterating and taking bold, but calculated risks. In order to prioritize decisions we ask ourselves, “How impactful is it, and is it reversible?” If it’s something that’s highly reversible, we’ll go for it. If it’s highly impactful and not reversible, we’ll seek out key stakeholders to weigh in.

Last but not least, we do a tiling exercise at the beginning of each quarter to figure out how we can break down our big projects into smaller chunks. Since we send out a change log to our customers every week, this helps keep us accountable and ensures we’re moving as quickly and efficiently as possible.

We’re scaling teams across the board.

Companies of all sizes (including a few Fortune 500s) are drawn to the simple developer experience and the flexibility offered by our API-first approach. Over the past year, we’ve introduced numerous features that make it easier to onboard and authenticate users, including SMS, email, and WhatsApp one-time passcodes as well as embeddable magic links, and OAuth logins – but that’s just the beginning. There’s clear product market fit and we raised a $90M Series B in November 2021. In 2022, we grew from ~20 to ~70 people and even moved offices to a beautiful new space to accommodate our rapid growth. We’re continuing to hire for key roles in engineering, product, and ops, so definitely check out our open roles!

We rely heavily on data-driven decision making.

We’re building a wide range of passwordless, frictionless solutions on one platform, with a focus on both security and conversion. By using both data and qualitative user research, we can create the best products for our customers. We’ve invested in telemetry of services from the beginning and have several dashboards in the office that show traction toward goals. Analytics also help inform our site map and information architecture. For instance, we used analytics and research to revamp our onboarding experience.

Building a culture that values psychological safety has been important to us since day one.

Even as a small startup with 15 people, we prioritized hiring key People roles to help build solid foundations for an inclusive environment. While technical skills are critical, empathy is a key company value and we evaluate candidates on both during the hiring process. As we grow, it’s important to us that everyone feels safe to do their best work. A large part of this means being able to give and receive constructive feedback. We know giving feedback is a difficult muscle to build, so we’ve implemented forcing functions or feedback structures to help our team give feedback more regularly, such as anonymous engagement surveys and anonymous feedback forms that we send out before every all-hands meeting.

We’re currently in the process of developing a feedback training with our managers and also plan to run psychological safety focus groups where teams sit down with managers and someone from HR to go over what’s working well and what can be improved to help everyone feel supported. Last but not least, we have 360-degree reviews twice a year as well as more informal check-ins every other quarter so we can keep a pulse on how we’re doing.

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!

“Fail fast” is one of our core values.

In order to innovate quickly, we have to be willing to take risks and learn from any missteps. We always ask ourselves, “Are we thinking big enough?” and strive to figure out the best way to work fast and effectively. One way we do this is with our hackathons, which we typically have three times a year. We dedicate a week to coming up with creative, out-of-the-box ideas and the sky’s the limit. For example, during a previous hackathon, the winning team integrated Algolia to improve the search experience in our docs. This change is live today!

While mistakes are inevitable, we don’t dwell on them and always move forward quickly. The platform team migrating from Terraform to Crossplane (to simplify building automation on top of our infrastructure) is a great example. Since Crossplane is a relatively new project, it doesn’t have full feature parity with Terraform, but it offers a better experience in general. We were hoping that most of our resources would easily convert into the Crossplane equivalent. We had success moving some resources over, but for ECR (our Docker image store), Crossplane’s AWS provider didn’t have a feature we needed at the time, but Terraform did. We thought we were stuck, but Crossplane released a new provider that wraps Terraform, and it had the functionality we needed. The caveat was that the provider was still in preview, but it looked like it could be a potential solution. We were able to get it working, but we realized that it wasn’t production ready for a couple of reasons (mainly it made the EKS cluster very slow). We decided to remove that Terraform provider and migrate that code later once the Terraform provider improves or the AWS provider reaches parity.

We’re intentional about building a diverse team.

We are committed to building a diverse, inclusive, and equitable workspace where everyone (regardless of age, education, ethnicity, gender, sexual orientation, or any personal characteristics) feels like they belong. To do so, we have internal DEI goals and actively work toward increasing our pipelines so we can hire more folks from underrepresented groups. For example, we partner with female-centric engineering recruiting platforms (like Elpha and Grace Hopper). While we’re proud to have several female managers (3 out of 4 on the engineering, product, and design team), we recognize there’s more to diversity than gender. We welcome people from all backgrounds, whether they have CS degrees or are self-taught. Last but not least, we’re a great place to work for families and offer 16 weeks paid parental leave for birthing parents, and 12 weeks for non-birthing parents.

We want you to progress in your career here.

While there are a lot of benefits that come from hiring managers externally (who can share best practices and processes), we also care deeply about helping our talent grow both personally and professionally. Mary is a great example. She was one of our first three engineers and now manages our Product Eng team (frontend, fullstack, mobile eng) and has done an incredible job building out a highly empathetic and ambitious team. On the design side of the house, we promoted our first designer, Bing, to lead all things Product and Brand design. That said, there are multiple ways to grow your career and if folks want to level-up as ICs, we support that too! (We’re in the process of rolling out engineering levels to help with outlining and codifying growth paths.) Currently, formal 360 reviews happen every six months. During this time we go through a calibration process with managers, leadership, and the HR team where we discuss every person’s performance review (to help mitigate any bias) as well as their compensation with respect to their performance, market rate, and internal equity.