A Structured RFC Process
Maybe you are a new engineering leader at red-hot startup. The founders hired you on account of your previous experience at a successful tech company, they brought you in to take engineering to the next level. After a few weeks of onboarding, you now have a list of changes you want to implement. How do you find a way to propose that without making the old guard feel alienated from the process?
Or maybe you are part of the old guard yourself. You have shown interest in stepping up and leading the engineering team from a scrappy group of people working 7 days a week to a more mature organization. You were promoted to a position where you finally have the ability to tackle the root cause for the growing pains you all are experiencing. One question still remains, though: how can you make sure that your fellow engineers don’t feel that you are imposing your views like a tyrant?
Or it could be that those ideas aren’t even yours. You are a manager worried about the amount of technical debt and frequent production incidents caused by people rushing to implement their ideas withouth having them double-checked by a second pair of eyes. When you casually remind them about the benefits of collaboration, you hear about how they are are afraid that a reviewer will waste everyone’s time pushing for the perfect solution, and we need the first iteration of this thing out as soon as possible.
