11–20 of 45 posts
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.
Someone could take ownership of the project and make decisions instead of letting a monkey run around.
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, marke…
https://www.rubick.com/implementing-amazons-single-threaded-...
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.
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.
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."
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.
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.
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
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.
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.
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.
Earlier quoted context omitted.
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, marke…
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-th…
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.
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.