Monkey Management(mihirchronicles.com) |
Monkey Management(mihirchronicles.com) |
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.
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.
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.
The 'refactor' was integral to the success of starcraft, and is definitely a tradeoff that needs to be weighed for new products.
Product should have nothing to do with refactors on the systems.
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
That includes refactoring, pruning, training, scaling, vendoring, etc.
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.
Team should not be concerned by what to pick up but should be concerned by keeping the pace on the same level and if someone goes on vacation to make it clear for the product.
Which really sucks when product is the one that gets the say on what gets worked on ...
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.
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
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.
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.
https://www.rubick.com/implementing-amazons-single-threaded-...
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.
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.
Oof.
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.
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.
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.
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 ...