Managers: how to maintain effective technical discussions (Part IV: how to help when it falls apart)
… in which we propose strategies for getting a team back on track when discussions are not valuable, technical, and open.
The Series
Part I: the goals
Part II: setting up for success
Part III: facilitating discussion
Part IV: how to help when it falls apart ←you are here
How to help when it falls apart
Recall the original goals:
- high motivation and morale on the team
- get the best ideas and solutions possible out of the team
What can a manager do when the anti-patterns from Part I become patterns for the team?
Full disclosure: I am a software engineer and not a manager.
All I can do here is talk about what I’ve seen managers do that seemed to work.
Notice the problem
Failing to pay attention to these issues does not work to get your team to the goals.
Noticing these problems is not easy or natural for everyone. With effort and practice, it can get easier.
If you haven’t been paying attention to this, then your team probably has this problem. There’s also a good chance that you are part of the problem. The engineer(s) practicing the anti-patterns are using you to their advantage… but to the detriment of the team.
This is why it is important not to ask “who is the smartest person here?” or “who is right?” It is important that someone with authority is paying attention to whether the discussion is valuable, technical, and open.
How you might be part of the problem
There may be an engineer on your team who practices the anti-patterns from Part I but you fail to notice. In fact, if this is happening, you probably believe them to be the smartest engineer on the team.
If someone on your team is practicing these anti-patterns, and you believe they are smart, then they are probably a good ways out there on the sociopath or narcissist spectrum. They are good at what they do. What they do is gain the trust and respect of decision-makers and destroy anyone who threatens their social status.
If you are in this position, you won’t know it. If you’re lucky, the other engineers on the squad who leave will tell you. If you’re smart, you’ll listen.
The engineer who practices these anti-patterns is definitely demoralizing the rest of the team and preventing them from doing their best work.
What might surprise you is that they are also very likely completely incompetent. As technical as you might consider yourself to be, your head is not as deep in the technicalities as it used to be. You are probably not as difficult to fool as you think.
What does it tell you that they don’t want their work to be scrutinized and they attack anyone who tries?
The confident, certain, and well-spoken engineer seems to deserve your trust.
How can you determine if they are right or wrong?
You don’t have to be able to determine that… and you shouldn’t try.
Instead, determine if they are practicing valuable, technical, and open discussion.
If they are practicing the anti-patterns from Part I, even if they seem to be right and others are agreeing with them, you have a problem. At the very least, you have someone who is holding the team back from valuable, open, technical discussions.
All you can do is watch for the anti-patterns and take action… even if it is against the engineer you believe to be the smartest.
Take action
You may be about to find out why you’re a manager and I’m not!
But, if I were having this impact on my team, I would want my manager to talk to me about it in the following way.
- point out specific, documented examples of statements I’ve made that were chilling to valuable, open, technical discussions
- explain how those examples of things I’ve said or written could reasonably have a chilling effect
- do not allow the conversation to be steered into whether my proposals are right or wrong
- keep the focus on how I can do better at facilitating valuable, open, technical discussions
- set as one of my goals to improve on this aspect of my communication
If I am recalcitrant or defensive, then try having the team have some technical discussions or make some technical decisions without me. We might both be surprised at how well that goes.
If it doesn’t go well, then the team may be too reliant on one engineer. In that case, giving them practice doing this without me may still be the best course.
If I sabotage that effort, it might be time to let me go.
Final request
Please add comments!
Is the whole idea of having valuable, technical, open discussion misguided?
Is the proposed process over-the-top?
What process has worked for your team?
Have you seen other anti-patterns?
Are some of my so-called anti-patterns really not so bad?
What have you seen a manager do that worked?
What have you seen a manager do that didn’t work?
