It's not ok to set goals and let people just get on with them. The result of that is the most extraordinary implementations; it's just not possible to lock down requirements clearly enough to have the right outcomes come out without massive communication of implicit context.<p>The contradiction in management is that you must somehow know what's going on, but it is not helpful to interfere constantly.<p>I don't see how this framework helps with what I think is the most difficult problem in management: how to deal with talented people who aren't connecting to impact in their current roles. If you don't reward them, they'll leave. If you reward them, everybody else will be justifiably jealous. Setting interfaces doesn't help you figure out how to unblock them and might make it worse.
Interfaces are contracts between caller and provider. James Stanier, the author, is using interfaces as contracts in order to make expectations explicit while delegating out the provider's implementation.<p>He does not address the contract that you as a manager fulfill as a provider for your reports. He should. Given the volume of material on his site, I'd expect he addresses how managers serve elsewhere.<p>Stanier is talking about managers managing other managers, so the units of implementation are people who orchestrating other people's work and who are serving the needs of their teams in turn. A manager of managers has an interest in "what", the contract, and as well as "how well", the return, and following that, with exception cases, the causal question of "why". As a manager of managers you need to know enough specifics to quickly understand and add value in situations where your chief service is exception handling and diagnostics.
> Which processes will be used to run the team<p>As a manager of managers, I could not possibly care less. I'd certainly leave that one out of any "interface" I was designing. That's strictly an implementation detail.