I noticed that very technically focused people tend to underestimate the importance of communication. They dislike daily standups, coordination meetings, don't really value informal exchange. All these things take their time out of what they want to do - deep work on solving technical problems.
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 used to prioritize communication and collaboration because I’m better at it than most engineers I work with. A problem emerged where I noticed that come review and promotion time, I was always coming up short due to concerns about lacking technical seriousness. My interview performance was also suffering due to not spending enough time in the codebase.
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.
That's an interesting experience. I agree that this advice is probably more valuable to people who are already quite senior technically. Before that, it might be better to simply focus on sharping your technical skills. Reflecting on my experiences, I remember junior-ish people who chose to focus on communication rather than technical skills - without being able to back their communication with hard skills, they seem to kind of drift toward scrum master / project manager role.
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.
> I noticed that very technically focused people tend to underestimate the importance of communication. They dislike daily standups, coordination meetings, don't really value informal exchange. All these things take their time out of what they want to do - deep work on solving technical problems
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.
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.