Eliminating Passwords with Reed McGinley-Stempel

About Reed-McGinley-Stempel:

Reed is the Co-Founder and CEO of Stytch, a platform for passwordless authentication that makes it simple for apps and websites to retire the password.

Before founding Stytch, Reed joined Plaid as one of their first 100 employees. He remained with them until they grew to a $5B+ valuation.

With a selection of new products about to hit the market, Stytch is prepped to spearhead the transition to a passwordless future.

About Stytch:

Stytch improves security and user experience with passwordless authentication. Stytch is building the developer platform for authentication to enable teams to easily build experiences that delight their users.

 

Episode Transcription:

Brian Sierakowski: Hey, Reed, welcome to the podcast. How are you today?

Reed McGinley-Stempel: Doing well, thanks for having me today.

Brian Sierakowski: Of course, my pleasure. Let’s get started where we do usually get started. Where did you start your entrepreneurial journey?

Reed McGinley-Stempel: I guess really, the start of it was the first time I started working in tech, back in 2017, I guess that’s really where the seeds of it started to kind of grow. I joined a company called Plaid back in 2017. And before that, I would not consider myself especially entrepreneurial in particular, you know, I had worked in management consulting before joining Plaid, which I sometimes feels even contrast to entrepreneurship, often you’re just trying to make fine, small changes to things like operating expenses, et cetera, we’re not trying to create, net new things in the world, often in terms of at least the projects I’m familiar with. So I was much more interested in getting into something a little bit more, tech in particular, startups back in 2017 and that was when I found Plaid, which at the time was maybe a 90 person company out NSF, a series B Company, and I joined first on the go to market team in a generalist role, and then move over to the product team. And on the product team, I worked on an interface that probably most listeners have probably interacted with, even if they didn’t realize they’re using Plaid.

Plaid is the financial backbone of how you connect bank accounts to FinTech apps, so anytime you’ve connected your Bank of America, or Chase, or Wells Fargo account, to Venmo, Robinhood, Coinbase, et cetera, you’ve been using Plaid in the background in order to enable that handshake. And so I worked on the team that was responsible for the authentication experience from an end user perspective of when you link that bank account. And so I worked on both security projects that were aimed at preventing account takeover attacks, and also projects that were aimed at improving conversion so that our customers, the Robinhoods and Coinbases of the world would be happy. And I think that was really the first time I started thinking about founding a company was running into an issue that plagued us internally, but also just kind of made me scratch my head about why did we do that in the world and that actually came down to how do we actually log in and sign up for services online.

My co-founder, and I had noticed that as we were working on this project at Plaid, the most common headache that we had from both a security perspective, and a user experience perspective, in this flow was password based. Passwords were the biggest cause of fraud, but also the biggest cause of users abandoning the flow entirely and giving up because of the friction of not remembering their password and so we kind of asked ourselves, why do we even so use passwords or authenticate ourselves in 2020, when you have better technologies, like biometrics, you can use things like email verification, email magic links, SMS, so you can do mobile verification, et cetera. And so I think, kind of having that experience where I’d worked at a tech company, I had seen, how quickly things can evolve when you put a lot of attention care into building a great product, and then noticing firsthand something that we thought was really incorrect about the way that the world worked in 2020, when we started this company, was really I think, probably the burgeoning kind of experience that led me to starting Stytch and going deeper down the entrepreneurial path.

Brian Sierakowski: That’s awesome. What made you want to go and work at Plaid?

Reed McGinley-Stempel: Yeah. So it’s interesting, I think there’s probably two major components. One was kind of what was the push factor away from working at a great consulting firm like Bain and then what was the pull factor to go into Plaid in particular. And I think the push factor was similar to what I had talked a little bit about earlier, where Bain was a great training grounds in terms of analysis, logic, and structured thinking in terms of problem solving, I did not find it particularly creative or that interesting relative to what I wanted to do I felt as I had mentioned, you’re often kind of optimizing pretty small things, which could have a really large impact at a large organization but to me were less interesting than working on something that was that new or trying to create growth for a burgeoning company and so I kind of knew that consulting was not going to be a long term career path for me and startups felt like a pretty logical choice next, if I could find the right startup, just because their flexion point in terms of where they are in their journey, but also kind of the markets they’re going after. And so that was kind of the push factor for me was to kind of think about moving from consulting to startups.

And then Plaid in particular, was really interesting to me, because I credit a lot of luck to the actual outcome of the landing there, I did not know what Plaid was, at the time, when I started my job search, I just got a cold outreach from the recruiter and there wasn’t that much publicly known about Plaid at the time, they were a series B Company, but I think they’re valued around $200 million at the time so they’re still pretty early on in their journey. And I just remember from meeting the team, learning a little bit more about the product, and then asking just friends in Silicon Valley, what they thought of the company, while it was still kind of like a well-kept secret, everyone had a lot of reverence for the team and I noticed immediately after meeting them, that there’s something special happening there. And so that was kind of the pull factor was, even though I was not that deep into the API space, or FinTech in particular, it just felt like too good of opportunity to pass up once I met more of the team members at Plaid.

Brian Sierakowski: Wow, that’s really cool. And maybe I could just ask, I imagine that there was like a big culture shock going from the consulting world into a company. For me, Series B is like a relatively far along compared to the people that I usually talk to, but it sounds like, from your perspective, they were still like pretty early, especially compared to where they are today. Did it feel like there was a big shift for you with the type of environment you’re going from, from the consulting world into the more startup type environment of Plaid?

