this isn't purely laundering blame. it is frustrating for the infrastructure/operations side is that the dev teams routinely kick the can down to them instead of documenting the performance/reliability weak points. in this case, when someone complains about the performance of the site, both dev and qa should have documented artifacts that explain this potential. as an infrastructure and reliability person, i am happy to support this effort with my own analysis. i am less inclined to support the dev team that just says, "hey, i delivered what they asked for, it's up to you to make it functional."
> From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.
this belittles the intelligence of the dev team. they should know better. it's like validating saying "i really thought i could pour vodka in the fuel tank of this porsche and everything would function correctly. must be porsche's fault."
Yes, but can you blame someone for trying when all the gas stations are 1000 miles away? That's the exact situation the devs are put in all the time.
Oh, and the rest of the business doesn't even know what a car or gasoline are!
this still undersells the developers' intelligence and presses the metaphor a bit too far. if the implication is that the developers are unaware of (or do not have access to) infrastructure capabilities, that's seems like a procedural failure (communication, education, information, etc). i wouldnt expect developers to know everything, but i'd expect them to be curious about how their work will interact with the goal, at large.