In response to my previous post on engineering culture, Bill Higgins asked in the comments:
Recently I worked on a project with multiple sites, and one of our toughest problems was the vast cultural differences between the sites. As a trivial example, one of the sites was militant about test automation and another site barely paid lip service to it.
So it seems like there is some happy medium between “multiple, incompatible cultures” and “monoculture”. I would be interested to hear your thoughts on where cultural homogeneity is helpful and where it is harmful.
It seems to me that the problem here is not diversity but rather failure to reach consensus. One big challenge when it comes to building engineering teams is figuring out which things everyone has to agree on and which things everyone can do their own way. For example, if you’re a Python shop, everyone can use the text editor of their choosing, but everyone has to use spaces or tabs, mixing the two is not an option.
Similarly, test driven development only works if everyone on the team practices it. If you’re not writing tests, it’s really easy to write code that is nearly impossible to test. Similarly, if there’s no continuous integration infrastructure, the people who aren’t writing tests will regularly check in code that breaks the existing tests. Teams have to reach some kind of consensus about these issues with team-wide implications.
To me this is a separate issue from avoiding monoculture. Teams have to reach consensus in order to function well. I read someone who said that in interviews, they look for people who are willing to “disagree and commit” when they can’t reach consensus. Oddly, I find that these situations arise as often on teams with no demographic diversity (read, composed entirely of white guys) as they do on more diverse teams.