It's about having one unique rôle.
Each class should be resumed by a role name.
A role is in fact a (set of) verb(s) associated with a context.
For example :
File provide a file's access.
FileManager manage File objects.
Resource hold data for one resource from a File.
ResourceManager hold and provide all Resources.
Here you can see that some verbs like "manage" imply a set of other verbs. Verbs alone are better thought as functions than classes, most of the time. If the verb imply too much actions that have their own common context, then it should be a class in itself.
So, the idea is only to let you have a simple idea of what does the class by defining a unique role, that might be the agregate of several sub-role (performed by member objects or other objects).
I often build Manager classes that have several different other classes in it. Like a Factory, a Registry, etc.
See a Manager class like some kind of group chief, a orchestra chief that guide other peoples to work together to achieve a high level idea. He have one role, but imply working with other unique roles inside.
You can also see it like how a company is organized : a CEO isn't a productive one on the pure productivity level, but if he is not there, then nothing can work correctly together. That's his role.
When you design, identify unique roles. And for each role, again see if it can't be cut in several other roles. That way, if you need to simlpy change the way your Manager build objects, simply change the Factory and go with peace in mind.