5 ms·

Monkey Management

d--b 2y ago
This is the first time I hear about this analogy and I think it's quite interesting. As with all business analogies, it probably doesn't fit all situations. Like at some point the monkey gets split into sub-monkeys, and suddenly you have monkeys all over the place. That said, it gives a good way to think about how to find a way out during those meetings where teams get stuck and everyone stares at each other while a big "ok, so what do we do now?" question is hovering the table.
boesboes 2y ago
This very nicely explains why I had to leave my job. I became 'lead of product development' but mostly had the role of PO. (and scrum master too i suppose). So it was more like several monkeys fighting on my back while I was face down in the mud, but yeah.
mihirchronicles 2y ago
[dead]
alxmng 2y ago
Someone could take ownership of the project and make decisions instead of letting a monkey run around.
- marcosdumay 2y ago
  The organization on the article is highly dysfunctional. But it's not going to be solved by higher management getting busy with the details of the project's work. The problem here is how the work is divided, with everybody disempowered and turned into helpless cogs. If the goal was to prohibit any kind of improvement, they wouldn't make such a perfect attempt... And yet, that's the "normal" way to organize software development.
  - blowski 2y ago
    This was my impression of the article as well. Nobody can agree on what they're all trying to improve in the product and why, everyone's just trying to avoid being fired while working on their own stuff.
  - mihirchronicles 2y ago
    Organizational dysfunction is what I had in mind when I wrote it. It is highly complex. A founder led or a small organization is highly empowered to course correct the ship as opposed to organization with several layers of complexity. Everyone wants the buy-in but people don't have high agency.
    - marcosdumay 2y ago
      Yeah, but tracking the monkey will only help you survive in there. It won't help fix the organization. What fixes that problem is delegating the authority over team-sized problems to the teams, and structuring the organization so that larger issues are all contained over the equally sized management structures. And despite management books all preaching that kind of organization, almost nobody does it in practice. A few problem-oriented organizations get the large structure right, but nobody at all gets the fine-grained delegation.
- wslh 2y ago
  It is not an ownership problem only, the issue, which is very common, is that you need someone who can connect the dots and know that if he/she doesn't, the ball will go back and forth infinitely, and far from the soccer goal. One profile that fits here is a generalist and/or program manager who had strong experience and skills in a specific field (e.g. developing software). The generalist can talk about sales, marketing, operations, and business and match with real experience. He/she knows how to move the ball forward. Ownership alone only provides illusions.
  - cpeterso 2y ago
    An organizational solution to this problem is (Amazon’s) “single-threaded owner” model: all the disciplines report to (perhaps with a dotted line in a matrix org) one directly-responsible manager. The manager sees the big picture and can break down roadblocks, though they still may be building their own empire and reluctant to pivot or shut down their big project. https://www.rubick.com/implementing-amazons-single-threaded-owner-model/ https://www.rubick.com/implementing-amazons-single-threaded-...
    - manosyja 2y ago
      Wouldn’t be that a bit like the OSS ‘Benevolent Dictator” model?
