Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Mistakes and Discoveries While Cultivating Ownership

Mistakes and Discoveries While Cultivating Ownership



Aaron Blohowiak talks about Netflix’s model of the five levels of Ownership: Demonstration, Oversight, Observation, Execution and Vision. He shares his well-intentioned mistakes and what they have learned so far.


Aaron Blohowiak is an Engineering Manager at Netflix in cloud infrastructure, where he learns and practices context-based leadership with a great team of engineers. Prior to Netflix he spent over a decade writing and operating software at various startups.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.


Aaron Blohowiak: I'm Aaron Blohowiak. I am @aaronblohowiak on Twitter. There is actually another Aaron Blohowiak on Twitter. I do not tweet about sports stuff, so if you're looking, it's mostly hot takes on distributive systems things. It's also, I share my email so you all will use it, hopefully, if you have anything you want to discuss later.

On your first day at Netflix, you can push code into prod, you can spend up to $25 million without manager approval, you can sign contracts, and all we ask is that you use good judgment. On your first day, are you ready to do any of that? No. So how do we get from here to there? How do we get from your first day where you don't really know what's going on to the point where you can flex the freedom that we grant you upfront? We do that through our culture. We avoid rules. Rules are something that most organizations tend to accrete over time. As they have bad things happen, they put in a rule to never let that happen again. As a result, they end up artificially limiting the space of options for people. People feel constrained, they feel like they're in a tight jacket. They can't have the freedom to do what they know is the right thing. Instead we say we don't need rules. What we need are smart people who know what's going on in the world, who have the right context. They can use really good judgment. To that end, we generally prefer people over process.

The world is ever-changing. Your process is a lagging indicator, it reflects the way that the world was five years ago when the process was put in place, not in the way that the world will be in five years. To that end, we try to have context, not control. Again, you can't make really good decisions if you don't understand the larger world, if you don't understand how your decisions here impact somebody else. We have this thing we talk about a lot called freedom and responsibility. Part of the key needs for having good context is to avoid the case where my freedom becomes your responsibility. Gathering context, understanding the world, is super important. If you try to have control as a leader, be that a manager, senior software engineer, team lead director, you will not have nearly as much information as the people on the ground actually doing the work. So a much better trade off to do is to give the right information to the people who can actually be there to make the decisions day-to-day.

Finally, I mentioned briefly freedom and responsibility. This isn't just a slogan or a tag line. This runs deep, it's how we structure everything. Freedom means we default to opening up and retaining optionality, having more potential things that you could do, do things that you'd consider doing. Responsibility means, if you're going to have all of this freedom, then we're going to hold you to account for the results of your actions, for the quality of your decision-making. It is important to separate out the quality of the decision-making from the result. We all are operating in an uncertain world. With that responsibility over time is really what we're looking for.

From the CEO down the hierarchy, that responsibility is delegated. Our Chairman/CEO is ultimately responsible for everything that every Netflix employee does, and that responsibility stems from the shareholders who effectively own the company. That responsibility gets divvied up and delegated down the hierarchy from the C-suite to the VPs, to the directors, to the managers, to the senior software engineers, teams leads, and senior ICs and teams. That's really how you can scale yourselves. If our CEO tried to make all of the decisions, that certainly wouldn't work. I spent a better part of a decade working at startups before working at Netflix, and I can tell you I've seen CEOs who try to have all the decision-making fall on their head, and none of those startups are currently in business.

Similarly, that vision is refined. As an ongoing enterprise, we have a pretty simple business to describe. We offer a service for sale. People give us money, and we provide the service. From that large vision of streaming movies and videos online, there's lots of details to figure out. The potential space of things that we could do as a business is vast. The primary job that leadership hierarchy has is to narrow the scope of options of the problems that we're solving and to narrow the scope of the solutions that we're willing to consider. And this happens at each layer. Again, as you get closer and closer to the work itself, the vision should be more refined, but along the way, we still want to retain maximum flexibility so that the people who are closest to the work can make the best decisions they have.

We really pride ourselves on how few decision management is involved in. I've heard a rumor from a secondary or tertiary source that our CEO has bragged about having only made a couple decisions in the last year, and that all goes down to setting the right context and having the right people.

The Expectation

This is the expectation that we have for every employee at Netflix, responsibility and follow-through. If you say you are going to do something, I am not going to check up on you ever. We hire fully-formed adults. We expect that when you say it, it's going to happen, and if it's not going to happen, you're going to proactively reach out and manage that graceful disappointment which is necessary. You shouldn't be afraid to disappoint people, you should just do it very well.