Reed McGinley-Stempel: Definitely, I remember there were probably two main things that I noticed immediately after joining. The first was actually one piece that was a massive change. And the second one was something I expected to be more different, but actually was not as different as I had kind of supposed. The first piece that was really different was just the bias towards action and the fact that in consulting, you’re often turning decks and that means you’re doing a new deck every day or week, in order to show it to the exact team at this fortune 100 company, you’re getting feedback from your partners, and then from them, and you’re adapting it, you’re going back to them. And it was one of the things that frustrated me was, you’re often just turning decks and not actually taking action for months or years until after you’ve delivered that recommendation. And so there was maybe a bias towards doing work in consulting, but there wasn’t often a bias towards action, and actually taking the recommendation and implementing it. So that really frustrated me but I remember, it was just complete change when I moved to Plaid kind of a just do it mentality around if you see something broken, just fix it, run the project, let people know if you have an idea around something, and you can just fully take ownership of that. And so that was really refreshing.

 I think the thing that surprised me, because I probably expected it to be a little bit more disorganized, is what was 90 people so it wasn’t super small, but it was a smallish startup. I remember joining and expecting there just be a world of difference in terms of the organization of a really large consultancy like Bain and Plaid when it came to things like onboarding, employee training, operations, etc. And so while you could gain a lot of ownership by taking control of something applied, I was actually really impressed by how structured everything was from kind of an onboarding, training, et cetera experience, that was one of the pieces that wasn’t surprisingly to me, that different relative to where I was coming from.

Brian Sierakowski: That’s really awesome and super good to hear. Do you have any examples of like, a time where you saw something that was broken? Or you saw somebody who saw something that was broken? I guess I’m curious like, what sort of guardrails, if any did Plaid put up to make sure that if everybody is in the process of trying to make sure that things are constantly getting better, how that doesn’t result in everything either go sideways, or like some things get worse, was there any sort of like structure that’s put into place to make sure that things are actually moving in the right direction? Or did they have the mentality that was more like, well, in order for us to achieve like our long term goals, we have to be a little bit more permissive in letting people just try stuff because we know a lot of things aren’t necessarily going to work but as long as it’s a little bit better, maybe that’s okay?  I’m curious, like what was the sort of like mentality there as far as like, the counter side of if everybody is going to be allowed to make changes and take ownership of stuff, how they protected if at all against things potentially going in the opposite direction?

Reed McGinley-Stempel: I think there is an interesting blend of both top down guidance that was valuable in terms of avoiding people kind of spreading in too many unrelated directions, but also providing a lot of bottoms up ownership to the team. And so for example, I remember, there was always really clear, two to three, maybe four top line metric goals for the company on an annual basis. And often that would become a common language for how people would communicate is how does X project move this metric versus that metric. And that would be a really easy way for team members that maybe weren’t in leadership positions, to negotiate with each other on how important was a project to actually fix this now versus leave this broken, because it’s not going to hit any of the primary goals that we have. And so I think the fact that they’re always pretty clear top line goals made it much easier on the ICE level, to negotiate what you should be working on.

And then I would say you usually would not do like a large project without at least getting buy in from your manager, or someone else that was a little bit more plugged in to the executive team. So for example, one of the things I worked on was kind of overhauling how we did customer surveying and getting inputs for our roadmap, and it was the type of thing where creating a really large NPS survey process, figuring out what were the features that customers wanted to build is pretty big project in terms of a lot of customer communication, then you also need to make sure that communicated, feature requests, moves to the product team then gets implemented so it doesn’t feel like you’re not listening to people, and says that example of the type of project where I definitely wouldn’t have done it without any buy in from the executive team but when you have managers and executives that are supportive of that ultimate outcome, and you propose something like that, it can move pretty quickly given Plaid bias towards action.

Brian Sierakowski: That’s really cool and correct me if I’m wrong here, but the feeling that I have is, it was sort of like the company is very clear and discreet in the high level goals, and the spirit of them saying anybody can fix anything, to certain extent is sort of like if you’re trying to achieve one of these high level goals, and then there’s some sort of process or structural issue that’s getting in the way of you hitting this goal, then you’re also empowered to fix that thing, like remove that blocker so that you can successfully hit the goal. So it’s not a situation of when it comes time to do goal review, or whatever end of the month or end of the quarter, nobody’s walking into that meeting and going I couldn’t hit the goal, because of this reason sounds like in the Plaid environment, they would say like, well just fix that problem and then it wouldn’t be an issue.

Reed McGinley-Stempel: That’s exactly right. 

Brian Sierakowski: That’s really great. And you mentioned doing user surveys,  I feel like within an organization, every time you’re operating internally, it’s a lot easier to get the team rallied around fixing issues that kind of are only on the inside of house but I kind of feel like it’s one of the things like as soon as you start messaging customers, then it’s like, okay, let’s be a little bit more thoughtful, instead of just kind of throwing things against the wall. I thought it was a really good example you gave us. If one team is going to be getting feedback from users, then you really do have a responsibility to make sure that those features that you’re asking about make their way into the product eventually, otherwise, people are going to feel kind of miffed about that of like, glad I took all this time to share my thoughts that none of it actually happened.

Reed McGinley-Stempel: Definitely. A customer serving process, no matter how good it is on the intake side, is not going to be super effective, it might even actually be detrimental to what you’re trying to do if you don’t have the buy end product in edge to implement those features across like you mentioned.

Brian Sierakowski: While you were at Plaid, you said you’re in the go to market team, and you are working on some of the biggest integrations out there that like you mentioned, I think that I’ve actually used Plaid unknowingly, as well. Could you share what was the process going through, especially if somebody is relatively new to the tech world? What was it like going through these large scale projects? And what did you learn from the experience of working through them?

Reed McGinley-Stempel: So there are two different roles I held during my time at Plaid. The first was this kind of generalist go to market role, like you mentioned. And then the piece where I worked a lot more directly on the product and authentication was when I moved to the product management org. And I worked on this product called Plaid link that I was talking about earlier, which is just that application that gets embedded within Venmo and Robinhood and Coinbase so that when you choose connect my bank account, and you search for a bank, you connect your bank account, that’s all Plaids UI, that’s embedded in this client applications. 

In terms of kind of the breadth and depth of what is actually underneath that surface area is that Plaid link product, which gets embedded in those FinTech apps. It connects with 10,000 different bank integrations, all that are speaking slightly different languages and so plaid has to standardize the way that a developer can interact with Plaid via unified API, and this is where a lot of the value for Plaid comes from.

