Ask people about their experience rolling out microservices, and one theme dominates: engineering is the easy part, it's people that are hard. Everybody knows about Conway's Law, everybody knows they need to make changes to their organization to support a different technical services model, but what *are* those changes? How do you know if you're succeeding or failing, if people are struggling and miserable or just experiencing the discomfort of learning new skills?

I'll cover a half dozen variations on this theme, all of which emerged from private/anonymized conversations with leaders & teams who survived the real experience of rolling out microservices. Questions like: who makes decisions? How can you tell if you're piling up tech debt that will make future you miserable, or cause people to burn out and leave? When are you routing around bad tech debt, when should you pay it down? When should you replace components, should you adopt an "immutable services" model or "always be rewriting"; when should you maintain your damn code? How do you know if you actually ended up with a distributed monolith, and how do you work your way out of it? How do you design consistent, scalable communication flows? And how do you balance optimizing locally for individual technical problems vs globally for a maintainable stack where engineers can move about more freely?