We also want you to not just be responsible, but proactive. You need to be thinking two steps ahead. Netflix employees aren't only the ones who will stop by to pick up the trash. They might also consider moving the trash can closer to where it needs to be. That proactivity anticipation is really what lets you, as a leader, scale yourself, having more heads truly brought to bear the problem.

Finally, in addition to just thinking ahead in the short term, we want all of your decisions to be based on the long-term. We hope to be a very long-lasting business, a very long-going concern, and so we want to set ourselves up for future success. This doesn't mean giving into Yagni-type issues as, if you were in Justin's [Ryan] talk previously, he mentioned we plan for two to four x scales. Some places plan for 10 x scales. We do want to plan in the future. We will be revising our decisions, but overall, we do want to take that long-term view.

Finally, we expect every employee to be defining how things should be. I worked at one place a long time ago where there was an employee who was responsible for creating a report together, and we were sitting in the cafeteria, and she was complaining to me, "I spend about a third of my time putting this report together, and I know that the doctors I give it to barely look at it." Why are you doing the report? She didn't feel empowered to say, "Is this really the best use of my time? Would a two-page summary be good enough?" When we have that freedom and responsibility, it creates that sense of "Yes, I should be helping shape how things should work, not just responsible for executing my particular role." We expect everyone to have that kind of owner mentality, that kind of architect mentality.

This expectation really translates that every employee at Netflix will have the highest level of ownership. This is pretty Netflix-y - we tend to hire very senior people, and we do give them that incredible amount of freedom, so we do require that very high level of ownership, that visions level of ownership, of understanding how things should be. Not every org expects that of every employee, and that's totally fine, but through this talk, I hope to give you a framework for understanding the different levels of ownership that will help you navigate understanding what the right level of ownership is for the right person at the right time.

What Is Ownership

What is ownership? It's really a collection of beliefs, of attitudes, and behaviors. Do people believe that they own the destiny of their particular responsibility? Do they have this mindset that they can have the freedom to do what's right? Finally, are they proactive in understanding what needs to happen next, not only immediately but in the long run?

It's important that ownership is not this yes or no thing. it's not a single bit that can fit, although Shane did talk about fractional bits. That's really confusing. No, it's not binary, it's a spectrum. What are the different levels of ownership as we've defined them? Zero of ownership. I'm not a Lua programmer, so this is Demonstration, which is ultimately no ownership. I'm going to do something or the senior person or the lead in this scenario is going to do the thing, and the person who is having the responsibility ultimately delegated to them will be responsible for asking really great questions. That's Demonstration.

The next level is Oversight. You're going to do it, but I'm going to have myself or somebody else preapprove it, look at it first, and you should expect a lot of revisions. The next level is Observation. Go ahead, you do it, and I'll look at it after it's already done. I may give you some high-level guidance.

For these three levels there's a fundamental aspect of approval that's occurring from the person that's delegating the responsibility, and we try to spend as little time as possible at these levels at Netflix, as we want people to ramp up quickly. On your first day, you probably will be at demonstration just learning how are things done here. While we don't have rules, we do have norms that help things go smoothly. Moving beyond that approval realm of ownership, we start to get into independent execution. We can establish this is the place you want to go to, and I know you'll do a great job. There will be some random check-ins just so I can keep abreast of what's happening and understand how you're doing your job, but ultimately, you're kind of heads down or out in the world, and we'll check in in our one-on-ones.

Finally, there’s that last level, that Vision level where you're shaping the future, and you're understanding your area of responsibility and all of the stakeholder domains, how your area of responsibility interacts with them and the larger business context. That's that vision level of ownership that we expect every individual contributor at Netflix to embody. If your organization puts that expectation at a different level, that's fine. This is just a framework for talking about it.

In that Demonstration level, the belief here is that you are in a student role. You do not yet know what is going on, and it's important to know when you don't know what's going on. Your behaviors here should really be asking great questions, not just the whats but the whys. Why is it done that way? How did you come to this standard? What's the purpose of using master as our integration branch? All of these sorts of things, you want to learn as fast as possible. With our ramp-up framework that we have on our team, you have an onboarding buddy that is basically there to answer all of your questions, and the quicker you can extract the information from their brain, the better you're doing as you onboard.

