Building Engineering Excellence with Bruce Wang, Netflix

This episode is brought to you by Boast AI. Each year, the US And Canadian governments give out billions of dollars in R and D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. Boast AI gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging boast AI software to maximize cashback. Check out www.boast AI.

If you're going to go do anything or implement anything and even that idea, you have the idea, oh, it didn't work. I'll move on. Okay, are you sure? Did you go that one level deeper? Oh, I read this blog. Let's implement. Who cares? Are you sure? Did you read one level deep? I would say just maybe go one step further and really try to understand, like, what is happening here. What is the mechanism that's actually working? And I think that could help you really understand both what is really truly product, market fit or your customers want or do whatever. Is that maybe just that one extra step? Take that one extra step. And I found that when I take that one extra step to just like learn a little bit more about something or someone tells me and I'm like, let me just take the extra step to look it up and then ask you a better question. Right? Or you asked me to do something and take that one extra step and do a little more research than I actually should even ask me just has served me really well. I need some traction. You need some traction.

Hey, what's up, innovators, entrepreneurs, visionaries and disruptors. This is your Traction podcast host, Lloyd Lobo. We're a community of over 100,000 people just like yourself on a mission to help you get the methods, the money and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more.

I need some traction. You need some traction.

Hey, Traction fam. Another exciting episode today we have with us Bruce Wayne, who's been in and around the tech space and leading engineering teams from grassroots to greatness. Currently engineering director at Netflix, leading the product systems. And I got to know Bruce through a close friend of mine, Quang, CEO of plato, which is one of the largest communities for engineering leaders and engineers who want to level up to engineering leaders. And Bruce is the top mentor on that platform. And we had a great conversation, we hit it off and I'm like man, you know so much about the engineering space, about just building engineering teams, about leveling up engineers. I think our community would love to soak in some of that knowledge. And Bruce is not only an engineering leader, but he's a two time founder. So he understands the founder perspective, the founder mindset. So Bruce, super excited to have you here. Welcome to Traction. How you doing?

Oh, great. You know, also I like to tell I did one success, one failure. The failure was important.

As they say, you don't fail. You're either learning or you're killing it. You're either learning or you're winning. One of the two, right?

Yeah, yeah, yeah.

I think failures are super important because you learn to appreciate the wins along the way. I think I had two or three failures before both started to do really well. You really shouldn't appreciate it. I feel like the people I know that have been winning, they don't appreciate the failures. But the journey is you definitely fail at one or two things almost like every month. Especially when you're an entrepreneur. Like something doesn't work out. That's the reality of life. So before we get into your top lessons as an engineering leader and leveling up engineering teams, give us your backstory, man. Where did you grow up? How did you get into engineering and Silicon Valley and startups and.

Yeah, so I was born in China, but I moved here when I was six. So I came from mainland China from like Beijing. You know, it was really rare. I came in the 80s, so like pretty rare to have like someone coming in from mainland. I grew up Midwest, mainly in Michigan. And I don't know, I just got into computer super early on, was on the bulletin boards and was into building my own computers and we were on like super slow 14, 4K modems and always wanted to get some super fast. So I just was really early on in that industry. And then yeah, I went to Michigan. Go blue and then. And I went to engineering school there and it was during a hot time, during dot com boom. So I was really interesting experience interviewing and then got an opportunity to come out to Silicon Valley to work for a startup. And that's where I've been for almost my whole time except three years in Kansas due to one of the acquisitions, but mainly in the bay area for 20 now. 20, 20. 21 out of my 24 years.

Fantastic. And I, I think being an immigrant or born to immigrant parents probably had something to do with you getting into engineering. At least mine did.

It's funny for sure. Definitely. Math was a big deal for my family, but I don't. I think engineering was so new then, like, it wasn't a thing. Like today I feel like everyone's, oh, cse, it's the big thing. Then I think it was like, it's cool, it's interesting, it's math based, it's engineering based. So I think they were fine with it. My parents were pretty great. I don't think they put so much pressure on me. They put plenty. And I think I was lucky to go after something I actually really liked and end up being okay at it. And I just worked out that way.

Fantastic. Now, you did two startups before you became an engineering leader at Netflix. What were your top lessons as a founder that helped you succeed at Netflix? You've seen number of promotions at Netflix, leading the product systems team. Tell us more about that. Right.

