In physics, entropy is the measure of disorder (well, not exactly, but let's roll with this for now, and I'm not a physicist to be pedantic on this anyway). In nature, systems tend towards increasing this entropy. For example, if you eat an apple, then you take a nice orderly fruit and turn it into disorderly heat, as well as really disorderly thoughts. This increases entropy. Contrastingly though, if you eat a bowl of Elon Musk's tweets (X posts?), then what comes out of your other end will be significantly more ordered than what went in.
Our big luck is that we have the sun in our neighborhood, which gives not just electricity for us to make sand think to read such letters, but it's also our source of low entropy (see this great Veritasium video about it). Basically, we all make a big mess, but we siphon the sun for that tidy energy, so we can continue to exist and engage in highly sophisticated debates on Twitter.
I think there's a similar dynamic of low and high entropy in human relationships, social structures, business entities, and software development teams too. Some people will increase the entropy of the system (couple, community, company, project team), and some people will work on decreasing it. E.g., you might leave the butter out around the kitchen, but your partner will always put it back into the fridge, so when anyone needs it, it's always in the same place. There's a balancing act here: The system needs to keep a state that's low entropy enough for it to function (if you open the fridge, the butter needs to be there, otherwise your hangryness will take over) but this can't come at the expense of the low entropy people giving up (your partner throwing the damn butter at your face if you leave it out one more time). Ideally, the optimal level of entropy is the same for everyone, but if not, then the people infusing the low entropy (putting the butter away) should be happy with their role in the long term. If this is not the case, eventually, the system will disintegrate (and you can enjoy your awful room-temperature butter alone).
Talking about a software development team, entropy is increased by e.g. writing sloppy code, not being attentive in communication, not following common standards, not keeping promises. Then somebody should work on lowering entropy by fixing the code, refactoring, asking the person repeatedly, chasing matters up. If this is not done, the team will eventually cease to deliver.
In my experience, productive development teams, i.e. those who consistently deliver high-value products to end-users, are usually where either everyone is of the low entropy type, or where key energetic people keep everything in check. In a good team, the latter are also developers, engineers themselves. When a manager type tries to keep entropy low against their team (there are entire methodologies for this like Scrum) then it usually doesn't work, and even low entropy developers can stop caring.
Note that I'm talking about entropy, not uniformity or homogeneity. Open-source software development can deliver spectacular results with team members being anything but uniform, or, to an uninitiated observer, even being bafflingly chaotic (the deservedly cultic essay "The Cathedral and the Bazaar" is about this phenomenon). This is because it's important to understand where low entropy actually matters, and only put effort into trying to enforce it there. Successful open-source teams instinctively know this, and usually, it's all about code quality. As long as you write good code, i.e. don't increase the entropy of the code base itself, your contributions are welcome (unless you're an insufferable jerk, but sometimes even then). Inefficient teams in large organizations, in contrast, put a lot of effort into enforcing superficial rules and processes, driving uniformity, instead of focusing on low entropy driving value.
The idea behind us at Lombiq trying to organize ourselves more as an open-source team than a company stems from a similar rationale. This style is certainly not for everyone, since most people can't function without a consistent outside source of low entropy (the sun excluded, we all kind of need it). But I think, at least when you want to run your own development team, you need to try to surround yourself with people who thrive in a low entropy environment, and who themselves can be a source of low entropy when needed.