The Modern Leader
You get a message from someone on the Support team who says:
“Hey, did your team push out an update yesterday?”
Sound familiar?
How do you respond to something like that? “Yes, why?” “Yes?” “No?” “What do you want?”
Now, flip the script - you’re a leader, and one of your engineers pushed out an update that, frankly, was either poorly written or perhaps introduced a regression. You want to talk to them and you want to get to a better solution, but what you don’t want is to come across aggressively or in an attacking manner. How do you bring this up?
Asking questions to your team or fielding questions from others in your organization is not always a straightforward task, although it seems like it should be. I mean, a question is a question, right? In reality, the way you frame your question and present your question could have rather rough consequences for the one on the receiving end.
What should you think about when presenting a question to someone?
Get to the point - don’t be vague. “Hey, is X broken?” is not helpful. “I was attempting to take X action, but I experienced Y behavior instead of Z. I wanted to bring this to your attention because Z behavior was working for me recently (e.g. last week). Can you take a look at this? Here’s a screenshot/video. It’s preventing me from being able to complete Task A.” Look at that! You’ve not only brought up an issue in a helpful way by providing evidence, but you got right to the point.
Don’t attack in your questions. And now I present a gif I use far too frequently:
Something tells me that you probably aren’t phrasing your questions this way unless you are secretly Michael Scott, but the point still stands. It’s really easy in a heated moment to phrase a question in a way that could come off as attacking the person on the receiving end.
A common scenario here is when someone on your team introduces a regression that causes an outage or degradation of sorts. They’re probably already not thrilled with themselves for introducing this regression in the first place, but as their manager you still want to have a conversation with them.
Instead of asking “What did you do to cause this?” you can break down your line of thinking more clearly:
- Can you walk me through your PR and show me where the regression occurred? (You may already have this information, so if so, skip this step.)
- How could we have prevented this regression? What was missed? Are we lacking tests, are our tests not adequate enough, or was it such a weird edge case that we just somehow managed to miss it?
- What steps can we take to prevent this from happening in the future?
You’re basically reframing a question that could come off as attacking as a mini-post mortem for a particular incident, and you’ll benefit in two ways: your engineer will appreciate you taking the time to work through this with them and you’ll build more trust with them along the way, and you’ll have a better product in the end.
Now, there’s a difference between avoiding conflict and addressing it head-on in a calm manner. If this is a repeatable offense for a particular team member, you can absolutely still stress the severity of this situation while also asking questions in a non-attacking manner.
Lastly, don’t worry about a question being stupid. As you move up in an organization you’ll be removing yourself from the day-to-day, and as a result, you won’t necessarily be keeping up technically or from a business or decision-making context in every regard. Ask your question and don’t worry about whether you think you should know this already. It’s a learning opportunity for you and it’s entirely on them if they respond in a judgmental manner. It’s better to operate under more knowledge than to operate with partial knowledge because you were afraid of how your question would be perceived.