[o10449366]

I've had the same experience at the big tech company I worked at.

I expressed these frustrations to upper management and the explanation I was given was that for many of these big companies, their goal is to grow their 1,000 sub-businesses to 10 million ARR businesses each. Growing these 10 million ARR units to 100 million ARR is much more difficult than going from 0 to 10 million, and so when they have a successful unit, they disproportionally reinvest that success into the poor performers (the 0-2 million ARR units).

This felt backwards and unfair to me as an engineer on the teams that worked hard to get to the 10 million mark. It really sucked seeing my team lose headcount or engineers to less successful and poorly designed/managed projects. But from a business perspective on the larger scale I see why they do it - I just think it creates a poor engineering culture and, in the long-term, a sub-par customer experience because velocity in product development slows when projects are de-invested or put into KTLO.

[angarg12]

I kind of see your point at the macro level, but in our case we are both working in the same product, and contributing to the same bottom line. I see no strategic advantage on shifting resources from a high to a low performing team.

And of course the triple whammy happens when low quality software written by one team is handed over to a better team to fix it. I'm going through that right now. We have an upstream dependency that it's always causing all sorts of trouble. We've been told by leadership that if we notice issues we should go fix them ourselves rather than asking the other team to fix it. Go back to the incentives, what message are we sending the other team?