I have been on many different teams over the years and how they handle architecture design discussions is always a point of interest for me. In general, there are a few rules that I try to personally abide by while leading these discussions. How teams handle these rules can look different, but the underlying principals are important for a successful discussion to be had.

Safe space required

Engineering decisions can be large and complex, and this means they can be hard to understand on a first pass. I find that many engineers, myself included, have a level of imposter syndrome that kicks in when they don’t immediately understand the scope of a problem. Making sure that your team understands that they are not just enabled but actively encouraged to ask clarifying questions is important. Especially on designs that I have been working on for a long time, one of the first things I remind people is that I am trying to give information at a good baseline, but I have been digging into this for a while, so I might have my baseline too deep. This usually helps break the barrier because it is already agreed that I might have not explained things well.

Another call out that I frequently make is that those clarifying questions have saved me from over engineering many times. I have worked on designs for extended periods of time just to have a question from a new engineer trying to understand the problem bring me out of a complicated problem to realize that if I had stepped one layer up the solution was obvious and simple. Sometimes our deep knowledge of a system can make it easier to overcomplicate a solution based on biases than coming at it with a fully fresh viewpoint.

We are on the same team

Especially when you are working on a cross team goal, it is important to remember that the end goal of the discussion is to find the best solution for everyone involved. At the end of the day, you are all a part of the same team that is trying to deliver the best product you can to the customers involved. Differing interests and needs from the various engineers or subteams involved can turn into friction points and if that is allowed to continue, it can lead to difficulty coming to a decision that everyone is happy with.

The common trap with this friction is that it can turn the one team into all the subteams against each other thinking that those teams just want to make a shortcut to achieve only their goal. When you truly dig into the viewpoints of each team, they are all coming with a fragment of the picture and trying to make sure that the solution makes sense in that fragment. Having someone piece those fragments together into a full view is extremely helpful. This person needs to try to leave any of their fragment’s biases and let the whole be their focus. One way to help with this is to have a different representative from their subteam in those meetings to allow their fragment’s voice to be heard without feeling the need to do so.

Leave your title at the door

Leaving your title at the door is more than just saying that anyone should contribute to the discussion. It is encouraging others to give their opinions and making sure all of the voices in the room can be heard. This can seem like a no-brainer, but sometimes this can be broken because of biases on the side of engineers to listen to certain voices in the room. This can make it prudent for engineers with higher capital to intentionally wait to provide insights to give time for others to voice their opinions.

On some teams, this might require some coaxing from less confident engineers. Asking them their thoughts before giving your own and being intentional that they should feel capable of not lining up with your own. This can help give them a platform to speak their mind, but does require a Safe Space to exist for the engineers to feel comfortable doing so.

Question even if you agree

When a solution feels obvious, sometimes the whole group will immediately agree that it is the route that should be taken. When that happens, I find an important role is to have someone play the detractor. In that role, you are trying to think of the holes that might have been missed to make sure they are accounted for even if you agree with the overall approach that is being presented. This can feel really awkward at first because you feel like you are saying that what you agree with is wrong, but it is a great way to solidify the solution. The more you can determine during the initial design, the smoother the implementation will be.

I will give a word of warning on this. There is always a balance of making it seem like you are attacking an idea instead of trying to solidify it. Finding this balance and identifying when your goal isn’t understood is important. Don’t be afraid to reiterate that you do agree with the approach, but are wanting to make sure that we have done all of our due diligence as a team.

Don’t be afraid to enforce scope

The scoping of the design is always important to lean on. Many times in a design meeting, there will be thoughts about other capabilities that could be unlocked or additional constraints that might be needed. While these can be nice to allow for future proofing a solution, they also can be detractors from a good solution. If those additional capabilities are something that are in the distant future, it might make it more prudent to ignore that and readdress the need when it actually comes up. This is especially true if you are making a decision on something that is easily reversed or pivoted on later.

When this scope enforcement doesn’t happen, you can enter into a state of decision paralysis over all of the what ifs that exist or you can end up deciding on an overcomplicated solution due to requirements that never become necessary. These states can be very large detractors from the goals of the team as a whole.