Tonic platform systems, just so we're clear. But yeah, so just so you know, I've pretty much only worked at startups, right? And yeah, I did, I found it too. But then mostly I just been in startups and when I say startups, mainly like under 200, 300 people, right. So pretty like similar kind of experiences. Until I got to Netflix, one of the acquisitions, we, we were brought in by a bigger company. And so that I have two big company experiences. I really think about three things. One is adaptability in dealing with change, right. I think you talked about it. There's always ups and downs with the startup. And you know, Netflix, I've been here four years now and we've had some ups and downs in those four years, right. And I think just my ability to deal with that and be okay with the change and the chaos, I think people think, oh, you go to a big company, you get stability, right? But you've seen the industry has had quite a bit of changes. And so I think that adaptability, dealing with change at a startup is pretty helpful. Another is reduced sense of fear. I don't, I don't know how to put it, but I have a pretty high risk tolerance. And I think at Netflix you have to be okay to be fired to do well at your job. At least that's my kind of theory is you just have to be willing to make those bets and you're going to get feedback and you're going to struggle and you're going to have to be okay with it. Right. And I think really that fearlessness, I don't wanna say it's fearlessness, but like just less fear and higher risk tolerance. And then the last is I Actually built up some pretty good networking skills. Mostly worked for B2B companies. Before startups, I had to do like sales calls, pre sales calls. When I took over a team at a start a larger startup, I had to go to user groups and conferences and meet people. And that networking skill actually helps immensely inside a company, like being able to connect with people, reach out to people, partnering and getting to know them has been really helpful for me. And so I think those kind of lessons as startup founder and also just being in a startup and working in these different environments has really helped me there.

Definitely. Now what are some concrete examples where you can say this reduced sense of fear or higher risk tolerance? Right. What are some things you dealt with that prepared you for this?

So I worked at a startup called marimba for four years, right. 2000 to 2004. And you know, I always wanted to do a startup. So it was like, hey, I want to do a startup. But it, dude, I. We couldn't raise money. We didn't know what we were doing. I had to just be like, oh my gosh, I'm just gonna deal with this financial situation for like two years. And I never thought it was going to take that long to raise money. And then we had a lot of ups and downs. We're trying to land our first customer that almost didn't work out. And then even as you got more traction, it just felt like there was always problems and fears. And I think for me it was just like dealing with all the paint I think just gave me a stronger sense of like, hey, it's okay. And I think when you're at a bigger company and you're, you're making pretty good money, it's not as risky as you would think that compared to was a startup. And I think that really helped me not be afraid to fail and learn. Like for instance, I got thrown in to be a manager. It was terrible manager, by the way, first time. And it was just like, hey, you had to do the job, right? There was no one else to do it. I had to lead a team, small team, grow the team. I didn't know what I was doing at all, right. And I just leaned into it and figured it out over time. Right. Pre sales called, post sales call. I never done that before. But you know what, we're a startup. I was like acting cfo. I don't know why, but like, yeah, it's cause I took a couple accounting classes and I had to do it. So there's like all these things. I think as a startup Founder and in startup leader, you just sort of have to like, do everything and be okay with it. And we also didn't know what we were building the first original business. We had to pivot a few times. So I think that's the other thing is you realize, oh, it's not what you think it is, and it's okay, move on and deal with it.

That's the thing, right? There's a lot of risk in doing startups especially. You're dealing with unknown, ambiguous situations. It never plans out or pans out like you're planning it out on a spreadsheet. And everything great is on the other side of pain and risk. I often say, like, luck and risk are two sides of the same coin because a lot of people say, oh, you got lucky here, you got lucky there. I'm like, yeah, of course I got lucky. I've always used the word luck. But luck and risk are two sides of the same coin. The ones that do well are the ones that keep flipping. They never stop. Risk. Now, from a networking skills side, right, as an engineer, we're typically introverted. I certainly was. I wasn't a very outgoing person and I had to work a lot on improving my social skills and networking skills. And especially as we were building our startup, building boast AI and I had to go out there and meet people, get customers, evangelize the company. How did you develop these skills? And it must have been daunting to start with, right?

I think we're similar. I think we're all closet introverts, right? I think I, I seem pretty boisterous for people who meet me. And it's just, yeah, I had some of that personality, but also been pretty shy as a nerd growing up.

Right.