And then you also have to deal with kind of the other issues I was talking about where, in addition to kind of unifying this API layer between 10,000 banks in the US, Canada, UK, etc. 

How do you also make this a good user experience in order to connect a user’s bank account, but also, at the same time, prevent bad users from trying to take advantage of a system that aggregates so many different banks? 

Because you’d imagine it’s also fraudsters could try to target something like this with credential stuffing attacks and other types of attempted fraud.

The interesting thing to me was just the first day I showed up at Plaid when I had never worked in tech before, because I worked in consulting and was working on very different types of companies and products that weren’t really, maybe tech adjacent, but definitely not tech companies. 

I remember the first dinner, I had actually at Plaid that first day I started sitting across the table of my now co-founder, Juliana, and she was explaining how they had built one of the bank integrations and I remember the amount of complexity that was getting shielded from our customers was just astounding to me, and really across the Plaid product, but also across any API company that’s successful, it’s really impressive, and also continually surprising to me how much you’re abstracting away in terms of friction and complexity in order to give something like a simple API endpoint for someone to interact with to access this primitive and provide this functionality to them.

Brian Sierakowski: Yeah, it’s something that we have experienced with on the Baremetrics side of dealing with different payment providers, APIs… and we experience that same pain all the time. 

For us, it’s a little bit different, because we’re trying to like unify so that everybody who uses Baremetrics can see they’re in a similar way, regardless of the payment provider, or how they have their account set up, which there’s a lot of different ways that you can go about creating subscriptions. 

And it’s like, basically, every single day, we find that, especially with a platform that’s so robust like Stripe, it’s like every day, we find there’s a new way to modify the price of a subscription or something like that. 

So we’re like, constantly in it’s like that exact same mentality, you mentioned  like we don’t want people like, worrying about it, I guess to some extent, we want people to appreciate how much hard work it is, and that it’s like, not super straightforward to turn their account into these numbers, but we don’t really want them bogged down in like the actual logistics of like what did it take to pull the data that we had in this other system and like, putting it into this new format that looks beautiful and great and could leave the customer with the assumption that oh, this probably wasn’t that hard to do?

Reed McGinley-Stempel: Definitely, I think that’s pretty frequent challenge of building something that’s so simplified on the outside, but so complex internally and I think it’s something I think about as well as an API company like Stytch.

Brian Sierakowski:  Yeah, I wonder if there’s like some process around like customers who like don’t want to pay for it or don’t want to pay what it’s worth it just like having the approach of like, well, go try it. 

If your alternative is like, we’ll just do it ourselves, I’d be like, yeah, you know what give it a shot and just for fun let’s book a follow up meeting in like, two months from now and I just want to hear how great it is. 

I generally don’t not quite that cheeky when I’m talking to people but it’s kind of feels like that sometimes if you only knew what we did for you, you’d really appreciate me so much more. Correct me if I’m wrong, it sounds like your time at Plaid was like, really great.

Reed McGinley-Stempel: Yeah, I thought it was a fantastic experience.

Brian Sierakowski: Awesome. But you’re not there right now. So, I’m curious, like, what happened? Was it this realization that you had this product that you wanted to build? Or what was the sort of thought process as you were thinking about leaving plaid and going somewhere else period?

Reed McGinley-Stempel: Yeah, it was a tough decision. I’d been there three years, had been planning on staying longer, because I liked the people, I liked the product, and I liked what I was working on. 

I already  had a number of different, what I would call probably viable startup ideas during my time at Plaid,  viable in that I think you could make a venture backed business out of them, maybe not viable for me to go start because I didn’t feel like I was necessarily the right founder for it or I didn’t think I would actually have my heart in it in a way where I could endure a decade-plus journey to go build that product.

I think there was something very different about the idea for Stytch, where working on that password frustration, and then noticing that there’s just a really common technological relic that all end users get frustrated by and creates really large security gaps online, but also a ton of friction online, which can hurt both users, but also businesses’ core metrics, like acquisition cost for users, lifetime value of users and I think, as I had that first person experience with the problem, and then also realize just how broadly expansive it was to the internet, and how much general improvement you could provide by solving it. 

That was where it became really hard for me not to take a really hard look at leaving Plaid in order to go start this company. And I think that was really the thing that started outweighing everything is feeling that this is something that I could dedicate decades to, and that would have a really big impact on both users and businesses and to me felt like, if we didn’t do it, I’m not sure if it was going to get done in terms of someone retiring the password, which is something we talked about is one of our goals here at Stytch. 

And so that was probably the biggest consideration. 

I’d say, there were some other things that maybe made it feel a slightly more opportune time to leave Plaid. For example, this ended up not going through, but they were getting acquired by Visa at the time, I had decided to leave and I think it would have been great to work with Visa I don’t know if I would have planned on staying there as long as I would have stayed at an independent Plaid. 

So I think that was definitely a contributing factor but I’d say the biggest thing was just getting an idea that I was really passionate about and then also sharing that idea with a great co-founder like Julianna made it feel like a pretty easy decision in retrospect.

Brian Sierakowski: Once you resolved internally that it was like time to leave and like you were really motivated to start this this new business, what was it like immediately after that? What was the first step into getting started?

Reed McGinley-Stempel: Funny, I’m going to say the first step was actually convincing those around me that it wasn’t a terrible decision to walk away from a certain amount of unvested Plaid equity in the middle of an acquisition and then also, this was the beginning of the pandemic, so this was May 2020, when I gave notice to Plaid. 

It’s funny, the first step was actually probably me trying to pitch my friends and my then fiancé, now wife, on the idea of me leaving a really comfortable job and being able to make the leap into entrepreneurship. 

I think as we explained the idea to others, it also was interesting to me how visceral of reaction, even people that weren’t super deep into tech had when they heard about this concept of being able to get rid of passwords entirely. So it’s funny that was actually probably the first step. 

