One of my favorite reads this last year was Team Topologies by Matthew Skelton and Manuel Pais. A key thesis of the book was that - due to Conway's Law - sometimes in order to reach a desired software architecture, you have to change the architecture of your organization (i.e. team structures and org chart).
I look at my current and past organizations and the applications we built a lot differently after having read about Conway's Law and other concepts discussed in Team Topologies. You can see how a stream of work with both its efficient and wasteful steps flowing through a series of apps was designed to mimic how that work previously flowed manually through a series of teams with similarly efficient and wasteful processes, for example.
In hindsight, that seems obvious. We write code often to automate business processes or provide some service to customers, but before those processes were automated they were written down or memorized and before that service was automated it was likely done by hand. Most folks are generally pragrammtic so of course we're going to take the collected "best practices" of those workflows and turn them into code.
That lesson along with the concept of value stream architecture has made me come to the realization that I've spent an awful lot of time solving problems with code that could've been more effectively solved by talking to people and questioning the assumptions around those problems.
Maybe instead of automating their process around their teams and sometimes been disappointed with the results, we should've instead fixed what was wrong with the process or the teams then decided if any code needed to be written at all. Something to think about before you open your IDE again, I guess.