Hacker News Reader

Comment by version_five | Hacker News Reader

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.

View on HN

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.

"People join companies. They quit managers."

> 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.

> does an attorney help you write code?

That does not sound like the right question. How about: have we vetted our dependencies' licenses?

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.

Man you just harshed the vibe of this free spirited Netflix love-in thread.

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.

Why would someone go to the effort of republishing dependencies?

Can you have a gplv3 dependency and licence your project under bsd

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).

Hah I think Yury leads the Clickhouse development now. I interviewed with him and he seemed like a very interesting guy

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

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.

Hi, Jordan! :-) I consider myself lucky to have worked with you.

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

Reply on news.ycombinator.com