My experience has been that writing the design doc is not as controversial, as much as the review process.
Does anyone have any insights on how to make the reviews more constructive + quicker?
Does anyone have any insights on how to make the reviews more constructive + quicker?
1. Start with defining the problem you want to solve and identify the stakeholders. Then meet each stakeholder 1-1 and get approval.
2. Propose an API. Then meet 1-1 again for approval.
3. Make a high level arch diagram. Seek approval again.
4. Proceed with actually writing the design doc and begin the formal and official review.
Points 1-3 could be done in a week if planned well and will make the design doc a lot less controversial and get you through the review process quicker
- Have a single person (engineer) who is responsible for making final decisions. Gather input from others but there should be one individual who is responsible for making sure that the design has a consistent vision that meets the goal. If a non-critical decision is taking too long, just make a choice and run with it.
- Be clear about the goal of the project. At Amazon they use the PRFAQ process where you need to begin by writing a costumer-centric press release that basically details why customers should be excited about the project. This helps keep design discussions focused on the customer.
- Be clear about the non-goals or things you will not do.
- At the beginning of a review meeting, have everyone read the document. The document should describe all relevant context. At the end of reading the doc, everyone should have enough context to understand and discuss the design - everyone should have the same understanding of the design (i.e. no confusion about which version of the doc we're talking about, no one who didn't have enough time to read the doc beforehand and just skimmed it).
- Have people add comments as they read through it, the authors can respond to the comments in real-time and once everyone is done reading the doc, the comments act as a list of things that need to be discussed.
- Have the doc be the absolute source of truth. If it's not in the doc, we're not planning on doing it. This prevents cases where you have a chat with someone about an idea, look into it further and decide to not do it/do it differently, but the reviewer thinks you are still going to do it, but you just haven't updated the document yet.
I have also been at a larger company, so you bring up a good point about fighting for work. I also think this is right.
1. If you win the fight for high visibility work, that's a good sign that you're the right person for the job. It wouldn't make sense for the company to have you work on something for your own benefit over the company.
2. You may opt not to fight and discover other problems to work on that have strong potential for being high visibility. Maybe that's something relegated to PMs or eng management, where the engineer might feel helpless to the given assignments, but that's more of a culture problem. I think politics increases when there's less work/budget/praise than there are people, which is more situational than cultural, in my opinion.