Building Up Great Engineering Leaders with Greylock's EIR Wade Chambers | Greymatter

Hi, everyone, my name is Josh McFarland and welcome to Gray Matter. At Greylock, we're always looking to learn from practitioners about how to solve real problems for startups. And we started bringing these practitioners into Grey Matter so that others can learn as well. In this episode, we feature Wade Chambers. Now, you've probably heard him on previous episodes sharing lessons about how to hire 10x engineers or increasing your team's capacity to win. And so I would like to welcome, for the first time in history, Wade, to come back for the third podcast. The first two of which I will point out, were among the most listened to that we've ever done. So welcome, Wade.

Super excited to be here and thanks for inviting me. This is kind of a cool medium, right? If you're the average of the five people you spend the most time with, how many chances do you get to spend time with Reid Hoffman or others? And the fact that it can be sort of captured and played back at your leisure just elevates your level of thinking. So thanks for having me here.

And let me just say this, if you stay to the end of this podcast, I promise you an Easter egg about Wade that is not to be missed. It's funny you say that. I actually have to say it's a privilege. It's an honor to be able to get to spend more time with you now that you've joined Greylock as an executive in residence. And I think about you and the podcast that we're about to do. And I think about the reason that I chose Greylock as an entrepreneur and, and now as an investor. So I thought that I would start with just the story of how we met and then ask you to chime in with your half. But I remember this is several years ago and at Telepart, we were going through an intense scale up period. I think we were only about 14 or 15 engineers at the time, but we were on path to almost triple revenue to about $50 million. Right. So we were starting to come apart at the seams a little bit in terms of the. Some of the systems and processes that we had built. And so we started a search for Vice President of Engineering, which is probably the toughest executive search that you can do in Silicon Valley. We hired a great executive search firm and I remember reviewing the candidates on a weekly basis on the calls, and I just wasn't finding the person that I was looking for. We had seen some great executives, no doubt, but I think what we were looking for is a really unique blend of characteristics. And so I reached out to a few friends. And these are people that were running their own companies, whose opinions I deeply valued as people that had been able to hire great executives. And two of my friends came back with the same name, your name. And so I reached out to you on a whim and I said, hey, we have these friends in common. Would you love to grab coffee? And you said, sure. Like, come on down to Saratoga on the weekend, right? So we met on a Sunday, and I remember we were in a Starbucks. And first thing you said as you sat down, it was, I apologize if I smell like smoke because I have been smoking these ribs on my smoker. And by the way, here's the Android app that I built to manage the PID controllers that manage the heat and the airflow in my smoker. And right away I knew that you had this intellectual curiosity, which you actually reference in your podcast about hiring 10x engineers. And for me, that was a really important characteristic because I think the amount of intellectual curiosity that it takes to achieve and continue to achieve as you rise in the ranks was something that drew me to you as an executive. And so I remember leaving that meeting feeling really energized that I had found the first candidate that hit both of the vectors of optimization in this search for me. And one was proven ability to scale, because at the time you were a Section 16 officer of a public company running hundreds of engineers across 10 offices around the globe. But that you also had the ability to be really close to the metal in the manufacturing sense. You know, you're not just the big boss at corporate. You can be actually down there on the line with the individual contributing engineers relating to and understanding what they're talking about on a day to day basis. It took me another six months to convince you to join, but you were always our top candidate as judged by those two important vectors. When we finally made the magic work, I remember you came in and I'd love to get your side of the story. Tell me about the whiteboards.

