Managers: how to maintain effective technical discussions (Part III: facilitating discussion)
… in which we are introduced to different ways of encouraging the actual discussion of the proposed solutions.
The Series
Part I: the goals
Part II: setting up for success
Part III: facilitating discussion ←you are here
Part IV: how to help when it falls apart
Facilitating discussion
Once there are some proposed solutions, we want the team to have that valuable, open, technical discussion.
There are several choices to make and there is no single approach that will work for every team. Try some of the suggestions here and see what works.
Creating the technical decision document
We want to have an artifact that documents the technical discussion. This allows us to show we have done due-diligence and may help us answer the question that will inevitably come up: “why did we decide to do it this way?”
The team will need to decide whether they prefer to write this document synchronously in a meeting or asynchronously in a shared document. I recommend that the document starts as a shared document with asynchronous contributions as long as that is productive.
The team will need to decide on how many (if any) synchronous meetings are needed and when they are needed. You can obviously help with this if you see that valuable progress is not being made.
The document itself
We want a document that encourages valuable, technical, open discussion.
I recommend avoiding a table of proposals that contains all discussion. This can become illegible quickly.
I recommend that the document have intentional space for discussion of each proposal.
Here is an outline that I use:
1. The problem and constraints
1+n. Description of proposed solution #n
A. Technical advantages of proposal #n
B. Technical concerns about proposal #n
C. Technical responses to concerns about proposal #n
Allow the engineers to contribute to the document, adding their proposals.
The team may want to go ahead and document advantages and concerns about their own (and maybe other) proposals.
You have an important role as curator of the contributions. This is where you watch the document as it grows and think about the values discussed in Part I of this series.
Additionally, watch for repetition in the advantages and concerns. Someone may want to make a proposal look good or bad by saying the same thing in several different ways.
Also, encourage brevity and a focus on technical discussion.
To meet or not to meet
If there seems to be confusion or a lack of valuable progress, call a meeting whose goal is modest: ensure there is common understanding of the problem being solved and of each of the proposals. Try to stop any arguments for or against proposals until the team is satisfied that there is a common understanding.
At that point, the team may want to break and go back to the document asynchronously.
At some point, they may want to get back together for a meeting to discuss more in person.
Meetings
If you have synchronous meetings (or if you know that the engineers are having meetings without you), then encourage the following practices:
- Start by noting the problem we are trying to solve and constraints or non-functional requirements on the solution.
Do not begin discussing solutions until everyone is satisfied that they have a common understanding of the problem.
Try to document this common understanding as well as possible. - Describe a solution.
Discourage discussion of advantages or concerns until everyone is satisfied that they have a common understanding of the proposal. That can be difficult because questions can lead to discussion. Some of this discussion is necessary to get to a common understanding. Pull the conversation back to the question of “do we all understand this proposal the same way” if it goes too deep prior to getting a “yes” from everyone.
Try to document this common understanding as well as possible. - Discuss the proposal. Now we go deep.
Encourage folks to move through the discussion by pointing to an arrow on one of the diagrams and saying ensuring everyone is ready to focus on that arrow. This will help to avoid rapid subject changes or contention due to contextual confusion.
This is where the values from Part I need to be attended.
Try to document the technical advantages and concerns as well as possible.
Of course, the synchronous conversation may not stay this organized and that is expected. The common understanding will evolve as proposed solutions are discussed.
Coming soon
If you find notice (and you should) that some of the anti-patterns listed in Part I are occurring on your team, how can you help? We’ll propose some ideas in Part IV.