And then from a more kind of operational side of how do you actually turn this into a company so that we’re not quitting our jobs for nothing we had spent probably before we had given notice, and I had been at Plaid, my co-founder who I met at Plaid, she had been at a company as the first product hire called Very Good Security for roughly the year prior. 

Before we gave notice to those two companies, we had spent probably four to five months, just kind of pushing the idea around and trying to break it in different ways and flex it and figure out if we were wrong about the opportunity here. 

That involved a lot of conversations with developers that have built authentication by hand with or use different vendors like Okta and trying to figure out if there really was the significant gap that we thought we had identified in the market. 

So as that had been happening, before we gave notice, we’d also started kind of writing down our general pitch of what we thought the business model was, the product was and started putting together I guess, a pitch deck.

And when we gave notice, we started having a couple conversations with friends that were associates at VC firms or with Angel investors, just to get their feedback. And I think one of the thing that’s things that spiraled out of control faster than we probably anticipated as your deck starts getting shared with VC is you start getting a cold inbounds from different venture firms asking for conversation. 

And very quickly, we found ourselves in a seed fundraise process and said that was probably the next big step for us was really sharing our idea for this product, the proof of concept that Julianna had built, and where we saw this going with dozen plus VCs in the valley before ultimately choosing a benchmark leader or seed fund with Index as a participating investor as well. 

So I’d say that was probably the next big step, and then a lot of hiring focus after that and building.

Brian Sierakowski: Yeah, that’s awesome. Do you think there was any response or feedback you could have gotten from your initial round of friends and family that would have made you reconsider the possibility of starting this business?

Reed McGinley-Stempel: Yeah, I think that Juliana and I both consider ourselves and I think we actually are quite pragmatic. I think we’re like really ambitious thinkers but I think we’re pretty pragmatic about finding the faults and ideas and where things break. 

I think if either of us had started to get discouraged by the “Oh, the market won’t actually buy this product” or “X company is actually solving this problem better than we might be able to”, I think it would have been a pretty honest conversation between us that probably doesn’t make sense for us to go quit our jobs and found this company. 

What was interesting, though, is I think we were getting more conviction with every single call we did, because the really common theme throughout was, yes, if this existed, I would buy this and I would use this. 

And that’s where a lot of our early customers came from was people that were excited to get their hands on product.

Brian Sierakowski: Awesome. And what was it like going through the fundraising like that seed round process? It seems like you were intentional, but almost seems like partially by accident that you kind of went into like a larger fundraise, like, what was what was that process like to get started? 

Did you have any given thing built at that point in time? Were you kind of just given the pitch? Or like, what was that like going through the initial fundraising process?

Reed McGinley-Stempel: Yeah, so I would actually probably describe it as we stumbled into the fundraise process, I think the two things that we had done prior to it, that helped us a lot and set us up for success in it were 1. That we had pushed the idea in a lot of different ways and as a result, we had started working on our pitch deck to make sure we’re being clear with ourselves about what we’re building and how we’re pitching it.

And then my co-founder had also built out a proof of concept for a couple of the off products that we wanted to offer from password less lens. 

So we had those two pieces going into kind of fundraise but I think the reason I say we stumbled into is we, at first intended to start discussing that pitch deck the idea with friends that were in the venture ecosystem, just to get their honest assessment. 

And we were getting really good feedback from that but that was the point where we probably hadn’t expected to start a full, fundraise cycle where we were going to pitch partner meetings, et cetera over a two to three week span and that accelerated really quickly, as we noticed that once your deck kind of gets leaked out there, you kind of have to seize the opportunity to connect with these different VCs, communicate your vision outside of the 10 to 12 slides that they might have seen over their email. 

And that was really the piece where I’d say it worked out very well but we probably didn’t plan it as closely as I probably would have in retrospect.

Brian Sierakowski:  Yeah, it’s interesting.  I’m sort of imagining in my mind as you’re going through the process, and it gets to the point where it’s time to make a deck like that consulting experience that you had, it’s just like, finally this is where I shine. 

I have like years of experience doing this thing. I wonder, do you think there’s any like truth to that of like, the did your experience in the consulting world as it’s time to like sell the company through a pitch deck did that come back to be really helpful and give you something you felt like, was a relatively polished product?

Reed McGinley-Stempel: I think so actually. In addition to learning a lot of like the specifics about how to make nice slides, et cetera, I think the biggest thing that you learn around slide making is really storytelling in consulting and concision in terms of how you communicate different narratives. 

And so I think that was something that was really helpful as we’re thinking through how to build the deck. And so it’s funny, I’m laughing a little bit, but I think it’s accurate to say that that probably was a contributing factor to our success.

Brian Sierakowski: That’s great. We do our best when we can use all of our experience and like not leave anything on the ground when it’s time, especially when starting a business and everything is unknown and everything is on the to-do list and nothing’s done yet, so totally checks out to lean into the strength there. 

So with the business you kind of started, you got your seed round, then you said you moved directly into kind of the hiring mode and getting started. What was that phase like for you?

Reed McGinley-Stempel: Yeah, it was really fascinating for me, because I think the thing that I maybe knew in the back of my head, but became really clear very quickly, was the need to become maybe not a complete expert at a net new function every couple months as the founder, but you have to become pretty competent at that function and so as an example  fundraising was really becoming a good salesperson and communicator, and maybe even a marketer, because your story is telling a lot. 

And then when you have that first cash in the bank, as an entrepreneur, and you’re kind of in hiring mode to make sure that you can build the right team to build the product that you set out to build, there’s a huge focus on recruiting, of course. 

And recruiting isn’t just outbound, though, that is something that’s really important is finding the right ways to find really good candidates. It’s also about what is the actual interview process panel, et cetera, that you put in place to make sure you’re getting the right signal, and that you’re getting reliable signal so that you’re not introducing bias into the equation. 

