Hacker News new | past | comments | ask | show | jobs | submit login

Yeah; a lot of the solutions you see pushed here on HN don't really scale past a startup-sized company. A lot of times if you have a very large product, you have multiple engineering teams working on a layered architecture. For example, the product guys will hand off a requirement as a user story that describes "As a customer, I can push the green button and it orders a pizza sent directly to my desk." That user story involves the front-end team (UI mockups, interface implementation, etc.), the back-end team (now has to support storing and retrieving the user's pizza preferences), the billing systems team (now has to ensure the pizza billing process has the proper audit checks, etc. on it), the deployment team (who now has to ensure pizza-order messages are allowed through the firewall to the pizzeria), etc.

It's a bit of a contrived example, but you get the idea. Unless you have a centralized management function, all of this doesn't happen and your glorious pizza button either doesn't work or fails deployment. Usually the onus falls on the product manager to do this, but with so many teams involved it can be a nightmare.




The problem with the approach you describe is the notion of a "front-end team". In my view, that's not a team.

In the kind of organization I describe, teams have business purposes and are cross functional. So in your example, there'd be a pizza-direct-to-desk team. In that case, you don't need centralized management of everything.

Plenty of organizations work this way. Spotify, which has done a number of talks on their organization, works just fine with cross-functional teams focused on individual purposes. I interviewed some team members at YouTube, and they had a similar structure.




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

Search: