I speculated on Twitter that adding members to a software team reduces the number of new technologies that team can use. This is because unless all members are comfortable with a new technology, adding it can cause a Conway's-law-like split. For example, a system written in Java and C++ might split into two systems managed by two different teams, each exclusively using one language. The resulting teams would each have a less diverse technology stack, further contributing to the pattern. This speculation is based on my personal observations that smaller software teams tend to be more diverse in the primary languages and tools they use, while larger teams tend to be less so (i.e. "We use anything that works" vs "We're a Java shop"). 

To examine this a little closer, I first need to explain what I mean by a "team". A team is a group of people who succeed or fail together. If you can fail while I succeed, then we're not on the same team. What success means for a software team varies, but it's harder for members of a team to participate in the success of that team if they can't contribute equally. A simple way to achieve this is to have every person do/know everything. As I examined in Powers of Two, a pair of programmers can do this quite easily.

As a team grows, it's less likely that every person on the team will be able to use all technologies equally. A common reaction to this is to limit the number of technologies used, relying only on the ones that everyone on the team can use effectively. As more people are added, the only common technology becomes a single language or platform, and the primary prerequisite for joining the team is that you know this technology well.

Adding a new technology into this mix can cause the team to fracture along the technology boundary. If some programmers prefer working in one language/editor/platform or another, or have a preference for working on the type of problem that technology was adopted to solve, the goals of the individuals on the team can begin to diverge. Unless the team takes steps to resolve these conflicts, they will eventually lose a common definition of success.

As one sub-group starts to view success differently than the others, the pressure to split increases. The wider organization can respond to this by changing the org structure, by rolling back the addition of new technology, or by forcing the individuals to continue working as a single unit with divergent goals. In two of these three cases, you wind up with teams with a technology monoculture...the same result as if you had never introduced the new technology at all.

This idea is speculative, but I do think it's something you could measure empirically. If you could find a way to tease out the actual teams, Github organization data might have everything you need. You could see how many different languages each team regularly uses, and try to compare that to the size of the team to see if there's a pattern. I'll leave that exercise to the Github data mining experts.