Building and Sustaining Excellence with Bruce Wang (Netflix)

Alexis:

Welcome to Le Podcast on Emerging Leadership. I'm your host, Alexis Monville. Today, we are diving into the art of leadership in tech, building and sustaining excellence with our distinguished guest, Bruce Wang, Director of Engineering at Netflix. Bruce brings a wealth of experience from the intersection of tech, business, and team culture. His journey from a hands-on developer to a leader focused on people leadership, culture cultivation, and mentoring offers invaluable insights into the evolving landscape of tech leadership. Welcome to Le Podcast on Emerging Leadership, Bruce. How do you typically introduce yourself to someone you just met?

Bruce:

I'll probably just say, hey, I'm Bruce Wang. I've been an engineering leader for about 20-plus years, two-time founder, and currently I'm a director at Netflix.

Alexis:

Excellent, thank you. Can you tell me about your key principles and how they are essential to building an engineering culture?

Bruce:

Yeah, I have this guiding leadership philosophy. I call it: trusting team, seeking excellence, driving customer delight. What I'm trying to convey is three pillars that every leader needs to balance. How do you build a trusting team? How do you seek excellence and drive mastery? And how do you make sure you're delivering customer value? The challenge of engineering is keeping those in balance.

What I've learned over time as a leader is it's all about the balance. You can't get all of everything. You have to figure out how you balance between these three. Sometimes you would break trust with a team if you have to do something on the seeking-excellence side, so how do you balance that and make sure you're doing it well? All of my sub-values and things I think about sit under that principle.

Alexis:

Can you share your approach to growing a team — really starting something and helping that team grow?

Bruce:

It's funny, I was trying to think, do I have a formula? It's interesting because I'm actually taking on a new team in a week. I'm switching roles. I used to run a team called Product Platform Systems. By the time this releases, I'll have the new job, which is a games platform. It's still within Netflix, but it's a totally different group. So I've been thinking about, what do I do with this new team? People know me, but not everyone on the team.

The first thing I typically do with any team is set a vision first for myself. What is this thing I'm leading? What does this team do? What's the essence, the core? A lot of people think, oh, this is the technology we build. No, no — what's the thing we're driving at? This goes back to customer delight. What are we here for, our purpose? I actually wrote a memo for myself to figure out, why are we doing what we do?

In this particular team, the games platform team, it's a newer team. I don't know if people know, but Netflix actually has games and that's a growth area for us over the next several years. It's very interesting, kind of a little bit like a startup. So for me, it starts with the vision of what the team is and could be. Then, who do you have? Who's there? What are you building? What's your team structure? The other anchor point in building trusting teams is really around the makeup and diversity of your team. Do you have the right parts? Do I have enough managers? Do I have enough ICs? Are they focused on the right areas? If you think about it as a leader, how do you decide the right team structure if you don't know where you're going? Know where you're going, and then figure out the team makeup.

Then the seeking-excellence piece — what do we need to do now and do well to deliver value? It's the vision, the team structure, and our goals. I have a philosophy I've written on my GitHub page from a book called Winning Now, Winning Later: you have to do tactical and strategic at the same time. The goals we set have to deliver on 2024 goals; we also have to prepare for 25 and 26 and beyond. That's how you get a team in a good place — building those three things together.

Underneath all of that, the foundation to everything is trust. How do you build trust with the team? How do they trust you as a leader? None of this works without trust. That's why trusting teams is the first thing for me, because if you don't have a trusting team, the vision is not going to make sense, they're not going to trust you, the goals — they're not going to push, and definitely hiring and conveying what the team structure is — they're not going to believe you. So underneath that is constantly building trust with the team.

Alexis:

Help me understand that. So I'm one of the engineers on your team, hypothetically. You're the new lead of that team. Do you believe I will trust you, like that?

Bruce:

In this particular case, no, you won't. I have to earn your trust. I do have a slight advantage in the sense that I have been here for four years, so I'm not some random person coming in from the outside. You've already seen multiple outputs of what I do and how I think at the company. The good thing is my reputation precedes me — I hope in a good way. I have team members who actually used to work for me who advocated for me, which is always nice to hear. Honestly, as a leader, that's the only criteria — do they actually want to work with you again? So I'm not starting from scratch.