That next level is Oversight. Again, we try to spend very little time in here. The one thing that we do have an ongoing expectation for oversight, is things like changes to the code. Pull requests are fantastic for sharing knowledge throughout the team, and in some ways, that is an expression of ownership. Now your role of being overseer or overseen will change depending on whether you authored the PR or you're viewing. This also goes to show that these dynamics on ownership are changing over time within relationships and within particular products. The attitude here, if you're experiencing the oversight, is to be grateful for the additional context that is being provided to you, and if you're providing the oversight, the attitude needs to be one of empathy and understanding that, if I'm going to put 50 comments in your pull request, that's tough, so you have to figure out how to message that in an empathetic way.

The Observation level: Here, we're really in that reactive mode now where you're operating mostly independently, but someone who's responsible for delegating to you is going to observe and give you high-level realignment, long-term adjustments, course corrections, rather than really detailed feedback at all times. Many places, this is what they started to consider a mid-level engineer to be low impact on the immediate manager or leader of whatever form that may take. That can be really tempting to get stuck in that level as a leader, because you still know what’s going on, and you can feel like people are able to pursue mastery, autonomy, and purpose, but the fact that you're ever-present and watching all of the work that they're doing takes a whole bunch of your time and ultimately deprives them of understanding what it means to be truly independent.

Moving onto Execution, this is where the leader sets the direction and checks in infrequently to see how things are going and this is where a lot of people top out when they start to describe what it means to be a senior engineer on a lot of teams, very little management oversight and at this point of execution you should be able to train somebody else to do the same tasks. Fundamentally though, that vision level is the highest level you want to get to, where you're looking further out. I think I might have belabored that point, so I will just proceed.

We have here the hierarchy of the levels of ownerships, and there is an analogy to something you might be familiar with: Maslow's hierarchy of needs. Starting about mid-way through, at the Observation level, you have that community interaction where someone is looking at the work that you're doing. You have an understanding that you belong, you have that approval that can feel good. Ultimately, you want to go further than that and get into this notion of esteem that Maslow had where you get the confidence and respect of the people around you. It's very similar to Execution. If someone says, "Go there," and I know you can go there without worrying about it or checking in, that means you really have my confidence. Maslow initially taught that the peak of the hierarchy of needs is self-actualization: determining who I am going to be and how I fit into the world rather than taking in other people's role and expectation. That's very similar to this Vision level of ownership where you are imagining for yourself the way that things should be.

Fun historical fact: the pyramid representation was never presented during Maslow's lifetime and in his writing, he talked about these different levels never needing to get rid of the first level. You always need to eat, you always need to have your basic needs met. It's just that as you develop personally, you spend an additional portion of your time working in the higher levels of personal development. This is very similar in ownership. Even when you're very tenured at the company, there will be some things where you'll still want to have somebody else preapprove before you send out. It may be that you're reaching out to peers to take a second look at something. When we publish things at the tech blog, of course, there are people that have expertise that we're going to rely on. We never totally abandon the lower levels of ownership throughout our careers no matter how advanced we are.

Does this sound good? Hopefully you'll want to build a team of high ownership individuals, and that's hopefully where we want to get to. This talk is about how to do that, how to cultivate ownership. But really, let's talk about how not to cultivate ownership, and I will be leading here by counter example. Many of the names that follow, their stories have been changed to protect the innocent, and they really are the innocent. As my brother used to say, the response you get is the message you sent.

As a leader, if I’m not seeing the correct level of ownership from the people on my team, it's my failure to set the correct context. I didn't give them the right information they needed to make the best decisions possible.

Archie's Communications

For the first story, we're going to talk about Archie's communications. Archie was very experienced when he joined Netflix, like many people who are when they join. Unlike many people who join Netflix, he expected that the way that Netflix did things was going to be very similar to the way that he had done things previously. One of the things that our team does is we perform regional evacuations. Quick two minute spiel: we run in three different AWS regions. We can run in any two of the three for high availability reasons, and so we regularly evacuate regions. As a result of doing that, we then send a communication out to tell people, "How did this go?" When Archie was onboarding, I said, "Go ahead. Here's the folder in Google Drive. Look at our best communications, use the template, please match the tone, format, and style, and run it by me before you send it out. Archie, being very experienced before joining, wanted to show his proactive spirit, and he went ahead and put an email together and sent it out without asking for anyone to look it over first. That email had spelling, grammatical, and factual errors, and unbeknownst to him, when he copied the email address from the template, that distribution list included all of engineering.

