As a team, we've created some shared standards around architecture reviews to only improve quality and consistency across the board, and increase transparency into the decisions that are made. Documenting these decisions will also give future engineers something to reference if they wonder why we chose a certain schema or communication pattern.
We aim for bigger decisions (anything that has long-run consequences, and any one-way door irreversible decisions) to have a proposal that gets reviewed, through our "Architecture Review" process.
This is hard to define, but the kind of thing that should get reviewed is any irrevesible/hard to reverse decision (are you going through a one way door?) or a decision that has long-run consequences and far reaching impact. Use your best judgement in deciding what should get a review.
Architecture review is a decision maker / advice process structure that is consistently used for bigger implementation decisions.
Here is the overview showing how to structure a proposal for an architecture review: Template for Architecture Proposals
Your proposal will share the goal you're trying to achieve, your plan how you'll achieve that, and some answers to key questions, and possible alternatives to your plan.
Responsible for creating a solid proposal: This would usually be a senior engineer on a team. This role may also be played by an Engineer III if they have the context and expertise in this area. The Proposers job is to create a solid proposal that ideally doesn’t need too much iteration to finalize and approve.
Accountable to that proposal being solid: The team’s EM is accountable to choosing the right engineer who is responsible for creating a solid proposal. More than one person can work on a proposal.
Consulted: The engineer responsible for creating the proposal should proactively seek out the advice of subject matter experts to create an good proposal. Other (product) engineers, Domain experts, PM, anyone relevant who needs to give input on the goal or help suggest viable solutions. For example, a new Database decision may spark consultation from Steven as a domain expert.
Informed: Anyone working closely on the team, or anyone who will be affected by this decision. The person responsible for creating the proposal should share the outcomes clearly with anyone affected. The architecture review is completely transparent, so here “informed” means “proactively giving a heads up”. By default, everyone will have access to this information.
Responsible for reviewing the proposal: This would usually be either Dan personally, or a staff or senior engineer with the right context and experience that Dan specifically delegates this responsibility to. Hopefully the initial proposal is solid enough that it keeps ‘forward motion’, even if it requires a few smaller iterations.
Accountable to the outcomes of technical decisions made: Dan remains overall accountable to the technical roadmap and to the outcomes of all these decisions.
Consulted on the proposal: Any subject matter expert who’s advice would improve the outcome.
Informed of the solution: Anyone working closely on the team, or anyone who will be affected by this decision.
This is an important growth area if you’re looking to become a senior engineer down the line, or in general grow as a technical leader. Your EM is here to support this growth and help you find opportunities to either create proposals, or collaborate with input/advice from a senior engineer on proposals.
Your track record at making good implementation decisions will be part of how your EM decides you’re ready to create bigger proposals, and your successful work in creating architecture proposals is an exciting milestone to recognize and reward on the path to being a senior engineer!
If you’re already a senior engineer, you’re essentially doing much of this already in your advice process emails, technical chats with Dan if you have those, and your leadership of cycle planning if you’re in product. Doing architecture proposals will make that existing work more transparent, but doesn’t change the nature of the work you’re already doing in your role as a senior engineer.
It shouldn’t change much - this is happening already, but more casually in calls, Jira and emails.
What is different about an architecture review advice process is the clear lines of accountability and the transparency of what decisions are made, by whom, why and exactly how.
As Dan shares on the template, not only does this increase consistency across engineering and with our technical roadmap, it also reduces knowledge silos on our team and serves as a decision history for our future selves. This way we can revisit and understand past context, and learn better from our past decisions if they don’t go quite as planned 😉