
Managing Teams Through Interfaces - jstanier
https://www.theengineeringmanager.com/managing-managers/managing-through-interfaces/
======
vii
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.

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.

~~~
ElatedOwl
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.

~~~
beardedwizard
Same here. Teams need autonomy to thrive. Managers need to be able to let go.

------
troelsSteegin
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.

------
kevsim
> 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.