I had tried to set us at that Oversight level, and he wanted to jump straight to that Execution level. We had a chat and I told him, "There is a reason why I asked to be at Oversight level here," and I realized that I had failed to provide that context so he didn't have all the information he needed. If it was just an email going out to our team, maybe up our management chain, it might not have been a big deal.

To visualize this, I thought that we were somewhere between Demonstration and Oversight, Archie thought we were at Execution. That mismatch is where the pain crept in. The mistake here is that we had different ideas about which levels we should be at, and the discovery is that you really need to be explicit about what level we are at and what level we should be at and then explain why we are at the level we're at.

Lily's Communication

Now we'll talk about Lily. Lily is amazing. She joins after Archie, and same spiel: "Here's the folder, please match the tone, format, and style. Let me look it over before you send it out." Lily's great, her email was perfect, no errors at all, and she said, "Does this look good?" I said, "Looks good to me." Now the problem was, the next time she sent the email, she also asked me to look it over, and I was, "Hmm." I wanted to encourage her to start taking that additional ownership, so I started replying with just slack emojis. I thought, this is going to encourage her to go ahead, "You got this," but instead of encouraging her, it actually reaffirmed I was giving my rubber stamp and by giving that stamp, I was double underscoring that we were at the Oversight level. We had a little chat, and I said, "I do not need or want to look over your work. You're great. Go for it." She said, "Cool," and never again has she asked me to look over her emails.

I thought that we'd moved over to Observation. I'm still on that engineering email list, but she thought that we were at Oversight, because that's what I had told her. The mistake here was that we had different ideas about which level we were at, and the discovery was that we want to be really explicit when that level changes. Lily has a very ingrained sense of propriety, and since I had made an explicit request to look over this email, she was going to go ahead and follow through with that from now until the end of her employment.

The next thing is that if someone is stuck in that approval-seeking behavior, they might just be waiting for permission. She didn't love getting my approval. She didn't need it or really care about it. She was just trying to follow what I had set up for her as a context. That final thing is that if I had established that goal that everyone should ultimately get to Vision which each of the tasks that they're at, then she would've had upfront permission to escalate that level of ownership on her own at her terms when she was ready.

Lily's Region Squeeze

Lily then took over a relatively recent activity that our team does, which is we load test entire regions. With our traffic steering mechanism, we can send everyone to the same region and see how the system does as traffic scales up. What's interesting about this is, it was taking over for a relatively new thing that somebody else had created. When Lily was taking this over, the first time she ran it, she appropriately was going around asking lots of questions. She created memos with all of her plans and ran them by her peers who said, "Yes, looks good to me." That first squeeze - total success. Afterwards I said, "Lily, you did this, we're at that Oversight Observation level, now this is totally yours. Go nuts with it. I expect you to be at the Vision level." Since then, for the next squeeze, she created stakeholder listening groups where she listened in for people's input. She created a rubric by which we will evaluate all the different feature requests and set up a road map for the entire project for the next year, all without me saying anything other than, "This is yours now." Much success.

Here I thought that we were at Vision, and she thought that we were at Vision. Sometimes you get it right. Again, that's really the importance of being explicit when that level changes.

Fred’s Performance Tooling

Getting a bit more serious, we have Fred's performance tooling. Fred is amazing. Fred was a little bit less experienced when joining our team but ramped up incredibly quickly. He got on call faster than anyone had before. He really had that depth of curiosity and drive that really inspired us and made me confident that I had made a great hire.

There was this new Greenfield Project to detect performance regressions in systems in prod by looking at the CPU to RPS ratio. The details don't matter, but they're interesting. Due to the track record of success that he had and incredible trajectory, I was like, "All right, you got this. Let's just go ahead." We had agreed that we'd operate at the Execution level. He independently knew that he had to develop this performance regression tooling, and he knew what the overall timeline was for the larger project at play here, so that seemed fine.

