I really like the approach of Netflix of 10 years ago when it was still small. They hired mature people so they could get rid of processes. Indeed, they actually tried to de-process everything. As a result, things just happened. Non-event was often mentioned and expected in Netflix at that time. Case in point, active-active regions just happened in a few months. A really easy to use deployment tool, Asgard, just happened. The VP of CDN at that time said Netflix would build its own CDN and partner with ISPs. Well, it just happened in merely 6 months with 12 people or so. Netflix said it was going to support streaming and move away from its monolithic Tomcat app, and it just happened. And the engineers there? I can't speak for others but I myself had just one meeting a week -- our team meeting where we just casually chatted with each other, to the point that the team members still stayed close to each other and regularly meet nowadays. I also learned that the managers and directors had tons of meetings to set the right context for the team so engineers could just go wild and be productive. At that time, I thought it was natural, but it turned out it was a really high bar.
Importantly, this requires mature engineers and managers. Nothing worse (from personal experience) than working at a place that hires experienced engineering talent and then has a bunch of junior "leadership" telling them what to do. That's how you end up inundated with meetings and frameworks and blablabla. Obviously you need experienced developers to get stuff done without handholding, but you need managers that can "manage" - I say coordinate, without handholding.
One of the strangest experiences in my career involves working for a very well known startup, which had lucked out into an extremely high talent pool, thanks to some key early hires. The problem is that while they had top engineers, their engineering management was no good, all taken from companies way bigger than them. The end result is that, as the layers of self-entrenching management grew, basically every engineer left within 3 years. They went from a results-oriented company, to a Jira-centric organization. Fortunately they had a working system and good product market fit, so the company could keep doing well via coasting. But the extremely high performance organization basically disappeared due to 4 bad hires, which then made many bad hires from their network.
Hiring extremely good engineers is hard, but hiring good managers is far harder. They also are much better at driving out the good talent tan a bad engineering hire is.
In addition to your last point, an employer may have good engineers and not even know it if their system discourages excellence. A lot of what the author mentions can cause good engineers to coast because merely changing a string can be an absolute slog of PRs, spurious feedback cycles, and code deciphering. Cash is king, so as long as an engineer gets paid and isn't totally driven insane, they'll stay just for the paycheck. Yet the whole time the employer has extra talent sitting there just being wasted.
Hiring extremely good engineers is hard, but hiring good managers is far harder. They also are much better at driving out the good talent tan a bad engineering hire is.
> The end result is that, as the layers of self-entrenching management grew, basically every engineer left within 3 years
I'm currently in this situation. Our small company was bought out a couple years ago. Before, we had one meeting every quarter and now we have at least one meeting every day (if not more). The managers aren't listening when I tell them that engineers are leaving because there are too many meetings. The crazy thing is that most of the meetings aren't even related to what we actually work on, it's absolutely insane.
Hiring managers from a bigger org into a startup is the easiest trap I've seen companies fall into. And the more experienced the manager and the more successful the big-co, the worse it gets - but also, the more seductive it gets especially if the founder feels like they personally are a bit out of their own engineering management depth.
Everything needed to keep a giant super-successful post-product-market-fit company running smoothly and reliably as, say, a VP at Google, is completely the opposite of what you need to move fast when you're trying to figure out how to thrive (or even just survive).
I haven't worked in one of those "this is like a startup inside a big-co" places that you often hear about, but I imagine it's why those struggle to compete with actual startups. It's hard to act like you are facing existential risk when you just plain aren't.
Absolutely. To start with, leaders must not be afraid of their teams making mistakes. Copying from another comment: "Netflix's culture demands very strong leadership and probably works only when the company is small enough. From CEO and down, leaders in every level need to know how to set context for their teams, give enough freedom to their teams, while making sure failures are manageable and success rate are maximized. That is, Netflix assumed that people would make mistakes and fail, but the trick was to ensure that failures do not hinder overall success of the teams and the company."
I'll give an example of the leadership style of Netflix. Jordan Zimmerman, a great engineer who created Apache Curator, once asked then the director of cloud platform, Yury, if he could open source Curator. Yury just casually said: okay, do it. Jordan was puzzled and asked: "don't I have to talk to an attorney? ". Yury smiled and asked: does an attorney help you write code? Jordan said no, and Yury concluded the conversation: then you don't have to talk to an attorney.
Someone just forwarded this to me. It's absolutely a true story and it changed the course of my career as well as starting Netflix OSS. I'm forever grateful to Yuri and Ruslan Meshenberg for their support.
I suppose that's a tangible benefit to hiring well- you don't have to ask your team basic questions like these. Presumably the engineer well knows to check licenses.
Don't mind me then. I think early Netflix' management philosophy -- as far as I know about it from the outside -- was exemplary. I strongly recommend No Rules Rules: Netflix and the Culture of Reinvention.
Sort of. You can always license your IP (code) how you want. However if you distribute the GPL code together with your product you can’t say the whole bundle is BSD. (I understand you can dynamically link to GPL libraries distributed separately if you want that, but I’m not 100% sure where bundling .so/.DLL files leaves you).
This just kinda sounds like the common trope of software engineers ignoring everything that isn't involved in software engineering, and then proclaiming that they are so much more productive for it.
I mean like yea, technically they get more "done", but only because they steam roll all their other legal responsibilities
This makes a lot of sense at deep tech places that don't sell to enterprises where one can put their head down and just work on technical challenges. A similar place like Mongo DB or the hardware division of NVidia comes to mind. But if you're supposed to iterate with any input from more than 2 people that isn't highly objective (technical metrics that can correlate well with product satisfaction), communication and diffused collaboration is important and necessary. That doesn't mean it has to suck. But the Netflix model you described isn't applicable everywhere and shouldn't be blindly replicated.
This. In our tiny company, Lowdefy, we try to distinguish when something is done as part of innovation, or as a deliverable or chore. The work that falls into the two categories are vastly different in nature, stakeholder expectations and outcomes. Being deliberate about what category of work you are busy with provides freedom to thrive when innovating required while introducing the structure needed when deadlines are on the table. Mixing the two results in frustration and reduces quality and output. I would be interested to know if this applies same to larger orgs?
I assume these storie-lets are true but the timeline is wrong, it was much more than 10 years ago. I went to an Adrian Cockroft talk in 2012: they had thousands of engineers and hundreds of services at that time, Asgard already existed and was in the process of being open-sourced, etc.
Do you think this is thanks, at least in part, to the fact that Netflix is a rather narrowly defined product? It is a library of content and it streams to your screen.
In the places I've worked, the product is poorly defined. Not because we've neglected to define it, but because it's novel and amorphous and nobody knows what it should be, let alone what it will be.
Netflix on the other hand, in my view, has a clear goal: get video onto screens as efficiently as possible. It becomes much more of a pure technology problem solving situation.
Of course, I won't assume there aren't ongoing product development tasks constantly. I'm sure there's a massive back office suite, along with ads, etc.
But the overwhelming majority of the Netflix product "mandate" is pretty solid, so you don't need to spend a lot of time making sure folks are on the same page, or am I way off?
My own experience is that there was enough ambiguity in what we needed to build. Take building a CDN for instance, what tech stack would you use? How would you deploy them? What's your caching strategy? How would you partner with ISPs? What kind of hardware would you use? A large company may spend months approving every single such decision.
Wow that's so cool but makes sense! Is it not like that there anymore? They still hire experienced engineers, so I wonder what changed? As an aside, is there any low hanging fruit / interesting work left to do at Netflix?
I left Netflix years ago, so I don't know their current culture. Netflix's culture demands very strong leadership and probably works only when the company is small enough. From CEO and down, leaders in every level need to know how to set context for their teams, give enough freedom to their teams, while making sure failures are manageable and success rate are maximized. That is, Netflix assumed that people would make mistakes and fail, but the trick was to ensure that failures do not hinder overall success of the teams and the company.
Netflix was known for being very fast to fire if you stopped producing. Netflix didn't even value Netflix employees beyond what they could produce in the moment. They leaned into the zero loyalty to employees model that US corporations rely on.
Read this article which is pushing this as a positive. Grep for "Tell the Truth About Performance" to see where they talk about changing what an employees job needed. An employee they recognize had done a good job for 5 years, but wasn't what they wanted going forward so they weren't even going to try and help get her the skills to do the new job, but just lay her off immediately.
Netflix's culture stack used to say that culture is all about who gets rewarded and who punished. So, yes, people did get punished for their failures. The key here is what behavior led to a failure? We have to analyze consider the failure and the associated human behavior together and see if there is a lesson or a punishable pattern - this is where strong leadership is needed for a just assessment and action.
There is no rating. At that time, one either their job or not. There was no bonus either, as bonus contradicted to the no-rating system.
> How did they incentivize taking risks?
Taking calculated risk was also part of the culture. Good people actually wanted to take risks. So the incentive systems is to take road blocks away.
> Were Netflix employees from then valued very highly?
I think the success of the company and the quality of the employees make them marketable. Everything else is secondary.
It was a very very special place to work for a time. Everything changes, though, and I will leave it to say the Netflix I left early this year was a completely different place from the one I joined almost 8 years ago.
To expand a bit on what Aaron said, 2022 was a year where the company experienced drastic culture changes: introduction of levels, new VP&director-level leadership with more traditional / "big corp" management styles, push to hire junior engineers, decrease in transparency during decision-making, to name a few... These changes have alienated a lot of people who self-selected for the unique culture the company had, which was truly remarkable.
Netflix's competition changed. They were one of the few players in streaming. Now, there are infinite streaming platforms, all angling for their cut of the pie. For Netflix to continue to be profitable, it decided it needed to spend more on original content. Then I suppose the cost cutting came for other expenses. Hiring a bunch of very experienced engineers does not come cheap. Netflix was known for having the highest cash comp in the valley. They've started hiring new grads again, because it's cheaper to hire one senior engineer to lead a bunch of junior engineers instead of a few seniors to do everything themselves.
I’ve no clue about Netflix specifically, but at some point as an industry we have to hire some junior people in order to have new seniors a few years down the line…
