> For even moderately complex projects, you need to work with a team, and being "nice" - which just means not being a jerk - is pretty essential for working even with an all technical team.
Would you call Google a moderately complex project? Because Google is very much focused on individuals rather than teams. Sometimes individuals works together, but it isn't required and you can spend your entire career just working on your own separate problems.
Of course Google also has lots of people who are competent at organizing and talking to people, but having a ton of engineers you can give a well defined problem and they will build a great solution without any extra input is still great to have and you can use that to compose reliable solutions to huge problems. There is no reason work groups needs to be teams rather than individuals.
> Would you call Google a moderately complex project?
Yes... but Google is my employer of well over a decade, so I might be biased on the complexity of the problems worked on here.
> Because Google is very much focused on individuals rather than teams. Because Google is very much focused on individuals rather than teams. Sometimes individuals works together, but it isn't required and you can spend your entire career just working on your own separate problems.
This is untrue in nearly all of my experience at Google. I'm not sure where you are getting your information from, but it's a big company, so maybe there are some corners where that might be true, but it's far from the norm.
ICs at all levels are expected to do a lot of intra and inter-team communication and collaboration. You could limit your opportunities if you choose to silo yourself.
> having a ton of engineers you can give a well defined problem and they will build a great solution without any extra input
This is what interns and entry-level engineering hires do at Google, with the strong expectation that they move beyond working on unambiguous problems into tackling harder problems with more ambiguous and often conflicting requirements.
Have you worked at a team outside of Google? I don't think you understand what people mean when they talk about teamwork. 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 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.
> This is what interns and entry-level engineering hires do at Google, with the strong expectation that they move beyond working on unambiguous problems into tackling harder problems with more ambiguous and often conflicting requirements.
Right, they tackle problems on their own, that was my point. They are expected to figure out requirements etc, and ask the questions needed to be asked. That greatly reduces the amount of communication needed compared to the teamwork approach where you split this project up into 10 parts and those are done by different people who go and ask a lot of different questions that then needs to be communicated and then some things were missing so people have to go and ask more things etc.
Communicating with stakeholders and users is very different from communicating with teammates. First and foremost the quantity is much lower, so people who burn out quickly from social interactions can still manage. Lets say a person gets burned out on social interactions after 5 hours a week. That is enough for an hour of meetings a day and then individual work, more than enough to work as a senior engineer at Google (non manager), but that wouldn't be nearly enough to work at most places where you need to communicate a lot just to code.
> 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".
Would you call Google a moderately complex project? Because Google is very much focused on individuals rather than teams. Sometimes individuals works together, but it isn't required and you can spend your entire career just working on your own separate problems.
Of course Google also has lots of people who are competent at organizing and talking to people, but having a ton of engineers you can give a well defined problem and they will build a great solution without any extra input is still great to have and you can use that to compose reliable solutions to huge problems. There is no reason work groups needs to be teams rather than individuals.