The analogy is gonna be strained, but the real problem is the way SRP is stated as “only one potential change in the software’s specification” - this is not person centric. The way OP started this is more the way SRP was initially misinterpreted as a module should do one thing and only one thing. That’s actually more the Unix cli philosophy of “do one thing and one thing well” — but it’s not SRP.

Internally, we don’t try to pre-determine if a module follows SRP, we use actual changes being made to the system to identify modules that are changing as a result of different actors/people. We then refactor a module to split it so that it once again is aligned to one axis of change.