Managing Teams Through Interfaces(theengineeringmanager.com)
theengineeringmanager.com
Managing Teams Through Interfaces
https://www.theengineeringmanager.com/managing-managers/managing-through-interfaces/
5 comments
I manage at a lower level, a team of developers. I’m a big fan of stating a clear goal and letting the developer/team decide how to tackle. I may have suggestions, I may veto proposed solutions if I have legitimate problems with it, but ultimately I want them to be the drivers. In my experience they take ownership, are more motivated, and it helps them grow. They’re more likely to solve little problems on their own and only involve me as needed.
Same here. Teams need autonomy to thrive. Managers need to be able to let go.
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.
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.
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.
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.
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
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.
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.
The contradiction in management is that you must somehow know what's going on, but it is not helpful to interfere constantly.
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.