How Netflix Thinks of DevOps

Link to the video of how Netflix thinks about DevOps(Hint: They don’t)

Netflix Github Page

Instead, what they do focus on is a lot about culture, which is really be what every company should be focusing on. In this era, for better or for worse, we as humans have become more “Me”-centric. How we actualize the vision of ourselves, and how much the company supports that actualization is an important factor influencing the decision of choosing where to work.

I digress. Below are the summary points of the video of what Netflix does. It’s entirely non-DevOps related, and entirely cultural.

  1. Don’t build systems that say NO to developers and engineers.
    • In some companies, there’s the concept of a “Need-To-Know-Basis”, both on data access, and system access. There is absolutely no reason to do so, after all, we all have the same vision the company has (If not, why are you even there?). By denying access to both data and systems, you’re essentially telling your engineers: “This is not your problem. You have no business to be looking at this. Focus only on what you’re hired to do”.
    • In addition to breaking engineering serendipity and spontaneity, you’re inducing a lot of overhead for policy crafting, determining who has access to what, and enforcing those rules.
  2. Freedom and Responsibility
    • Hire smart people, and get out of their way. Let them do what they were hired to do, and trust that they would do it. The engineers should have the freedom to choose and architect solutions they see best. The company should not restrain the engineer in the worst way possible; restrain their engineering choices.
  3. Trading [X] for Innovation
    • Where [X] is your core business concern. For Netflix, it was uptime of their services, and trading off some concerns for uptime to invest in innovation was one of their strategies. Think about what [X] is in your company, and instead of obsessing over the optimization of [X], ensure that an equal (if not more) effort is spent in innovation.
    • The by-product of innovation also optimizes [X], and should not be seen as an activity to do “only if you have free time”. That should be the main job you’re doing: Innovation.
  4. Cut down on Processes and Procedures (P&P)
    • These “safety guardrails” do nothing but induce more administrative overhead. The opposite of introducing P&Ps is to cultivate more trust. Trust that your employees are doing the correct and right thing, instead of making them document everything and request permission.
    • Having trust implicitly means delegating authority to them, and that means no P&Ps to request unnecessary permission.
  5. Context
    • Make sure the people you are working with have a quality and constant flow of context of the business, and business decisions. Being too caught up in your technical mumbo-jumbo and into the rabbit hole can lead you to lose sight of the bigger picture. Context of the business, and exactly why you are doing what you’re doing should be constantly reinforced.
  6. Required Standard
    • Not “No required coding standards.”, but rather no required tech stack requirements. Don’t enforce tools to use, don’t enforce tech stack to use. Instead, enable your engineers to choose what they want.
  7. Silos/Walls/Fences Should be torn down
    • As if this isn’t obvious enough. Know your internal dependencies and consumers. Know exactly what is it they do and want, and know exactly what is expected of you. Knowing what each team does reduces the need for guessing, and cuts the cost of wrong anticipation.
  8. Guesses/Instinct/Tradition
    • Don’t rely on instinct. Back it up with quantitative data. Don’t fall victim to tradition. Always challenge for a better alternative.
  9. Finally, Culture
    • Know what culture you have. The 8 points above are an example of what culture is. To give an example of a counter-culture:
      • I build tightly controlled systems, and only allow relevant engineers to access the system.
      • I tell the engineers exactly what to do, and rob them from their freedom.
      • I forsake innovation, and focus only on KPIs.
      • I introduce numerous P&Ps, because I don’t trust my engineers to do the right thing.
      • I don’t focus on the Why enough, and only how the How and What
      • I restrict my engineers to use a predefined tech stack, because change is bad, and we only support such technology.
      • I silo my teams, and everything internal to one team is a “Need-To-Know” basis to another team
      • It has always been done this why, so don’t ask why. If it ain’t broke, don’t fix it.
    • Make your comapny culture well-known, and when you ask every engineer what the culture is, they should be able to tell it to you right away. If you have differing cultures, and groups of people optimizing for different things, you’ll end up with a lot of problems. Internal cohesion falls apart, and different groups will work towards different goals. This will tear the company from inside out. Pass on brilliant people if they do not fit into your culture.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s