I will say that those conversations also helped me understand that this is someone I would want to work with. I got a sense of through talking to you, that you sweated the details, the type of people that you wanted to have on your team, how much you cared about the business, the customers who you wanted to surround yourself with. You had me come up to Burlingame to talk through details and challenges of the business. And I remember that one evening we were talking about, and I think that you were trying to figure out is like, just how deep can you Go. How involved would you be? Et cetera? And I remember that we had to walk out of one of those conference rooms and walk to kind of. It was an open, aired space, so we had to go to one of those edges to go to the whiteboard. And as we drew out the different swim lanes and the various stages that you would go through, and we talked about the details of how that could work in a very low friction way, it was obvious that we needed whiteboards that were a little bit more mobile. Now you've went through all of this time to actually build out an office that looked just amazing for the talent that was there. You didn't want just a whiteboard that sort of leaned up against the desk. You'd want something that moved around and sort of looked like it belonged. We could put together something that was just on wood, but would look appropriate for the space, but would be very mobile. And if we had standups, we could roll it there and be able to jump on it real quick. And if we needed to drag it into a meeting, it would be able to move close. So I talked to somebody who had done a lot of work at the office for us. I'm like, look, I only have a couple of requirements for this one. The whiteboards have to be magnetic, and then it needs to look appropriate for the space. That was it. And then when they rolled in, they were like six by six wood planks that had been burnt. So they looked rustic, and yet they looked very cool. And it was just like, wow, that's impressive. But I realized at that point in time, I totally messed up because I didn't actually dig down into what's the cost of this going to be. It's an awkward conversation to have with your CEO within your first, you know, few weeks of having whiteboards show up that are way too expensive. So, yeah, a lot of embarrassment. But looking back, if there was an earthquake, I was going under one of those things.

I remember when these things rolled off the semi truck, and I was just like, oh, my God. Like, one, like, those are incredible. And two is like, what is Wade thinking? And you can see pictures of these whiteboards online in the blog post where I introduce Wade as an executive in residence. Let me rewind the clock a little bit and talk about how you got to where you are. Tell me about some of the failures that you experienced along the way and what you learned from those that. That helped you become the incredible executive that you are now.

I think my career started like a lot of other people's that get into engineering management started out as an individual contributor working on a variety of different things. And it felt like I constantly needed to be learning that next new technology. I went from being a UI engineer to a server engineer, to a middleware engineer, to developing server frameworks to lots of other things. And it felt like every new role that I stepped into, I increasingly took on more of a leadership role inside of it. Being the tech lead and then being a staff level Engineer. The first 10 years sort of went through that typical pace of, oh, I need to learn X, learn X and become a better engineer. And then I was at a company, Verity, here in the Valley, and way back in 1994, feels like a long time ago now. I was sort of the tech lead of a project that really was the underpinning of how Verity worked as a company, that next generation of it. And I was approached to do you want to be a manager? That feels like the right next step for my career. Right. I've been always at the front of a team. I should do this. Fast forward three months. I failed miserably. Why? Because I kept doing the same things I was doing as a tech lead. But now I had people reporting to me and so I would talk about what the design should be and how I thought we should separate responsibilities in the code and all of the things that you would do to make sure that you're building good software in the right way. And I was leaving no oxygen in the room for people who were extremely talented to be able to take on more ownership and move up in their own career after three months. The great part is I had one senior engineer who took me aside and said, what are you doing? I'm like, what do you mean? I'm doing things I've always done. And he's like, do you know how many times you talk about you and what you want to do and how things should be done? I don't think we've ever had a conversation of what I should be doing and what I want to do. And I realized I was just failing miserably as an engineering manager and so went back to being an engineer and then left the company a few months later because I could never sort of recover from that in my own mind. Now. Lots happened between now and then, but what it helped create is a very visceral pain point for me of I failed. I didn't do this. Right. There's something I don't understand about this role. And I think that if you fast forward with the gift of hindsight, you Know that the two reasons people normally go into management are, well, I've had previous success in a non managerial role and therefore I should become a manager because that feels like career progression. Or number two, I've had so much experience at this company and I have so much tenure that this feels like of course I know so much about the company, I should be a manager. If you think about both of those things, it's about individual accomplishment and technical competencies more than it has to do with how do you improve the capacity to win and actually win in an organization. And so key learning. There is. It's a different role. It's not an extension of being an individual contributor and taking on reporting responsibility for people. It is. You have to think about the role differently.

So tell me about what was it about teleport or maybe our culture that you saw some of the aspects that you could come in and you felt that you could add to and amplify.