I don't know, I think there's something about, like, you're trying to land your first. I still remember, like meeting like our first, very first enterprise customers. Just like two people trying to do their own startup. It's like, really scary. I was like, I don't know who these people are. I don't know. I've never done this before. And I think it's really just, you have to just get over the fear through the experience, right? You realize, oh, these are the things I need to do, right? I never did customer support, but we couldn't hire a huge team, so I end up doing the work, right? And then I think it's just that repetition that, like, hey, do what you need to for the business and you have to just get over the fear in some cases. It's a little bit of that like survival instinct, if you will. And I think as a founder, that's one of those things, right? If you're like there to just do one job, it's probably not for you. You kind of have to be okay with, hey, what do I need to do to get the business up and going, right? And just taking that call from a customer, asking you questions, filling rfp. There's all these things you have to do early on to land that customer and then follow up and build that business. And I think it's just a little bit of you get pushed into it, right? And you learn how to do it. And I think it, it also just for me, over time, we talked about this a little bit earlier. It's just I think there's that kind of focus on the hard skills. But these, what I don't even call them soft skills anymore because I think it's underselling it. There's this fundamental truths about like how well you communicate written and verbal and are you concise and can you meet people and get to the point and stuff like that. Those are all skills that maybe we don't talk about a lot as engineers.

Right.

But building those partnerships and relationships and you're building teams, that's so important to lead engineering teams and engineering, like engineering led company. And so I think that's also those things where like we're undervaluing it because of, hey, do really well on your AP test and do well in your classes, but you don't like, think about these other things that are really important.

Definitely. Now, when you joined Netflix, how big was your team and how big is the team today.

You know, was really. What's something maybe people don't realize? Netflix has really small teams by design.

Right.

It's talent dense, talent rich. So he was pretty small and had like 10 people, all ICs, no managers. I always joke. I was given 10 ICS, a few openings and a name, and then had to go figure it out with my team, what we're doing here. So it's small, but in terms of the scope and size of problem, it was pretty large. Right. It's like the consumer API space. And then we were building a whole new API layer being, being used by the, the, the studio business. So it was small. But then I, you know, we kind of slowly grew it out. I built a management team now where I think like 35 people with we have some like new grads coming in or interns and stuff like that. But yeah, and it's also change in scope. So like, I used to only run the API team and recently I took over a couple other teams as well. But yeah, it's, it's been a fun journey for sure.

That's a sizable team. Man. What is your framework and philosophy to maintaining a good product? Productive culture at Netflix? What are the top, I think or five things everyone should consider doing?

So Netflix obviously has a pretty well known culture memo that people can go read and you can read the all the things, values we care about. But I have this kind of saying. I have this simple saying. It's called Trusting teams. Seeking excellence, driving custom delight. Those are my core philosophies, right? Trusting teams. How do you build a trusting team with psychologically safe teams seeking excellence? Being great at what you do and being excellent in your work and your craft and the driving customer light is we're all here to make the business run, right? We're not here to just build cool tech. It's for the business, for your customers. Right? And so I have those kind of anchor philosophies when it comes to like trusting teams, for instance, one of the biggest misnomers with psychological safety is people are like, oh, it's all about being buddies and friends. That's not what it's about. It's about being accountable and open to that accountability. And so that trusting team is, do I trust enough to say, hey, this is when you messed up, or you trust enough to tell me when I messed up or I'm wrong? And so do you have that ability to call each other out when there's problems? And so that's in our, you know, Netflix philosophy of honest, productive feedback. And so trusting teams is not just about that camaraderie, but it's about building that trust to give each other that kind of feedback. Right? Seeking Excellence is just about growing your craft, like being better and always seeking to be better. Right? So that skill is that humbleness and drive to get better always. Don't think I almost like extra. I just think I'm bad and I have the imposter syndrome. And people are like, oh, you must be doing so well. I'm like, no, I feel like I'm always not doing well enough. And I think that excellence that seek to be we can be better no matter where you're at is such a powerful thing. And you obviously stole the seeking excellence from the memo. The memo is actually renamed Seeking Excellence.

Right?

And then the last is Driving Customer Delight is about what are we building these platforms for? So I lead these API teams and product data systems and stuff like that. And it's like, what are we building all this for? It's all internal, right? I don't have external customers, all internal users. So building these platforms that people want to use, excited to use, almost like a startup, right? Build it for your customers. And I think driving that mentality and being really customer focused and empathetic to your partners and your customers, even when you have an internally focused platform team, is so powerful. Right. And I continue to use that philosophy when I drive these projects.

What is one concrete example, tactical thing our listeners can do in each of those buckets to build excellence and trusted teams and customer delight.

Yeah, yeah. So trusted team. First one is be vulnerable yourself. I think as a leader, you probably made mistakes. I made mistakes, right? And I really remember the first time when I told the team I was struggling, I was like, man, I'm struggling. This is hard. This is really hard. Leading a team of this complexity and coming in, and this is during the pandemic and everything was shut down. And I still remember that moment when just being vulnerable with the team, I think people are like, oh, yeah, this is not easy job. And being a little more empathetic. And I think that was a turning point. And so it's a little bit of just you being a leader, have to be vulnerable yourself about the mistakes you make and recognize it and be introspective about it. So that's an example of being vulnerable with your team and just say, hey, I don't know what I'm doing in this case. Right? I really need your help.

