[HN Gopher] Monkey Management
___________________________________________________________________
Monkey Management
Author : mihirchronicles
Score : 32 points
Date : 2024-04-12 16:14 UTC (1 days ago)
(HTM) web link (mihirchronicles.com)
(TXT) w3m dump (mihirchronicles.com)
| alxmng wrote:
| Someone could take ownership of the project and make decisions
| instead of letting a monkey run around.
| marcosdumay wrote:
| 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 wrote:
| 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.
| wslh wrote:
| 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 wrote:
| 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-...
| manosyja wrote:
| Wouldn't be that a bit like the OSS 'Benevolent Dictator"
| model?
| throwaway98797 wrote:
| 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
| nine_zeros wrote:
| 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 wrote:
| First thought, not having worked with more than 15 people
| simultaneously in many years:
|
| _Oof._
| from-nibly wrote:
| 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.
| VyseofArcadia wrote:
| I think in the real world, what almost always happens is, "it
| looks like you're dedicated x capacity to technical debt
| reduction, but this is a critical business initiative, so you
| need to defer that and work on new features."
| feoren wrote:
| And everything is always a critical business initiative,
| because otherwise some senior manager is worried everyone
| will realize his job is pointless.
| feoren wrote:
| This reminds me of those useless articles like "Donald Trump
| should resign". Okay, and? We _should_ all have mansions and
| sex robots. It 's utterly pointless to pontificate about
| _should_ ; it makes it sound like you have no understanding of
| the actual real world. In the real world, your company is run
| by pathetic parasitic asshole narcissists who will never give
| half a shit what anyone like you thinks.
| datavirtue wrote:
| This. It all boils down to shared vision and autonomy. All
| teams should be acting in concert for the same goal. If they
| aren't the board needs to cut the CEO yesterday and find
| someone who is going to foster a cooperative culture.
|
| I work in a company where each team is aligned and has
| autonomy and trust, where people listen and find ways to help
| the other team. It's game theory with the right algorithm
| installed. Oddly enough, the company was founded during the
| peak of the military hierarchial taylorism cargo cult
| clusterfuck that bore mutants like GE. The military doesn't
| even work the way these companies operate.
| rahimnathwani wrote:
| Product should have nothing to do with refactors on the
| systems.
|
| Let's assume the reasons to refactor are:
|
| 1. Reduce unnecessary complexity, and
|
| 2. Reduce the gap between the code architecture and our current
| understanding of the domain.
|
| Sure, you could refactor and preserve 100% of existing system
| behaviour, but:
|
| - why not take the opportunity to discover the remove features
| that are annoying to maintain, but that the ops folks can live
| without (with some process change)?
|
| - for #2, product folks can be helpful
| necheffa wrote:
| > 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 whatever for refactoring.
|
| That doesn't work in all cases, especially if the code base is
| particularly tangled. But you can get a lot of small things
| done this way.
| netman21 wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-13 23:01 UTC)