I think it was really cool to be able to walk into a company where that was a set of conscious conversations that you and I had. And so we had some shared battle scars in getting to what that was. And they became very deliberate acts that we put in place. As an example, we talked about incrementality all of the time, right. What it meant for our customers and why that was important to us. And it wasn't these hollow words. We actually put a business model in place that helped make sure that was the case. We would do things based on a rev share basis. So if our customers weren't making more money, we weren't making more money. And so we lived or died based on incrementality. And we would talk about it and how we needed to have love in, not lock in because we're generating so much value for our customers. It introduced all of these subtleties into the business as well. Egos tended to fade away. It wasn't about what was the right design. It was did it improve incrementality. We would have a B testing, we'd constantly experiment. And it was always put through the lens of the does it drive further incrementality? Engineers knew how to think, which is one of the key parts of scaling, right, is that you want decisions to be made at the lowest level that you think are completely in alignment with the business and a decision that you as a CEO might have made. And so how do you create the conditions where that continuously happens? This was a key part of it and I think done really well. Ownership and responsibility was a key thing that we we put in place, and a lot of people talk about ownership and responsibility. So we had to go one step further, and as we're going through interviews, talk about what that meant. As an example, we talked about not having QA or OPS people at Telepart. And it's not that we didn't believe in those disciplines. Right. There are extremely talented people in each one of those areas. But we were trying to solve a problem very early in the company's existence of making sure that engineers didn't push the responsibility of that downstream. And so guess what? If something breaks, you're going to get paged, you're going to get woken up in the middle of the night, and you're going to have to go fix it. You don't like that. Let's actually make sure that we're taking the cost out of the business and taking all of those issues out of the software so that you don't have to. Well, when that happens, you're going to feel more ownership and you're going to feel very accountable for the results. So it facilitated some really good conversations of where we're at right now and what should we be focused on. It also got us to the point where we talked about how infrastructure was preventing us from moving faster, as well as improving the stability of the system. And we would invest in significant projects that would help move that forward. But we always use the cost and the incrementality that it created as a yardstick of what we should or should not be focusing on. Everybody felt responsible for getting to a better answer that drove the business forward. A great example of that is how we managed cost. We were trying to actually grow revenue, and there was a focus on growth. And so we put a very early metric in place that we wanted infrastructure cost to be a percentage of revenue. And as long as it was below that percentage point, there was nothing that we needed to do. So create incrementality, grow the business, and we're all good. But when it went over that, we knew that we needed to do something to actually claw cost back out of the business. And so we had a cadence of measuring that, talking about it every month, predicting what the cost was going to be the month ahead of us, and then reviewing what the cost was the month behind. And it created a very lightweight process that allowed us to say, cost is important, but we know when we're actually going to go work on it.

So many things waterfall from our decision around the business model. It's like when you get paid a percentage of the revenue that you drive your own cost model becomes a derivative of the revenue that you drive.

Right.

Whether it's infrastructure costs or AWS bills or our headcount plans, it's not like we ever managed to a fixed budget because for us, it was all about managing, growing, and we knew what our primary growth metric was, and we knew how we could affect that. And so you knew that if you grew revenue by 20% ahead of plan, you were free to hire 20% ahead of plan.

Exactly right.

What are the key characteristics that you can draw out of your own path and those that you've seen of your peer group that you really think would be lessons that you could impart to somebody that would like to achieve what you have someday?

Obviously, public companies versus startup companies have very different needs in the role. Some of the public companies have already found product market fit, they've established markets and the product for those markets. So a lot of it is about managing cost or bringing back innovation into the business or managing customers. With startups, you have a very different set of challenges of where you're somewhere in that S curve of trying to build product that's significantly better at solving a known problem than the current way. And you have to figure out how to get it into market. And those are competing in many different ways. And I think that as a result, some of the things that you do as an engineering leader in those companies significantly differs from a public large company. As we were talking about, like, how do you create that culture of allowing people to make decisions that felt like the decision you would have made? Or even better, creating clarity and constantly reestablishing clarity from the point of view of what matters and differentiates your products and what helps us capture the market. And what have we learned that needs to be a constant investment? And so I look for that in an engineering leader of do they constantly create that clarity that's required? Oftentimes a byproduct of that is that they have to lead through change. And so you have to be aligned with the business and where you want to be, and then constantly keeping your organization nimble and not letting it become brittle and resisting change, but actually inviting change and understanding why we're going through that change and how they can participate in that. And I think that engineering leaders have to be very adept at helping to usher change in and helping it get to where it needs to be. The role of an engineering leader needs to be constantly refocusing on what you should be doing, because there's a lot of, well, there was natural progression of a project in one quarter and it kind of spills over into the next quarter. Is that the right thing to be doing? An engineering leader needs to be able to point back to what's the business that you're in, how has the market changed? How are your customers changing? What's your competition doing? And maybe putting a stop to some of those things and actually focusing on what you should be doing and managing through that cognitive friction.

