The best race car drivers are not only the ones who can drive well but can also communicate clearly with the pit crew on how to set up the car (eg tyre pressures, suspension settings, etc). They understand the adjacent fields and are able to communicate with them. They’re not mechanics. They leave the task of setting up the car to the experts, but they do have enough knowledge about the setup of the car to to transpose the sense of how it feels and how it can be optimised.
OSS is the same. You might be brilliant at what you do within your role in OSS but in almost all cases you will also have multiple adjacencies to align with and communicate with to ensure the car is running optimally. This requires a thirst for questioning and empathetic learning from the adjacencies rather than the more prevalent practice of demonstrating brilliance in your field of expertise.
The other part of the race-car analogy is that race teams are constantly tinkering with the settings to try to optimise outputs for the changing conditions. Whilst OSS doesn’t do laps (although OSS projects can go around and around at times) thus allowing lap times to be compared for a given setup, we can learn from the analogy by tinkering, testing, measuring and refining. We definitely do a lot of tinkering, but we don’t always have a clear set of measures to test and refine against.