Yap. It reflects not just directly on the product but on the team dynamics.
I have seen this happen at least twice in the past: start with a great team, smart people, self-sufficient. New manager comes in. What does the manager do? Stay by and watch the team do what they do best. Nope, start to set up meetings to improve communication, to streamline, to optimize, adds new rules , new Kanbans, some agile thing maybe, intensify devops a bit. "But why? it doesn't make sensse". Developers are wondering, watching their motivation and productivity get sucked out.
But it does make sense. The manager has a manager. When the end of the year comes, they'll have to report "I did X, implemented Y, facilitated Z etc". They are paid more than the average developer, their know it, the expectations are high. They have to do those things, so that behavior starts to make more sense.
Clearly we work on the same team, at both this job and my previous. Are you me?
Add to this people leave, new people come in and day what the old people did they could do better. A couple years later new people discover why the old people created what they did.
New people either look for new jobs or get into the same cycle as the ones before them.
The odd thing is that when you stay around you can start to see patterns in misconception. People come into a long-lived codebase and naturally fall into the same thought traps, wanting to rewrite the same parts for the same misguided reasons. There is a principle here to follow on a new codebase, that of 'senseless inaction', meaning that as long as something doesn't make any sense to you yet, you should refrain from making deep changes to it. Only once insight is formed on why the seemingly completely pointless and bizarre feature exists and what purpose it is serving, then can a deep change to it be safely considered. Tragically, the natural instinct is to lay off the parts that make sense and to rewrite the parts that don't. That's a guaranteed way to make a product unsuitable for the business it is in, because the weirder a feature is, the more adapted it is to the real world (most of the time).
I have seen this happen at least twice in the past: start with a great team, smart people, self-sufficient. New manager comes in. What does the manager do? Stay by and watch the team do what they do best. Nope, start to set up meetings to improve communication, to streamline, to optimize, adds new rules , new Kanbans, some agile thing maybe, intensify devops a bit. "But why? it doesn't make sensse". Developers are wondering, watching their motivation and productivity get sucked out.
But it does make sense. The manager has a manager. When the end of the year comes, they'll have to report "I did X, implemented Y, facilitated Z etc". They are paid more than the average developer, their know it, the expectations are high. They have to do those things, so that behavior starts to make more sense.