> Lets take a project you would give to one junior engineer at Google, at a typical large company they would give that to a team of 5
This statement lacks any sort of basis for the 1:5 Google:Non-Google staffing ratio you are quoting. I'm not sure where you are getting it. Even though I work there, I don't think Google engineers are 5x as "effective" as a typical engineer at another large company, they just often deal with problems specific to Google's technology and scale.
If anything, large companies like Google can afford to staff their projects with a deeper bench than smaller companies - in part to mitigate burnout caused by being overworked, but also to maximize knowledge sharing and minimize knowledge silos. It's not a good thing if only the person who wrote a system understands how the system works.
> and then they would need to communicate and talk a lot with each other how to get that project done, all that communication disappears when you work like Google does.
That's not my experience at all at Google. It's the opposite: engineers at all levels communicate and talk a lot with each other to get a project done. In fact, we rely on these conversations heavily to validate our ideas and get constructively critical feedback on our approach. It's wired into the process, from design documents through to code reviews. Very often these can require F2F communications and even negotiations when engineer-time is a constrained resource. So I'm not sure what you mean by "work like Google does".
Many
> Lets take a project you would give to one junior engineer at Google, at a typical large company they would give that to a team of 5
This statement lacks any sort of basis for the 1:5 Google:Non-Google staffing ratio you are quoting. I'm not sure where you are getting it. Even though I work there, I don't think Google engineers are 5x as "effective" as a typical engineer at another large company, they just often deal with problems specific to Google's technology and scale.
If anything, large companies like Google can afford to staff their projects with a deeper bench than smaller companies - in part to mitigate burnout caused by being overworked, but also to maximize knowledge sharing and minimize knowledge silos. It's not a good thing if only the person who wrote a system understands how the system works.
> and then they would need to communicate and talk a lot with each other how to get that project done, all that communication disappears when you work like Google does.
That's not my experience at all at Google. It's the opposite: engineers at all levels communicate and talk a lot with each other to get a project done. In fact, we rely on these conversations heavily to validate our ideas and get constructively critical feedback on our approach. It's wired into the process, from design documents through to code reviews. Very often these can require F2F communications and even negotiations when engineer-time is a constrained resource. So I'm not sure what you mean by "work like Google does".