Okay, "struggling" might be a little strong, I'm not drowning, yet it's a somewhat appropriate word, because I am struggling a small bit on a project. I'm not struggling technically on the project, I do well figuring out problems on the technical side. It's the person side of the project that I'm struggling with a bit. A lot of the issues stem from my experience at Twitter.
When you work with someone who dismisses your ideas when you make them, then accepts the ideas when they are made by the next person at the table, you're not working with someone who accepts your suggestions on their own merit. Instead you're working with someone with motivations outside doing a job well, outside of making the product the best it can be, and outside of a professional relationship. If you're a woman in this situation, and your male counterparts are the ones repeating your suggestions and being praised for your great suggestion as if it were theirs, well, you have a bad work situation that will be resolved only with outside help.
I would argue when the situation hits that point, the group is suffering from a severe lack of trust. The developers know the project manager distrusts their opinions. The project manager knows the developers distrust his direction. It becomes a clusterfuck of CYA and the whole system dissolves into low productivity, crappy quality and meager output. It's hard to break out of the death spiral of no trust. I'd also argue that it is impossible without one or both sides committing to establishing trust.
This project I'm on is heading to that place. The new project manager bullied his way into the project, barking orders left and right, throwing out solutions, setting agendas without feedback from the developers, and expressing undeliverable expectations. Throwing more developers or more time at a project won't solve the problem. Throwing solutions over a wall without explaining why the solution is the best, or worse, just throwing solutions over the wall and not throwing problems, is awful. Having expectations or promising output without consulting the people doing the work is a guaranteed path to disaster.
I don't want to be a on a project that is on that path.
I won't be on a project that is on that path.
The best way I can figure to step off that path is communication. This is where I am, this is where the project is, these are the tasks completed, those are the issues we were having, that is why the project is delayed, this was never communicated to us, this is what we think needs to be done to get us back on track, these are the people to talk to, these are the resources we need, this is what we tried before, this is what we'd like to try next, here is the suggested way we can recover this project. Start there. Over communicate. Talk talk talk talk, email, talk, summarize, expand, document, talk.
At some point, in a good case, everyone will be on the same page, the project recovers, we have success. Everyone cheers.
In a bad case, the best thing to do is move onto a different project. Understand why the project lacked trust, let the participants know how they failed _without insulting the person_, and move on.
I've not given up on this project. I think it can be recovered. Trust is key, communication gets us there. I like to stop struggling with the lack of reciprocity on the effort, and get there faster. We'll see.
When at 
