There is absolutely no replacement for experience.<p>I have worked with one engineer I would literally chose over 30 random senior engineers. They dealt with all the problems from 200 to 20000 engineers and they understood the systemic solutions rather than hack job half way solutions. They also come with clout that people would defer to. When you pay someone a lot, they have more organizational value and are therefore able to more easily get their way. Often times line workers will understand the problem and the solution, but not have the clout to lead an initiative. Incredibly experienced people are rare and hard to hire.<p>I've found PHD's to be half absolutely phenomenal and half kinda meh.<p>Leadership is a much harder problem because a lot of people in leadership have failed upwards. I don't have a lot of respect for most of the senior leadership of companies I've seen, but long term direction needs to come from senior leaders. Especially for the work that sucks (refactoring/migration). My understanding is that they frequently consult with peers at other companies or pay retired folks for consultation.<p><i>Extreme Ownership</i> is a fantastic book on leadership. Having been in exactly your situation (I think?), that book did an amazing job of breaking down why the leadership at the company I worked for wasn't great, as well as how they could have done better.<p>If I had to guess, there are some pain points that no one has direct ownership of, specifically the monolith doesn't have a team of people who directly claim ownership of the monolith itself. This likely leads to flakey tests, flakey builds, slow tests, slow iteration and all manner of problems.<p>Monoliths are fundamentally a tragedy of the commons. Every individual engineer is incentivized to add complexity and almost every engineer is also incentivized not to reduce complexity. Complexity is like fish in the ocean, and once all the fish are fished (once it's too complex), you can't catch any more fish (you can't generate new features quickly enough).<p>The answer to a tragedy of the commons is a government which enforces regulations, so a monolith owning team will likely need to be given authority (and more importantly resources) and then to start regulating the complexity of the monolith (no more bespoke features/dependencies without major justification and a design doc to review).<p>Creating the concept of ownership for directories/files in your code base and then wiring up automatic code review for owners of various areas goes a <i>long</i> way towards fighting the "no one wants responsibility for this" problem. All code must be directly attributable to a team.<p>If you have specific problems, you might try asking HN how they have been solved, or you can ask here too.<p>If you are a member of the ACM, then you also have digital access to the entire o'reilly library and can peruse their offerings. "scaling" is probably the key word that most directly applies, but "monolith" might have results too.<p>I think this blog has a lot of fantastic content if you want to go mining: <a href="http://highscalability.com/start-here/" rel="nofollow">http://highscalability.com/start-here/</a>