Managers: how to maintain effective technical discussions (Part I: the goals)
…in which the values of technical discussions are described and illuminated.
The Series
Part I: the goals ←you are here
Part II: setting up for success
Part III: facilitating discussion
Part IV: how to help when it falls apart
The goals
In what follows, you may see things that don’t seem right. Please read through the series and comment on the last part.
The goals:
- high motivation and morale on the team
- get the best ideas and solutions possible out of the team
I believe that in order to attain those goals, we need valuable, open, technical discussions.
The constraints:
- you have human beings on the team
- they have different experiences
- they have different levels of skill in dealing with conflict in a healthy way
Ah, that’s going to be trickier than I thought.
It is tempting and natural for a manager to trust or agree with one engineer over another. But this can have the ill effect of preventing participation from other engineers who may be able to make valuable contributions when given a healthy atmosphere.
What can you do, as a technical manager, to encourage and facilitate valuable, open, technical discussions in your organization? I hope this series of articles will help to get you close to an answer.
A difficult task for a manager is to try to look past questions like “who seems to be the smartest person in this discussion?” or “who has the right solution?” But the payoff of having valuable, open, technical discussions is that you will get better solutions and higher morale out of the team.
These three attributes are tied together and must be seen as intertwined.
Valuable
The discussion begins with a description of a problem that the customer or business wants to solve and ends with an artifact that explains the team’s approach to a solution.
We want most of the individual contributions to be valuable in themselves. Here are some features of a valuable individual contribution:
- Add to a common understanding of the problem being solved.
- Add to a common understanding of a proposed approach.
- Reveal a technical concern or weakness in a proposed approach.
- Reveal a technical advantage in a proposed approach.
- Reveal a feature of the problem that is not addressed by a proposed solution.
All of these (and similar features) are clearly of value if the goal is a highly functional and motivated team.
Technical
Proposals, concerns, and arguments should have real, technical backing. A statement may sound fine and smart, but that can be faked. Ask yourself whether the statement is accompanied by real, technical reasoning.
Open
We want input from all participants who are forming questions, challenges, or contributions that are valuable and technical.
This attribute is about “soft” skills. Due to the way folks on the narcissist or sociopath spectrums control discussions, this is the one that can be the hardest to achieve.
Watch for statements that chill further discussion of an issue without technical reasons.
Some specific things to watch for
Below are some examples of anti-patterns that can chill valuable, technical, open discussion. These behaviors can prevent the team from getting to the best possible solution or maintaining high morale.
Getting personal
Watch for statements that lead a conversation into personal rather than technical values.
— — — — —
Even a seemingly-innocent statement about “my experience” or “my gut” — without real, technical reasoning — can make it difficult for respondents. A criticism of the proposal becomes an attack on the person’s “experience” or the quality of their “gut.” This kind of statement will often end threads of discussion because folks don’t want to question the speaker’s “experience” or “gut.”
— — — — —
Steer folks away from ad hominem remarks. Encourage folks to address proposals and concerns rather than people.
“What are some advantages of that approach?” instead of, “Why would you want that?” The latter is a challenge to a person that only that person can answer. The former is a challenge to a proposal that anyone might be able to contribute to.
Another example: “You don’t understand what I’m saying,” instead of, “Help me understand this objection.” One is a personal attack! (Read it again.) The second encourages further discussion from all quarters.
— — — — — —
Avoid “philosophical” debate. When someone brings up a legitimate, technical concern about a proposal, someone might say, “well, you and I just have philosophical differences.” This does not add value to a technical conversation. The effect (intentional or not, it doesn’t matter) is to short-circuit technical discussion.
Non-technical negative characterization
Watch for negative characterization of a proposed solution without technical details.
This might be something like, “sure, we could implement an infinite series of stop-gap measures,” which — even if you ignore the inappropriate sarcasm — implies, without technical reasoning, that the counter-proposal is an infinitesimal, stop-gap solution.
Whether they are right or wrong is not the issue. Was there anything technical in this response? No, it is simply a characterization without anything technical to back up the characterization. The effect, (intentional or not, it doesn’t matter) is to chill further discussion.
Speaking in absolutes
“That’s impossible.” “Everybody knows…” “Nobody does it that way.” “All the bloggers say…” “This solution is incompatible with our current architecture.”
Unless clear, technical reasons are given, this kind of statement does nothing but chill further discussion.
Unexplained modalities
“Technology X should only be used for Y.” “Technology X can’t do Y.”
Are there technical reasons the X should only be used for Y? Are there technical reasons that X can’t do Y?
Recommending that the “expert” be allowed to make decisions without scrutiny from others / Getting help from management to end valuable, open, technical conversation
You may have an engineer who gains your trust and respect then tries to use that to avoid having their technical proposals scrutinized or understood by the rest of the team. Try to notice this and find a way to resist.
Appeals to special knowledge
This might be, “I had a conversation with the lead and she said …”
Or a statement like, “the company has decided to use this approach…”
Such statements do not add value to a technical discussion. The effect (intentional or not, it doesn’t matter) is to end discussion.
Further, is it even true? Who was involved in that “decision?” Was it reviewed? At what level of the organization did someone say that this approach is what we are doing and it is no longer open to discussion? Often, the answers to these questions are “no,” “no,” and “nowhere.”
Finally, even if it is true, if we are trying to have a technical discussion, then this begs the question: is this technically a better solution?
Using ambiguous jargon
For example, “multi-tenant” means a lot of different things. It’s a multi-dimensional spectrum of different approaches and solutions. Saying we have, don’t have, want, or don’t want a “multi-tenant” solution is not helpful without (a lot) more details.
Another example is “declarative programming.” To quote Eric Evans in his Domain-Driven Design book, “This term means many things to many people…” Using this phrase without additional detail or context is a sign of an inexperienced engineer trying to impress people.
The unqualified use of phrases like these does not contribute to technical discussions. Instead, it stifles further discussion with ambiguity. Junior engineers may be afraid to ask and senior engineers may not want to embarrass the speaker by pointing out the ambiguity.
Scoffing at questions
If someone asks a question like, “what do you mean by ‘multi-tenant?’” are they scoffed at or dismissed? Or do they get a diagram explaining what the speaker means by the phrase in the given context? Prefer the latter.
Responding to questions without answering them / Simple answers on complex issues
If the speaker doesn’t ask, “did I address your concern?” ask it for them. Make sure the person who brought up a concern is satisfied.
Changing the subject
This can be hard to catch especially when someone is practiced at this art. If tracking the current topic becomes hard for you, ask the team if anyone else is having the same problem.
Creating fog
This can be difficult to catch because you will be in the fog, too. When you suspect the fog is rising, you might ask the team if they’re feeling the same way.
Coming soon
In the next part, we discuss how to help the team prepare for valuable, technical, open discussion.