Right.

And I think that really builds that trust, that sense of trust with the team. Right? Seeking excellence. There's so much you could do. I think one thing, this might sound weird, but don't let the success get to your head. I don't know, that's not like a simple piece of advice, but it's like that idea of, you know, you're doing well but don't get complacent, right? Don't be like, oh, now I can just rest, right? I've reached it and now I can rest, right? But there's always more you could do and there's more you can get better at and that kind of seeking more complex and harder issues. And so I think for me that seeking excellence is really about not getting. I don't want to say lazy is not the right word, but just like comfortable. I don't know if that's the right word. And then the driving customer delay, I think that's easy, not easy, but it's really just what do your customers actually need? And as a technology team, for instance, as a platform, internal platform team, it's common. It's easy to just be like, you know what? This is the play pass and this is it. You just use us because we own this platform and you have no other choice, right? Or you could be like, hey, where are all the gaps? Where are the problems? Where are the issues? This also touches a little bit on the trust, is like really listening and trying to understand what the problems are, right? And really get to the essence of like, where is the platform falling apart? Where are the problems? So this goes back a little bit to not getting complacent in your success and being like, so I'm always seeking, like, where is the problems that we're seeing and where can we get better at? And that's really about listening to your customer. And I think this is having that different mentality for a bigger company. You have lots of different internal teams, right? And I think having that sort of like external customer empathy type focus is really valuable. And look, you also need to know you can't just take all the feedback and just implement everything. So you also have to balance, like the asks with your roadmap. And so there's a little bit of strategy in there. But I think really like understanding the customer needs and really listening in. I think as an internal company for a bigger team, I know that. I know for startup people that might seem like, oh, that seems easy, like, you should always do that, but I think you can kind of lose sight of that.

Certainly now in terms of your experiences. What are things that hindered you through your journey?

I'm almost like two startup. Like, I have so many ideas, I have so many things I want to try. I'm like, very much like, try pivot, throw away, try pivot. I'll read stuff and try it right away. Literally. I'll read a blog, be like, oh, that's a cool thing. I'll just start trying to do it and then it won't work and I'll abandon it. And I've actually gotten feedback. Whereas, dude, you seem to be just doing a bunch of stuff like, why are you doing all that? And I think for me, that was one area where I had to really think longer term, right? I'm not fighting for my survival all the time, right? I'm not trying to start a bunch of ideas and then just see which one hits, right? I had to be a little more intentional about the projects. I lead and push for.

Right.

And you could. This is feedback I've gotten. I post my 360s publicly. People are like, hey, you have a lot of ideas, you need to like focus.

Right?

So that's been something that's hard. And then I because mostly worked at startups that hadn't been around this long at this scale, I didn't fully appreciate the complexity of the technology implications. So I'll give you an example. I've done a few talks about our ATI stack and I say five generations over 15 years. I've never worked anywhere. That's 15 years, right? To think about the implications of owning a stack that's 15 years old with five different generations and something that's like literally 15 years ago that someone built that no one's even really around. Those are things I never really considered. Obviously the scale, large scale systems in terms of traffic and the number of members and number of internal customers is massive. But the timescale is really complicated and that's something I never really dealt with and took me a couple years to really fully understand the implications of that. And so being startup founder guy or startup person, I never really seen that before.

Right.

Because most of the companies were smaller and they didn't have to deal with that kind of complexity of code. So those are definitely one area it took me a little bit of time to really get.

Nothing is as easy or as hard as it may seem, but we typically underestimate the level of difficulty or how long something really takes. So I can empathize. The other thing I can empathize with is founders just have this tendency.

To.

Always be surrounded by ideas, right? There's so many ideas, there's always people bringing you shiny objects. But the only way to win is to be an inch wide and a mile deep and be laser focused. You have to earn the right sometimes I feel to do the next thing. So this is great advice here. Now a lot of people, they have this, let's say they validate the idea, they get the company to product, market, fit, they're small team and then all of a sudden now they're ready to get to a point of scale or they're growing. Let's say after the initial 1 or 2 million they raise some money and okay, now I need to bring an engineering leader and then they start to look at the Googles and the metas and the Netflixes and the apples and now they're all of a sudden aping these massive companies culture codes and engineering philosophies and Whatnot. What are the dangers of following what a Google or a meta or Netflix put out there?

