 Welcome, welcome to the Founder stage. My name is Otto Hilskan Founder CEO of Swarmia and for the next 25 minutes We're gonna be talking about engineering the engineering team Our guest Juliana Lamb is a very impressive first-time founder of stitch Who's recently raised money become a unicorn and she scaled in the CTO role while the company is growing So glad to have you here Awesome, I'm excited to be here Maybe to kick things off just a little bit on My background and sort of how we ended up starting stitch So my co-founder and I both worked together at plaid I was on the engineering team there and he was on the product team and We both basically worked on a lot of problems related to fraud and authentication When we were building out some of these features We sort of went to the market to look at vendors that we might be able to use to help solve some of these problems Basically didn't find anything that we really liked and we're sort of frustrated that we were having to build Authentication which is is not something that is super differentiated Basically every company out there that has a login which is as many of them needs to build authentication And so after building all of these things in-house We were like it's crazy that that nobody has built a really developer friendly product out there that makes it really easy to embed different authentication experiences from passwordless authentication all the way to Passwords and maybe more traditional forms of authentication and do so in a really flexible customizable way that Enables great user experiences So that was sort of the the genesis of of stitch that conversation happened about three years ago And it's pretty wild to see how far we've come in that time That's great To give people a little bit more context at what stage are you in terms of people products customers at the moment? Yeah, so We're a series B company Raised about 125 million to date our team is about 70 people a little over half of that is still on the engineering product and design side of the house And we've supported thousands of developers building on the platform We have about a dozen different authentication methods that you can pick and choose from and Build the experience that that works for your use case your users, etc. That's great We're gonna be talking about the journey of a CTO as as a startup is evolving as well as building a team onboarding them managing them but 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 it gets to some kind of a product market fit So what did that journey look like for you? Yeah, so as we were sort of exploring the idea of maybe starting this company I spent some time building what I would call a very rough sort of proof of concept of what this product could look like Design some of the API endpoints and and spun that up Pretty quickly though as we started to sort of embark on this journey. We ended up raising our seed round And after that it became pretty clear that what we were doing here was building a company not just sort of like hacking on a side project anymore, and so my focus shifted pretty quickly to recruiting and building the engineering team and Really enabling them to go and and build the product So I think there's there's still some of my code that runs in production, but not not very much of it anymore Right What about then you mentioned your co-founder you work together previously How do you work together? How did you kind of start? Leading the company together. How did you kind of divide the responsibilities? How do you have any tips for working with a co-founder because that's another important aspect of an early stage? Yeah, so my co-founder and I have pretty complementary backgrounds and skill sets Where we do have overlap is product But my background is is all in software engineering and then I was a product manager for a little bit before we started stitch 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 a lot of ways in terms of sort of how we thought about Dividing up responsibilities So he basically Overseas all of go-to-market and ops, and then I oversee engineering product and design But I would say we spend sort of the bulk of our time Together talking about product and product strategy That's the thing that we really enjoy just sort of Going into the weeds on brainstorming etc. And I think it's been really beneficial to have Fairly clear sort of like roles and responsibilities in terms of the teams that we manage and sort of what we oversee But also as a very sort of product-driven company The fact that that's what gets both of us excited. I think is is a really good sort of unifying Factor that that helps us build together Maybe the main topic here is the engineering engineering team building a team so 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 yeah, so The way that we sort of articulate What we look for in people we bring on to the team is By two hiring values that we have and the reason that we think it's important to have Hiring values as your interviewing candidates 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 Think creatively and have a lot of ownership over The work that they're doing and so that requires a really high degree of trust in in the people on your team And so we are we're pretty rigorous with our interview process both from the technical side, but also from sort of the motivational side of you know, what is this What gets this person going what excites them? What kind of problems do they like to? Work on and so our two hiring values are we look for people who are ambitious and empathetic And we think that's a really fun combination of person to work with They're excited to think about The big lofty goals that we have here at stitch and how we can achieve them But they're also really good teammates that are going to help make everyone better Throughout the process as well That's a nice way to find a balance in the type of personalities then Hiring in the very early days is maybe a bit different than it is later. What's your? Guidance on the very early hires for your engineering teams. What makes it great hire? Yeah, so in the early days it was my co-founder and me doing all the interviews I would do coding interviews and then architecture interviews and then he would do some of the more sort of soft skills interviews I think another thing that we leaned into pretty hard in the early days was references Which I think is is sometimes not super common, especially with engineers at least in in the Bay Area and We got really good advice early on that You know, it's hard when you're two people Evaluating someone and bringing them on and creating a team for the for the first time Sometimes to visualize, you know What is this person going to be like as a teammate, etc. And so being able to hear from people who have worked with them? Is is super effective and so we spend a lot of time on those reference calls of really understanding You know, what kind of a teammate are they where do they spike? What are their specific strengths that we should really get excited about? I think the like number one thing and in early employees is is just a really high degree of ownership And ability to deal with ambiguity You know, you're joining at that point They were joining two of us and kind of an idea basically and you have a lot to figure out you have to spin up Services for the first time infrastructure for the first time there's a lot of sort of really Wide open space that you can go after and so people that Can prioritize the things that really need to get done can move forward and Accomplish what they need to accomplish when there's kind of limitless possibilities is It's a pretty tough top challenge And so looking for people that that have that high degree of ownership and are going to be effective at sort of navigating the ambiguity That's very important and I feel that that's kind of part of the recipe of the Silicon Valley startups You have people who are very outcome oriented who prioritize their own work think about the customer And I feel that 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 But how do you test for this kind of ownership outcome oriented ness? And how do you build a culture that supports that in practice? Yeah, so there are a few questions that we like to ask in the interview process to help sort of Understand how people think about the work that they're doing and the impact that it has In particular we really look for sort of people who are business impact oriented So engineers who are excited to think about you know 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 people who are excited to sort of think creatively about the the products that they're building And so we tend to test for this by sort of 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? tied the projects that they're working on back to team and company level KPIs or metrics or other sort of Goals that were impacting the business at large versus something. That's maybe a little bit more sort of siloed within the team of I don't know maybe you made Some piece of the code base a lot cleaner for example It's like that for the sake of doing that not necessarily the most impactful Did it maybe accelerate the speed at which developers could contribute code then that's that's super impact oriented? And so little nuances and how people sort of talk about The impact of the work that they've done is is how we sort of evaluate for that Throughout the interview process and then when people join And how do we sort of you know foster that culture? I think a lot of it comes from Setting really clear sort of company level goals But 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 There's a lot of excitement too and in getting to sort of like explore creatively like that And so we think people's best work gets done when they have a lot of sort of freedom to explore and Figure out, you know, how to make the most impact for the company as a whole That's great. 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 and do you have ideas about? the me seniority makes or like how do you how do you evaluate people in practice? Yeah, so it's definitely evolved a lot in the past two and a half years or so I Spent a very significant portion of my time Doing everything from sourcing, you know looking up people on LinkedIn trying to find Good candidates trying to get them engaged To actually running the interview process I like spun up our first Applicant tracking system. I was definitely sort of like recruiting team zero We prioritized hiring recruiters pretty early on And so I think under 10 employees we added our first technical recruiter And I think that was really helpful in terms of sort of giving me a lot of time back to focus on The interviews themselves and closing candidates instead of Some of that sort of more top-of-funnel aspect of recruiting of building the pipeline, etc Today it's mostly hiring managers that run The the recruiting process and and they partner really closely with our recruiting team But our philosophy is is sort of 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 on the engineering team themselves And so it's a big part of managers 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 and so I'm still heavily involved. I would say I don't think my time spent on recruiting has has changed drastically But where I'm spending that time has has changed quite a bit From yeah spending many many hours scraping LinkedIn To now mostly focusing on sort of final round interviews for candidates 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 So any thoughts on onboarding and kind of how you're thinking about that. Yeah, so Our philosophy is basically that onboarding starts when you first come in contact with stitch So the onboarding process sort of begins during your interviews That's how you're meeting some of the team for the first time getting introduced to How we work in some ways and so 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. And so we really think of it as sort of that mutual process There's one thing we do when we give offers to candidates that I think really sort of kind of kicks off the more formal onboarding process and integration within the stitch team and What we do is we basically surprise candidates with a zoom bomb is what we call it 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 And we really love doing that because it gives candidates Really clear picture of who they might work with and and just why those people are so excited about having them on the team Let's them sort of picture what it might be like to be on that team And then sort of day one at stitch We also have a really structured onboarding process and we've actually had that since our first engineer joined 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 you know barely existed at that point Now the the function leads run all of those on onboarding sessions My co-founder and I just sort of do a company mission and value session so that has has changed drastically and sort of what it looks like but The philosophy there is is having a really sort of structured first week for people joining the team Or they basically learn about every single function at the company from the people who run those functions We do some other sessions as well around things like how we work as a team how we think about Using different communication tools for example And we also put a lot of sort of thought and structure into Sort of what the first tasks are for engineers to give them the ability to ship code Basically in most cases day one at the very least week one and are really thoughtful about picking things for them to work on that give them good exposure to The code base helps introduce them To what it's going to be like to contribute code at stitch And I think this sort of like overarching philosophy from from all of this is is just being really intentional About how you sort of integrate people to the team So that you can sort of then let them run with whatever it is that they're going to be doing and give them The foundation the information that they need to be able to succeed. 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 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 do you how quickly do you know if it if it was a right tire if you succeeded in the hiring process? Yeah, I think You tend to know pretty quickly maybe within sort of like the first couple weeks and I think there's People that sometimes interview Extremely well and then you know, maybe they join and maybe they're 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 you're really pleasantly surprised by just how impactful someone can be And I think you sort of start to see that early on Part of the responsibility of of us is to make sure that we are setting people up for success though And that starts with being really sort of disciplined in that hiring process and making sure that We are getting really good signal and so that we hopefully aren't surprised that someone joins and Maybe they aren't able to have the impact that they thought that we thought that they were going to have And then the onboarding is also super critical. Make sure that people are sort of set up for success have the resources that they need and Don't sort of yeah leave them leave them there wondering what to be doing on that first day Makes sense and Do you have any red flags or like common things that might go wrong with building the team and hiring engineers? Yeah, one thing I touched on a little bit earlier is that sort of business impact and I think something that We tend to look for in people is sort of grit and ability to tackle really hard problems But I think there's a really big difference between being able to go out and solve and dig into hard problems and being motivated by Solving hard problems. And so I think the people who are motivated by solving hard problems Maybe a startup isn't isn't quite the right fit there because you're going to get to do some of that But there's also a lot of just like random stuff You have to do is you're building a startup And so that's why we really look for that business impact Orientedness because if that's what motivates you then You're going to be okay You know dealing with maybe some of the more annoying tasks that you have to do that might have a really big impact But you know might not be at the most like technically challenging problem that you could work on and so I think that's something that we We really try and sort of evaluate It's that ability to go after those hard problems, but not necessarily being Solely motivated by those types of challenges Makes sense What about then in the early days? You're just a small team. You're Kind of part of the team working together with them building the first products But one of the big kind of pivot points is when you go from one team to a team team of teams So how does your role change and how did you handle that? Yeah, so started out by managing all of the engineers and then Little under a year and a half ago or so we sort of spun up teams for the first time And what we did is we had one engineering manager join us who? Had previous management experience one of our early engineers Stepped up and started managing one of the teams and so we basically split out into two teams At that point I was no longer managing any of the IC engineers and I think that was that was a really big shift for me I think there's sort of been a series of these shifts the first one is is going from being sort of yeah in the weeds with people Actually writing code reviewing PRs to then sort of my job being more fully around managing people then it was about managing the managers and In in about a week We have a head of engineering joining and so I won't even be managing managers anymore And so that's going to be a whole new sort of evolution of the role And I think it's something that you you really have to I think be self-aware of How your job is changing as a founder as the team is growing? Because the things that you know, I was doing two years ago would be just like so ineffective today I should not be in like code reviews like leaving comments right that would not be productive for anyone And so I think it can be really hard to Sort of leave some of that behind as as the role changes and so the way that I've tried to sort of Deal with that and make sure that I am evolving at the pace that the company needs me to is Just taking a lot of time to sort of reflect on Where I'm maybe sort of still trying to get my hands in something that I should be delegating to someone else And and just be sort of cognizant of that talk to our managers as well And and you know ask them like say 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 should take on and I think that self-awareness really helps with Sort of yeah letting go of a lot of things that you used to do yourself and For the final question I'm really impressed by founders who are able to scale with their companies because 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 at some point. So how do you keep learning? How do you? Seek for mentorship. How do you how do you learn new stuff that you need to be prepared for next? Yeah, I think something I think about is basically if I'm doing the same job that I was a month ago Then I'm probably doing the wrong job today And so I think one piece of it is just being aware that your job should be changing And then as you start to go and sort of you know, maybe try and figure out like oh There's this thing that I need to start delegating or maybe I need to hire this person in I tend to look to I'm sort of experts in in different areas So I wouldn't say there's necessarily like one person that I go to but it kind of depends on on the problem at hand We're fortunate to have a really fantastic board And so we'll go to them for a lot of things there. They're really helpful about Things like thinking about when to sequence various hires etc. If I'm trying to figure out You know, maybe it's like an engineering management problem Then I'll go to engineering managers that that I know and respect It's a design problem like when we were trying to hire our first designer never been a designer I don't know what good looks like in that role We talked to just a ton of people that we really Respected and so I think it's it's a lot about just going and sort of seeking out experts And you have to identify the problem that you're trying to solve in order to do so And so I think that's the hardest part And definitely that sort of like steep learning curve and making sure that you are Continuously doing that is I think the most effective way to scale Right, thank you, Juliana. It was very insightful great having you and thank you everyone who joined. Thank you