To kick down an open door, the first part of the title of this blog post is simply wrong. Even if you’re a technical lead, you shouldn’t be leading a technical discussion; you should only be coordinating and facilitating the discussion.
This sounds pretty obvious, but often the most talented technical people are introverts. It is not easy for them, including myself, to say anything in the heat of the discussion. So stop occasionally and ask everyone personally to contribute. I understand that it seems a bit forced to ask every team member to contribute to the technical discussion, but often the best technical designs come from the quietest team members.
My favorite way to conduct small solution architecture design sessions is on a whiteboard. A whiteboard session is the ideal way to create an initial technical design with lots of short feedback cycles. It doesn’t matter whether it’s a traditional whiteboard or a fancy digital whiteboard. Of course, with the traditional whiteboard, it is more work to manually erase the board to start a new design. I think that’s a positive because it keeps you from jumping from one topic to another too quickly. When a traditional whiteboard is erased, it is like a conclusion of the design session on a particular topic.
Another tip is to make sure that only one whiteboard marker is in use at a time for all the people in the room. While one person explains and draws on the board, the other person listens. The whiteboard marker acts as a token so that only one person is speaking at a time. The equivalent during a video call is raising your hand, with the host giving each other time to explain their point. This strategy, of course, can also be used during a traditional meeting, just use a teddy bear as a token.
In a previous project I worked on for a large banking company, to prepare for a new development cycle of the next sprint, we had several whiteboard sessions together with a rotation system. Every team member, junior or senior, participated equally in the whiteboard sessions by following a simple rotation system. “You can’t escape, now it’s your turn to speak up!”
The final refinement of a technical design should best be done by the entire team. This meeting acts as an approval of the technical design, so you know the whole team is on the same page. For ticket distribution, I would divide the work among the team members present at the meeting. Quickly review each other’s tickets and make sure the acceptance criteria are clearly stated. If no major changes to the technical design are needed, at the end of the meeting, with the design still fresh in their minds, the team can do the story estimation right away.
If you have a lot of experience as a technical lead, you may want to avoid just coming up with a solution (even if it’s a really good one). Point your team members in the right direction and let them discuss the pros and cons of one design versus another. As you know, there’s no such thing as the perfect software architecture design. It’s always a tradeoff between scalability versus simplicity and availability versus cost, just to name a few. Given these tradeoffs, you need to choose the technical design that’s right for your particular use case. Just make sure you’ve worked out and agreed on the technical design with your entire team.
Finally, my last piece of advice applies to every communication you make. Tailor your communications to your target audience. Recently, a manager asked me to explain the solution architecture for synchronizing on-premises data and documents to the cloud. With limited time to explain the solution architecture, I focused more on the different teams in the organization that would need to work together and how each team would be responsible for delivering the solution. A deep dive into how the technologies work together to deliver the target architecture would not have been the best use of the limited time we had for the meeting.