Following on from “Ask Advice, Not permission” See also “Monkey Management”.

Monkey Management ideas aren’t new (eg see this which quotes it as being from 1975). It’s basically describing the problem of how unsolved problems of employees are pushed upwards causing the “monkey” to jump on a manager’s back. This increases workload for a manager and makes focus difficult. This piece nicely discusses the issue in the view of Product management.

From Monkey Management:

Despite the complexity, monkey ownership continues for Product. It is your circus, but not your job to train monkeys.

Monkey management is effective when there is organizational complexity. It has two critical benefits. The first is time management and the second is creating high agency staff who are able to deal with problems autonomously.

If you understand whose back the monkey is on, you can understand the art of time management and delegation.

A comment from HN

The reason monkey keeps jumping around is because there are ZERO directly responsible owners of the delivery of the cross-functional outcome for the business.

In my company, we have PM, Sr. PM, Director of Product, VP of product - interfacing with Designer, Sr. Designer, Design manager, Sr. Design manager, director of design - interfacing with Eng 2, Sr Eng, Eng manager, Sr Eng manager, Eng director, Sr. Eng director, Eng VP.

Nobody can tell who owns the final decisions, decisions cannot be bubbled up, every management chain is only focused on their own goals. There is no decision-making structure at all. Inevitably projects get delayed or there are unaccounted issues. Then each management chain stack ranks their reports for not achieving goals - never once accepting that the empire structure never made any decisions when it was necessary.

The empire structure has to go. It is dysfunctional, doesn’t work, and only causes grief to everyone involved. Tasks are unnecessarily hard. It is easy to do. Just make your highest paid people directly responsible for outcomes. Give them the freedom to pull people from various org functions to get a project to success.

From Ask for Advice, Not Permission

The problem with permission is that you are implicitly asking someone else to take some responsibility for your decision. You aren’t inviting them to participate in its success — permission is hardly seen as a value adding behavior — but if it goes wrong you might end up involving them in the failure: “Hey, I asked that team and they said it was fine.

and

Advice, on the other hand, is easy. “Hey, I was thinking about doing X, what advice would you give me on that?” In this instance you are showing a lot of respect to the person you are asking but not saddling them with responsibility because the decision is still on you.

Its a great read. Whats interesting though is what happens when it goes wrong. From HN

“…and when someone asks for your permission (probably because you’re in the person’s management chain), one response could be: “you don’t need my permission, if you think it is a good idea after getting input, go for it. If it turns out to be a bad idea, share your learnings so we don’t repeat the same mistake.””