After a couple of check-ins, there were some yellow flags around some decisions he made, and some judgment calls about how he was prioritizing his work. As someone who prides himself on not being a micromanager, I waited to see if this was a pattern, if this was a one-off thing, because I don't want to nitpick someone's every decision. I just want to understand the long-term trends of their judgment making. After about a month, I started to get worried that there were no big milestones. I decided it was time to engage, dig a bit deeper. What I had learned at that time was not only was he not close to having a prototype ready, but he was still in the deep weeds of investigating different algorithms for comparing the data of previous to current performance work. That was wildly out of step with our expectations that you're going to get something done from end-to-end with kind of a not-so-good algorithm that can detect huge performance variations, then we can refine things over time. That was the sort of implicit value that our team had around getting something done end-to-end and then refining it and refining it, as opposed to understanding truly the best algorithm and then building the UI to support that algorithm.

There are a few different ways we can look at this. We very well could say, "Bad performance, we expect something to be done, it's not done, that's on you." We could also look at it as poor judgment. "Ok, so what you were doing through this algorithm evaluation was very good work, but the judgment of this being the thing you need to do versus getting something working end-to-end, that's poor judgment. You should know as a mature member of our staff - get something done, make it work, then make it right." We could take that approach when evaluating what happened. We could also look at it as bad onboarding. Maybe that onboarding buddy of his was responsible for setting that context. "This is how we do things. Greenfield Project - here you go." Many places that we could point the finger of blame. My dad has this thing where when you point your finger, there are three that point right back at you. We could also look at this as that incorrect level of ownership. This is the one that'll fall in the middle that I believe. I don't believe in blaming the victim.

I thought that we should be at Execution. He thought that we should be at Execution, but we should have been at Observation. If there was a bit closer monitoring of what was going on and I could've intervened much earlier on, we wouldn't have to claw back. He wouldn't feel like he was a failure for the past month working on the wrong thing, and we would've quickly escalated up to Execution once we knew he was headed in the right direction.

This mistake is that we agreed at what level we were at, but we were both wrong. Finally, the discovery is that even amazing people can't just jump into that deep end. If they don't understand the current context, the implicit values, and not only do they not understand the current context, but their onboarding buddy or the leadership present doesn't even know what they've forgotten to tell them. The curse of knowledge: "I don't know how much I know about Netflix, because I've been in it for so long." It's like the fish in water kind of thing.

Akwesi's Meetings

Now I'll talk about Akwesi. Akwesi is amazing, senior contributor to Netflix, been with us for a little while, had been executing fully, independently, had been operating at the Vision level, helping us understand what our team is and what it should be. He proposed a giant project that would affect how hundreds of teams operate in production. He created the documents. He led it through our decision-making process. Awesome, beautiful work. The giant project, through that process, it got approved. Everything was going great. As part of the first steps of the project's execution, Akwesi was going to meet with a bunch of the different teams to understand more deeply our stakeholder's concerns, brainstorming some UI decisions, those kinds of things, and I was super-excited. I was, "You know what, Akwesi? Can you add me as optional to those meetings?" This is what he said: Why? Don't you trust me?

For those of you that may not be well versed in management theory, there is no better signal that you're a crap manager than having someone ask you this question. I wish I could say that I understood the ramifications of my actions. I really wish I could say I was my best Aaron that day. And I wasn't. I was so excited for what was going on I wanted to be part of the party, and from Akwesi's perspective, he was executing at the Vision level, kicking butt, and here I was saying, "I want to be in the room while you do this, and I'm going to watch you as you work." How could he not take that step down from Vision to Observation or in his mind, Oversight, as anything but a signal that I didn't trust him. I was taking away something from him. I was ratcheting down my expectations.

On my side, Akwesi had been kicking butt, performing at a very high level, not only influencing our team, but beyond our team in all of production engineering. I wanted to see what he was doing so I could be justified and well versed when I was making the case that he gets compensated at a whole new level, and this is the question he asks me. It was super tough. I tried to explain to him, "This is why," but if you've ever tried to put toothpaste back in the bottle, you know emotions are hard. It was a tough lesson to learn.

I thought from my reasons as a manager, as a leader, that we needed to go to the Observation level, so I could justify the compensation increase commensurate with the new role that I had every expectation he was going to fulfill. Fom his level, he thought he should be at Vision, because that's where he had been executing at, that's where he had been kicking butt at. Those mismatches, that's where the pain comes in.

The mistake here was that we had different ideas about which level we should be at, and the discovery was that ownership really evolves over time, not just over the course of relationships, like it would have with the other people I had talked about, but even the course of projects itself and not only in the upwards direction but up and down as things come and go for reasons sometimes related to the projects, for reasons sometimes related to being a manager, for reasons sometimes to my boss's boss somehow is trying to micromanage this, and I need to provide you cover. If you don't make that clear to people, they don't have the right context. All they see is you’re ratcheting up the desire for approval. You really have to have empathy for those emotional implications of changes to the levels of ownership.