But I'm doing something very early. I believe in vulnerability-based trust. So here's what I'm doing. One: setting that vision doc early to say, hey, I want to learn more about the business and define a future that's exciting for all of us to pursue. The second: the day I start, I have a town hall where it's about me. Hey, learn about me, read my leadership philosophy doc. Here's my intro to me as a person. I live in San Francisco, I have a wife and kids, but these are the things I like — I love food, I love travel.

And something I'm doing is having the people who used to work for me, that's on that team now, verbalize critical feedback they've given me in the past — what's wrong with Bruce? Now as a leader, you have to be careful. Coming in new, vulnerability also has to be earned over time. If you just say "I don't know anything," that's not going to instill confidence. So you balance the "I know what I'm doing, I think," with "but also I'm not perfect, I'm not infallible, I have weaknesses just like anyone else." That's how I'm doing it right away — try to build through that closeness of, hey, I'm a person and I have flaws, and then ask any questions. The spicier the question, the better. Challenge me, question why I'm in this role, push me hard. What I'm trying to convey to the team is, I want the openness to discuss problems. Inside the memo I wrote, I list out all the things I heard that are difficult for us as a team and just verbalized it, said, yeah, I know it's really hard to be a startup in this giant company that's been around for 25 years. Let's not underestimate how hard that is.

Alexis:

I have to admit I would love to hear the segment "What's wrong with Bruce." There are people who know you — I love the idea, I need to do that. The other thing is when you said you write the memo about the vision, why are we doing what we do — that means you're not doing that in isolation, you are interviewing a lot of people, probably the team.

Bruce:

Well, that's the thing. I wanted to be careful. When I originally started writing the doc, it was for me to write down what I thought this team was doing — and I'm like, I don't know enough. So instead, the memo became more like "embrace hard mode." It went from specific tactical here's the technologies we need to work on, to we need to embrace the challenges ahead of us. It became more of an inspirational, yeah, I know it's hard, but we're going to have to do it.

I wrote in the memo: if we want to do extraordinary things, we need to overcome extraordinary obstacles. Anything worth doing is hard. So the memo became more like, let's embrace the hardness. Not overwork, but yeah, it's difficult. You're trying to build a new system, establish product market fit, but you still need to integrate with Netflix. How do you do it well? You've got systems built for SVOD, not for games. How do you integrate with those systems? There's real technical challenge in that.

I shifted from "here's what I know, what we want to do" to "I know how hard it is to be in the situation." And then, look, I still need to collect feedback. I readily admit, I don't know what should be in this doc. I just wrote my initial version. The good thing is, the first few people I shared it with were like, oh, this really resonates. So then I'm like, okay, I'm on the right track. At least I didn't write something where people were like, this makes no sense, why did you write it?

That's also how I work. A leader will put out a vision memo and they think it's written in stone — dude, we can completely change this however we want. More information I have will help us make this vision better. So definitely inviting people, being transparent about what you're trying to do, is really important. I'm kind of a shower and a doer at the same time. I don't want you to just trust me that I am a trusting leader — I want to be transparent, I want to be open, I want to be vulnerable. I'm just going to do it, not just say it.

Alexis:

Excellent. The next question is also about doing and saying — or doing and helping others. It's about growing people. And I know growing people often starts with oneself. So help me understand: what is your philosophy about growing people?

Bruce:

Everything is about growth mindset. Just because you don't know something now doesn't mean you can't learn it. The idea that you can get better and be better. You start with yourself — you realize where your challenges are, where your weaknesses maybe are, and you want to get better. The second thing about growing is also recognizing what you're really good at, what you're exceptional at. What's my superpower, and how do I do that more?

One of my superpowers is connecting with people and networking within the company. One of the challenges of games is that it's sort of insulated and isolated. So my job is using the connections I already have to start doing roadshows. That's an example of how I also use my own strengths to my advantage.

With the team, it goes back to figuring out what you have, where the strengths are, where you can push, where you can support and coach where there's weakness or somewhere to improve. Growing people, like you said earlier, first starts with yourself — you have to be humble enough to know that you don't know everything. Then when you work with people, as they build that trust, they can open up to here's what I'm good at, here's what I'm not, here's where I want to grow.