I think you classically refer to this as gtrsd, Getting the right shit done. Right.

The real question is how do you pull together all of the assets that you've got to win and then increase your capacity to win? It's the focus, the prioritization, making sure that you're focusing on what you should be doing instead of what you could be doing. It's the driving the outcomes. People say, oh, that's what you should be doing. Awesome. Everybody understands that and you back off. No, you have to lean in. That's the most important thing that you can be doing. It should feel that way to the organization as well. There should be follow up, there should be risk assessment. How are we going to work through that? Are we connecting the right people? Are we talking about the project at the right level of depth? Have we identified all of the key risks associated with projects? What are the key things, theses behind what we're doing? How can we test those as quickly as possible? Does it need to be a technical implementation or can we go do a paper prototype and go talk to our customers? Driving projects forward becomes really key. Part of that is making decisions. Decisions have to be made and you don't always have clear information. I love the old Barksdale quote of if we've got data, let's go with data. Otherwise if we're going with opinion, let's go with mine. Well, you were very good at that. I think that's a key part of the business, right, Is that you have to directionally make calls without precise data and be willing to say we were wrong, back up and go a different direction. But the whole point is the urgency is there with the team to actually go find out the answer. A different discipline which takes your skills in a very different direction is applying judgment. A lot of times, especially when you're early in your career on the engineering management side, you're working with a strong product manager who is going out and talking to customers and brings you back the list. Here's the set of things that you should be doing. Here's the prioritization and you're like, thanks, let me actually go work on this without actually questioning, are these the right things? Not from the obstructionist point of view, but from making sure that you understand what's truly important in this and how can I faithfully act on this? Because there might be an implementation that is 20% of the cost, but gives you 80% of the benefit. And you want to make sure that you're optimizing for where the business is at. And so two key skills that sort of fit into that, first principles thinking and critical reasoning skills, factor into that. On the first principles side, I think Elon Musk does a really good job of talking about this and has been well documented what are we sure is true and then reasoning up from that, to use Elon's words. And you constantly have to be thinking about what am I trying to accomplish, why am I trying to accomplish that? What's the fundamental problem that's associated with this and what matters most in the solution and to who does it matter? And if you can work through that, your results increase super linear. You just make better decisions over time and for the right reasons. And then you can engage in constructive debate where there's back pressure between the different disciplines of where you can have really meaningful contextual conversations about what's better for the business. Critical reasoning skills, again, a key part of that, you constantly have to be focusing on how do I improve my ability to add value to the conversation and improve the products that we're building. As a side effect, it feels to.

Me like these things all work in conjunction. So if you are the type of person who brings intellectual curiosity, right? You are also the type of person that relishes a first principles understanding of what's going on. And then you apply your own critical thinking against it. Because understanding the root of what is needed and where you're trying to go, what the objective function is, is the key key to doing something you've never done before. And so I think about all of the people that we hired, I think about your own background. You had zero knowledge of the customer data space, the ad tech space, these massively parallelized high throughput systems doing hundreds of thousands of queries per second was new to a lot of the engineers that we hired. And yet because they all came with the same characteristic of first principles thinking, of critical thinking, of being able to be reasoned, doing the right things in the right order, we were able to build a very tightly woven fabric that drove us to success. And I remember one of the things I appreciated about you is your ability to Wind down projects before their completion. Which I think goes to your point about getting the right shit done. Because getting shit done is not the point.