That was one of the things that where I had been on panels in the past at Plaid for a number of different roles. I’d never had to think about recruiting from kind of a procedural perspective and so having to learn how to effectively build a recruiting function that was just my co-founder and myself, that was really eye opening for us. 

I think the interesting thing to me and this is kind of stayed true over the last 18 plus months of starting Stytch, is that there usually is a new function, you need to quickly ramp up on and become competent in every two to three months. And then of course, you want to find someone that’s more competent than yourself and more of an expert, and hire them into that role, that often it’s impossible for you not to kind of be the intermediary for some amount of time until you find that person that’s talented at that particular role. And so that was one of the big findings for me. 

Something that we were focused on, especially for the first three to four months of the company was recruiting. And I think the big thing to keep in mind after that is recruiting should never become a backburner project, there always going to be other things that feel like they’re more on fire in terms of shipping this product , signing this customer, but really trying to hold each other accountable to making sure that recruiting is always top of mind in terms of sourcing, interviewing and et cetera as you can get into situations where if you don’t make it a priority for one quarter, you’ll feel it for like two to three quarters in terms of the pain and how it slows you down. And so those are probably a couple of the key learnings for me during that initial phase.

Brian Sierakowski: Right. Yeah, that makes perfect sense. 

Did you feel like it was difficult to or maybe I guess, it’s always kind of difficult to recruit, but especially considering the stage of the company and kind of like the state that the world was in a couple of months into COVID, was it challenging to convince people to almost putting them in the same spot that you were in of like hey, leave your comfortable, safe job amidst all this uncertainty and join up with us on the pirate ship and see what we can do.

Reed McGinley-Stempel: It was definitely challenging, it’s hard for me to know how challenging it is in a different environment. I mean, because obviously, we’re still recruiting now but we’re also a 30 person company with $126 million in the bank versus 6 million when we were a seed stage company. 

I think it’s always challenging. The thing that I found helps, actually was, I noticed a number of people were starting to get fatigued from their remote jobs, and were looking for a change because now we are in June, July, August of 2020. And so I think some of the novelty had worn off. Also, people felt they had a better handle on maybe what was happening with COVID. 

So I do think there was a portion of individuals that were ready to leave or open to leaving for the right opportunity. And so that was one thing I noticed. 

The other thing that I noticed, though, and continue to notice this is that passwords do evoke, as I mentioned earlier, a really visceral reaction. We noticed that when pitching VCs, we noticed that when pitching candidates, we noticed that when talking to prospects and customers. 

One of the things that resonated with a lot of developers was not just like the human element of “I dislike passwords, it’d be great if we had a better option” but also the way that we are solving it from a developer tooling perspective, many of the people we had reached out to had built off at some point in the past and often we’d get responses, even sometimes from people that wouldn’t end up interviewing with us, but have now since become customers that would say, I really wish that this existed when I built x or y or I’m going to use this next quarter when I need to build Z. 

And so I think that was one of the other things that benefited us was it’s both a tangible problem for just any user but it’s a very tangible product for the developers who we’re trying to recruit as well.

Brian Sierakowski: Yeah, that makes that makes a ton of sense. I forget where I saw it, I was reading recently, and someone’s talking about the value of having like the common enemy on the team, and the whole company is aligned against and it feels like passwords are a very good enemy to have because I think there are very few supporters of passwords out there and there’s a lot of people that that hate passwords. 

So it’s I think you picked an excellent enemy to align the whole team against and I’m sure even from the investor standpoint, from recruiting from customers, having this one thing that everybody hates, that you promised to get rid of it is a very attractive pitch.

Reed McGinley-Stempel: Thank you. Appreciate that.

Brian Sierakowski:  Cool. So we’re now a couple of months into the business. I’m thinking of what is the middle stage between getting your funding and getting the first round of employees in and maybe the next part is getting the first round of product launch? And today like what is kind of the middle stage of the business so far look like?

Reed McGinley-Stempel: Yeah, so we raised that seed round in June 2020, spent the next couple months we were hiring out the early team, and then had shipped our MVP by the end of 2020 and had started putting it in customers hands, getting really good feedback on our first password less product, which was email magic links offered via a direct API integration, and we also have a front end SDK, which handles the UI heavy lifting, for developers that want to use that. 

We spent a lot of that first half, or the second half of 2020, building out the product, getting feedback, doing kind of an alpha of the product. And then that kind of positioned us where we were seeing really amazing traction and investors were hearing about that, we actually did our Series A only about half a year after raising our seed based on kind of demand in the market and traction we were seeing. 

I think that was pretty pivotal because while we announced it kind of middle of 2021, we’re able to go into the year 2021 the emphasis on building out the team to being more than just the seven people that we ended 2020 with. 

And so today, we’re roughly 30 people and now I look back at the last roughly a year that we’ve been continuing to build as we came out of beta and we now have eight different authentication products that span biometrics, mobile verification, with SMS, email verification, as I mentioned, different OAuth connections like signing with Google, Apple, Microsoft, et cetera.

We’ve seen kind of like this explosion in terms of products set capabilities and also as a result, kind of the GTM metrics that follow that as well and that also spurred a lot of that on because we’re getting those feature requests from different customers. 

I think the other interesting thing here has just been how quickly things can go when you invest in the right foundation upfront. So for example, one of the common phrases, one of our board members would tell us early on in our company lifecycle is “go slow to go fast “and I think he’s talked about this publicly as well, which is making the right foundational investments early on is going to allow you to iterate and ship so much faster, 1 2 3 4 quarters from now, whatever it is. 

And it did feel like the first six months, we’re doing a lot of foundational work that felt like sometimes we’re going slow, because there weren’t a ton of products coming out of the door. 

But now the kind of velocity with which we ship is averaging four new products per quarter, and really pretty innovative products, like WebAuthn is one that we just shipped last week, which is allows you to use the built in biometrics on your devices for signup and login or you can also use UB keys, shipped and embedded authentication product a couple about a month ago focused on making it so users can actually have invisible authentication handshakes to them. 

