I can't speak for all teams, but I felt that the upper management I interacted with during my stay with one particular team, lacked experience. It was somewhat evident in the interview process, through some of the questions that were asked, but I ignored it. It became extremely apparent on the job as time went on.
There were a number of practices and culture values that were red flags.
There were members of management and the development team that had between 5 and 8 years of total experience, but felt they were experts in their field based on those statistic alone. Granted, I've run into some with 20+ years before that made a mess, as years aren't a measure of aptitude, however I can say there was a severe lack of humility and open-mindedness in dialogs.
1) No comments in code
I've never worked anywhere in my career where developers and management were actively against comments in code. I literally got told by senior developers to delete code comments after spending a week or more figuring out what a class or method does.
More than half the bugs I ran into were because previous developers made bad assumptions about what a class or method does. Upper management says, "Let the code be self documenting" and "I expect everyone to read the code"....which is unrealistic in a large, complicated code base, much less one with accumulated technical debt. No developer is going to read 100s of 1000s of lines of code and memorize every unexpected side effect from every call each time they write a new line. They will look at the function stub and make assumptions, which turn out to be incorrect more often than not.
Some teammates claimed it took 10 or more months to understand the codebase at any usable level. This is due to the reliance on memorization vs documentation.
2) Rejections of PRs with more than a dozen or so line changes.
I am really not exaggerating. PRs were continuously rejected based solely on how much green they contained. If more than a few dozen lines were changed, regardless of whether they addressed the ticket, fixed a bug, or brought code to standard, they were rejected.
I don't think I've ever had to spend days arguing explaining why I added a default constructor, a log statement, or some comments, at any previous employ, much less have it called "risk".
I completely understand the need to contain scope creep, but the amount of fear in encountered goes way beyond addressing scope creep.
All code needed to pass the same couple reviewers, and they all followed this procedure. I don't feel as though they took more than a few minutes to understand the code in question, or grasp the effects of the changes.
At the same time, they expect bug tickets to be fixed. Many times they suggested extremely hacky quick fixes as alternatives.
It is my belief that this stemmed from a codebase that has become so fragile, due to poor practices, design decisions, and accumulated, technical debt, that management is outright terrified any change will break the product. This is fairly common when technical debt gets out of hand.
3) We have a standard, but don't follow it
There is a coding standard, but it was actively ignored with excuses like, "Well, in this case I don't feel that applies" and "Let's not change existing code." There was no plan to bring existing code inline with standards at all, which left a unhealthy mix of coding styles that will stay mixed for eternity.
4) Tickets Times
We're all used to constant "Is it done yet?" from project managers, but this has got to be the first place in my career where tickets were expected to be done in 1 or 2 business days from the time they were assigned.
This is coupled with the expectations described in (2).
Time was not allotted to fix anything properly. The amount of pressure to get the quick and easy fix without questioning it, was overwhelming. While the sky didn't fall if more time was taken, I did constantly encounter "What's taking so long?", "Do you need another developer to help you?", "Why is this so complicated?", before information gathering for a ticket was even close to done, one or two days after it was opened.
I also felt that team success was largely based on the number of tickets closed, rather than what was done to close them and what it meant for long term product health.
5) Bizarro world
Things that most software engineers spend their careers being told are good are treated as bad. Most leaders absolutely beg their team to document code, create unit tests, to write confluence pages, to provide advice for QA, to trace bugs to their root cause and provide that information.
At NinjaOne all those practices were treated as though the developer did something wrong. Usually because it costs more than 1 business day to complete.
6) Rogue Programming
While there were code reviews, some new components were completely designed and implemented by one individual. This leads to the reappearance of any misconceptions, bad practices, or anti-patterns that individual employs. There should always be checks and balances. Code Reviews are not enough when people don't run the code and aren't forced to consider the design. When multiple people work on a component, consideration of the impacts decisions create are forced in the day to day.