throwaway98797 2y ago
best solutions come when those that own the problem statement get enough info to slightly modify the problem ie., it is far easier to make men be cleaner in urinals, than to make the cleaners more efficient but if you can’t be the person to place a little bee on each stall you’re shit out of luck
deleted 2y ago
[deleted]
nine_zeros 2y ago
This article does a good job of touching on how empire-style organizational structures are dysfunctional. 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.
rrr_oh_man 2y ago
First thought, not having worked with more than 15 people simultaneously in many years: Oof.
from-nibly 2y ago
I know this wasnt what the article was about. However... Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. Engineering needs to own their own availability to product. Engineering cant be 100% available to product and engineering needs to grow up and state their availability to product.
- pluto_modadic 2y ago
  My (limited) understanding supporting developers for two years is that product does not take no for an answer, and controls everything from budget to sprints, and can insist on whatever they like, whenever they like. So... I'm going to take your comment as a lovely fantasy like spherical cows. Refactors are a joke that never gets off the ground, after a decade.
  - sethammons 2y ago
    In the healthy orgs I have worked in, it is a give and take relationship between product and engineering. Engineering should absolutely push back on some things and needs to also push for engineering specific projects. No spherical cows, just adults talking about needs and priorities. The current place I am at has a history of eng doing anything product wants and not saying no or "yes and." As a result, the eng side is a mess, builds are slow, service and data boundaries are muddled, and shipping working software continues to slow. Incidents are rising and customers are starting to churn and larger customers are harder to sign. As part of eng leadership, my role is helping teams learn what a healthy product and eng relationship looks like, which includes pushing back and gaining alignment on the need for eng focused projects.
    - ElevenLathe 2y ago
      So you will diligently improve the relationship and get things cleaned up, maybe even get credit for it, but the incentive for the next person in your post will be to cash out that built-up equity by saying "yes" to everything again and then getting promoted for their amazing velocity, nevermind that the code is now goulash again. I guess this is the cycle of basically every organization in human history.
netman21 2y ago
I was introduced to monkey management principles at my first job out of school. This was 1982. My boss taught it to me. Has helped me ever after.
benreesman 2y ago
This is kind of adversarial sounding. I’ve been in some messed up teams, but by the time it’s the blame game, I feel like people have stopped pretending? Once the incentives are corrupted your business is living on borrowed time. But people generally agree (at least in private) when that’s happened. YMMV.
- mihirchronicles 2y ago
  100% and this is unproductive in value creation for any organization. We all know it too when this is happening which is the sad part.
beryilma 2y ago
> It was boss-imposed meaning it cannot be disregarded by Product team. It is expected to deliver otherwise the team will face penalty. This is often the problem. The bosses impose fad of the day as the next thing to work on and expect everybody to be excited about it. And the fads keep changing year after year. And when the managers try to pass the monkey to software engineers, in my case, engineers do a half-ass job because they don't care about the new fad.

d--b 2y ago

This is the first time I hear about this analogy and I think it's quite interesting. As with all business analogies, it probably doesn't fit all situations. Like at some point the monkey gets split into sub-monkeys, and suddenly you have monkeys all over the place. That said, it gives a good way to think about how to find a way out during those meetings where teams get stuck and everyone stares at each other while a big "ok, so what do we do now?" question is hovering the table.

boesboes 2y ago

This very nicely explains why I had to leave my job. I became 'lead of product development' but mostly had the role of PO. (and scrum master too i suppose). So it was more like several monkeys fighting on my back while I was face down in the mud, but yeah.

mihirchronicles 2y ago

[dead]

alxmng 2y ago

Someone could take ownership of the project and make decisions instead of letting a monkey run around.

marcosdumay 2y ago
The organization on the article is highly dysfunctional. But it's not going to be solved by higher management getting busy with the details of the project's work. The problem here is how the work is divided, with everybody disempowered and turned into helpless cogs. If the goal was to prohibit any kind of improvement, they wouldn't make such a perfect attempt... And yet, that's the "normal" way to organize software development.
- blowski 2y ago
  This was my impression of the article as well. Nobody can agree on what they're all trying to improve in the product and why, everyone's just trying to avoid being fired while working on their own stuff.
- mihirchronicles 2y ago
  Organizational dysfunction is what I had in mind when I wrote it. It is highly complex. A founder led or a small organization is highly empowered to course correct the ship as opposed to organization with several layers of complexity. Everyone wants the buy-in but people don't have high agency.
  - marcosdumay 2y ago
    Yeah, but tracking the monkey will only help you survive in there. It won't help fix the organization. What fixes that problem is delegating the authority over team-sized problems to the teams, and structuring the organization so that larger issues are all contained over the equally sized management structures. And despite management books all preaching that kind of organization, almost nobody does it in practice. A few problem-oriented organizations get the large structure right, but nobody at all gets the fine-grained delegation.
