In November 2022, Stytch co-founder and CTO Julianna Lamb joined Otto Hilska, co-founder and CEO of Swarmia on stage at Slush in Helsinki to discuss Engineering the Engineering Team and how to effectively build and lead engineering teams, from startup to scale. Below is the transcript of their conversation, edited for clarity and readability. Watch the full conversation on YouTube, or read the transcript.
Otto:
Welcome, welcome to the founders stage. My name is Otto, co-founder and CEO of Swarmia and for the next 25 minutes we're going to be talking about “Engineering the Engineering Team.” Our guest, Julianna Lamb, is a very impressive first time founder of Stytch who's recently raised money, became a unicorn and scaled into the CTO role while the company is growing. So glad to have you here!
Julianna:
Awesome, I'm excited to be here. To kick things off I just want to give a little bit on my background and how we ended up starting Stytch: My co-founder and I both worked together at Plaid – I was on the engineering team there and he was on the product team. We both worked on a lot of problems related to fraud and authentication when we were building out Plaid's features. But when we went to the market to look at vendors that we might be able to use to help solve some of these problems, we didn't find anything that we really liked. We were frustrated that we were having to build authentication ourselves, because it’s not a super differentiated feature – every company out there with login needs authentication. After building all of these things in-house, we thought it was crazy that nobody had built a really developer-friendly product that makes it easy to embed different authentication experiences, from passwordless authentication all the way to passwords and more traditional forms of authentication, and do so in a flexible, customizable way that enables great user experience. So that was the genesis of Stytch: that conversation happened about three years ago and it's pretty wild to see how far we've come in that time.
Otto:
Thanks for that context. Can you give people a little bit more context at what stage you are at, in terms of people, products, customers at the moment?
Julianna:
We’re a Series B company. We’ve raised about $125 million to date. Our team is about 70 people and a little over half of that is still on the engineering, product and design side of the house. We've supported thousands of developers building on the platform and have about a dozen different authentication methods that you can pick and choose from to build the experience that works for your use case, your users, etc.
Otto:
That's great. We're going to be talking about the journey of a CTO as a startup and how it is evolving, as well as building a team, onboarding them and managing them. Being a founding CTO is a pretty special role because in the beginning you have nothing, and then the role shifts very rapidly as the team grows and the business grows. But really the first job usually is to build the first product that gets to some kind of a product market fit. What did that journey look like for you?
Julianna:
At first, we were just exploring the idea of starting this company. I spent some time building what I would call a very rough proof of concept of what this product could look like. I designed some of the API endpoints and spun that up pretty quickly. But after we raised our seed round, it became clear that what we were doing here was building a company, not just hacking on a side project. From there, my focus shifted pretty quickly to recruiting and building the engineering team, and enabling them to go and build the product. I think there's still some of my code that runs in production but not very much of it anymore.
Otto:
Right. You mentioned your co-founder and you worked together previously – how did you work together and start leading the company together? How did you divide the responsibilities, and do you have any tips for working with a co-founder? That's another important aspect of an early stage startup.
Julianna:
My co-founder and I have pretty complementary backgrounds and skill sets. Where we do have overlap is product. But my background is all in software engineering, and then I was a product manager for a little bit before we started Stytch. My co-founder worked on the go-to-market team at Plaid before joining the product team there so it was it was a pretty clean split in terms of how we thought about dividing up responsibilities. He oversees all of Go-to-Market and Ops, and I oversee engineering, product, and design. I would say we spend the bulk of our time together talking about product and product strategy – that's where we really enjoy getting into the weeds, brainstorming. etc. I think it's been really beneficial to have fairly clear roles and responsibilities in terms of the teams that we manage and what we oversee. And as a very product-driven company, the fact that product is what gets us both excited I think is a really good unifying factor that helps us build together.
Otto:
The main topic here is the “engineering engineering team” – building a team. Do you have some kind of philosophy behind your team building, something that you're specifically looking for? How do you approach the whole thing?
Julianna:
The way that we articulate what we look for in people we bring onto the team is by two hiring values.The reason that we think it's important to have hiring values as you're interviewing candidates and evaluating their fit is that we want people to be able to have a lot of freedom when they join to go and tackle the problems in front of them. We want them to be able to think creatively and have a lot of ownership over the work that they're doing, and that requires a really high degree of trust in the people on your team. For that reason, we're pretty rigorous with our interview process, both from the technical side but also from the motivational side –we want to know what it is that gets this person going, what excites them and what kind of problems they like to work on. Our two hiring values are that we look for people who are ambitious and empathetic. We think that's a really fun combination to work with – they're excited to think about the big lofty goals that we have here at Stytch and how we can achieve them but they're also really good teammates that are going to help make everyone better throughout the process. It’s a nice way to find a balance in the type of personalities.
Otto:
Hiring at the very early days is maybe a bit different than it is at a later stage of a company. What's your guidance on the very early hires for your engineering teams – what makes a great hire?
Julianna:
In the early days my co-founder and I did all the interviews. I would do coding interviews and then architecture interviews and then he would do some of the more soft skills interviews. Beyond establishing clear roles for each of us during the process, in the early days we also leaned pretty hard into using references as part of the hiring process, which I think is sometimes not super common, especially with engineers in the Bay Area. We got really good advice early on that references help you visualize what it will be like to work with someone, which can be hard if you’re just starting to build your team. Hearing directly from people who have worked with candidates is super effective to that end. We spent a lot of time on those reference calls, to really understand what kind of a teammate they are, where they spike, and what are their specific strengths that we should really get excited about. I think the number one thing in early employees is just a really high degree of ownership and ability to deal with ambiguity. At that point, candidates were joining two of us and an idea, basically, and there was a lot to figure out. When there's kind of limitless possibilities – it’s a pretty tough challenge, so looking for people that have that high degree of ownership and are going to be effective at sort of navigating the ambiguity –– that's very important.
Otto:
I feel that's part of the recipe of the Silicon Valley startups. You have people who are very outcome-oriented who prioritize their own work and think about the customer. I feel that's maybe a little bit different in Europe where we don't have as strong of a background with great product companies but it's definitely changing and there's a lot of companies who are here doing that now. How do you test for this kind of ownership and "outcome-orientedness," and how do you build a culture that supports that in practice?
Julianna:
There are a few questions that we like to ask in the interview process to better understand how people think about the work that they're doing and the impact that it has. In particular, we really look for people who are business impact oriented – engineers who are excited to think about what they're building, not just how to build it. Especially as a developer company, a lot of our best product ideas come from our engineering team and so we’re looking for people who are excited to think creatively about the products that they're building. We tend to test for this by digging into past projects that they've worked on and how they articulate the impact of those projects. I think you can see pretty clearly people who tie the projects that they're working on back to team and company-level KPIs or metrics or other goals that were impacting the business at large, versus tying them to something that's maybe a little bit more sort of siloed within the team. Maybe they made some piece of the code base a lot cleaner, for example, for the sake of doing it, which is not necessarily the most impactful, versus doing it to accelerate the speed at which developers could contribute code, which is very impact oriented. Little nuances in how people talk about the impact of the work that they've done is how we evaluate for that throughout the interview process. In terms of building a culture that supports ownership and outcome orientedness – I think a lot of it comes from setting really clear company-level goals, and then giving people a lot of freedom within those goals to define the work that they're doing and what they're prioritizing. I think a lot of excitement comes from getting to explore creatively like that and so we think people's best work gets done when they have a lot of freedom to explore and can figure out how to make the most impact for the company as a whole.
Otto:
That's great, but what about all of this in practice? How do you run your recruiting? Who does it, how much time do you need to spend on building the team? Do you have ideas about the seniority mix or how do you evaluate people in practice?
Julianna:
It's definitely evolved a lot in the past two and a half years. In the beginning, I spent a very significant portion of my time doing everything from sourcing people on LinkedIn, trying to find good candidates, trying to get them engaged, to actually running the interview process. I spun up our first applicant tracking system and I was kind of our recruiting team zero. We prioritized hiring recruiters pretty early on – I think we added our first technical recruiter when we were still under 10 employees. I think that was really helpful in terms of giving me a lot of time back to focus on the interviews themselves and closing candidates instead of some of that more top of funnel aspect of recruiting, building the pipeline, etc. Today, it's mostly hiring managers at Stytch that run the recruiting process, and they partner really closely with our recruiting team. Our philosophy is that the teams hire for their team and recruiting is there to be a partner to help them with that process but the job of hiring really falls on the engineering team itself. A big part of a manager’s responsibilities is hiring. I still run some hiring processes myself – I'm hiring for an engineering manager right now, for example, and I still interview every single engineer that we make an offer to. I'm still heavily involved and while I don't think my time spent on recruiting has changed drastically, where I'm spending that time has changed quite a bit – from spending many many hours scraping LinkedIn to now mostly focusing on final round interviews for candidates.
Otto:
That makes sense – the work doesn't end with recruiting though, so when you have identified a great candidate, made an offer, got them to accept it, you need to get them to be a productive member of your team. Any thoughts on onboarding and how you're thinking about that?
Julianna:
Our philosophy is that onboarding starts when you first come in contact with Stytch, so the onboarding process actually begins during your interviews. That's how you're meeting some of the team for the first time and getting introduced to how we work in some ways. We're pretty intentional throughout the interview process that it's as much about selling the candidate and giving them the information they need to make a decision about whether they want to join as it is about evaluating their skills and their fit for our team. We really think of it as sort of that mutual process. There's also one thing we do when we give offers to candidates that I think really kicks off the more formal onboarding process and integration within the Stytch team. What we do is surprise candidates with a “Zoom bomb” – everyone from the interview panel joins that Zoom call and goes around and tells the candidate why they're so excited about them potentially joining the team. We really love doing that because it gives candidates a really clear picture of who they might work with and why those people are so excited about having them on the team. It lets them picture what it might be like to be on that team. Once they’ve started, on day one at Stytch, we also have a really structured onboarding process and we've actually had that since our first engineer joined. It probably felt very comical at the time because my co-founder and I basically ran a series of onboarding sessions. We would talk about things like the competitive landscape or what we think makes great developer products. We talked a little bit about recruiting and marketing and all these different aspects of the company that barely existed at that point. Now the function leads run all of those onboarding sessions, my co-founder and I just lead the company mission and value session. So while who leads what has changed, the philosophy is still the same: there is a really structured first week for anyone joining the team, where they learn about every single function at the company, directly from the people who run those functions. We also put a lot of thought and structure into what the first tasks are for engineers, to give them the ability to ship code within the first week. We’re really thoughtful about picking things for them to work on that give them good exposure to the code base, to help introduce them to what it's going to be like to contribute code at Stytch. I think the overarching philosophy from all of this is just being really intentional about how you integrate people to the team so that you can let them run with whatever it is that they're going to be doing. That means giving them the foundation of information that they need to be able to succeed.
Otto:
I love that, especially the kind of way to empower the teams really is to give them all the tools so that they can be successful and you need a certain level of knowledge to be able to successfully prioritize your own work. So, the sooner you get people on board, the faster they'll get to really own their own stuff. How quickly do you know if it was a “right hire,” if you succeeded in the hiring process?
Julianna:
I think you tend to know pretty quickly, maybe within the first couple of weeks. I think there's people that sometimes interview extremely well and then they join and maybe they're great but maybe they're not quite as exceptional as you thought they were during the interview process. On the other hand, I think sometimes you're really pleasantly surprised by just how impactful someone can be and I think you start to see that early on. Part of the responsibility lies with us, to make sure that we are setting people up for success. That starts with being really disciplined in that hiring process and making sure that we are getting really good signals, so that we hopefully aren't surprised by someone’s performance when they join the team. The onboarding is also supercritical to make sure that people are sort of set up for success, have the resources that they need and we don't leave them there wondering what to be doing on that first day.
Otto:
Makes sense. So you have any red flags or common things that might go wrong with building the team and hiring engineers?
Julianna:
We tend to look for in people who have grit and the ability to tackle whatever is necessary for the company to succeed. I think there's a really big difference between motivated by impact and being motivated by solving hard technical challenges for their own sake. I think for people who are motivated solely when they get to tackle a hard problems, a startup might not be the right fit, because they're going to get to do some of that but there's also a lot of other random stuff you have to do as you're building a startup. That's why we really look for that business impact-orientation – because if that's what motivates you then you're gonna be okay dealing with some of the more annoying tasks that you have to do that might have a really big impact but you know might not be the most technically challenging problem that you could work on. That's something that we really try and evaluate – that ability to go after those hard problems but not necessarily being solely motivated by those types of challenges, but by how solving them will have a larger impact on the company.
Otto:
Makes sense. What about dealing with growth? In the early days when you're just a small team, you as CTO are still a part of' that team. But as you grow, the org changes from being a single team to a team of many teams. How does your role change and how have you handled that?
Julianna:
I started out by managing all of the engineers. Then a little under a year and a half ago, we split into two teams, each managed by people other than me: one engineering manager join us who had previous management experience and in parallel, one of our early engineers stepped up and started managing one of the teams. At that point, I was no longer managing any of the IC engineers, which was a really big shift for me. I think there's been a series of these shifts – the first one is going from being in the weeds with people actually writing code and reviewing PRs, to then being more fully about managing people, and then it became about managing the managers. And it’s still changing! In about a week we have a Head of Engineering joining, so I won't even be managing managers any more. That's going to be a whole new sort of evolution of the role. I think it's something that you really have to be aware of – how your job is changing as a founder as the team is growing. The things that I was doing two years ago would be so ineffective today. I should not be in code reviews, leaving comments – that would not be productive for anyone. I think it can be really hard to leave some of that behind. The way that I've tried to deal with that and make sure that I am evolving at the pace that the company needs is by taking a lot of time to reflect on where I'm maybe still trying to get my hands on something that I should be delegating to someone else. I try to be cognizant of that and to talk to our managers as well and ask them, “Hey, is it helpful that I'm doing this thing or is that something that you think you should take on or someone on your team?” I think that self-awareness really helps with letting go of a lot of things that you used to do yourself.
Otto:
For the final question, I'm really impressed by founders who are able to scale with their companies. As a normal employee, you're kind of always learning and so on but as a founder, if the company is growing 10x, you have to grow with that company or otherwise you're not really able to scale the company anymore. How do you keep learning, how do you seek mentorship? How do you learn new stuff that you need to be prepared for next?
Julianna:
The way I think about it is: if I'm doing the same job that I was a month ago then I'm probably doing the wrong job today. One piece of it is just being aware that your job should be changing and then as you start to go and try to figure out what you need to delegate or hire for, look for experts in different areas. I wouldn't say there's necessarily one person that I go to but it kind of depends on the problem at hand. At Stytch, we’re fortunate to have a really fantastic board, and we'll go to them for a lot of things. They're really helpful about things like thinking through when to sequence various hires, etc. If I'm trying to figure out something like an engineering management problem, then I'll go to my engineering managers that I know and respect. If it's a design problem, I’ll connect with people with that expertise. When we were trying to hire our first designer in-house, I’ve never been a designer, I don't know what good looks like in that role. We talked to a ton of people that we really respected and that really helped. I think it's a lot about just going and seeking out experts. You have to identify the problem that you're trying to solve – I think that's the hardest part. There's definitely a steep learning curve, and making sure that you are continuously evolving and identifying new problems as you grow I think is the most effective way to scale.
Otto:
Thank you, Julianna. It was a very insightful discussion. Great having you, thank you, and thank you everyone who joined.
Share
