We use an 'I' prefix for interfaces and that's about it. Generally speaking, we try to comply with the language (we use multiple) for naming conventions to avoid having to mix conventions in our code for places where we're required to comply with the existing conventions. We don't go against the language standards, so to speak, as that would require us to mix conventions.
After working with various projects and coding standards over the past decade, I've come to believe that the more exotic standards become and the more they impede into subjective domains, the more likely they are to turn people off completely which can seriously hinder the team's productivity.
There are good practices that help to make code easier to debug, for instance (don't cram multiple statements on one line, e.g.), and help to produce more efficient, robust code (define variables when they can be sensibly initialized with limited scope), but the ones which don't have very unbiased, objective arguments in favor of them usually demand developers to subscribe to someone's personal preference.
With naming conventions in particular, some practices are just downright harmful and counter-productive. Hungarian notation, e.g., places a predominant focus on types when modern developers should generally be concentrating more on the interface(s) that a type provides and polymorphism than on the specific types themselves. I'm not particularly fond of the 'Manager' convention either, as most high-level classes that make use of composition would often be considered to fit into that category and then the suffix becomes quite superfluous and used far too often.