 Awesome. Thanks so much for joining me today. We're going to be talking about building really high-performing engineering teams. And it all starts with the people. So we're going to talk a little bit about hiring, and then we'll get into some more details on how to plan your roadmap, manage engineering, execution, and manage your engineers. But really it starts with building a great culture. If you don't have the right people on your team, none of the other stuff matters. So how do you build engineering excellence by focusing on the culture and the people that you're bringing on board? So what this looks like is being really intentional from day one about who you're hiring, but also who you're rewarding, who you're promoting, and what kind of values you're celebrating within your team. So the way that we think about this is defining your values really early on and being really disciplined about holding people to those values. It matters when you're bringing someone in the door if they're going to be a really strong values fit for your team and be a positive addition to the engineering culture and team that you're building. And so it's super important to create a really structured and rigorous interview process. And it can always be really challenging, hiring engineers is always hard. It can be easy to want to compromise and say maybe this person didn't quite hit all of the points that we're looking for them to. And it's super critical that you continue to hold that really high bar and be super intentional about the people that you're bringing on board because one wrong hire can really derail an engineering team. And then finally, making sure that you're codifying your values in your levels, in your promotion process and ensuring that those really exceptional performers that embody that culture that you're trying to create are rewarded and seen as the example that people should live up to. So I'll talk just a little bit about some of the questions we talk about during our interview process to really get at some of the engineering values that are super important for our team. So the way that we sort of codify our values is that we look for people who are ambitious and empathetic. And so the questions you see here are really meant to sort of tease out holistically how does a person think about the work that they're doing, what motivates them. We really look for people who have a high ownership mindset. So they're excited to take responsibility for the work that they're doing, think creatively about how to solve problems, and be really autonomous in the work that they're doing. And if you hire engineers like that, then you can set really high level goals and give those engineers a lot of autonomy to figure out how to achieve those goals, which can result in a really high performing culture, because people are motivated, excited, and probably thinking of ways to solve problems that you, as a manager or leader, might not have even thought of. And so these are just a sample of some of our interview questions that really try and dig into some of that values fit. They can be broadly applicable, but your organization might have slightly unique values or traits that you're looking for. And I think the really critical thing is to find questions that you feel like you can get a really sort of high degree of signal on, where you can ask these questions and you can come away from an interview and say, yes, this person has the right sort of mindset and motivations. That can be a really ambiguous thing to dig into compared to something like a coding interview where we really obvious like, did they solve the problem or did they not solve the problem? But I would argue that these questions and those sort of values fit interviews are just as critical as the technical interviews. Okay, so you have an engineering team. You've hired people. How do you structure that engineering team to be able to execute on your product roadmap and actually ship the things that you want to be shipping? So there's two really common sort of ways of organizing engineering teams. And I'll talk a little bit about some of the sort of pros and cons of each of these approaches and how to think about maybe when the right time is to go one direction versus another. So functional teams are typically how a lot of really early stage companies sort of start out. This is how we started out. You have a small team and it makes sense to organize around more sort of functional areas of ownership. So we have a back end team, a front end team, et cetera. The benefit of this is that it creates a lot of flexibility of resources. You're able to prioritize work based on what's sort of the highest priority products or features to be working on. And teams are able to flex across different product areas. The problem, though, can be that you sometimes end up with a lot of resource contention where maybe the back end team has a lot of stuff on their roadmap and isn't able to prioritize work that the front end team needs. And that can create a lot of sort of like coordination cost when you're having to go back and forth between those teams just to ship a feature. The other really common structure are vertical teams or sometimes it's called like the squad model, very oriented around sort of the product focus area. And that team is self-sufficient and able to sort of execute full stack on whatever that product is that they're focused on. This typically is more successful when you get a little bit later stage and have just a little bit more sort of like confidence in longer term roadmap because the downside of doing this too early is that you might end up with sort of product teams that have varying degrees of priority projects. And so if one team has like a dozen like P0 projects to work on and the other team doesn't consistently have that many P0 projects, that means that you're sort of maybe wasting resources and not having everyone working on things that are really sort of critical. I think as a company develops, you're able to sort of have more confidence but in the early days when you're still trying to find, you know, product market fit, you're still iterating really quickly, product priorities can change super rapidly. So this is just an example of sort of how we organize our engineering team. We have about 25 people on our engineering team, so still relatively small and the way that we think about organizing it is sort of a few different product vertical areas and then we have our platform teams that are meant to sort of support the work of those product teams. So we have things like Infra, DataEng and then our core back-end team that's sort of responsible for the health of our back-end services. And then on top of that, you have teams that are focused on different areas of the product. We have one team, our fraud products team that is sort of the most nimble of these teams. It's very small and more even R&D focused. I think that can be an interesting way to continue to really foster innovation even as the team continues to grow and scale. Awesome. So how do you make sure that teams have the right resources to succeed? This is meant to be a very sort of rough example of what might make sense in terms of a product vertical team and how to structure that so that you have sort of autonomous resources that have everything that they need to be able to execute on that product roadmap. So for us, this typically looks like a couple front-end engineers, a few back-end engineers, designer, product manager, and then an engineering manager. And that pod is sort of able to execute full stack on the work that they're doing. Building a really solid management team is also super critical to ensure that your engineers have the right guidance, feedback, and growth opportunities. The way that we think about sort of structuring engineering management is having a mix of people in the team that are sort of rising through the ranks and start as an IC engineer and grow into a manager role, as well as hiring in managers externally. The people that are coming from within and growing into that manager role will really intimately know the engineering challenges that you're facing, your product, et cetera. And that can be a really valuable perspective. But you also probably want people who have done this before are really strong in people management, can bring best practices from companies that they've worked at previously and sort of introduce those into your team. We focus a lot on making sure that we have the right sort of management to IC ratio as well. So we aim for like five to seven direct reports. That's typically on one team, but depending on sort of the size and scope of a team, it might be two teams. And then finally, as a startup, I think the thing that time and time again just becomes really clear is that you have to be super flexible and scrappy and just know how to operate without too many resources, maybe without someone really giving you a ton of guidance in a lot of cases. And so we really think about making sure that we're hiring people that have some startup experience and have dealt with a lot of ambiguity in the past. Because I think sometimes if you're coming from a bigger company, you might not even realize all of the support systems you had and can be sort of thrown off the deep end then if you're joining a startup and all of a sudden don't have any structure or process to sort of figure things out. OK, so we've built our engineering team. We have figured out the right sort of structure given where we are as a company. How do you go about then planning the work that you're doing, building your roadmap, and figuring out how to focus engineers on the right problems? So I'm going to talk a little bit about how to think about evolving your planning as your company continues to grow and scale. I think this can look very different for different phases of growth. And I think it's really important to continue to evaluate whether you're doing the right sort of planning process as your startup continues to grow. So I think in the very early days, you have a really small team. Flexibility and nimbleness is really table stakes. Your product roadmap is going to be evolving quickly. You want to be able to respond to the new information that you're getting from customers, the market, the work that you're doing, and be able to adapt your roadmap accordingly. And so the way that we did planning in our very early days was basically having just a high level list of key priorities, but then really planning project by project and checking in week to week on whether we were working on the right things or whether we needed to reevaluate what those priorities were. I think really frequent touch points then are super important because you want to make sure that everyone is on the same page and focused on the right things and do so without too much structure because that process can end up just slowing you down. So we did things like have the entire team do a stand up a few times a week, talk through priorities, and really be able to troubleshoot quickly about whether you're focused on the right things, blocked on something, and whether you need to adapt your plans. So company continues to grow and scale. How do you think about evolving, how you think about that planning process? So the way that we sort of did our next phase of planning and growth was basically evolving into a more monthly cadence, so still very far off from maybe a quarterly planning cadence or even annual planning cadence that a larger company will do, but introducing a lot more structure than that kind of ad hoc week to week prioritization. We started to build the muscle of building a quarterly roadmap, but wouldn't sort of plan a quarter in advance since we were still getting so many new inputs that were influencing how we were thinking about our priorities. Flexibility continued to be really critical here, and so that's why we started to plan month to month where we could check in and make sure that if new priorities came up, we didn't have to redo all of our plans to adjust, but also had enough sort of clarity and visibility for the team a few weeks out in terms of what they were going to be working on, making sure that GoToMarket and other cross-functional stakeholders that were starting to become more important also had clarity on what we were building, what they could be talking to customers about, and all of that. At this point, we started to introduce a little bit more structure too in terms of just how we thought about capacity planning, and I'll talk a little bit more about this later on, but basically starting to introduce more sort of like project management structure, ensuring that your setting deadlines and understanding sort of like how your engineering team is performing starts to become more and more important. So as you continue to grow, obviously you're gonna need to get a little bit more sort of forward-looking in terms of how you think about your roadmap, and so by the time we were about 20 engineers, we started to shift to a more structured quarterly planning process, things like PR launches, early sort of like customer partners as we started to do betas for new products, all of those things started to become really important and you can't do that if you don't know what you're gonna be shipping a quarter or more in advance. And so at this point, we started to structure a much more concrete quarterly roadmap, understand timelines for projects, even a bit beyond a quarter, depending on the scope of the project and how large it was. At this point, we also introduced a lot more structure in terms of sort of how we do reporting out on project status, you have six or seven, maybe more engineering teams, really important that they're also able to understand what other teams are gonna be working on in case they have dependencies. All right, so you have your roadmap, you have your plans, how do you make sure that engineers are actually able to build the things that they're supposed to be building and aren't getting sort of pulled in a million directions? It's a really hard problem at a startup where there's always so many different competing priorities, so many different requests coming from different teams, how do you make sure that you're able to actually focus and deliver those really large important projects? So here's a few tactical ways to help create some of that focus for your engineering teams. We do a no meeting day on Wednesdays, I think having that structure helps people also think about how they break down their week, and so different teams will kind of think about this differently, but often will group a lot of their meetings on other days and try and protect as much of the other time as possible. I think one of the great things about being a startup and hiring people with a really high degree of ownership is that they're really excited to tackle a problem when it comes to them, right? So maybe a customer is facing an issue, go to market team has a question about a product, people are always excited to jump on those things, but if you're constantly doing that, that can create a lot of context switching and really slow down the work that people are doing, and so we try and create a little bit of structure there so that people don't feel like they're constantly having to react to incoming questions or jump on whatever the latest thing is, and so we use linear for all of our issue tracking and we have a few different sort of processes within linear in terms of people reporting bugs, triaging those bugs, people requesting new features and how we think about triaging that and creating some structure essentially to make sure that those issues are getting looked at and people are paying attention to those incoming sort of questions and bug fixes, but that it's not everyone on engineering's job to always be doing that so that they can focus on those big rock projects. And then finally, so we are critical infrastructure for our customers, reliability is super table stakes for us and has been a really important part of our culture from day one, and one of the ways that we ensure that we're able to deliver on that is having a fairly structured on call rotation that's there for major outages if and when they happen, but also to be able to be more flexible in tackling some of those bugs and other feature requests as they're coming in without having to sort of entirely shift priorities from the main project that they might be working on. So essentially thinking really intentionally about sort of how you structure engineering time and carving aside some time for people to be more reactive in dealing with those things that are coming in on the fly, but also making sure that the bulk of your engineering time is focused on shipping those major projects. Okay, so we have roadmap, we have plans, we have our engineering team structure. I think one of the most important things about building a really high performing engineering team is how you think about measuring performance and creating growth opportunities for individuals on your team so that they feel motivated and excited and people feel like they're being held to a really high standard and are excited to meet and exceed that standard. So we'll talk a little bit first about measuring individual performance and then we'll talk about measuring team performance. So as you're growing your engineering team, often in the early days, you won't have a ton of structure around engineering levels. At a certain point, you're gonna introduce engineering levels which creates a lot more sort of structure and clear sort of growth opportunities for engineers on your team. But it can be really challenging to ensure that you have the right career growth opportunities for people before you introduce those structured levels. So how do you make sure that people are getting really important and valuable feedback without necessarily sort of being overbearing in terms of process and structure when you're an early stage team? There's a few different ways that we did this. We introduced really lightweight performance reviews super early on. I think this can be really valuable for a startup where there's always 10,000 different things happening and taking the time to actually sort of step back and have that performance conversation with people might get just sort of lost by the wayside if you're not really intentional about creating those checkpoints. But it's also super important that people are getting feedback because I think if you have really high-performing engineers, they wanna know how they're doing. They wanna know how they can get better and they're really excited to grow and getting that feedback is super critical to keeping them excited and motivated. We made sure to create individual development plans so people could sort of see their growth opportunities, make sure they're on the same page with their manager about what that growth and career development looks like. And making sure that you are reviewing compensation and being intentional about how you think about kind of rough bands of compensation as you're going to need to codify that even more when you start to introduce engineering levels. And then finally, just making sure that you're actually taking time to celebrate and reward the values and work that is really great. And you can do that with things formerly like comp, but one of the things that we've done from the beginning that I think has been super positive is we have a Slack channel praise and people can just jump in there and praise people on the team for the work that they're doing. Maybe someone helps me figure out how to solve a bug. I can just jump in there and praise them. And I think that sort of ad hoc, lower stakes recognition can feel really valuable. At a certain point though you're gonna wanna introduce levels. It makes it a lot easier to have sort of those clearing consistent expectations, makes it more clear how to do compensation. It helps with hiring. Oftentimes people might be coming from a slightly larger company that has engineering levels and wanna know sort of where they're gonna stand within your company and what those career growth opportunities are going to be like. And levels can be a really effective way of communicating that. Introducing levels and doing it at the right point in time can be a really tough situation to navigate. I think you're building a startup and you're focused on building a product, getting customers and spending a bunch of time on building a leveling framework and rolling that out to your team can seem like a lot of work. And so it's easy to, I think, punt it down the road. And I don't think you should do it so early that maybe you only have like five to 10 engineers. That's probably a little too early to do it. But I think by the time you have a few different managers and start to need to make sure you're being sort of fair and consistent across engineering teams, that's when it can become really valuable. I think our point of view is that you should do it a little bit too early rather than a little bit too late. It's gonna take a lot of time to roll it out. But once you've rolled it out, I think it can really accelerate things like performance reviews, promotions and all of that and make it a lot easier for managers to also hold their engineers accountable. So do it a little bit too early rather than too late. That can look very different for different companies depending on sort of the type of product you're building maybe, the time the company has been around. I think the longer engineers are with you, the more important levels become because they wanna make sure that they're able to progress through their career. And I think ultimately you'll know when it's time, people will bug you about it. You can probably wait a little bit longer once the first few people start bugging you, but I think it'll feel pretty obvious at a certain point. All right, how do you measure team performance? You're able to hold engineers accountable now to the expectations for an individual, but how do you make sure that the team as a whole is also performing? So there are a few different pieces to this and it might look different depending on the size and stage of the company, but I think making sure that you're able to set really clear goals, set deadlines for projects, make sure that there is appropriate rigor in sort of how engineers are estimating the time it's gonna take them to finish a project and that they feel really good about the deadline that they're setting and then hold them accountable to that deadline. Obviously, things always happen and you're not always going to hit every deadline and so when that does happen, making sure that you're sort of reflecting on why a project got off track and how you can learn from that experience. So I'll show a few quick examples of sort of how we do this at Stitch. So this is a screenshot from our linear of our product roadmap. Basically you can see a few different features that are in the works here. This is our sort of roadmap view and you can see how projects are tracking. If you click into those, you can see more details like status updates on how the project is tracking. We pipe these out into Slack too so it's really easy for everyone to stay on top of how a feature is progressing, what the status is, what's still to be done and this can create really good cross functional visibility so that everyone at the company knows what's happening, when to expect new features and can sort of plan accordingly. So that's all I had for you today. Hopefully these are some helpful pieces of advice in terms of how to run really high performing engineering teams. Thanks so much. Thank you.