I generally find that you can't effect change if you only deal with problems reactively as they come up. I find that people are more receptive to feedback if op

I generally find that you can't effect change if you only deal with problems reactively as they come up. I find that people are more receptive to feedback if open dialogue is part of the culture of the team. One way to start cultivating this type of culture is with post mortems. It usually involves reiterating every 30 seconds that it is not a finger-pointing exercise, but a session to identify future goals for improvements, in order to maintain the positive tone throughout the session. Regular planning meetings are another place where it's possible to market the practice of open dialogue. Since these are already focused on upcoming objectives, it's easier to bring up concerns and discuss it as a team. It's also a great opportunity for quieter team member to voice support for something you believe in, which helps an idea gain more traction. Likewise, it helps you stay humble when people disagree with you and bring up arguments that you had not thought about before. Another place where dialogue can be cultivated is through documentation. I don't mean a passive-aggressive README in the repo that nobody is going to read. I mean through active discussions in tasks-related tickets. There's something about writing things down that helps make vaguer ideas more concrete and actionable. Semi-related to the previous point is code reviews. The idea here is, again, not to confront or alienate a co-worker, but to give actionable feedback in small enough chunks that someone would feel motivated to do, out of a sense of perfectionism or whatever. Code review also let you familiarize yourself with things that are coming. The challenge with code reviews is that they are difficult to start if they team isn't already on board with it. You can start by pushing commits to code owned by someone else and then nagging them to review it. The idea is to gradually push for a workflow where landing changes (at least large ones) should require someone else's approval. But again, this newfound "power" should not be used for rejecting work, but to foster early communication. As you grow communication channels, you can also use them to convince others that you should be the one to do the work that you care about. The biggest trap you should avoid is falling into the "they are stupid" mentality. If things become adversarial, it becomes very very very hard to persuade people. Also, be humble and be realistic. Sometimes decisions that you don't agree with have reasons that have not been brought up to you and that you had not thought about. And sometimes, things will indeed just turn out to be bad even with your best efforts and hopefully those times will be a learning experience for someone. At those points, focus on what can be done, and start the dialogue again.