The thing articles and project management philosophies both miss is this: What is the fundamental math constraint that shapes a project? I personally believe it

The thing articles and project management philosophies both miss is this: What is the fundamental math constraint that shapes a project? I personally believe it is NP growth and when you really understand it you see why things fail and what algorithms can help you succeed. You have a problem and resources to solve that problem. By trying all combinations of the resources you can decide what is the optimal solution. But it is NP growth so you can't actually search that space because the heat death of the universe is often waiting for you. The only time you should search the whole space is if the number of parameters is small enough that you can fit it all in one head and solve it. If it is too big for that then the only thing you can, and should, do is divide and conquer and keep doing that until you hit a leaf node small enough to put the problem completely in your head. People intuitively get this, but then they screw it up in predictable ways. After dividing they then accidentally recombine parts by sharing too much communication between parts. NP strikes again because there are too many parts to find an optimal solution now. Or, after they divide and find a local optimum, they 20/20 it and say 'had we combined we could have found a better solution' so they combine teams and fail the next project. Technically the combined team could have done it better, but NP time would have stopped you and you wouldn't have found that solution that the smaller, isolated, teams found. They think 'lets put things into a backlog and figure out what to attack one at a time' except it is an NP problem to order that backlog (and by the time you knock a few things off the top the things at the bottom are unrecognizable anyway) so NP strikes again. They divide and micro-manage from above which means they never actually divided and there are, again, too many pieces to search so NP strikes again. The solution is always this: 'Is this too much to fit in one head? Yes - divide / No - exhaustively search and implement. This gets to a core point here. The pyramid that divide and conquer creates must include communication restrictions between teams and resources carve-outs between teams or else you have failed to divide. However, -inside- a team you need to communicate and share resources in whatever is the most efficient way based on the problem you have carved out. So, it is possible to communicate too much, when you cross divisions. It is the right answer to hoard information in some cases, if the communication was designed to be limited to enforce a division.