wslh 2y ago
It is not an ownership problem only, the issue, which is very common, is that you need someone who can connect the dots and know that if he/she doesn't, the ball will go back and forth infinitely, and far from the soccer goal. One profile that fits here is a generalist and/or program manager who had strong experience and skills in a specific field (e.g. developing software). The generalist can talk about sales, marketing, operations, and business and match with real experience. He/she knows how to move the ball forward. Ownership alone only provides illusions.
- cpeterso 2y ago
  An organizational solution to this problem is (Amazon’s) “single-threaded owner” model: all the disciplines report to (perhaps with a dotted line in a matrix org) one directly-responsible manager. The manager sees the big picture and can break down roadblocks, though they still may be building their own empire and reluctant to pivot or shut down their big project. https://www.rubick.com/implementing-amazons-single-threaded-owner-model/ https://www.rubick.com/implementing-amazons-single-threaded-...
  - manosyja 2y ago
    Wouldn’t be that a bit like the OSS ‘Benevolent Dictator” model?

throwaway98797 2y ago

best solutions come when those that own the problem statement get enough info to slightly modify the problem ie., it is far easier to make men be cleaner in urinals, than to make the cleaners more efficient but if you can’t be the person to place a little bee on each stall you’re shit out of luck

deleted 2y ago

[deleted]

nine_zeros 2y ago

This article does a good job of touching on how empire-style organizational structures are dysfunctional. 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.

rrr_oh_man 2y ago

First thought, not having worked with more than 15 people simultaneously in many years: Oof.

from-nibly 2y ago

I know this wasnt what the article was about. However... Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. Engineering needs to own their own availability to product. Engineering cant be 100% available to product and engineering needs to grow up and state their availability to product.

pluto_modadic 2y ago
My (limited) understanding supporting developers for two years is that product does not take no for an answer, and controls everything from budget to sprints, and can insist on whatever they like, whenever they like. So... I'm going to take your comment as a lovely fantasy like spherical cows. Refactors are a joke that never gets off the ground, after a decade.
- sethammons 2y ago
  In the healthy orgs I have worked in, it is a give and take relationship between product and engineering. Engineering should absolutely push back on some things and needs to also push for engineering specific projects. No spherical cows, just adults talking about needs and priorities. The current place I am at has a history of eng doing anything product wants and not saying no or "yes and." As a result, the eng side is a mess, builds are slow, service and data boundaries are muddled, and shipping working software continues to slow. Incidents are rising and customers are starting to churn and larger customers are harder to sign. As part of eng leadership, my role is helping teams learn what a healthy product and eng relationship looks like, which includes pushing back and gaining alignment on the need for eng focused projects.
  - ElevenLathe 2y ago
    So you will diligently improve the relationship and get things cleaned up, maybe even get credit for it, but the incentive for the next person in your post will be to cash out that built-up equity by saying "yes" to everything again and then getting promoted for their amazing velocity, nevermind that the code is now goulash again. I guess this is the cycle of basically every organization in human history.

netman21 2y ago

I was introduced to monkey management principles at my first job out of school. This was 1982. My boss taught it to me. Has helped me ever after.

benreesman 2y ago

This is kind of adversarial sounding. I’ve been in some messed up teams, but by the time it’s the blame game, I feel like people have stopped pretending? Once the incentives are corrupted your business is living on borrowed time. But people generally agree (at least in private) when that’s happened. YMMV.

mihirchronicles 2y ago
100% and this is unproductive in value creation for any organization. We all know it too when this is happening which is the sad part.

beryilma 2y ago

> It was boss-imposed meaning it cannot be disregarded by Product team. It is expected to deliver otherwise the team will face penalty. This is often the problem. The bosses impose fad of the day as the next thing to work on and expect everybody to be excited about it. And the fads keep changing year after year. And when the managers try to pass the monkey to software engineers, in my case, engineers do a half-ass job because they don't care about the new fad.