Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

IMO the best approach is to have as little shared infrastructure between teams as possible even if it means more work in the end

That's the route to shipping features faster for sure, but it costs more, requires duplication of effort, and is really painful when you discover two teams built the same thing and you want to unify on one version rather than paying to run and maintain both. Plus, when the cost cutting comes in the bad times, you find whole teams are axed because you don't need two sets of people doing the same job. The remaining engineers then have to unify the features but without the resources to get the work done and without access to the institutional knowledge required to understand the version they didn't build themselves.

If you're an engineer in a FAANG it's not a bad solution to the shipping issue. If you're anywhere else it's a road to absolute chaos.



You do bring good points, I was a bit too forceful with the language in my original message. "Most of the time" was probably better language to use.

In my experience shared infrastructure is less prone to breakage on reorgs because "platform" teams usually get the axe first as they are not directly delivering value (from upper management perspective at least)

IMO each team should maintain their own infra and tools and be free to choose what works best for them within reason, a few exceptions need to be made of course like having unified authorization and the like, infosec is usually better to be a separate team consulting to individual product teams, etc


Only speaking as a FAANG engineer, but it's absolutely essential to shipping anything as a vertical team. If you depend on updates to any platform that isn't federated to enable your own siloed development: good luck.


What does federated mean in this case




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: