Ok, so you can read guidelines on identifier naming \'til you\'re blue in the face... camel case, pascal case, make \'em descriptive... but they won\'t help you actually pic
A good point is to use design patterns and you'll have all done :)
If you're in a .NET environment, you can use FxCop for guidelines. As far as naming a class, I usually will go with noun/purpose. You're exactly right, what does the Manager class do? If it's a controller class, call it ManagerController.
1) Don't abbreviate. Use acronyms only if they are industry standard ones like HTML.
2) Be self-consistent in your names.
3) Use terms from the domain your application is in. When coming up with a name, pretend that you have a limited number of bullets to spend when adding new names that people won't be familiar with.
You might feel that some subtle feature in your class differentiates it from a 'Foo,' and feel inclined to make up some new concept for it because of that subtle difference. If 80% of people using it won't care about that subtle difference, stick with the known term.
4) In most OO languages, autocomplete matters. When possible, the first word should tend to be the one that people are most likely to type in when exploring a namespace. Other people feel that having it read well in English is more important, so this is kind of debatable.
When I find it difficult to pick a meaningful name, it alerts me that the class is too big or I don't really understand the domain of whatever I'm coding.
When you do finally come up with a good design addressing the concerns brought up by Uncle Bob in Clean Code regarding concepts like appropriate abstraction, single responsibility principle and whatnot, then the names become easier to pick.
Difficulty picking names is almost always a sign that the logic's organization still needs work. After all, the compiler doesn't care how well or poorly your logic is organized. Organization is there only to help manage complexity and the sanity of your fellpw developers.