Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monkey Management

mihirchronicles.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Monkey Management

#31

Post by mihirchronicles »

marcosdumay wrote: post #5
alxmng wrote: post #3

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

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 d…

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.

Re: Monkey Management

#32

Post by mihirchronicles »

benreesman wrote: post #26

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.

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.

Re: Monkey Management

#33

Post by necheffa »

from-nibly wrote: post #22
necheffa wrote: post #20

Earlier quoted context omitted.

> Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. In practice, Product often controls the budget. So even if Product doesn't have the explicit power to veto a refactor, they have a lot of implicit power to deny this by only allocating enough to get a feature done. Now if you care, you just pad estimates and don't mention that there is a 20% tax or whateve…

When we cant communicate honnestly its time to pack it up. If there is not trust how can you get anything done?

Your job, as an engineer, is to keep the ship battle ready. Not waste time by ceding control to another entity that doesn't have any engineering know-how to evaluate what does and does not need done. Take the reigns and do what needs doing.

If there was no trust, they wouldn't be asking you to do the work in the first place.

Ridged top-down organizations wither away and die because they lack the agility and insight to respond to unexpected conditions. Leadership can set the high level goals of a mission, whether they like it or not, they need to also give the autonomy and authority to the field commanders to achieve those goals however they see fit.

If you are concerned your field commanders are going to go off and not stay focused on the goals then you've promoted too early.

The time for sitting around a table and talking openly at a higher organizational level is when deciding what goals to set, not in the heat of battle, unless it is to call a retreat.

It is only time to pack up when leadership is so full of itself that it cannot understand this.

Of course, you could argue that having a funding structure that necessitates padding in the first place is the early signs of the wheels coming off - which I would agree with.

Re: Monkey Management

#34

Post by marcosdumay »

mihirchronicles wrote: post #31
marcosdumay wrote: post #5

Earlier quoted context omitted.

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 d…

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.

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.

Re: Monkey Management

#35

Post by d--b »

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.

Re: Monkey Management

#36

Post by pluto_modadic »

from-nibly wrote: post #11

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.

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.

Re: Monkey Management

#37

Post by navane »

from-nibly wrote: post #11

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.

Blizzard wanted "Warcraft in Space". Designers came up with gameplay, which would be hard to implement in the existing warcraft engine. Engineering told the designers; we can do everything you want, but then we need extra time to build a new engine first. Everyone agreed and the best game of all time was made.

The 'refactor' was integral to the success of starcraft, and is definitely a tradeoff that needs to be weighed for new products.

Re: Monkey Management

#38

Post by sethammons »

pluto_modadic wrote: post #36
from-nibly wrote: post #11

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.

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.

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.

Re: Monkey Management

#39

Post by pvdoom »

from-nibly wrote: post #11

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.

> Product should have nothing to do with refactors on the systems.

Which really sucks when product is the one that gets the say on what gets worked on ...

Re: Monkey Management

#40

Post by pvdoom »

necheffa wrote: post #33
from-nibly wrote: post #22

Earlier quoted context omitted.

When we cant communicate honnestly its time to pack it up. If there is not trust how can you get anything done?

Your job, as an engineer, is to keep the ship battle ready. Not waste time by ceding control to another entity that doesn't have any engineering know-how to evaluate what does and does not need done. Take the reigns and do what needs doing. If there was no trust, they wouldn't be asking you to do the work in the first place. Ridged top-down organizations wither away and die because they lack the agility and insight t…

> Not waste time by ceding control to another entity that doesn't have any engineering know-how to evaluate what does and does not need done. Take the reins and do what needs doing.

Problem is organisational power. What happens when the "another entity" is the one that has the decision making power and is the one that can use that power to pressure you what to do and what not to do?

Asking cause this was my life for a while, and its an endless and gruelling battle of persuading, educating, trying to make someone understand things they don't want to understand ...

Post reply on HN