Project managers who don't observe work flow
Related to your #10, I worked at a place where I "evolved" into a multi-tasking role. It's not something I asked for. It just became necessary, because we didn't have the right mix of staff to delegate everything that needed to get done. I got a new project manager, after having worked there for 2 years, who assumed I would follow a linear schedule, but that was impossible. He didn't observe or ask me about my work flow at all. He tried to impose one on me, but if I had followed it, some IT operations would've fallen apart. I tried to explain that to him, but he didn't listen to me. He tried to compensate for what I did by reassigning staff to do some of my "diversionary" tasks. My memory is it didn't alleviate my multi-tasking, and he just had to deal with it, or else we wouldn't have gotten anything done.
Just a word to project managers. It's very disconcerting when the software team feels like what you want is out of sync with what they know needs to get done. Depending on the makeup of the organization, people may have found it necessary to multi-task just to keep the whole operation "up." If you're trying to change the work flow by adding/reassigning staff, it's going to take time to do that. "Hit the ground running" doesn't work in this situation at all, and creates disruptions to your entire operation if you insist on it.
Related to your #5 and #6, another problem with large teams is they can miss *huge* tasks, especially if parts of the team are not allowed to communicate with each other, and/or there's dysfunctional communication among the staff (possibly caused by management practices). At this same company, with the same project manager, I discovered a critical task that was not scheduled, and no one was assigned, *two days* before a large system was going to be tested by a client. It resulted from a miscommunication between a software architect and another project manager, who worked under mine. My project manager tried to coordinate a fix for the situation, but did it badly, because he tried to assign blame. I think the reality was it was nobody's fault. The right hand simply didn't know what the left hand was doing. It was a systemic failure. We managed to pull it out, and it was a contractor who I hadn't even met before this who saved our ass. He had been using his experience and a design discipline in his code on the affected system, which enabled me to coordinate a technical solution that a team I assembled could implement quickly, which connected two systems together. It was still a close call, though. We were literally testing and debugging the system, including our "fix it quick!!!" fix, up until 5 minutes before the customer did their first test on it. It was surreal. I always thought those scenes in action movies where something big is gonna blow, the hero pulls it all together in the end with a team, yells "NOW!", someone presses a button, and the system that saves them all starts up, and works, were just fiction! The customer didn't notice any of the chaos, and that's the way it should be, though of course we would've all preferred if the chaos hadn't existed in the first place!