And so I think that’s one of the things that’s probably been clear to us was just putting the right investment in the foundation upfront, has really paid a ton of dividends now that we’re in the faster cycle of building and shipping and iterating. And so that’s probably what I’ve noticed most over the last year.

Brian Sierakowski: That’s really cool. And yeah, I’ve certainly been in situations where I’ve tried to just go fast, and it doesn’t work. So you’re totally right. In practice, what is going slow look like in that context? 

Reed McGinley-Stempel: A lot of it had to do with how we thought about the platform team early and some of the developer ergonomics for internal development of different products and how we deploy things. 

We often get told that our platform engineer, Danny, set up an amazing remote dev environment, which has made it much faster for people to iterate and build on but also, then I think a lot of the abstractions that we built internally, around shipping new API features, shipping new SDK features have also paid dividends so some of it kind of goes down to the foundation at the actual like platform layer on the platform engineering side of how we build things and I think there are also a lot of abstractions the team has thought about throughout different parts of the stack as you get to more product oriented pieces that we’re building.

Brian Sierakowski: Got it. So thinking about all those little pains that they get bigger over time, like the test suite that takes too long to run or like what is the deployment process look like? 

Were there any like process things of like, because we’re on a remote team, what is pull requests review look like? And we’re all those things sort of, in your mind as far as how can we optimize to make sure that we can get things out the door, high quality and as quickly as possible?

Reed McGinley-Stempel: Definitely. And I’d say you’re never perfect on those, but they were all discussion points and things that we installed policies for. 

So for example, at one point, we thought and everyone is working on a lot of things, building a lot of things that just makes sense that PR reviews were sometimes taking too long, and therefore that was stalling someone. 

And so as we got that feedback and kind of saw that in action in 2020, our CTO installed some clear guidelines around the timeframe for which you need to review a PR by and what is the kind of SLA that we impose internally and that’s probably actually something. 

I’ve never been an engineer, but I would guess most companies have something around that but I think doing it really early is something that you might forget about if you’re just trying to in Build mode, but I’ve noticed even small policies like that, to your point stack up over time, as they’re all just cutting wasted hours or toiling away from the development process in a way that hopefully you can do faster.

Brian Sierakowski: That’s great. I think that when I’ve experienced things like that, it’s kind of like, really, the tradeoff that you’re making is like would you rather ship the product or do the thing? Versus making that long term investment? 

Like you’re saying, and I think that sometimes it can be difficult. I don’t know, I’d be curious to hear if this was the case for you. But especially for very good engineers, like they want to ship and they want to get their products out there and they’re really excited to get it into the world. 

Was there any like sort of environment that you created? Or anything that you said directly to help the team appreciate that? 

Like, yes, I know, we could get feature one out the door or product one out the door more quickly. But what we’re really concerned is in three months, in six months, we want to your point like you are launching like four features, or four products a quarter.

Was there any like specific communication or any sort of system you set up to kind of like get the rest of the team on board without like, hey I’m okay with us shipping slower now, because we’re going to go faster later?

Reed McGinley-Stempel: There were a few times where we actually brought in the board member, I mentioned Chetan Puttagunta, for fireside chats with the early team. I think we did this twice. 

And we actually made that a discussion point at both of them, which is what is this concept of “go slow to go fast” mean? How have you seen this work at other companies? 

Chetan focuses on developer companies and his investments and so he has some great of anecdotes and analogies of what’s worked well, and what hasn’t worked well. 

So I think that was really helpful kind of way to exemplify what we were talking about and that was probably the main way that we kind of talked about this, then I’d say, my co-founder is really diligent in kind of technical conversations of asking that question to people of like, sometimes we just need to get MVP out, because that’s how you get information about what needs to improve. 

But to your point, also, sometimes you need to make sure that you’re taking a little bit of extra time upfront, so that this is something that is going to be able to move much faster, a quarter or two quarters from now and so I think our CTO, and my co-founder, Julianna has also balanced that really well, from the conversations I see internally, when we’re talking about tradeoffs with a new feature or product.

Brian Sierakowski: Yeah, and the thing that I felt instead, it can be like, a little bit scary to from that standpoint, to kind of, like, reflect on the emotions of it because you can definitely quantify that you’re making an investment but whether or not that investment pays off is like, if you ship something, you definitely got that thing shipped and you can see that and you know, it’s like it is done. 

But you know, the investment is kind of speculative. Did you have that sort of feeling? Were you ever up late at night going we’re not shipping anything yet and I really want to get more out the door but I know, in my head that we’re doing these things to move faster but in my heart, I’m kind of feeling like, I’d rather just ship the things, did that ever crossed your mind, or was having that board member being so accomplished and kind of having the pinch enter from that perspective, having them come in and say, here’s where we need to be and here’s what I’ve seen be successful, was that kind of enough for you to be like, okay, cool, I’m going to stay the course and I have confidence that we’re on the right track?

Reed McGinley-Stempel: It would definitely cross my mind and it’s something that would kind of be in the back of my head occasionally but to your point, I think we had enough. We would notice you start seeing the wins accumulate, where some small things, oh, we did this investment two months ago and now this piece is going way faster and so you couldn’t see everything because some of these are multi quarter bets, but you started seeing that, and then having also that backbone, as you mentioned, in terms of a really supportive board member that has kind of seen this before, allowed me to kind of allay any of those concerns that I might have. 

And so it definitely does cross your mind because I think to your point, you always want to ship something faster so you can see that tangible product in the world. 

So I’d be lying if I said it wasn’t something that can cause a little bit of heartburn. But at least you know it, it’s like medicine, you know, it’s good for you, even if you don’t enjoy taking it.

Brian Sierakowski:  Yeah, for sure. And I’m wired is such a spas naturally that it’s very difficult for me to have the attention span even though as you’ve mentioned, like I know it’s best to make these long term decisions, but I certainly find myself going like yeah, but what if we just got it done? 

What if we just figured it out and dealt with, kind of slog through it. 

