1. Talk to folks about what they actually want. People will find a way to resist/gum up things they don’t actually want to do. 2. Document the shit out of anyt

1. Talk to folks about what they actually want. People will find a way to resist/gum up things they don’t actually want to do. 2. Document the shit out of anything you change. Because you’re introducing a new standard on how to deploy, things will slow way the hell down as people have to figure out how to adopt these new patterns. 3. Then, dog food it. Spin up 5 new dummy services, and double down up improving the process, documentation, figure out where you can automate. All of this is also to say, if a new principle engineer joined up after I had been there for 5-10 years, and suddenly told me we need to pivot to changes no one asked for, I’d either push back as hard as possible, or look for the door if I wasn’t specifically courted and take my tribal knowledge with me. Your job is to advocate FOR developers, not to impose.