Now, as a leader, the challenge is that I've had the benefit of leading ICs, but as I build up the team I don't directly lead ICs anymore. Usually I have managers who lead ICs. So how do you grow people when you're not directly interacting with the ICs? You have to grow your leaders. You have to grow your people leaders and make sure they're reflecting the vision and the ideals and pushing you as well. My people managers push me all the time to get me to rethink and learn. As you move up, it's really about scaling yourself. You can't meet everyone. You need to make sure you're building scalable structures so that your managers and their managers can build strong teams. Growing is about scaling out beyond just you personally one-on-one growing someone.

Alexis:

Yeah, I love that. It's funny, I'm starting working with a new customer this week, and I always love when I'm able to meet with everybody on the team. And during the first call, before we started, he told me, okay, so there's 800 developers on the team. I said, okay, that will not happen — I will not meet with all of them. We need to have a really good strategy to scale myself, because I will not have 800 meetings during the first week, and not even during the first year. So it's really different to be directly managing a team of individual contributors, versus starting to have managers do that with you.

Bruce:

By the way, that's actually a really great tactical example of growing my team. The first team I led at Netflix was API Systems, and it was just ICs. The whole point of me coming in was to help establish a team structure, but it was all ICs. When I started getting engineering managers, it was this weird thing — I had worked with the team to build out this vision, but now I have managers who are pushing that vision and changing the vision. How do I let go? Growing the team sometimes is letting go. You not being in it — because I felt obligation. I felt, hey, this is the team we built together, I don't want to let go. And actually growing the team sometimes means letting go.

Alexis:

I feel that's important. Letting go — okay, we'll put that in bold at some point. Can you share a challenging project that really stretched your skills?

Bruce:

Oh man, they're all challenging. When I first started at Netflix — I always tell my story of when I started Netflix because it was the hardest job I've ever done in my life, times two. I came into a dream company. I'd been following the culture for years. I'd designed my engineering culture based on the culture. So you have an aura — like, I have no idea how it really is in the company. I'm just like, oh my god, they must know everything, they must be right on everything, they must be the best company everywhere. So you already have deep imposter syndrome coming in. Then you have a memo that says keeper test, dream team, A players. So you're constantly worried, am I going to get fired at any point?

And then, you know, I've been mostly a startup founder and worked at startups leading teams. This is multiple orders of magnitude higher traffic, more complicated systems architecture. The technology is way harder than I'd ever seen before. Mix all that together, and COVID hits in March of 2020. I started in January 2020, got two months in the office, and then it was lockdown. So you're also facing an existential crisis within the world and within Netflix, because Netflix was built to be an in-person company.

I still remember early on attending meetings — we had this major API migration project, .next to EdgePass. NEXT is this API platform we built over many years, and EdgePass was the new GraphQL-like graph language API, already going on for multiple years. In the check-in meeting, everyone was in the room. Literally all the engineers — and I'd never seen that before. I was like, oh my gosh, everyone's here, this is amazing. I'd mostly worked for startups where it's all remote and distributed. Then lockdown — everyone's remote. The company isn't even prepared for that.

That combination of "do I know what I'm doing, am I going to get fired at any time, plus learning an environment that everyone was dealing with" was super hard. I don't know how I got through it. I tell people it took me nine months to a year to really understand what the team did, and two years to feel comfortable.

It's not one difficult thing, it's like 10, 20 difficult things. And actually, what was really hard about that situation was even after I built up good rapport, I fell down a year and a half in, where I'd felt good and then made a huge mistake with the team and lost some trust. So you have to rebuild that and figure out, oh my gosh, what did I do wrong here?

So building out the API team to be more scalable — the vision I came up with was "hourglass to turbine." Hourglass is what everyone tells API it is — the middle layer between two huge groups, UI and backend teams. We're the middle layer, that choke point. We wanted to become more of a turbine, an engine for innovation. It took many years to figure out how to do this, this really complicated piece of the ecosystem, and move it to a more scalable architecture and team structure. And not everyone was happy about the move. That's another example of trusting teams and seeking excellence conflicting with each other. So this journey was a multi-year journey with many difficult ups and downs. It's not a single event I can point to — it was the whole journey was really hard.