And so it’s very cool to hear your experience and it almost feels like, I don’t know if this connects at all, but it almost feels a little bit like I don’t know if selfish is the right word, but I’ve been on a lot of engineering teams in the past, where a lot of the work that the team does is sort of like self-indulging of like, well, we’re going to redesign the system, or we’re going to put these developer tools in place and those didn’t contribute to the product moving more quickly. 

It was just kind of like, because the dev team sort of had a lack of direction, and the company wasn’t really clear on what needed to happen next, the engineers would kind of figure out the thing that they could do that would feel like work, and  from the outside it approximates work, but it actually doesn’t do anything. 

So I feel like there’s a part of it to have maybe a little bit of a historical memory of me of like I don’t want us to go too far down that road, but clearly, you found like, a pretty successful pattern here of like, there’s a line to be drawn of like, how much playing around with the environment we do versus like how much okay, now it’s time to ship it and get that feedback that we need to make good decisions moving forward.

Reed McGinley-Stempel: And you articulate a really important thing to keep in mind, which is that piece of, at what point are you investing in foundations that aren’t actually going to have returns? 

I think it’s something that you need to be really mindful of, in those internal discussions about, should we actually invest in this upfront, but also I’ve noticed, it’s something that gets talked about a lot in our debriefs for candidates, where whenever we’re asking them to talk us through a project in their past they worked on that was complex, or interesting and we’re having them talk us through and what they worked on what their contribution was, how they plan for it, how they solve problems, et cetera. 

It’s always kind of a red flag if somebody chooses maybe it’s actually a super impressive technical project but they’re not as concerned about what the actual impact was to the org or company.

So I think that’s another way that we discuss it is, is this engineer that we’re interviewing consistent with kind of the ideals that we hold? 

One of the values we talk a lot about at the company is designed for the future build for the present. And so what we mean by that is, there is a balance, sometimes you do need to ship the MVP, which is building for the present, but you should at least have in mind… you want to make sure it’s not hamstringing you in terms of what you want this ultimate product to be.

That’s where we see people sometimes make mistakes with getting the first feature out is that they neglect the foundation that way, but of course you can, to your point, over invest in the foundation in a way that doesn’t even allow you to build for the present either.

Brian Sierakowski: What are your criteria to make that decision on if this piece of infrastructure is the right thing for us to focus on to move faster later, and if now is the right time to put that put that piece of support in place?

Reed McGinley-Stempel: The primary things that we talked about are timeframe to benefit, and then is that benefit something that we’re going to build anyways?

And so I’ll give an example of kind of like our OAuth products. We launched OAuth support in q3 of this year 2021. And we could have launched it a couple quarters earlier with just maybe like signing with Google and we wouldn’t have invested nearly as much in the foundation that makes it really extensible and easy for us to add new OAuth connections. 

So the things we had talked about in that decision were if we did invest much more in the upfront piece that delayed us getting out the sign with Google option, but allowed us to be more scalable, long term, what would be the timeframe to reward and we knew it was less than two quarters, which is often quite a random proxy but it’s a proxy that we think about as a company, because we usually plan in halves of years versus whole years and we do tiling on a quarterly basis so timeframe to kind of benefit. 

And then we ask the question of like, what is the magnitude of the benefit? Does it mean adding a new OAuth connection goes from a few a couple sprint’s like a couple weeks to a day or less? 

And if you’re talking that type of kind of like, repeatable notion where you’re saving days or weeks, for every net new product, when you know that we’re going to end up with 30 40 OAuth connections in the next 12 to 18 months, that became a really easy decision. But I’d say it’s not always that easy but often we look at kind of timeframe to results, and then how much, we’re going to need to be working on top of that foundational layer in a way that we can kind of generally predict how much time it might save the team ultimately.

Brian Sierakowski: It sounds we’re substituting time for money, but you’re just trying to make a sound investment. 

Like if we invest an extra three months, if this thing we think it’s going to take us three months longer over the course of the next full year do we think we get three plus months back? 

And in your case if you’re saving multiple weeks per OAuth connection, and you’re going to have dozens of OAuth connections, you can do the math pretty easily be like, yeah, it’s totally worth the extra eight weeks or 12 weeks that it’s going to take, is that kind of like a summary of like, how you’re in abstract thinking about making these sorts of investments?

Reed McGinley-Stempel: Yeah, that’s a good summation.

Brian Sierakowski: And it also sounds like you’re also operating against like, timing, too. If you’re like there’s some other externality that says, like, we really should get this product out by this point in time, then that’s the other side, you’re going to compare against if like, how important is it that we nail this release by a specific date? And are we willing to deal with the tech debt from that on the outside versus does this just inherently spending the time on this thing are we going to get like a return on time moving down the road like is that going to actually pay off for us?

Reed McGinley-Stempel: Yeah, exactly. 

Brian Sierakowski:  Cool. That’s a great way to think about. It’s kind of like not to diminish the wisdom, but it’s kind of like obvious, if you think about it’s like, well, if spending time on this thing now is going to save us more time later and it happens like a relevant time horizon, then that’s certainly something that you should factor in, as you’re thinking about, like what’s the immediate need for this feature? 

I’m sure I must have done some sort of analysis on that, but I don’t know that I’ve ever done it like so plainly and discreetly like that. Maybe it feels different in practice for you but it feels like that’s a really consistent way to make these sorts of decisions and at least know like all the different variables that you’re working with.

Reed McGinley-Stempel: Totally. And I think you’re right, that it is obvious. I think sometimes it’s hard in a startup, to break away from some of the other structural pieces, like, do I have runway for that long, so that these long term investments will matter? 

I totally understand why sometimes companies feel like they can’t make these decisions early. I think, if you have really long-term oriented investors, it definitely becomes much easier to justify but to your point, I think anyone could think like this. Sometimes startups put exogenous kind of strain on the ability to think like this, but we found it at least helpful for us here at Stytch.

