# Building systems at scale: how Skyscanner approaches engineering design reviews DevFeed: [Building systems at scale: how Skyscanner approaches engineering design reviews]() Original publisher: [Read original article]() Author: Skyscanner Engineering Published: 2022-10-31T10:04:46Z Content type: opinion Language: en Sources: [Stories by Skyscanner Engineering on Medium]() Topics: [Architecture & Design](), [systems](), [Web]() Tags: [design](), [engineering](), [review](), [scale](), [systems](), [teams]() ## AI overview This article explains how Skyscanner uses engineering design reviews to peer-review changes from small code modifications to system designs. The process uses structured documents to establish shared context, align stakeholders, gather feedback, and surface incorrect assumptions across more than 80 engineering teams. ## Source excerpt By Tom Butterwith, Engineering Manager Designing systems at scale can be a daunting task at the best of times and when you add in the complexity of managing stakeholders, the whole process can get complicated fast. One of our engineering principles at Skyscanner is that we peer-review every change and we apply this principle to everything from one-line code changes to system design. We accomplish this by conducting a design review: a process centered around a document capturing the what, why, and how of a problem and its proposed solution. What are design reviews, and why do we use them? When designing systems, there are a few challenges we try to overcome with our design review process. The first is developing a shared context. In order to provide appropriate feedback, we need to ensure that everyone reading the document understands the "why" and the "what" of the problem. The "why" can be understood as why are we thinking about this in the first place, and why is this work important to the business. The "what" is the problem's parameters -- what issue are you trying to solve with this design, and what are you explicitly not doing. It's also important to think deeply about who should be involved in the process and who should be informed of the changes. Often the most difficult part of building systems at scale is aligning your stakeholders, and setting the scene up front in a design document is a great way to bring people along in your process. Given that we have over 80 engineering teams working on a wide variety of services, a large change such as replacing our web framework of choice naturally affects a wide number of people. The team responsible for this conducts a series of design reviews to outline their thoughts and how this will affect the wider business. This gives each of the teams involved a place to contribute to and challenge the proposal while highlighting any assumptions that might not be correct. The design review process usually involves a single au