Bringing It All Together

Starting to bring it all together now, we had these four levels of ownership: watch me, I want to preapprove, I'll watch you, go ahead and do it, tell me what we need to do. This is not a strict hierarchy, but we have all of these different things happening at different levels over time. If I had made this clearer, perhaps with Akwesi, the fact that we would have a little bit of green sneaking in would've been ok.

There are some broad classes of mistakes that we can categorize mostly around those level mismatches. We can have different ideas about which level we are at. We can have different ideas about which level we should be at. We can agree on the level that we're at, but we can both be wrong, because big discoveries are all about understanding that most failures of ownership are failures to set that right context. Given the right information, people will make the right decisions. Along with those lines, sometimes a piece of that context is what your expected level is and that the goal is going to be to get to vision and that the level will change over time.

Don't jump in the deep end, even for amazing people on your team. Sometimes we've heard that phrase, "They weren't set up for success." That can mean that we didn't provide them adequate scaffolding to get from where they needed to go from a zone of incompetence into a zone of mastery. Helping provide that ladder, that escalation of ownership, sets people up for success over time. Finally, as leaders we all have to have empathy. I've found it to be particularly hard to have empathy two times: when I'm really excited and I just think, "Everyone's going to think this great," and I forget that the way that they're going to take this might be the way I intended. The second time is if I ever find myself feeling righteous, but that's a different talk for another day.

Just to drive this point home, given the right context and that freedom to do what you think is right, people will make great decisions. One of the things that our team is responsible for is managing all of the reservations and capacity for all of Netflix on Amazon, which is quite a big responsibility. The way that we do this is, we let every engineer do what they think is best and spinning up instances and auto scaling and choosing instance migrations. And instead of trying to prevent errors in those spaces, we pursue rapid recovery. If something goes a little hinky, if we see a dramatic increase to your scale with a low utilization, we'll come have a chat and say, "What's up?" When we talk to some of our peers, and they ask, "How do you achieve sublinear cloud costs to your business growth without having cost controls?" we say, "People want to do the right thing, so we let them. Sometimes they don't even know when they may have let something go on too long and run too cold." Giving them that context, they will prioritize it. If they got a big push, then maybe they'll delay, and that's good for the business. Maybe they'll say, "Whoops, I'll actually turn on a TTL for my logs that are stored in S3 and save a bunch of money every month."

Having that right context lets people make great decisions, and if you instead lean on control, people think, "Not my job." They won't even be that proactive. Actually, having that freedom creates in people that sense of responsibility, so if you take nothing else from this talk, this should be the main takeaway.

New Hire Onboarding

As a way to embody this on that team to have a culture of ownership, not just a one-off in each of the different relationships, we bring this in to the very beginning of that relationship with the person on the team. The first thing that I do in our first one-on-one is, I say, "Thank you. How's it going? The second thing I do is talk about the levels of ownership, and I say that "After the first three months, we have certain expectations for you." You will primarily be in that Demonstration, Oversight, and Observation mode. We expect you at the end of the three months to ask a heck of a lot of questions to learn the reasons why we do the things we do and to be part of our on-call rotation. That's the goal for three months. In six months, we expect you to be handling one of our quarterly goals that the team outside of yourself has previously established as the right thing to do but executing on that independently. So we expect you to be at that Execution level before the end of your sixth month on the team. Finally, at the end of your first year, you need to be responsible for helping us set what the team should be, helping shape the vision of the team." That Vision level is our expectation of every IC at Netflix in almost every role that I'm aware of, and that may be unique to us, but still setting a timeline for your expectations of what kind of ownership you expect to seek in general sets people up for success.

Flash Back

A quick flashback - remember Archie, the one who sent the email to all of engineering? That was totally on me. I hadn't set the context that this distribution list included all of engineering. Maybe if I had, maybe Archie would've slowed down, but those factual errors that were in there were actually a sign of things to come. Archie was so experienced in his career in his career and so used to operating at a very high level that he just wanted to get back to doing that kind of work. But that's not quite the way that things work for us. We expect you to come in and work your way from the brilliant basics all the way on up to ratcheting up the level of ownership over time. He kept on trying to jump forward and would rush through the work that he viewed as more pedestrian so his work product, while there was a lot of it, none of it was really usable. We had to ratchet down that level of ownership and really set it clear, "Look, we want to have oversight over all of the work that you do." Either he didn't hear it, he didn't want it, but the work that he produced was not commensurate with the work he had produced in the interview process. Ultimately, he failed to ratchet up those levels of ownership, and I had to make the call to fire him.

