There's often the hidden assumption that "solving technical problems" equals "creating value", but that's not always so. Lack of communication often leads to solving the wrong problems, solving more general/complex problems than needed, overengineering the solution over actual needs etc. To avoid this, it's a good practice to talk about stuff you work on and getting feedback from other people, including questions you yourself did not think of.
I deprioritized collaboration as a result and now I get much better results. It’s not an issue because I am happy to explain the trade off up-front to anyone who asks. My job title is “software engineer” and my job role is to ship code. If you want me to be a staff+ engineer, engineering manager, or PM, happy to chat about a role change, but until then collaboration needs to take up a minority of my time.
But once in a senior position, a person should start thinking "larger" than just their own code, especially if they want to further advance.
> but until then collaboration needs to take up a minority of my time.
For sure. I would say from Staff position upwards, the collaboration aspect might take a larger chunk than pure engineering.
All this is of course very organization specific.
I’d say you’ be taken the wrong lesson from your observations.
Big formal coordination rituals typically are simply round robin of 1:1 communication. Occasionally 1:3, but never ever 1:n when the speaker isn’t management.
The reason is simple. Tasks are often independent. In that case, there’s no one to coordinate with, beyond updating the person running the status board. Even when there is a take that needs coordination, that coordination is already happening, just not at that place.
Or in other words, people that get the most out of these rituals simultaneously overestimate the average degree of connections in the social network, and underestimate the amount of communication that happens outside of their immediate view. Call it a bias in a local a hub in a network.