5 ms·

Importantly, this requires mature engineers and managers. Nothing worse (from personal experience) than working at a place that hires experienced engineering ta

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.

g9yuayon 3y ago
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.
- esafak 3y ago
  > does an attorney help you write code? That does not sound like the right question. How about: have we vetted our dependencies' licenses?
  - progman32 3y ago
    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.
  - andrewstuart 3y ago
    Man you just harshed the vibe of this free spirited Netflix love-in thread.
    - esafak 3y ago
      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.
  - hgsgm 3y ago
    Why would someone go to the effort of republishing dependencies?
    - zaphirplane 3y ago
      Can you have a gplv3 dependency and licence your project under bsd
      - andyferris 3y ago
        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).
- dilyevsky 3y ago
  Hah I think Yury leads the Clickhouse development now. I interviewed with him and he seemed like a very interesting guy
- lovich 3y ago
  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
- Randgalt 3y ago
  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.
  - g9yuayon 3y ago
    Hi, Jordan! :-) I consider myself lucky to have worked with you.
throw3823423 3y ago
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.
- ravenstine 3y ago
  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.
- reaperducer 3y ago
  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. "People join companies. They quit managers."
- bonestamp2 3y ago
  > 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.
aledalgrande 3y ago
This in my experience can go up to the VP level and C suite too in startups cringes at bad memories

g9yuayon 3y ago

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.

esafak 3y ago
> does an attorney help you write code? That does not sound like the right question. How about: have we vetted our dependencies' licenses?
- progman32 3y ago
  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.
- andrewstuart 3y ago
  Man you just harshed the vibe of this free spirited Netflix love-in thread.
  - esafak 3y ago
    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.
- hgsgm 3y ago
  Why would someone go to the effort of republishing dependencies?
  - zaphirplane 3y ago
    Can you have a gplv3 dependency and licence your project under bsd
    - andyferris 3y ago
      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).
dilyevsky 3y ago
Hah I think Yury leads the Clickhouse development now. I interviewed with him and he seemed like a very interesting guy
lovich 3y ago
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
Randgalt 3y ago
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.
- g9yuayon 3y ago
  Hi, Jordan! :-) I consider myself lucky to have worked with you.

throw3823423 3y ago

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.

ravenstine 3y ago
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.
reaperducer 3y ago
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. "People join companies. They quit managers."
bonestamp2 3y ago
> 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.

aledalgrande 3y ago

This in my experience can go up to the VP level and C suite too in startups cringes at bad memories