Alexis:

I love it. The context was really challenging. When I listened to your leadership philosophy, I was wondering how the system, the processes, the tools — are they important in what you're doing? Help me understand how you deal with that.

Bruce:

When you say systems and tools, do you mean technical tools, or like Jiras and Kanban boards? I'm curious, what do you mean?

Alexis:

I mean everything. I want to leave it as open as possible. There's a Deming saying that a bad system will beat a good person every time. The system is really everything that people interact with. So I'm curious about what is in the system to you, and what do you feel you have to do with that?

Bruce:

Right. So what's really interesting about Netflix is that Netflix is well known for a culture aspect called "people over process." We're, shall we say, not anti-process, but "process is bad" — that's actually a culture meme we have to break. Process is not bad. Deploying code, CI/CD — that's a process. Running an offsite is a process. You need processes. You can't treat it as a dirty word.

The thing I had to fight was, how do we introduce some lightweight processes? Can we just use Jiras to track what we're working on? Can we have a lightweight Kanban board to see what the team is working on? What I've learned over time is that everything you learn, all the tools you learn, you have to apply for the situation and the problem on the ground at that time.

What I'd built before — building Kanban processes — that's kind of a strength of mine. When I read something about a process, I can synthesize it pretty quickly and get to the core of why you do it: OKRs, Kanban boards, whatever. So those are easy for me to implement in a good way. Kanban is all about limited WIP — work in progress. You're trying to stop the line when you're having a problem. It's not about filling it with a billion things; it's about filling it with less things and doing.

Implementing some lightweight process when there was no process or very little — because at Netflix process was actually considered bad — that was the challenge. You have to take into account the team, the org structure and culture you have, and then figure out how to integrate into that. I got feedback early on — my team was worried, oh my god, this is some guy who read a bunch of blogs and was trying everything. And it was funny because that's what I was doing. I was like, oh, I read this is a good structure, let me try that. I had to adapt. What helped the team realize is, look, I'm a startup person. If something's not working, I'll just throw it away. I'll try a different thing. I'm not going to force-feed some process down your throat until I make it work.

So my process was seeing what worked with the team. I tried putting stuff in Airtable — that didn't work. Okay, throw it away. Do Kanban boards — okay, that worked because we were mostly using Jira, doing sprint planning and switching over. That's the example of just adapting to who you have and the company you're in, and being able to implement some things to put more structure to organize the team a little bit.

For me, it's not about a set thing — implement these 10 things and it will work. It's the growth-mindset mentality of, what are we trying to do right now, and how do we make it better? It's more of a philosophy of how we get better — that's seeking excellence, making the system work better — rather than a specific thing. So I'm more principle-based on that than a formula of things.

Alexis:

I love it. I would love more people to answer that question with a more principle base. Implementing a framework or adopting best practices is not necessarily the best option they can pick. Reflecting on the core principles is probably more important to adjust and adapt to the current context.

Bruce:

I'll give you a quick example. Whether we like it or not, I think Netflix has influenced the industry on GraphQL, because my team wrote blogs about our federation technology. I always find it very interesting when teams say, oh, Netflix is doing it, so we must do it. But Netflix has very specific reasons why they're doing it. It's not just because we want to. I find people want to copy success — like, oh, this company's doing this, let's just copy what they're doing — without recognizing what they actually need.

Alexis:

Yeah, it's very dangerous to do. It's harder to really understand the core principles. You went from being an individual contributor to a higher-level leader in a new large organization, and as you said, a dream company. What is your perspective on what makes a good people leader?

Bruce:

There's a book I read called Team of Teams by General McChrystal. He had one of the best lines — he said he looks at himself as a humble gardener. It's one of my favorite images. Being a humble gardener: one is being humble — don't assume you know everything — and the gardener piece, for me, is the image of being in the dirt with the team, figuring out what needs to be done, clearing the brushes, making the environment in which everyone can grow.

I like that mentality. Your job as a leader is to make sure everyone else grows and gets better. Sometimes, depending on the situation, you have to take a much more hands-on approach given the current team structure or experience. Other times, you just need to let go and let it shine. It's very dynamic, based on the situation.