I think this goes back to how you don't appreciate the complexities of a big company like that, right? And you look at like technologies like our federated GraphQL, right? Yeah, that's really hard. By the way. Don't just do that because you read we do it because we literally need to, right? We have so much complicated data and our data system are very complex. Imagine trying to represent your production process or pre production making content, right? Like how hard that is. And so you have a really complicated ecosystem that requires some of this hardcore technology to help you, right? So I think the danger really is, I know success by proximity. Google did it, so if we do it, we will win.

And.

But that's Google now, right? That's not you, that's not, that's not Google from 1999. Right. They wouldn't have implemented the systems that they wrote at that time, right? So I think that's the question is like, is it really the right fit for you given where you're at, right? Same thing with a leader, I think you might want to say, hey startups, you, you get that money, you get that traction, all of a sudden you're like, man, I really need to build that culture. I really want that success and I want that. So let me bring someone in that can give me the success. And it's just about timing, right? Are you going to bring in a leader that managed a thousand people to a 40 person team? Is that really going to work? The problems are different, right? And I'm not saying which way is better or worse. It's just the problems are different. And so I think that's probably the biggest danger is to like feel like this pressure of I gotta get to that thing, right? And by, by betting on the technologies and the people, I'm gonna get there. But you really need to go through your own journey. Like you have to go, it's not like you can't learn from the companies for sure, but like you have to go through your own journey and figure out what works and what doesn't. And that's something I always think about is even when I read books or articles about some culture thing or something that's interesting, I've got to see what works here, right? And what doesn't work here and mix and match and figure out what's that formula. And so I think that's really the big danger is just that like success by proximity problem that I see Certainly.

I think one of the key fallacies is reasoning with analogy. Just because it worked for somebody doesn't mean it's going to work for you. But what always works is boiling things down to the lowest common denominator to first principles and then going up from there. Right. This needs to happen before the other thing needs to happen versus saying, okay, let's try this, let's try this tactic because it works for this other person. Like a famous example being like, oh, Airbnb jump started growth by cross posting to Craigslist when Craigslist didn't even have an API. Can we hack into some website to drive growth? Just because it happened for Craigslist, for Airbnb doesn't mean it's going to work for you. Like, where do your customers hang out? What is the value they're seeking and then how do you deliver them that? Those are first principles. Right. Which people don't look into now. Yeah. What are some key elements of engineering that can be misunderstood? Give us some examples.

I think OKRS is a big one that I think about.

Right.

Everyone talks about okrs. It's famous because Google implemented once again, right. Google did it. So if I implement it, I will become Google.

Right.

And I, I've read the book, I've used the things and I think people don't realize OKRs are meant to focus, align, stretch and measure.

Right.

And the focus in line are the two pieces that consistently hear, oh, we're doing OKRs. How many do you have? Like 50. Okay, how, how is that going to help you focus and align? Right. And it's people get really into the measurement piece. It's oh, I need to do this thing. The KR says that.

Yeah.

But it also says to shift if you need to and throw away and change.

Right.

And so that's an example of like, yeah, I read some blog about it and I think it's objectives and key results. I know exactly how to implement it. And then you just throw away some of the, like, oh, well, I don't like this part. So whatever, I don't care. You almost have a misunderstanding and misimplementation of it. Right. And people get super, super enamored with the measurement piece. Yeah. I think for us, like when we introduced it was fascinating. Yeah. Red is good. Red is how you know it's not working. So what do we need to do differently? And it's so funny because people think red's bad, right? Red means we're failing. So I must show green krs.

Right.

And it's no, you need to be able to surface where it's broken, right? And it's funny, it's hard even when you know intellectually that Red KRS is good because you want to surface the problem so you could address it. As a person who doesn't like to fail, that's really hard to say. You know what? I have a Red KR and here's why and here's what we're doing to solve it. So that's an example of are you really willing to make the trade offs? Are you willing to line, Are you willing to like bring up the problems? Are you willing to shift and change the KR when you need to? But I think those are the hard parts. You said it's that surface level understanding, but you get into the deepness of it and you're like, oh man, this is more complicated than I thought. Maybe this is over overcomplicated. Maybe like, were you doing too much?

Exactly.

That's an example. I, I have a bunch of them like this, but that's one I want to get into.

OKR just for our audience, right? OKR is objectives and key results. What is the way to do? Do you institute it for your teams at Netflix? Do you recommend companies use it and what stage a company should use? Objectives and key results. Maybe we dive into that.

I tried to use it internally just for myself, just to play around with it. But it wasn't until really we bought in at a pretty high level. At my VP level, hey, we're going to adopt this that it really took off. But right away if you talk to people, we had a bunch of them, we have too many.

