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

I worked at Google for many years.

Google is so huge that it's extremely common to know you have an important bug for another team, but not to be able to route it to them because you can't find their team name.

Most teams have "code names" that have nothing to do with the public name of the project. For example, the parental controls team might be named "pigglewiggle-team" and the Android contacts team might be named "katniss-team" and their bug components might have similarly obscure code names. If you don't work with those teams frequently it can be really daunting to find.

Even when the bug components have hints that get you close to the right place, it's not unusual to learn that most of the engineers are busy working on the new version of the app that isn't released yet, and the old version of the app (the one with the bug) has been destaffed and bugs are supposed to be routed to some other random team that's literally never touched the code.



This giving codenames to projects thing seemed so endearing when I was working in a team and company of 10, but now that I’m working in a team of 100, and an org of 2000, it’s so extremely aggravating.


So, it isn’t just my company that does all of the above. I guess that’s good to know. At least we aren’t the only dysfunctional ones.


I think any company that has more than 1 employee leans towards dysfunctional


Any large bureaucracy seems to do that. Either you have a relatively flat org chart, but then teams have limited visibility past their "neighbors". Or you have a deeply nested hierarchy, where there's a clear path to route requests to any given place, but it takes ages because of all the red tape involved in escalating it sufficiently to route it properly (and then people try to avoid that hassle).


I think it's safe to say their competitor does not have this issue.




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

Search: