Communication skills in a team.

If you're a junior developer, don't be afraid of asking questions. How does particular module in project work? There's things that are not on the internet. And other programmers have knowledge you need to be good junior developer. But when you have your answer, write it down, so that you won't be asking the same thing twice. Remember also about internet, documentations, source code, issue tracker... sometimes you don't need to ask if you can check it yourself. But overally asking is way to go. There's many thing specific for project (e.g. requirements) that you won't predict if you don't ask

If you're a regular developer, you still will need to ask questions if you don't know something, but you need to be more proactive in your communication. You shouldn't be only focused on your task, but communicate to help other people or to gain insights about project/its progress/implementation details/architecture approach etc. It's time to be more assertive and to be able to defend your technical decisions in front of others.

As a senior developer you will need skills of both junior and regular dev, but also you should be more responsible for whole team. Especially if not everyone on a team has great communication skills. You need to be able to solve some communication bottlenecks. E.g. why this junior developer has poor performance and doesn't manage to do their tasks? Sometimes you need to step in and ask directly if somebody understands everything (some junior developers won't ask themselves). But also you need keep balance in a team. Sometimes most loud programmers have most influence in a team, even though they propose stupid solutions or don't respect other people. You as a senior developer should notice such situations and mitigate them.

As a PM (or Product Owner, Scrum Master and other non-technical roles) you should have previous skills but also be able to get along with people of various specializations (programmers, designers, stakeholders, customers etc.) and often serve as a proxy between them. You should also be more inquisitive. And I don't mean "controlling" because micro-managers also may seem inquisitive "when this feature will be done?". But I mean things more like "what does block you from do this task?". Or "Maybe we don't need this feature if it turned out to be harder than we thought?" Or "Why are we past deadline, what gone wrong?" or being curious about others work (e.g. "I'm not a programmer but I learned about Git or what 'classes' and 'methods' mean in programming, because I want to have better understanding of programmers work").