Right?

Because you have a lot of teams. It's a massive. And so that's an example. I think you could do it locally, but it does work better when it's really bought in more globally. I think for startups it's like commit at the CEO level. For us it's our vp which is a pretty large organization. And so you need to commit at an organizational level that, that you're going to do it.

Right.

And I think that's something where like okay, now we do it like how are you going to do, like how are you going to make it work? And so this year for instance, one of our big things is having less goals, right? Just having less top level goals. That's not saying teams can't have their own things that they want to do. It's just that we're going to track our org level. So that's an example of A startup CEO who's. What's the three to five things you really want to drive? Absolutely. You have to do. And you're willing to trade off for it. That's why it has to be at the company level, right? Because sometimes teams can't trade off and the CEO maybe has to say, you know what, we really have to drive this one key objective, so we're going to move off of this other one.

Right?

And so that's the question. Are you willing to prioritize and say no? And usually that requires you to do it at a time top level, right? You can't. It's harder to do it if it's just like a sub team.

Certainly. Now, what are some other examples of key engineering elements being misunderstood?

You know, there, there's sort of that DevOps SRE culture, right? That's an example. I mean, that's kind of a long, like a little older type problem. But it's this idea of what does it really mean to have a DevOps organization or SRE.

Org.

And it's really about that culture of reliability and how do you build that in, right? And so that's an example of just because you have a SRE team doesn't mean you're going to increase resilience, right? You have to really build that culture in. And so that's another example of, hey, if we hire a DevOps team, we'll become like DevOps ready, right? But like DevOps and SRES, a culture movement is how you think about building software and being more resilient, right? And related to that is blameless culture, right? It's like when you have a problem being truly blameless and trying to figure out the root cause of what caused the problem so you can make it better. Right? I've seen situations where it's like it starts having outages and guess what? Start blaming people who did what to make. But it's not truly learning, right? The whole point is you're learning to get better. What exactly happened? Why did it happen? How do we prevent it from happening? How do we invest the time to make it better? So this goes back to. To implement it is hard. So everyone's looking for that shortcut, right? I want that injection to give me that DevOps life instantly. And no, that stuff is really hard to do. And even for us nowadays, we sometimes miss the result, resilience. And we, you know, we have our own core SRE team and we've even had this problem where they've driven the metrics for so long that Some of the teams feel distant from it.

Right.

So that's an example of like, how do you continue to push that culture of excellence, of quality, not a team that just does it for you. So that's another example I think gets misunderstood or at least gets misinterpreted.

You know, certainly now I want to switch gears to leadership. Right? You mentor a lot. You're one of the top mentors on plato.

I don't know if I'm top mentor. I don't know. I'm one of the mentors.

That's what I've been told. But why do you, number one, choose to mentor and what does it take to become a great leader?

I choose to mentor. Giving back, like just, I don't know. It's funny because everyone asked me why I do it. One is I give back. I. I want to, like, I learned so many lessons and I feel like I can give back and contribute. But other is I learn a lot too. So I feel like when I talk to my mentees, I'm like, you know, I'm learning a lot from you too. Right? I'm trying to understand what you're trying to do and where your challenges are. And we get to work on problems together and I get to learn a lot and I get a lot of that startup life without being in a startup. Right. And so I, I two benefits. One is giving back and really sharing my knowledge. And the second is to learn about what are the problems on the ground now, what's the issues? And this is where I hear about, hey, we're trying to do this thing. It's not working. I'm like, oh, why is it not working? We read we're trying to do this thing because we read it somewhere. Wait, what? Wait, do you know why we're doing nothing? And that's where I learned what's happening on the ground. So for me, it's also gives me a sense of understanding what the challenges are for leaders today. So it's a little two way street in terms of that going back to the leader thing. I want to tell you, it was funny. I remember interviewing here and my very last interview, it went from interview me to pitching. At one point you're like, oh, pitching's good. I think pitching's good because when the interview becomes pitching you to come to the company, you're like, I must be doing okay. And so it's funny because I joined the company at Netflix and then a year later I met that same leader, the vp. I'm like, hey, you remember you started pitching me, why did you do that? And he said it was actually when you were like, man, I failed as a leader. And here's all the lessons I learned. It's that really introspection of here's what I've been bad in the past and I've struggled and I'm learning from it. I think that's the part about leadership that maybe is undervalued is your ability to really think about where you failed and what's not working and why is my style not working. You know, I have had struggles where I've been told I can take oxygen out of the room, right? I can take up so much space. No one else has space to talk, right. Or contribute their ideas. So then I have to really think about how do I need to adapt and change as a leader. So I don't do that, right? And being able to adjust on the fly and really understand where I'm failing or why is it not working the way I think it is. So I think that introspection as a leader and really understanding where you're doing well and not and being able to take that feedback, it's not easy, right? When someone tells you you're not good at this thing or you do this thing really poorly, I've gotten multiple of those things in the past and it hurts. But I think if you get past the defensiveness, which sometimes humans we can be defensive and really think about the problem. What are they getting at? How do I get better at that thing? I think that is where as a leader you really grow up, right? And get up level your skills. Because the moment you start understanding where you're failing and where you can get better, I think that's where as a leader you start really advancing.

