Armed with [edit: never quite] all there is to know about solving scalability problems, it's just short of impossible to walk onto a client site and fix their poorly performing application. Changes to the system require an understanding of what the system does and it's intended interactions with other systems. This complex hierarchy of dependencies starts with lines of code (hopefully encapsulated in object-oriented classes if it's C#) and quickly jumps from other processes on the same machine to distributed processes owned by other teams (especially if SOA has been employed). How do we know when we've broken some undocumented feature? Unit tests? Hardly anybody uses them. Integration tests? Does your team even know what they are? Who writes these tests, and when?
If the tests don't already exist, it will be much more difficult to determine that a scalability fix hasn't negatively altered the required behaviour of a process. But in a time when the bottom line is the final word and employers are encouraged to differentiate developers by price (for example: choosing a large off shore team) it's less common to see the tests written up front.