One part of emotional intelligence is understanding how our words impact others.
This is a topic I ranted about briefly in "Being Critical of Past Developers" but I thought it would be worth a longer discussion. The message is still the same, though: your mindset matters, and your language matters.
The longer I work in tech the better I understand that I don't want to work with the smartest people, I want to work with the most collaborative and empathetic people. I might be impressed with someone's T-shaped knowledge of their discipline, but one thing that makes me excited to come to work every day (or makes me lose a significant amount of motivation) is being able to work alongside problem solvers that don't dwell on past imperfect choices, but instead want to work together towards a better future.
No complaints. No blame. Just questions and actions with a positive intent.
I can't speak for all developers (blanket statements are something we'll talk about in this article), but I can't imagine I'm alone in what words and actions will immediately make a day worse.
I think the idea that developers or engineers have little to no emotional intelligence is trite and untrue. I don't relate to it, my friends don't relate to it, and most of my past and present colleagues don't relate to it. Maybe I've had the privilege of working at companies that hire well, but I just don't come across many people who show up to work every day with a poor attitude and negative intentions.
Even with that said, emotional intelligence is still a muscle that we have to exercise like any other, and taking time to reflect on what is and isn't working is crucial.
So until proven otherwise, I assume my fellow developers are emotionally intelligent and have the best intentions. But even with the best intentions we might not realize how some of our phrases or word choices could affect others, so I want to discuss that here.
Blanket statements, or speaking in absolutes, mostly when there's a negative connotation, can come off as inflammatory without the speaker intending it. Here are some examples:
Our local environment is terrible, it doesn't work at all.
Our unit tests are bad, they're hard to write and slow to execute.
(Past decision) was a terrible idea, why did we choose that?
We don't do a good job of pushing back on tight deadlines.
This task took way longer than it should have [because our code isn't as easy to contribute to as it should be].
These examples are overtly negative, but even with different word choice there are still a few problems.
They don't assume positive intent.
This is the main reason someone might perceive these statements as inflammatory. Someone, possibly someone still on your team, is the person that wrote those unit tests that have gotten slow or made that decision in the past that needs to be revisited. These artifacts and decisions didn't come out of nowhere, they came from people, and it's likely there was a complicated context that led to the outcome.
Instead, try to seek understanding:
Do we have a technical design document that discussed the tradeoffs of this design?
Do the anchors that led to this decision still hold true, or would it make sense to revisit this decision?
We can almost always assume that people made the best decisions they could at the time given their knowledge, resources available, and time allotted.
They're complaints without solutions.
Maybe the sentence will be followed-up with a proposed solution, but it started from a place of complaint. There isn't a way for complaints to be perceived as positive, helpful, or optimistic. People who share complaints often may gain a reputation of being a complainer, and with that comes a perception of being pessimistic or non-collaborative.
A strategy to avoid this is to state the problem statement, immediately followed by a possible solution or a question:
I have found it difficult to contribute to our unit tests, how do people feel about us re-organizing our volatile dependencies to make test setup easier?
Sometimes I find myself blocked due to staging environment contention, what have been the challenges to running our full stack locally?
They're stated in absolutes.
No room is left for middle ground. The local environment is either terrible or great, the unit tests are either bad or good, and decisions were either short-sighted or clairvoyant. It's likely the truth is actually somewhere in the middle, and focusing the conversation on specific challenges helps lead to specific actions that can be taken.
They use collective pronouns.
The statements are speaking on behalf of the entire team's opinions, handiwork, ownership, or actions. Maybe you don't feel we do a good job of pushing back on deadlines, but I think we do the best we can. Maybe you think our documentation is weak or incomplete, but I think the small subset of people that contribute continually make it better for everyone.
Using collective pronouns also absolves personal responsibility. It doesn't take ownership. Yes, maybe the setup for our local environment is cumbersome to set up and has too many dependencies, but every developer on the team has the opportunity to make it better for the whole team.
One coaching strategy
A past partner of mine had a feedback strategy that was effective with me, and it could be a good strategy if you need to give a colleague feedback. Their strategy was to soften or preface feedback with "you may not realize", and that helped make feedback less confrontational to me. Some examples:
You may not realize it, but people might perceive you as bragging when you talk about your job. I know you're proud of where you work, but your language doesn't always come across with humility.
You may not realize it, but you haven't been investing time in your friends lately, they might appreciate some of your time and attention.
I also had a past manager that used a similar strategy:
You may not realize it, but you have colleagues that see you as a mentor, and your negative attitude is influencing them.
You may not realize it, but the high expectations you have of yourself may be carrying over to expectations you have for your colleagues, and that isn't entirely fair to them.
To me, this phrasing has helped bring unintended consequences of my words and behaviors to my attention, consequences that the person giving feedback believes that I don't want, and they're likely right. It feels less confrontational because there's no judgement or demand being expressed outright, just information that empowers future actions and decisions.
It is easy for blanket statements to come across as unhelpful or inflammatory for a number of reasons, even if we didn't intend it. Instead, we should try to:
- Assume positive intent for both our current and past colleagues
- Offer solutions to perceived problems, or ask questions to gain understanding
- Avoid speaking in absolutes
- Avoid collective pronouns, instead using "I" sentences