Starting an Architecture Review Team
How to start, manage, and deliver!
Hi everyone 👋 !
Welcome to Crushing Tech Education and welcome to 212 new subscribers who have joined us since last week.
Today’s article is a collaboration with
, a software engineer at Amazon and the writer ofI hope you enjoy 😊
“Reviewers thinking out of the box and making questions worth bringing to the product/business team”
“Reviewers with questions to make thoughtful suggestions, not trying to trap you.”
“A team with confidence that they understood the requirements and preconditions correctly after this review.”
All of these are anecdotes from a technical design and architecture review group.
This is the kind of engineering group you want in your organization.
It’s not the kind of work you see they are doing every day.
⭐ In this post, you’ll learn:
How do you start it?
How do you keep it running?
And how do you make a good review?
[Start it 🧱] Find the decision makers and write a proposal
Start small. Aim your initial scope for the teams under your skip-level manager
Showcase the metrics of existing groups in other organizations or companies to make an argument.
Keep in mind the benefits aren’t relevant if the costs are disproportionate. For an engineering group, the cost is just engineering hours. Show the benefits outweigh the cost.
Propose a system. This is what Jeff Bezos called “mechanisms, instead of good intentions”.
Include the tool, the steps to adopt the tool, and its feedback loop in your proposal.
[Start it 🧱] Find interested people to create a founding team
This initiative has the chicken and the egg problem
Your offering is a group, but there is no group yet.
It’s like social media apps. They start with invitations, launch parties, and events to drive traffic.
For our engineering group, socialize with your peers to create an initial set of reviewers. Don’t ask them to commit to full-time membership, just enough until you have the mechanism in place so they can exit it.
To get people to submit their work for review, and socialize in person, and in Slack channels. The best you can do is submit your work from trusted peers and invite people to join those reviews to see how the group works.
[Start it 🧱] Find the first problem to solve
Architecture review groups are expensive and getting a first problem discovered and solved is a big deal.
It helps in identifying relevant skills and knowledge gaps, provides a sense of achievement and momentum. It ensures that the group's efforts are meaningful and directly contribute to addressing technical challenge.
[Start it 🧱] Avoid the upfront cost
Don’t build the best architecture group. Build a good enough process to solve the first problem. Once you do it - you have a story to tell.
Often it happens the other way around. People keep investing time in processes without focusing on problem solving.
[Manage it ⚙️] Create an onboarding for new reviewers
Get the interested people to join the reviews and participate like another reviewer. This gets them to observe how others act and practice themselves.
Offer a feedback mechanism to calibrate new candidates and make them a full-time reviewer.
[Manage it ⚙️] Maintain quality by doing work before, during, and after the review
Before → Pre-read the document. Follow up with the customer team if anything is not clear. Ensure you have enough reviewers to attend the review meeting.
During → Take notes so the customer team can focus on the questions. Moderate the meeting so everyone has the opportunity to participate (the raised-hand button in most conference software is a great tool for this)
After → Share the meeting notes. Ask for feedback to improve the group.
[Manage it ⚙️] Constantly look for new problems to solve
Often, architecture groups are short-lived because they can’t find big enough problems to solve to justify their existence.
Find your niche and build an expertise there. Collect the feedback from the customer teams and spread the word. You should always be looking for more problems.
[Good reviews 👀] Consider what stage the document comes in
Don’t try to guess it. Ask your customer team to fill in a form selecting an option:
Tier 1 → You can question the core of the proposal. The customer team looks for guidance on technologies and frameworks to investigate and design around. They are not committed to any option and just want to validate the requirements and brainstorm unforeseen risks.
Tier 2 → You can question only important things they aren’t aware of. The customer team provides a technical design. They want help evaluating the tradeoffs to make a decision and want insights before starting development.
Tier 3 → Don’t question, just provide insights and call out risks. The customer team is confident in their design and they may even have started development. They want validation and insights into operational considerations.
[Good reviews 👀] Consider the question the audience wants to answer
Explicitly ask the customer team to provide the objective of the review.
Most teams want only general validation. But some will come to you about a particular decision.
Remind the rest of the reviewers about this objective before they start rea ding and asking questions.
Before the end of the review, explicitly ask the customer if you answered their questions. If it’s not the case, try to follow up offline or in a separate session.
[Good reviews 👀] Focus on delivering value
It’s fun to be in the architecture group. Your reviewers can argue about the tradeoffs, explain how this is a “good” or “bad” design.
But there is a trap. Your customer doesn’t care about “the best” design. They care about finding the best design given their limitations. Focus on providing options and solving a problem.
[Good reviews 👀] Make it easy for reviewers and customer teams
Create a simple process for a review lifecycle. Make it easy to submit the request and receive a review. It accelerates feedback cycles and enhances the quality of the review.
The ease of engagement encourages more frequent and constructive feedback, it’s refining architectural decisions and aligning them more closely with customer needs.
📣 Shout-outs of the week
How Canva Supports Real-Time Collaboration for 135 Million Monthly Users on
by NK- Reactive streams and Canva architectureThe importance of forming opinions in the engineering industry on
Engineering LeadershipbyGregor Ojstersek About the importance of sharing your opinions
12 Career Lessons for Software Engineers on
by 12 career lessons to keep in mindThe 5 Stages of a Software Teams Life Cycle on
by Interesting model to understand on what stage your team is.
Thank you for your continued support of my newsletter and the growth to a 5k+ members community 🙏
You can also hit the like ❤️ button at the bottom of this email or share this post with a friend. It really helps!
 | A guest post by
|
Being considerate of the customers and reviewers always pays off. Great one both!