Honestly, it comes down to curiosity as a leader. You have a lot of experience — great, but maybe you don't know everything, and that's okay, and learning, and that drive and thirst for learning, and being better, wanting to learn more, get better, incorporate more concepts. Don't think you know everything. That's a key attribute of any leader, whether you're a people leader or an IC leader.

Alexis:

I love that. And a really good reference — I love that book. There's a lot about curiosity, but you said it. I will put the link in the comments. We're about to be at the end of the episode. What is the question I should have asked you?

Bruce:

That's a good question. You kind of addressed it, which I think you could have pushed more — the failure modes. You asked, what was the hardest thing? That was good. But maybe even digging deeper on, what were the failure modes and what did you learn from them? It's not about the success that defines us as a leader; it's about how we dealt with the failures that defines us. Drilling down into where are some of those points where you learn from a failure, or some situation — you know, I mentioned to you I had a problem with the team where I thought I lost some trust. I had another one, letting go to my managers. What I don't like about the world of, you know, whatever you want to call it — influencing leadership talks — is it paints too rosy of a picture sometimes. You're actually seeing a lot more practical discussions of what's hard about leadership, not what's easy. Everyone could talk about being a leader, but it's actually pretty hard to actually be one. So that would be a good question — drill down into some of the failures more deeply.

Alexis:

Do you want to try it for us?

Bruce:

Sure. Many — I can't even pick all the mistakes I made. Let's pick the failure mode where I think this one is important, because this is where I had built some confidence with the team, and this is when I lost some trust with the team. I had already built some confidence on knowing what I was doing. That's actually kind of where hubris kicks in, where as a leader you're not being humble anymore, and you're sort of like, oh, I know what I'm doing, I'm just going to push forward.

The situation was, we had a new VP and we wanted to present our strategy for Consumer Edge — our new federated GraphQL API for the consumer product. We'd already established it for our internal enterprise within the studio applications, but we wanted to move toward consumer, which is the Netflix app, the product itself. I spent time with one IC who is a big proponent of that vision. We wrote the vision doc together and it was great. I even said, let's write it without using the word GraphQL in it. Because what are we trying to do? The vision is unified API, democratized edge. That means you unify all the APIs together — before, we used to have per-UI based APIs, BFFs, backends for frontends — and we wanted to unify on a single GraphQL API, but then democratize it in the way that it's unified, but the people who own it are actually the domain owners. The identity graph is owned by the identity team, not managed by an API team.

Really excited. We presented to the VP, and I think it went okay, it was fine. But my team was like, what are you doing? Why are you talking about this? We're not even sure if this is going to work. Multiple senior engineers in the team really pushed back on the concept. We don't even know if this thing will work, why are you talking about this? It was almost like, are you trying to dismantle the team on this new vision?

Because of my push for speed and my push to get this in front of this leader who's new, I didn't take the time. I used my confidence — it hurt me. I thought I'd built the trust of the team, I pushed fast, and I didn't collect enough information. So when I presented it, it wasn't a cohesive vision that the whole team supported. I had to go back and really work with the more senior leaders to define a more cohesive one. I even remember — it was lockdown — we had to find a room outside to meet, the four of us, just to talk through the vision. What is really underneath this? What's the meat of it? How do we really make it happen, not just write a doc? I still remember sitting outside, social distancing, discussing this vision together. That was a key moment for me. I felt really bad and the team was disappointed. I was like, oh my gosh, how did I mess up this bad?

Alexis:

Thank you for sharing, because it's very interesting and it shows the other face of the humility that's needed. I love the way you presented the vision doc and the fact that it was really a collaborative document that you refine each time you meet with someone. And then you're confident in that vision and you want to take a shortcut — and boom, doesn't work. Each time we take a shortcut, we should think a little bit about: is it worthwhile? Is it really a shortcut?

Bruce:

Yeah, that's a great one. I liked that term — is it a shortcut you took? And absolutely it was a shortcut, because it was speed. I wanted to go fast and present quickly.

Alexis:

Thank you very much, Bruce. Thank you for joining me on the podcast today. I really appreciate it.

Bruce:

It was great. It was really fun. We'll do it again.