Honestly, the things I've seen slow down deploys and engineering schedules are: 1. Using Git Flow. This inevitably leads to many branches for different teams/d

Honestly, the things I've seen slow down deploys and engineering schedules are: 1. Using Git Flow. This inevitably leads to many branches for different teams/deploys/reasons and cherry picking among them and something always goes wrong. Because management opted into depending on a fragile branching system. 2. Many repos with some kind of inter-repo dependencies (usually testing or ops). Some of that can be cleared up with packaging. Some maybe not so much. This is another kind of complexity that management chooses, but management fails to account for that complexity when scheduling. The "oh, no, your PRs are too big!" problem happens with every dev. Probably more than once. But it doesn't seem like a serious ongoing issue. As long as someone says "oh, no, your PRs are too big!" It's recognized as a problem and dealt with. The other two I've mentioned are not even recognized as problems.