Quarterly Architecture Review

Building a strong technical foundation is critical for the success of your product development organization.  In my last post I outlined a forum for making better technical decisions.  One of the pieces of feedback I got around it was anxiety around having an un-anchored discussion around technology which didn’t translate into making an impact for the business.  In this post I am going to be talking about a tool called an “Architecture Review” which helps to contextualize the product and technical investments and brings the team together around what the road ahead may end up looking like.

For a team to create meaningful impact for the business it is critical for there to be an understanding of what investments are being made and why.  Each individual has their own unique and valuable perspective, but if that isn’t reflected in a shared perspective it will be difficult for the team to be effective and coordinate well.  One of the best tools that I’ve used in the past to address this is the “Architecture Review”.   This is a forum with a critical document which creates alignment across various functions and connects to the strategy, resourcing and what to get done.

I like to work with the product team structure where you have design, product and engineering all working together on a clear set of priorities.  This enables strong alignment between the functions and rich conversations to happen.  For the review, I like to have one representative from each function to be engaged.  They should represent the overall perspective of the team with wider input.  In the review meeting there will be the product leader, engineering leader and design representative leading the presentation with the Sr leadership (CTO, VPE, CPO) present to give feedback and ask critical questions.  This enables a rich cross-functional exploration and creates a unity at the right level in the organization.

This team should get a template for the meeting ahead of time and should have the conversations to build a rich perspective of where the team is headed and how to get there.  This should involve talking to teammates, sr leadership and other relevant functions.

What is in the deck and conversation?  I like to have a few sections covered.

• Goals
• Strategy
• Product roadmap
• Technical strategy
• Technical roadmap
• Headcount
• Biggest challenges

I’ll be covering each of these sections in detail

Goals

This may sound obvious, but it is critical to anchor the conversation on what the goals are for the team.  Like all of the sections here, the cross functional team needs to come together and define the north star goals for the team and be able to articulate them.  It can be surprising how much disagreement there is in setting goals.  Your belief of what the goals are may be at significant odds with others in the team.  Moving through setting goals will stir up discussion and create a stronger north star. 

Strategy

This section is critical for establishing how the team will orient themselves.  Where is the team trying to get to?  What is the overall plan to accomplish the goals stated above?  This should be stated in such a way that some paths are clearly not to be taken.  This strategy should incorporate thinking from across the team and make it clear how the team is going to move forward.

Product roadmap

This is simply the priorities for what the team is developing on the product roadmap.  This makes it explicit what the team is looking to deliver and therefore what the team is not going to be prioritizing for the upcoming two quarters.  This should ladder into the strategy.  If they product roadmap doesn’t support the team strategy then either the strategy is off, or the roadmap is off.  Make sure this is aligned!

Technical strategy

Presenting what the approach is for the technology is a component that often gets overlooked in the hustle and bustle of building a product or it can get lumped in with each individual project.  I find it to be extremely helpful to have a section where the cross functional team is presenting where they are going from a technology perspective.  As an example, if you are going to be investing in new developer tooling, re-thinking how services talk to each other or other long term investments, these should be called out!  Make sure it is being talked about in a way that takes into account what the business impact ends up being and isn’t being done because it feels like the right thing to do.  Rigor builds credibility here.

Technical roadmap

If there are engineering specific projects, then showcase them here!  Often these don’t get talked about often enough outside of engineering even though they can be the most impactful to engineering efficiency and developer happiness.  Let’s celebrate and proudly represent what happens under this banner.

Headcount

People make everything happen for the team.  Showing the team to get a clear sense of the roles and the size makes it a lot more tangible who is going to be involved in the road ahead.  It can also quickly underscore places where key roles may be missing or too many people in a different area.

Biggest challenges

Finally underscore the biggest challenges the team is facing in the quarter ahead.  This can lead to really interesting conversations and awareness about how to better support the team.  Things which may seem apparent to the team may not be bubbled up elsewhere and this is a key place to build that visibility.

Let me know how this goes for you or if you have questions you can shoot me an email at [email protected].  You can always get these right to your inbox by subscribing to my substack at https://bradhenrickson.substack.com.