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.
That’s also how scrum should work you have the team that has burn down and by that you plan how much can be picked up.
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.
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.
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 weigh…
And then they got bought by Activision and everything went to shit.
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…
If they are also carry the responsibility over the wrong decisions, it's OK. If not, the organization is doomed.
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…
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.