> "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers" And even in those 9/10 companies, the failure doesn't even p

> "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers" And even in those 9/10 companies, the failure doesn't even prove that the engineers are the ones unable to create meaningful service boundaries, within a monolith or distributed to multiple services. All of those engineers have bosses and, I don't know what others are seeing, but I feel like I've seen Software Development Manager increasingly become Manager of Software Developers. I suggest that those same management structures which failed to enable their engineers to create meaningful service boundaries in their monolith, which led to the desire for a cure-all solution, also failed to manage (or protect) their developers such that those developers _could_ turn the existing system architecture into one based on microservices. Technical leadership has just become increasingly abysmal. Developers are tasked to fulfill user stories but those are often written in a way that completely ignores the technical work required to fulfill such a story. That creates a painful disconnect between expectations and reality, even in 90% CRUD, monolith web apps. Even in a monolith with proper separation of concerns, its easy to imagine one service being the "user" of another service for the purpose of more granular and clear tasks but, "that's not how user stories work." :(