 All right, so we're here to talk about scaling engineering, going beyond from that initial five to 10 people and the kind of structures and cultures that enable that growth. And at the heart of that, there are often our terms like empowerment or autonomous teams. At Vault, we call them high ownership teams. It's a very fluffy and kind of very kind of cool sounding word. But based on your experience, Mike, kind of like, what would you say is at the heart of this concept and why does it matter? Yeah, sure. Well, when I think about empowered product and engineering teams, I think about teams that have the tools and the context to be able to continually build and ship products that are pushing the company's goals forward. And I think there's some components that go into creating teams that are really able to do this. So one is around transparency of information and business context. So you have these teams, you have these creative people that you want to problem solve. How do you give them the context that they need to have good judgment and make good decisions about what to build? So in general, I think the more you're educating your engineers and your product teams on the mechanics of the business, like how does it actually work, the more creativity and innovation you're going to get from those teams. And I think there's another sort of component to it which is more structural. How do you set up your product teams such that they can operate as independently as possible with as few dependencies on other teams as possible? I know we've talked about this a bunch, so I'm sure we're going to touch on that some more in this conversation. So the reason to do this, why do you set it up this way, is as your company scales and as your teams get bigger, you really need product teams that instead of taking task lists of things to do, you can really give business challenges to and product challenges to. And they're able to sort of exercise their creativity, figure out the right things to work on, and really drive the business impact that you hope from them. So that's at least how we thought about it. But is that similar to how you think about it at Wolt? Yeah, definitely, definitely. I think there's a huge power in continuing the kind of ownership aspects as you have in a startup team, where you are actually owning the problem and the consumer and the customer that you're actually building for and scaling that same concept onwards through structural decisions as you grow forward. You mentioned a few pillars there for the kind of efficiency of teams. If you go a bit deeper into the context part, so you mentioned the business context being very important for the engineering teams, how have you kind of solved that, for example, Airbnb? Yeah, so I think there's a bunch of components to this. One thing that we really focused on very heavily was the onboarding process for new engineers who were joining the company. And so something that we did is we actually had every engineer go through a three-week onboarding program when they joined the company and before they joined their teams. And part of that onboarding program was really about educating them on the business, understanding the different facets of the product, how the business metrics worked, and also a bit about the landscape that we were operating in, like the competitive landscape that we were operating in. And so part of it was sort of right at the beginning, give them that context. Then I think another thing, and this is something we've also talked about, but is helping your product team members and your engineers be as close to the customer as possible. So I've been pretty fortunate in that, if you look at the last three companies that they just listed, Yahoo, Facebook, and Airbnb, each of those, it's relatively easy as an engineer at that company to use the product. So different companies have a different challenge there about how can you get your employees, how can you get your engineers to really experience what your customers are experiencing. So at Airbnb there was a little bit more of a hurdle because you have to actually pay to use our product if you book something. So something that we did at the company is we offered a quarterly travel credit for every employee to be able to book travel on Airbnb and sort of have that experience. And I think it accrued for two quarters and after that it was use it or lose it. So we really wanted you to get out there and book stays on the platform. That is amazing. I think we do kind of something similar at Volt where we kind of do these delivery days where everybody who joins the company has deliveries themselves to understand the core business. And I think it's kind of behind that kind of scaling phase when you have people joining a company that they didn't found, that they weren't in the early stages to get them to really understand the business what they're building for. I'm a big believer in general of this kind of putting engineers close to the actual consumers and the problems they're solving rather than solving tickets or these sort of things. Fully understand. Maybe the kind of other point you were already kind of a little bit touched upon was this minimizing dependency. So kind of allowing for this ownership of what the teams themselves, what sort of structures would you put around that? Yeah, I mean, I think for a product team, product and engineering team, as much as that team can operate as an autonomous independent unit, the faster they can go through, just like build the habits of shipping code all the time, shipping new products out, seeing what works, experimenting, et cetera. And part of the way that we tried to do that is to actually structure our consumer facing product teams as vertically as possible, so as full stack as possible. So if we have a team that's developing for the web, we would have front-end engineers, we'd have mobile engineers for the mobile screens, but even beyond that, we would have backend services encapsulated in that team as well. And maybe to try to bring that to life a little bit, I'll talk about one of the teams at Airbnb, which was our guest team. So the guest team was responsible for looking at the end-to-end guest booking experience. So that team had front-end engineers, mobile engineers, but they also owned the search backend that you use when you're actually searching for an Airbnb. Like it's a pretty significant piece of infrastructure, right? We put that into a product team so that the dependencies could be managed as much within that team as possible. They could have an integrated roadmap that can figure out here's the customer facing features we're trying to launch and here's our dependencies on backend systems to get it done. So I think that's a really good structure for product-facing, or sort of consumer-facing product teams. But if you do structure that way, I think it's also really important that you have horizontal infrastructure teams to complement the product teams. Infrastructure teams, some people call them platform teams, some people we call them core. Okay, core teams. They should really be building common components that all of your product teams are gonna use, right? And that could be anything like your containerization framework for running services in production, or it could be some of your mobile infrastructure in terms of how do you actually go from code to a deployed binary on the different mobile platforms. These are examples of the types of things that I think belong in an infrastructure team, and infrastructure plays a critical role in this whole composition. Yeah, I think we've seen that at Volt. It comes along at a scale. So typically around 100 and 150 engineers start to get to the point where things are slowing down if you don't have a centralized way of supporting the teams doing their kind of DevOps and infrastructure work, for example, or performance, or these things where you may be kind of hard to staff the teams themselves. We've seen the kind of a similar kind of trend going on once, and the bigger you scale, it seems to be that the infrastructure teams get bigger and bigger. I wanted to touch on the previous point a little bit. You mentioned that having a search inside the actual kind of guest team themselves, I guess that also ties into the kind of goal setting for that area, that kind of like the teams that are building the kind of backend heavy or the kind of more service heavy layer are still trying to serve the kind of same kind of customer or consumer needs. And for that regard, what sort of context methods would, for example, the search team use to kind of get that customer context? Yeah, I mean, I think you need different tools for teams to sort of build that intuition and context around what's important for us to build. For a search team, it could be a kind of conversion metrics. So how often are people making it through the search flow that we're going through and actually ending up at a booking and finding the right stay for them? And so something that we built internally, and this was sort of more on the infrastructure side, but was an experimentation system that would allow us to run any number of different multivariant experiments on the site as possible. In fact, in some cases, we would have hundreds of these experiments running. And that's a pretty significant infrastructure challenge in that you have to make sure that none of those experiments are conflicting with each other and that when you get statistical significance, like, you can really trust it. So that was part of our mentality around it was let's do lots of experimentation, let's see what's actually resonating with the customers we're trying to serve and let that help guide what we build in our teams. That makes sense, kind of all about bringing the context to the teams, using data, using user research, using whatever it takes. We have an experimentation framework at Vault, for example. We call it Regata, which is, I think, a nice and sexy name for this sort of a service, to kind of help teach the engineers on how to look at data in their empowerment methods. Now, if you kind of, we touched upon the fact that their teams should be somewhat independent, this kind of all-autonomically bringing context to the teams, minimizing dependencies across these functions. But that kind of tends to lead to a point where you have these independent sales who are shipping really well, they're bringing a lot of impact, but they're moving to different directions. And they can easily be kind of many different directions that they're going for, and you might create this multi-headed beast that isn't actually going to the direction where the company might need it to go. What sort of methods or things do you think are crucial in getting that direction for the team itself? Yeah, I mean, I think you're building, hopefully, empowered teams. With that power, they could build in a bunch of different directions, which obviously wouldn't be very great for your customers. So I think these teams do need to operate within a framework, right? And every company does this differently. I can share a little bit about how we did it, but one of the things that we always tried to have was, at any given time, we had a pretty clear vision for the next two years. And the idea was that that vision statement, which was usually a few pages long, like quite detailed and specific, was really answering the question, what does the world look like in two years if we're successful at what we're trying to build? And that vision statement sort of forms the foundation for setting company goals. And we would have a set of company goals that were intended to be pretty comprehensive, right? That would say, and answer the question, how do we know if we have reached our vision, right? How do we know if we've made it all the way? And the company goals, it's good to have quantifiable, measurable goals, right? So you can kind of measure it and make sure that you know you're actually making progress towards it. But that framework overall, sort of the vision and goals framework that we used served as the framework that we wanted our product teams to operate in. So if you have that set up, then you can say to your product teams, okay, figure out the sub-metrics that you're gonna track, the sub-goals that you're gonna set that ladder up to the company goals and then track your progress on that. So sort of keep your creativity and innovation, but do it in the spirit and in the direction of what we're trying to accomplish as a company. So I think that's generally like a pretty good framework. It worked relatively well for us. So I think you do something similar at world. Yeah, I think out of like the high-level metric show, kind of like KPS for the company, we do this kind of semi-OKR-style vision and measurable goal, very kind of measurable, very impactful, very high-level on purpose because we wanna keep the kind of ownership of the teams as high as possible. And I think there's a beautiful combination there where you have really high-level goals that leave a lot of room for a kind of actual problem-solving as you mentioned, kind of that the teams can really do and use their creativity and whatever tools they want to to actually solve those problems. So we have about five or six different company-level metrics that retain to the best parts of the business that we want to kind of focus on, be it growth or customer experience or the satisfaction of our couriers and then balancing from that out the teams themselves and find their own way. I think there's a beauty in it and it kind of supports the same empowerment model for the teams where the kind of ownership of the teams is still in the center with the right direction going forward. Maybe kind of like to get it a bit more concrete. What would you say would be the kind of the most successful kind of company-wide metrics that you set and why were they kind of like good for this sort of, especially on the context of engineering? Yeah, I mean we went through tons of iterations on this, right? Like it takes several reps, iteration, years of planning to start getting the right goals into place and the right goal frameworks into place. But to give a couple examples, I give one from Facebook. This is a long time ago. But one of the goals that we were tracking was monthly active users, right? Like at the time we were trying to get everybody in the world to become a user of that platform. That was a very quantifiable goal. It's fairly easy to forecast. It's fairly easy to set a goal against, you know, that's higher than the forecast and to measure your progress towards getting there, right? So that was a pretty effective goal in terms of driving behavior. At Airbnb we had goals around number of nights booked, right? Like how many nights are we booking? That's what drives the top line of their business. And that was also a pretty quantifiable measure. But we also tracked other things. And I actually think this gets to a point that's pretty important on goal setting, which is to make sure it's comprehensive of your overall customer experience that you're trying to deliver. So another goal that we tracked at Airbnb for a number of years was around the quality of the customer care that we were delivering for people who were actually out there traveling in the world. And that's not really like a top line business driver goal, but it is a customer experience goal, like how do you want your entire customer journey to feel for people who are using your product? And so, you know, company goals are powerful. They really do drive behavior. So it's great to have them set at the company level, but you have to make sure they're balanced. It's not just about driving your top line. It's about that sort of end-to-end experience that you want to give. Yeah, and I completely agree. And I think there is also an element of sometimes the goals themselves don't have to be, like, for example, doubling the business growth. Sometimes they might be a bit more kind of like an understandable and kind of platform-specific goal when it relates to reliability, for example, of a service in a high-optimistic industry such as Vault, we're running one of them, which is just the kind of availability of the service because when you're scaling super fast, it's actually super hard to actually keep up that platform as may have been evident from these awesome scalability challenges at Vault as well. So maybe going kind of a little bit back to the kind of dependency-free teams, what do you think about the kind of the key practicalities of the contribution model in this sort of present? If you have an end-to-end team that has all the competences needed, but when you're at company scales, we have like 40 teams, there's going to be dependencies across these teams. What sort of kind of mechanisms should do kind of engineering use, or what do you think in your experience of work best in creating the impact in this sort of stage? Yeah, I think it is very reasonable to recognize that there are going to be some dependencies across product teams, right? Of course, if there were no dependencies, you might as well separate out into separate companies. One of the things that we tried to do was build a culture of engineers feeling empowered to contribute in any part of the code base. So we felt like, if we fired you as an engineer, you're a talented, capable person working on this stuff, we want you to feel empowered to be able to work in code that's in your immediate team but also outside of your immediate team. And the thinking behind that was, this doesn't solve all dependencies, but the thinking was, if you have a dependency on another team and you can't get on their roadmap to satisfy the dependency, which many of us have probably experienced, one way that you can unblock yourself as an engineer is to actually reach out into that team's code base, propose a change to the code and unblock yourself, like get that dependency out of the way yourself. And what formed for us was kind of an etiquette around this, which was, if you're going to go make changes in another team's code base, make sure to get, it's like a peer review from somebody who's on that team before it merges and goes to production. A very simple etiquette, but I thought it was a pretty powerful statement and sort of a statement of ownership as well for the engineers to say, like, don't limit yourself just to the code within your team, like feel free to work in any part of the stack where you need changes to get made. I think that makes sense if you're thinking about empowered teams and empowered engineers, there are no other people's problems. There are just problems to be solved if you have the capability to solve them. So now that we've kind of gone through a kind of cultural mode of how we figure this team should be operating on and how they should be scaling and a little bit about the goal of the direction they're going towards. But maybe kind of going to the actual scaling a little bit deeper, so it's a very competed market right now for engineering. I think a lot of trouble for, for example, for growth companies is just simply attracting the right talent or getting the right talent at the speeds that they need to get. So your experience in Silicon Valley is probably like the most competed place on this planet to actually find engineers. And you managed to recruit over a thousand of them, for example, for Airbnb. What would you say is the secret sauce behind this? Yeah. Well, recruiting is so fun. I love that part of the job. You know, maybe like the first thing I want to say is the talent that you are able to attract to your company will have a material impact on how successful your company can become. Maybe that sounds obvious, but if you internalize that a little bit and think about how much time am I spending on recruiting, you might ask yourself, is it enough? So part of it, I think, you know, and we did this was really just hours spent, like time spent just working the problem, getting candidates in and ultimately closing them to join us. But one strategy that we took that I thought really worked was we tried to, in general, build a culture of recruiting at the company. And part of that was ensuring that every engineer felt like recruiting was part of their job. And in fact, I would meet with all the new hire engineers as they were going through their onboarding process. And this is one of the things I told them when they joined the company. Like, you're here, we're excited, you're gonna write a lot of great code, but recruiting is also part of your job. And one way that you can get involved in the recruiting process is by going through interviewer training and becoming an interviewer. And this actually really worked. We had, you know, I think 90 plus percent of our engineers, like only some exceptional cases didn't do interviews, almost everybody was interviewing. And it's really powerful for a couple of reasons. One is because it distributes the interview load across your team. So you don't end up with like a small fraction of your team just interviewing all the time, which nobody wanted a software engineering to do that. But it also, I think it creates this sort of feeling of ownership that I'm here, I'm at this company now, and they trust me to help bring more people into the company. So that was one thing we really focused on. I feel like, you know, share your thoughts on this as well. We'll go back and forth. I've got a bunch of thoughts I'm recruiting. Likewise, likewise. I think back in the day when we closed our, I think it was Series B and we started kind of like scaling quite fast as well. One of the big things I was talking with Mickey, we'll see you at that point, and he was like, your job for the next four years is going to be recruiting. And that was the kind of very brutal honesty of it. And it's true, after about over a thousand interviews, I can say that it's true. I think there's a couple of things that we've found at least involved, and I think it's probably pretty universal, is that the initial technical team you have, and the first like 20 people you have are really crucial for the rest of your scaling. You mentioned the fact that kind of like this kind of talent also attracts other talent and this kind of ability and this kind of flywheel of that. But those early people are the people who define your engineering culture as well and the people you have. So having the right people in the beginning and having them involved then as you scale in the engineering, in the recruitment has been very, very essential. I may be one other thing I would mention from our perspective is that kind of like putting recruitment really close to the business itself. Like recruitment from the beginning for tech reported to me at Walt. So we basically built it with my lead tech recruiter. We built this approach on how we do recruiting and every leader, every engineer in the company. Super close to that and shares the same goals and shares the same kind of passion around recruiting. I think you did something similar at Airbnb as well. Yeah, I mean we tried to make recruiting part of every engineer's job, like I mentioned. But especially we tried to build the connection between our engineering management team and the recruiting team. And you know, engineering managers have an even more elevated role in the recruiting process. They need to be deeply involved in this. They need to be really close to the recruiting team. And we actually had a lot of fun with it. Like we really worked to build a bond between those two groups. And we actually held a weekly meeting the entire time I was there that we would bring every engineering manager and the entire tech recruiting team together into a forum. And you know, we do the normal things you'd expect. We'd look at our metrics and you know, other things like that. But the most fun thing that we did was we would go name by name. Every single person we were trying to recruit or was in the process with us at that time. And that was an opportunity for recruiters to say, hey, we're trying to engage this person or we're trying to close this person. Can we get an engineering manager to reach out to them and like form a connection with them and help drive this process? And it was amazing. Like the sense of team that was formed in there, a lot of times the engineering managers who would raise their hand and say like, yeah, I can talk to that person or I can manage this situation. It wasn't even for an engineer that would end up on their team. It was just about having that sort of shared spirit of winning. Like we really wanted to win candidates. We really wanted to win against our competition. And because we went name by name with all these people, like you kind of got to know all the names of all the candidates who were coming in. And so when somebody was accepting an offer, like we would all celebrate together. It was like, it was super fun. And when somebody was considering us versus another company, like, we would totally trash talk that company and talk about how we were way better. It was kind of this energy, like to build a competitive spirit to win, hopefully a healthy competitive spirit to win in that team. And I think it really drove a lot of our success. We did manage to hit our engineering recruiting targets for the entire six years I was there. That is impressive. Being behind engineering recruitment targets right now, myself, I would love to get some of that energy going on. I think you touched upon this earlier when we were discussing that kind of, you also went a bit beyond the kind of typical things of just kind of pairing up with recruitment and building this kind of common team and ownership as we've been talking in the teams, working at the same ownership with recruiters. But you also mentioned this wonderful term called unfair advantage. And I think you had a couple of really good ones at their B&B. Yeah, I absolutely think it's so competitive for talent out there. You have to find ways to build unfair advantages for yourself to win in the talent market. And there's a bunch of ways you can do this, but one of the ways that we did it was, at least for the first 300 or so engineers that we hired, every single one of them interviewed with one of the founders of the company. Like think about how powerful that is. It doesn't matter how senior you are, what fancy title you're going after. It's like every single one of those engineers had an opportunity to connect with a founder and have that be part of their assessment and joining the company. Incredibly powerful. I'm another thing that we did and I was a little bit of a lunatic about this, but we really wanted to be the fastest. We wanted to have the fastest experience, like getting through your interviews and getting hired. And the reason for that is because recruiting is really a momentum thing. You build momentum with a candidate and you wanna like, when you have that moment of momentum is when you really wanna put the offer in their hand. And so we got to a point where after a full round of interviews, like one day of interviews, we could collect the feedback, we could hold the roundup, we could make a hiring decision, we could get an offer approved by finance and we could put that offer in a candidate's hand either the same day or the day following their interview. And that momentum, super powerful and helps you get candidates closed. Be the fastest. That's amazing. In an industry where the average is like 35 days going to one day for time to hire, that is grand. All right, this has been a lot of fun. I think we are out of time at this point. Thank you very much, Mike. Thanks for having us.