Brian Sierakowski: It creates a really nice framework to because if the organization knows that this is the decision making process, nobody’s really going to come up and say “I’d like to spend extra time working on this system, because it kind of feels like maybe it’ll be better.” 

And it’s like we need to have some sort of sense of quantification, like, how long do you think you’re going to work on it and then what sort of savings like what do we think the downstream effects is going to be? And so it feels like, it could be something that could really help make those conversations productive because if everybody knows that, you kind of have to have an idea of how long you think it’s going to take and you got to kind of have an idea of like, what you think the savings is going to be down the road, if you can’t answer those questions, I imagine that those are scenarios where the company is much less likely to invest there, because the upfront investment, and the return are so uncertain, that it might just be better to ship the product, and then you get better feedback that you can make better decisions moving forward.

Reed McGinley-Stempel:  Exactly. Yeah, I think that’s a great way of putting it. 

Brian Sierakowski:  That’s awesome. I really appreciate you sharing that, I think that’s extremely useful and very practical at any sized business, maybe it’s like extra good if you have a couple of million dollars in the bank account but I think  it’s a mentality that every business can have. And I think it is almost kind of a meme that as products grow and has development teams grow, things get slower and I think this is like a very good antidote to that of like, well, it gets slower, because when you have four lines of code, and you want to add a fifth line of code, it doesn’t really matter how difficult the environment is, it’s like, very straightforward to do that. But when you have 40 million lines of code, and you want to add another 10 million, then it’s a much larger task. 

I feel like this is super applicable to any size team to try to try to solve for that makes sure that there’s that long term longevity and that the development team stays happy and productive because to your point, engineers are in high demand and sometimes difficult to get to. So having a super happy super productive team, which is what brought you to Plaid is something you can create on your engineering team where people like yeah, it’s great. You can like ship stuff really fast, it’s actually almost the same pitch I don’t know if you meant to do that but if there’s like a problem, shipping software, you can own it, and we can fix it and we can make it better and the company has a long term vision that we want this to constantly get better. So I feel like that’s a huge benefit for your organization.

Reed McGinley-Stempel:  Totally. And it’s been amazing to see kind of the continuous kind of surprise from people when they join a startup like us and as they discussed the remote dev environment or notice some of those other foundational pieces we invested in and so to your point, also from an like engineering, ergonomics, happiness, et cetera perspective, I think it is one of those and during pieces that can also help with things like retention indirectly as well. 

Brian Sierakowski: Yeah, it’s something we see kind of like with the other hand on the private equity side, if we’re acquiring a product, like one of the things we look at is like how long does it take somebody on our team to get the product up and running? Like, how long would it take them to deploy to production, and we acquired a product recently, where the, we were able to deploy to production, like it within the first hour of having access to the repository, and that was such like an eye opener for like oh my goodness, like this is this is very good. This is like a very well built, very thoughtful, methodical system. So yeah, you’re totally right. It’s something I maybe didn’t have in context previously but I’m certainly thinking about it now. 

We I don’t want to take up too much of your time. It’s kind of curious like what’s kind of the latest going on with Stytch and what’s going on within the company? What’s on the horizon if you have anything that you might want to hint to or just sort of like, what sort of your current focus with the business?

Reed McGinley-Stempel: Yeah, so it’s been a whirlwind of 2021. Actually, we announced our series B, two weeks ago, we raised a $90 million round led by Cotu and so you know, a couple of the primary focuses really, for 2022 and what’s coming is we’re still a 30 person team, we’re still quite small, we’re shipping really fast but we see the product areas where we can invest way more in if we were better resourced. 

So we’re targeting to getting to over 100 people by the end of next year, based on kind of the product org design that we have right now for the things that we want to ship next year. 

And a lot of the continuous products that you’ll see us continue to bring to market are, I mentioned a little bit earlier that we just released, our first biometrics product a couple of weeks ago, as well, same day that we announced our series B. And that’s great. And we’re going to continue to kind of double down on these types of pretty innovative products that are both super high security when it comes to ability to protect against account takeovers, but also extremely low friction to users. 

So you’ll see a lot more investment there in 2022, as well as we’re getting a lot of more of verticalized, or category requests on how certain verticals would love to see off slightly better catered to their needs. So for example, we actually get a ton of requests from web three companies for some of the ways they want to bridge the gap from web two to web three, user onboarding, and login more efficiently. And so, that’s probably something that you’ll see a lot more from us in 2022. 

But to date, some of the verticals where we’ve been able to offer new products and really cater to what they’re trying to do are e-commerce and FinTech, for example, I mentioned that we had released a product a couple months ago called Embedded Authentication, which is effectively invisible authentication to the end user. 

It’s built on the idea of embedding high entropy tokens, so magic links, and existing customer communication channels so you can wrap that magic link token into a call to action button that you put in a promotional marketing email for like $10 off, or you can send it in an SMS text that says like “View your account statement”, or you can send it over Whatsapp, whatever it is. 

I mentioned that because those are the types of requests they’re applicable to every company but we’re hearing them in a very pointed way from companies that care a ton about conversion and user engagement, like FinTech and E commerce. 

Similar to that, and what we’re hearing in web three and other verticals, you’ll continue to see us kind of augment our both existing solution set, then also how its integrated in ways that can serve those different verticals needs effectively.

Brian Sierakowski: Awesome. Reed, I really appreciate you taking the time. I’ve personally taken a couple of notes here that I’m going to implement and I think it’s going to be the same for everybody listening to this. Thanks again so much for joining the podcast.

Reed McGinley-Stempel: Thanks for having me, Brian.

That was our conversation with Reed-McGinley-Stempel, co-founder and CEO of Stytch. If you need a better way to authenticate your users, you know where to go stytch.com. That’s S-T-Y-T-C-H.com. 

If it’s business analytics and growth tools you’re looking for, check us out at baremetrics.com We hope you enjoyed this episode and invite you to check out our other Founder Chats. And if you’re able to share with a friend or leave a review, it goes a long way. Thanks for listening.