Firing someone is never an easy thing to do, but if you have a value, that value's mostly going to be expressed in your hiring, promotion, and firing decisions. While it wasn't great to look someone in the eye and say, "Today's your last day," I knew what I had to do. I knew what the right thing was for us and for the team. Even though we try and set all failures of ownership are failures of context, if someone has repeated explicit feedback over a length of time and they still fail to get to the level that's expected - and it might not be the last level depending on your organization and team - but if they fail to make that transition successfully or if they go, they operate fine, and then they sink back down, and you see this happen a couple of times, then you know what you need to do. They're not in the right role.

Bonus Track

A quick bonus track. Back to our good friend, Maslow, this is what most people are familiar with with Maslow's Hierarchy of Needs. Later in his career, he came to revisit this, and he said "Self-actualization, this idea that the highest expression of oneself is figuring out what I want to be, that's a bit of egoic, isn't it?" What he came to understand is that there's a higher level. You find your fullest realization by giving oneself to something beyond oneself. When you live not just for yourself to understand "what I should be," but when you live to understand "what my community should be," what the larger world should be, the larger environment, that's really the pinnacle of self-development. There's a corollary here at our levels of ownership, and I would say that it's cultivating other people's ownership.

Astute viewers would notice I have a little wiggle room in this slide. We do expect all of the ICs at Netflix to achieve the Vision level of ownership. That new meta level of Cultivation, that's an expectation that we have for everybody who's in the leadership position, and that could be senior engineers on the team, could be senior technical contributors, it could be effective team leads. It's also managers, directors, all of our VPs on up. We expect that you are cultivating other people's sense of ownership. Then at the higher level, our expectation for directors is that they are making sure that the managers that report to them are doing the cultivation of the people and transitively or cursively or wheels within wheels all the way up.

Questions and Answers

Participant 1: A little bit further on this cultivation, how do we recognize when people are ready for the next level of ownership and that we're not preventing them from achieving that by providing too much training wheels?

Blohowiak: The question was basically around, how do we help ratchet people up through the different levels and know when they're ready. There I take a lot of inspiration from a guy, his name is Vygotsky, who talked about the zone of proximal development. There's some things that you have total mastery over and some things you have total incompetency about, and within that, you have this level that you can do things when you have different levels of assistance. You can start by providing a lot of assistance and you slowly take away that assistance. For instance, you think that they're operating successfully at the Observation level and they might be ready for Execution level. There's not really a chance in kind but more a change in degree with the frequency of check-ins, the frequency of feedback that you're giving them, and slowly you can back away. Similarly, from Execution to Vision, starts to ask those questions of, "This is how things are, should it be this way?" Then once you get to encourage those kinds of conversations, you start to really enjoy what you're hearing from them, then you should start setting the context of, I shouldn't be asking you, "Should it be this way?" You should be telling me what the alternatives are, what you're considering, how those things are going on. So, there are progressive steps between the different levels.

Participant 2: You mention that Netflix is one of the major companies you have experienced resources being higher, and you prefer the people over the processes. For a few of the companies that may not stand because you need to have people without experience or less experience, if you find they're not the right fit, you've got to have some process in place to scale them up and put them in the right place. Without process, how can you achieve that? If you just give them freedom, how do you make them successful?

Blohowiak: To summarize it, if you aren't Netflix, if you don't just hire senior individuals, how can you actually have people over process if you have junior folks who are going to unknowingly do bad things? There I would say that you actually don't need to lean into process. What you need to lean into is people having a higher degree of self-awareness. You need to understand that every relationship that you're in, you are either in the role of teacher or student. Very rarely are you true peers. Understanding what role that you're in, in which context, that takes a fair degree of self-awareness, and many people who are fresh out of school, me certainly included at that time, have an over-inflated sense of self, and the key context you can set there is, "You know, you're not that good. I believe in you. You're going to get there, and here's how you're going to do it." Then you can provide that level of understanding. In the beginning, you're going to be learning, learning, learning, and you're going to have lots of oversight, lots of feedback, and the way that you'll work in terms of progressing through the levels, that's determined by you. But, right now, for you to be successful at your level, you need to be great at being demonstrated to. I'm going to judge you on the quality of your questions. For oversight, you're going to be judged based on how well you loop people in to ask them to oversee your work, and once you demonstrate true competency at this level, then you'll be ready for the next. Ultimately, I suspect but have not practiced using people over process, even with more junior folks, if you set that appropriate context of expectation of what level they're at.