Certainly now in terms of building engineering culture in a startup, you join, where do you start? How do you build a productive engineering culture? I jokingly tell people your LaCroix and your ping pong tables are not what makes.

Dude, talking about misunderstandings, that's probably the worst, right? We perpetuate the. Oh, if I put a ping pong table, I'm gonna have that Silicon Valley culture, right? Sleep.

Sleep on.

Yeah. Okay, I'll go back to, I'll go back to psychological safety I mentioned earlier, right? Is the whole premise of psychological safety. So it was done researcher by Amy Edmondson and her whole research was on medical teams, right? And she had this really weird result. The teams that had most mistakes perform better. And she was like, how is that even possible? They have mo, they have More mistakes, How could they have better outcomes? And what they realized was it was because the team held each other accountable and actually raised the mistakes. And what was happening with the low performing teams was the leader was hiding the mistakes. They couldn't talk about, they don't talk about the mistake, we don't make mistakes, we're perfect team. And so the research found that safety, psychological safety, is how open you are about talking about mistakes and problems actually increases outcomes. Right? So I think it's really as a startup, you don't have to have a giant deck you can like Netflix made famous. I encourage people to write it down at least. But how do you get that trust and the accountability right? You trust each other to do great work, but you're accountable for executing. I think this is the piece of it is what are we here for? You're not here to play pinball. I like playing pinball. We're here to do work and execute and build the business.

Right?

We're not here to get our kombuchas and lattes right? Or our free lunches. Do you see what I mean? It's that are we holding each other accountable to delivering excellence?

Right?

And I think if you just followed that simple mantra of you have the trust where you build up that vulnerability and trust with each other, but you hold each other accountable. That's how you create that learning culture where you're accountable and you're trusting, right? And you're able to push each other. Hey, you know what? I didn't really like that thing. I don't think we should do that. We should do something else. Can you really say that? Team Wati, are you able to build that culture? And look, I've been on the other side as a startup founder being the founding engineer who knew everything about the code. And I think people didn't push back or I was kind of a asshole to them, you know, what are you talking about? You know what I mean? You're just not building that environment to create the truly trust. Say hey you know what? This piece of code is wrong. We should write it this other way. And so I think if you were at a startup and you wanted to just do something, it's do you have the trust of your teams? And then can you hold each other accountable to execute and do great work? And I think that's where the whole all the other stuff is window dressing, right? You're trying to make it easier for people to do their job right. Hey, ping pong table, take a break. You worked really hard. You Take a break. Not meant for you to play ping pong three hours, you know what I mean? And I think that's where you push people that way. And then people who don't want to work in that environment that they want to produce great work probably shouldn't be there. And I think that's where if you just have a simple formula, some operating principles if you will, you should start with that. It's accountability and trust.

Definitely. Trust is the cornerstone of all relationships. Man, this has been a wonderful conversation. As we close out, what are some parting words of wisdom? Anything else that we haven't discussed that you'd like to share?

I think maybe my wisdom is maybe just ask that extra question, dig one level deeper.

Right.

If you're going to go do anything or implement anything and even that idea, you have the idea, oh, it didn't work, I'll move on. Okay. Are you sure? Did you go that one level deeper? Oh, I read this blog. Let's implement okrs. Are you sure? Did you read one level deep? I would say just maybe go one step further and really try to understand like what is happening here. What is the mechanism that's actually working. And I think that could help you really understand both what is really truly product market fit or your customers want or do whatever. Is that maybe just that one extra step? Take that one extra step. And I found that when I take that one extra step to just like learn a little bit more about something or someone tells me and I'm like, let me just take the extra step to look it up and then ask you a better question. Right. Or you ask me to do something and take that one extra step and do a little more research than I should even ask me. Just has served me really well. And I feel as a leader, a startup founder, as an engineer, as a person person, as a human, just take that little extra step even to understand each other. Right. It's very easy in this world to just take that shortcut and be like, oh, that that group sucks or they're bad or they're terrible. Take that one extra step to really understand people and think about where they're coming from. I think will be really useful.

