"Hey - <problem> is causing <symptom>. I think you have context on this - can you drive <solution>?"
We're people. The nuance, tone, and empathy of what we say matters. I know some people will scoff at "coddling" or "beating around the bush". I think these people don't correctly prioritize the outcomes of their communication.
When I talk to someone, my goals are, in this order:
1. That the other person like me and want to continue working happily with me in the future and feel emotionally safe talking to me.
2. Whatever "primary"/immediate outcome I'm shooting for
Paying attention to 1 pays off in the long term. People are happy to work with you and it accelerates how effective you can be because people feel safe with you.
"Hey - <problem> is causing <symptom>. I think you have context on this - can you drive <solution>?"
Please don't go around blowing corporate-speak up people's asses like this.
Seriously this a huge waste of time. If I made a typo in some important document or piece of code, just tell me what it was, and I'll fix it.
We're team members after all. Plus we've been spent years at hard technical schools and are used to having our work evaluated and corrected by others. We're not babies.
Granted, your approach is much more applicable (and is arguably necessary) when things are fuzzier, when it's not clear what the root cause is or who (if anyone) is at fault.
Most of the time it isn't though - it's very straightforward, and has nothing to do with ego or blame at all. In these (the vast majority of cases) -- just give me the information so I get through the day, please.
> Granted, your approach is much more applicable (and is arguably necessary) when things are fuzzier, when it's not clear what the root cause is or who (if anyone) is at fault.
But can you always reliably tell? There might be a reason, what looks like a mistake to you, was done in the first place. A reason that’s not obvious to you, because the error is in plain sight and takes up all the space. So, by "blowing corporate-speak up people’s asses", you actually give them a chance to elaborate, without already coming to a conclusion and calling it a day. This is something I'd expect from a senior developer, for instance. I usually frame it as a question, to get an understanding as to why it was done.
And trivial errors like typos in a method name get a comment with a suggestion, that can be applied by the original author in Azure DevOps with a single click.
All I can say is that with both experience, and after getting into the groove and flow of working with a particular team - one starts to learn how to read the tea leaves, as it were, and to make reasonably accurate judgement calls about such things.
I'm not saying the "soft, guarded" approach is never suitable; quite often it is.
Most of the time, though -- especially after we've gotten to know the people we work with -- it's more efficient (and genuinely less distracting / bothersome to the other party) to just get to the point.
I think devs are often prone to misjudging that though. Especially when there's a power imbalance. A senior or staff engineer talking to a junior or mid-level ALWAYS needs to be cognizant of the effect your actions and words have on other people.
"after we've gotten to know"
In my experience, once you've built solid rapport, you generally can always be less direct.
"hey man did you just deploy xyz? I noticed there's some weird error prints, wanted to make sure you saw"
"yeah thanks, just saw them a minute ago, already on it"
There's no need to be highly structured or direct, just a small nudge/hint/check, and they know you have their best interests at heart and aren't upset or annoyed.
"Hey man did you just deploy xyz? I noticed there's some weird error prints, wanted to make sure you saw"
That sounds totally great of course. What I'm concerned about is when people think they need to get all long-winded and and jargon-y to avoid sounding "blunt". Per the example in the ancestor comment which tipped this all off (slotting your values in):
"Hey - it seems the XYZ deployment is causing some weird error prints. I think you might have the context on this - can you drive a solution?"
Even if your teammates don't need this, writing this way is a useful skill when dealing with vendors or other 3rd parties whose culture you don't know, and you don't want to give them an excuse to prioritise someone else's ticket
It starts well, with "X is causing Y", and reminds me of a framework we had at one of my previous jobs - behaviour -> impact -> outcomes (or options?). It's a model to provide developmental feedback, but can be useful to frame other situations. In this case:
"System X is currently way behind our target uptime. As you know, this was caused by the introduction of feature X which your team worked on recently. We need to get back on track and meet our SLOs before it starts impacting revenue."
Tells them everything they need to know. You shared the necessary info and actions to be taken are obvious, but adding a "we need you to focus on this and take the lead on fixing it" will not sound aggressive.
The approach you mentioned is very cloudy in comparison, "driving" something is not a clear outcome, "you have context" is soft blaming. It's just a very polished "it's your fault, fix your shit", and it would sound exactly like that to me. It's precisely the kind of beating around the bush that people scoff at. The message itself can be a lot better.
I think your pattern looks very effective. I never considered that the side effect of #1 is to create a psychologically safe environment.
Not to take anything away from your post, but I have noticed that a few people lean very heavily on #1 to get people to do a lot of #2 for them. In return, they are "always busy" and cannot help. I struggle the most with these people. I am sucker for #1, as I am human after all.
I have similar sounding goals except my first goal is this instead:
1. That the other person know they are valued by me as a person and feel safe talking with me.
It shifts the goal from one that is about me to one that is about them. And that is really what I want. It's not to be liked but for them to feel valued.
"Hey - <problem> is causing <symptom>. I think you have context on this - can you drive <solution>?"
We're people. The nuance, tone, and empathy of what we say matters. I know some people will scoff at "coddling" or "beating around the bush". I think these people don't correctly prioritize the outcomes of their communication.
When I talk to someone, my goals are, in this order:
1. That the other person like me and want to continue working happily with me in the future and feel emotionally safe talking to me.
2. Whatever "primary"/immediate outcome I'm shooting for
Paying attention to 1 pays off in the long term. People are happy to work with you and it accelerates how effective you can be because people feel safe with you.