Is there any strategy to partition the classes to apply Single Responsibility Principle?

Is there any strategy to partition the classes to apply Single Responsibility Principle?

In a medium size team, we are developing a wearable manager app which can connect with different types of wearables, let’s say, Wearable1 and Wearable2 (single connection at a time). Each wearable device has different types of capabilities to exchange data. So I decided to partition the responsibility based on wearable types. i.e.

interface Manager {
    // common functionalities
}

class Wearable1manager implements Manager {
    // Manages wearable1 specific functionalities
    // as well as wearable1 related capabilities
}

class Wearable2manager implements Manager {
    // Manages wearable2 specific functionalities
    // as well as wearable2 related capabilities
}

One of my colleagues is denying my design saying it is violating the Single Responsibility Principle (SRP) because Capability related functionalities should be handled by Single capability manager. His proposal is like,

interface Manager {
    // common functionalities
}

class WearableManager implements Manager {
    // Manages wearable1 specific functionalities
    // as well as wearable2 specific functionalities
}

class CapabilityManager implements Manager {
    // Manages wearable1 related capabilities
    // as well as wearable2 related capabilities
}

Basically, I found that we both are emphasising to apply Single Responsibility Principle but our thought of dividing responsibilities are based on different aspects. I often find me in such critical situation when I need to decide based on which responsibility I should partition the classes. So my question is,

Is there any specific guideline for OOP design which helps to take decision to partition the classes to apply SRP? Or is this dependent purely to experience? I hope there should be specific sets of steps to analyse and resolve this confusion. Suggestions from experienced are appreciated.