Certainly. Now let's say your new CTO at a startup. I want to end the startups doing 10 million, let's say or 5 million post product market fit.

Sure.

And they scraped it together there with just a few contractors and the founders doing everything. And now they brought you in as a cto.

Yeah.

How would you build a team who would Be the first people you would hire. Let's say you walk in here and it's a bunch of mangle together contractors with the technical co founder calling the show. But we need a real upgrade.

By the way, I actually walked in this first time it became a cto, I walked in this situation. Similar. Not exactly, but a little bit similar. What I did at that, in that circumstance is really understand where you're at.

Right?

Right. Like where, what is the situation you're in? Like where is the code base? Like where's the team? Are you, hey, it's easy to be like, oh, I'm going to start from scratch and just wipe the whole team and just. But are you sure this team got it that far? And maybe people are in the wrong roles. And so this is, I think, classic example of that. CTO probably should never have been a CTO and probably should have been a staff engineer or lead. Lead engineer. And it's really understanding where people can play the roles better. And now in certain cases maybe it's, hey, you just don't have the talent. But honestly, if you've gotten that far and you got product market fit and you got something working, it can't be that bad. Maybe it could be. So I, I think first is just look in the team and figure out what really makes it work and where are the leaders there. And you might be surprised. That contractor that you thought was just some person over there actually is one of your star engineers. Right. And really figured out what do I need to build this team?

Right.

Based on what you have today. And then after that, I think this really then just depends on what is the problem that you're trying to solve.

Right.

So Is it the 10x scale problem? Is it like you gotta really shore up your UI side, bunch of backend developers who built UIs and then you really need to redesign the back UI architecture. I think that then gets into the. It's really based on that circumstance of like, where are you at?

Right.

Where's your challenge? And then do I need to hire people with that experience, get me out of that challenge? And it's not necessarily like they've already done it, but it's who's excited about implementing and working on that problem.

Right.

And I know that's not an answer because the problem is I can't give you a general answer. Right. It's. It really depends on understanding what the current situation of the technology is and being as a leader, hopefully strong enough to go in and understand you don't have to necessarily Be coding. But you should really understand, like where are we at with the technology and the code and the design and really figure out, okay, here's what we're really missing. We don't really have any data. People really need data engineering.

Right?

And then you shore up that. Right. And so I think I would first look at what's existing on the team, but then second identify your most acute need and then tackle that first.

I like that. Just in time, right? Versus just filling in roles you fill in for the goals and the gaps. I think that's much better because a lot of people, they say, okay, you know what, we need a program manager and we need like DevOps and we need like somebody for security. They start like throwing bodies without understanding the problem, without understanding the gaps and the goals. And it's often like, hey, we all exist as a company to deliver value to the customer, deliver an outcome to the customer. How are we producing to deliver that outcome and what's stopping us from getting there? And that's where this whole concept of filling in the gaps and filling in for the goals will help you operate as lean as possible and also keep our velocity up.

I love this, man.

Where can we follow your wisdom? I know you're on plateau, right? And yeah, if people want mentorship from you, they can just go to PLATO HQ and search for Bruce Wayne. Right?

Yeah, I have very few openings, just so you know. I'm just warning you because by. By the way, that's the other thing is just a little last little tidbit. I don't actually have that much time to mentor. If you're doing your job well, you don't have that much time to do stuff. Right. I try to protect my time. I only have very few spots, but yeah, I'm actually not on any of the normal socials. I'm on LinkedIn and I also have a GitHub about page about me where a lot of the philosophies you read and my three 60s and my talks and are all on there and you can even find my calendar. I've actually had people book off of just reading that and book the time with me. We should do that.

Sounds good, man. I will drop the links when you have a moment. Actually send me the links for these other two, the Plato I have, but I'll drop it in the show notes, the. The links for your. For your GitHub and whatever else you're promoting. Thank you so much. This has been a fantastic conversation and look forward to staying in touch, man, and discussing many more ideas out there.

Yeah, yeah. Thanks so much for having me. It's been awesome.

This episode is brought to you by Boast AI. Each year, the US And Canadian governments give out billions of dollars in R and D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. Boast AI gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging boast AI software to maximize cashback. Check out www.boast AI foreign.

Thank you for listening.

I hope you enjoyed this week's episode of the Traction. If you enjoyed the show, please leave us a five star review and you can find more information and all the resources mentioned in today's episode.