Participant 3: This was great, and I absolutely adore it. A lot of the examples were within team. I'm curious about what levels of success you've had with managing this across teams when you have individuals thinking that they're executing on Vision versus Execution.

Blohowiak: Managing within team versus outside of the team and cross teams with having individuals who think that they're operating at vision versus execution - I think that can be really challenging. One of the things in John Maxwell's Five Stages of Leadership that he talks about is that you reset in each relationship. Each time that you're interacting with somebody new, you go back to almost zero trust, and you have to build that up over time. In large organizations, we have proxy signals for how trustworthy someone is, reporting structure, title sometimes, that sort of thing, but ultimately it is a relationship-based business. Having that be part of the conversations is something that we've found being very important to achieve big project success. To get a bit more concrete, one of things that we have made a first level citizen in our decision-making process is who the stakeholders are, and so by calling that out and saying these are the different levels of involvement, you're helping write the proposal, you're helping approve the proposal, or signal your approval of the proposal, because we don't achieve consensus, we don't seek that.

If you're watching and monitoring from the outside which level you're at, that will help us understand how to relate to you. It is that sort of opt in, people over process, but with a bit of a comfortable norm that everyone should be comfortable saying, "I need to be much more involved in this than I currently am. That's a totally fine thing to do, which also means they have to be ok with saying, "I totally forgot you." That also has to be fine. Then through those relationships, we can ultimately navigate those interactions. It does get sticky, especially if you have someone who has a security concern and someone who has a product deadline, and they can be in tension, and then who's really the one to set that vision? That would be a great talk I would attend.

Participant 4: You mentioned that you try to, in your organization, teach new people, "This is why we do what we do." How do you balance the tension, inevitably, that you're going to get with new people coming in with other visions, other experience, against this notion that "This is why we do what we do, and we've always done it this way, and we're never going to change"?

Blohowiak: Balancing longstanding cultural norms and bringing people in with different ideas about things. I have intentionally hired people with different ideas about what we should do be doing. Hiring people with different proclivities as engineers, some people prefer immediacy, some people prefer thoroughness, some prefer risk mitigation, some prefer risk avoidance. Bringing all those voices to the table, whether or not they're new or have been at the company a while, is important for creating the healthy tension that allows the team to respond to a changing world. How do we balance "this is the way we do things" with having everyone contribute a new vision of how we should do things? The reason why we have to say why we do the things, not just what we do, is that you have a basis for a sound argument. If we just tell you this is the way we do things, then you have no idea how to even start the conversation of challenging our assumptions.

There are a couple things that engineers do that are really bad. One, they optimize systems that shouldn't even exist. Two, they accept constraints that are external to them. In many ways, the question that you're asking is around people accepting these constraints about how we do things, and part of the way that we talk about why we do things is how things have evolved over time. Our team has now existed for somewhere in the order of six to eight years, depending on how you look at it, and we've had many revolutions and changes through how we've done it, so part of our story of why is that story of evolution of our process, and then we even try to include, and here are the things we are starting to think about for the future.

As part of our annual planning process, we talk about, "Should the team still exist? What team still needs to exist?" because we can recharter ourselves whenever we want, and what are the problems that we should be solving? That's really when we open up the conversation to starting from first principals, like a zero-based budgeting kind of approach, but toward technical strategy and approach to the problem, and then every voice is really incorporated into the room. People who are overeager to share their view of things before they've learned the history or the why, it's kind of like misjudging where you are in that teacher or student relationship and dynamic, and that can be inappropriate and distracting to the larger team context. Setting the context when you try and suppress that behavior a little bit, "It's not that I don't care about your opinion, it's that you don't have the good information to have formed a solid opinion yet," that's super critical. Then setting the timeline for, "In a few months, that's when we really expect you to be fully ramped up, and you're doing great as you're ramping up towards that level," so not shut it out, even if you are trying to lower it in the beginning.


See more presentations with transcripts


Recorded at:

Dec 23, 2019