Thoughts on Saumil Mehta's Five Principles for Successfully Managing Managers

Saumil Mehta wrote an interesting article titled Five Principles for Successfully Managing Managers. A colleague from our Leadership Team forwarded it to all of us. There’s some good thinking in there.

Different Roles, Delegation, Trust and Support

Mehta’s point about realizing that the role is very different when you go from managing individual contributors (ICs) to managing managers. This seems obvious, and to some extent it is, but I think he’s mostly trying to point out the increased abstraction.

While he encourages skip leaders, his term for managers of managers, to still “go to the Gemba” (or have direct conversations with ICs), he warns about exerting direct influence on them, and instead working with these ICs’ line managers if corrections are required. At the same time, skip leaders obviously have less knowledge about the details and less context. So they have to work at a higher level of abstraction.

This goes back to “working on the machine, not in the machine”. This phrase is usually directed at founders, but the same ideas apply here. Instead of diving into the issues at the technical level, skip leaders work at the organisational level. It’s about allocating resources (as illustrated by Mehta’s reference to task-relevant maturity, see Principle #5), coaching the managers they manage and reporting accurately without hiding issues.

Principle #3, “Never Undermine”, reminded me of Fredmund Malik’s book Managing Performing Living, in which he talks about extending and continuously earning trust. It’s been many years since I studied this book, but in short, praise go to team members, whereas criticism stays with the manager.

What Mehta talks about is a more subtle way skip leaders can undermine the line manager’s trust and authority, by reaching through their organisational level and influencing their ICs directly. Again, skip leaders should work with the line managers at the appropriate organisational level.

The API Endpoint Thought Experiment

I like Mehta’s Principle #2 “Conduct the API Endpoint Experiment”. Just like an engineer going through an API doesn’t have access to a system’s internals, a skip leader should work on “defining the API” (my expression) of their organisation such that it fits their needs and promotes effectiveness, without requiring access to the specifics.

He does point out that this is more of a thought experiment and should be taken “seriously, but not literally”, which I found was a welcome nuance in this age of opinionated management frameworks (Holacracy, anyone?)

Takeaways for Product Management

So what I can take away from this? Trying to label myself accurately, I’ve settled (for now) on “product manager that thinks like a CEO”, in the sense that I like to take on a challenge from scratch and create (or rearrange) the organisation to support both the product’s development but also its continued maintenance and further development, looking across the whole business model and all functions while doing so.

This means that I think big in scope and the projects I tackle can grow in scope quite quickly. I’ve repeatedly found myself driving cross-functional efforts, having no set team on my own but needing to recruit volunteers, sometimes delegating significant responsibilities to people I don’t formally manage.

While coaching is part of a manager’s job, it’s not their exclusive remit. As a senior leader, I find that I can also help the people I work with grow, albeit over shorter periods of time. I can apply many of the same principles here when working with people whom I will delegate a project to, including the “Never Undermine” principle.

In the same spirit, defining the right “API” is an interesting thought experiment that I can conduct on a regular basis to ensure I keep the overview of the various projects without getting bogged down in the details.

I recommend reading Mehta’s article, it’s well worth the time.