Harvard Business Review in 1974 published “Who's Got the Monkey” authored by William Oncken Jr and Donald L. Wass. The article described unsolved problems of employees which are delegated upwards causing the “monkey” to jump on a manager's back. This increases workload for a manager.
This analogy struck me hard. I have taken my own spin on the analogy and applied to my world of product management. Product managers do not own a team, but they manage sideways, upwards and downwards. If we are not good at monkey management, we can lose track of time and individual autonomy. It would be easier for Engineering, Design, and Leadership to target product team for being a bottleneck.
Let us explore a scenario which shall show how monkey jumps from one back to another.
Leadership team has decided to work on a key strategic initiative. The strategy is broadcasted to an entire organization, and Product team will be responsible for executing that strategy. They will need help from Design and Engineering. Design will explore solutions and help understand the usability of a solution. Engineering will explore feasibility of a solution. There are other functions of the business where co-ordination is required. But we shall stop here for simplicity.
A problem-statement has been presented by Product team along with what needs to be accomplished. Design comes up with a solution to the problem. Engineering recognizes a problem with proposed design. It has asked Product to reconsider the requirements.
Let us analyze how the monkey jumped from one back to another.
Monkey went from Leadership to Product to execute the strategy. It was boss-imposed meaning it cannot be disregarded by Product team. It is expected to deliver otherwise the team will face penalty.
Product passed the monkey to Design after finalizing requirements based on the expert knowledge about the business and its customers. It was system-imposed meaning there is an active support required from cross-functional teams. Ignoring will result in penalty, though not a direct penalty.
Engineering passed the monkey back to Product and Design because requirements need further clarification. Product can decide to de-prioritize or influence for support to deliver on original requirements. Design is now expecting Product to provide clarification. Product either can make on-the-spot decision or might need more time to collect information before informing Engineering and Design with next steps.
Where is the monkey? Product!
If Product does not get this monkey off its back soon, frustration will grow and Leadership will follow-up because of lack of momentum.
Let us analyze another scenario when there is a joint problem.
Same scenario as above, but Engineering comes back saying they can pursue the proposed solution by Design with all Product requirements, but will require re-architecting the system. Additionally, this will optimize the system for future needs, but pushing the launch date by several quarters.
Where is the monkey now? Is it the Product, Engineering or both? And is it known that it is a joint problem? Or the blame game is happening because Product is not allowing for time to refactor code and optimizing the database as the business grows.
Product is in dilemma because neither business nor clients care about system re-architecture, but it is critical to maintain technology systems for scale and growth. Engineering is looking for a green light on moving forward because everything else will need to be paused. Why is Engineering looking for approval? It is the business that provides funding to Engineering department.
Product needs to communicate this up the chain. Product cannot singularly make the decision. But a Leadership team that is not involved in technology requires Product recommendation with pros and cons before a decision can be made.
The monkey is on Product's back again.
This might not be a shared perspective from Product, but it is the result of complex organizational design. It is a joint problem indeed, but still requires momentum from Product to deliver on strategic objective.
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.
--
This essay was shared on Hacker News. There were insightful comments shared related to this topic.