I would say that I think that walking in, you helped set up a lot of that. And I really think that the CEO setting it up correctly of where you're going to have honest conversations and not dodge difficult tasks creates the right mechanism, the right fabric. I always felt we were having conversations about what drove the business forward, and as a result it made it very easy to go execute on those things. There's a couple other things that I think are really important for engineering leadership. We've talked about getting the right shit done. We've talked about improving your ability to apply judgment. There's two other areas that I think are critical. One is building teams and organizations. And the last one is the ability to coach on the building teams and organizations. You have to be part technologist, part anthropologist, part psychologist, but you have to put the right group of people and make them efficient. You have to be constantly focusing on how do I improve productivity. Some of the time it's process that gets in the way. Some of the time it's that you have too many people that are the same and you need diversity put into the team. You have too many people who are focused on overall quality and nobody who's focused on how do we change and how do we innovate. And so figuring out how to play chess with the teams instead of checkers, you're going to look at different skill sets and different people and different personality types and try and put together the right combination that actually improves the velocity of the team. And that's the key point. You constantly have to be looking at what improves the productivity of the team and helps create the impact for the business that you want. One of the key things that we looked for as we went through the interview process is that we wanted to hire amazing people and we didn't want to settle. And I think part of that is that applied intelligence piece. They had to have some sort of valuable strength. And it didn't necessarily have to be a strength that we could use immediately. It had to be repeated ability to create strengths in previous roles that we knew would translate into what we were doing at Telepart. And then we looked for people that were high potential, that had that motivation, that curiosity, that insight, that level of engagement and determination that they just were not going to accept obstacles prevented them from being successful. And last but definitely not least, in that we look for people who are a cultural fitness, not assholes. They were very much interested in aligning with what we were doing, how we were doing it, why we were doing it. They valued the team over the individual. They valued accomplishment over just activity. And I really think that sort of held everything together. And then going on to the coaching side of that, where one is, how do people work together? The other one is like, how do I unlock very specific things in an individual? And that requires you to be able to understand them as a human, understand where they're going and why they want to be there, and be able to help coach them through that process. And it really gets to the point of a lot of engineers are not comfortable giving critical feedback to peers. And definitely when you get to the point where you have people on your team, it's very hard to tell somebody that they are not as good as as they need to be in some specific area. And so I think that's where concepts like radical candor come into place. You care personally and deeply, but you challenge directly. And I think that you have to become good at that as an engineering leader, that you have to be comfortable at causally creating peak performance in each and every individual team member. And some of the time they may hit their peak at where they're at or the company changes. And you have to help them move on to their next role inside of the company or outside of their company, and bring in the next person that you can help. But I think that you should be able to say for each and every team member that you've got, that you know their strengths and weaknesses and it's universally understood by you and them where you think they're at, where they think they're at, and where any disconnect might be there, as well as get feedback from peers, colleagues, their management chain that just sort of takes all of the FUD around it and helps create clarity so that they understand where they're at and where they would need to be. And then it's your responsibility to help them get to that sort of conversational or declarative knowledge about that skill that they need to build. You need to provide opportunities that allow them to go and try and practice that. And it needs to be something that's in alignment with, needs to be done right. How do you coach people to higher levels of performance? A players want to grow. They want to constantly feel like they're being invested in. And if you create that culture of investing in people, if they wanted to leave, they're going to have to go find some other place that would have that same level of investment in them. And I think that engineering leaders have to understand each one of those four areas and become fairly good in each one of those areas to truly be world class.

This has been awesome. Reminds me of just why I love spending time with you and how excited I am that you've joined us as an executive in residence again. I feel like I've gotten an inside look of what it was like for you as a human being to go from startup to scale up, to go from individual contributor to senior vice president of engineering, to go from I to to we in how you think about the world and your teams. And so that's been awesome. What I would say to the founders out there who are looking for your own vice president of engineering one is I remember how hard the search was. It took a long time. And I would say don't give up. Like find your Wade, because when you do, you will find somebody who unlocks so much capacity within your organization. Look for someone who is both proven at scale and still close to the metal, and look for somebody who can amplify your culture. And on that last topic, for those of you who've chosen to stay to the very end, I have a little Easter egg for you. I want you to go to Twitter and I want you to search Wade's username, wadechambers, and the phrase out of this world. That's what I mean by amplifying culture. So with that, Wade, thank you again and thank you to all of our audience and hope to talk again soon on the podcast.

Thanks for the invite, enjoyed being here, and feel free to ignore that Easter egg comment.