Don’t be a jerk: How not to alienate people abruptly, and risk losing everything they have to offer

Here’s a little secret: everybody has something to offer.

A couple of months ago, no one would’ve believed that I could write a post with this title — and get away with it. But now I’m sure many will appreciate that I took the time to write a post like this. This isn’t a personality development post. But it does have some takeaways — especially for any developer/designer on a journey, like myself.

Coming to think of it, the title seems to be in reverse: it should’ve been How not to alienate people abruptly, and risk losing everything they have to offer: Don’t be a jerk. Because, really, it’s that simple. I also strongly believe that if you’re not pissing someone off, you probably aren’t doing anything important, but that’s not an excuse to be a jerk to everyone who approaches you and putting them off.

One of the most important things to do on a journey is to progress. And progress for a developer/designer comes in the form of improving one’s skills, and this usually happens with collaboration. And collaboration does not happen when you put off other people. There’s only one problem with putting off other people — you lose everything they have to offer. And we need everything people can offer us.

“A knotty puzzle may hold a scientist up for a century, when it may be that a colleague has the solution already and is not even aware of the puzzle that it might solve.”
 — Isaac Asimov, The Robots of Dawn

It’s very easy to lose people and what they have to offer — but I think it’s easier to not do exactly that. Towards this end, here are a few things we can start doing right now:

Don’t use I or You

Instead use we where possible

Using I or you in conversations can sometimes quickly turn the heat up. When talking to people, usually the conversation involves the both of you (and others pertaining to the group), and it’s better to collectively include them instead of singling out a person.

Let’s take an example scenario. A project you were contributing to (and may be the owner of) was implementing A, and another person who just started contributing to it started doing B. The conversation could go:

You: Hey, I just noticed you introduced B. I use A.

Even without writing any more, the weight of the I and the you in the previous statement should be immediately apparent. I and you have this bad habit of pointing at someone, which really isn’t that productive (except in special cases). A better way to take the conversation ahead would be:

You: Hey, we just noticed that this contribution brings in B. We generally moved towards A for x,y,z reasons, and we would like to know if B is really necessary or improves anything on this front. Please share your thoughts.

The theme that this piece of text sets is that we are open to taking things forward, and we respect the other person’s thoughts and work. This is very important when expecting and being part of a collaborative effort. It’s easy to unintentionally start a heated head-on argument that quickly gets personal, when we use I or you.

Don’t command

Instead convince, or be convinced

Sometimes we might be in a better position to command or exert influence on a person to do things the way we want — due to our experience, position, familiarity with the process, whatever be the reason. It is important in these cases to not command a person to do something, but have them do it out of their own will.

This improves their confidence and the team harmony. Doing things because we are sure they are to be done in such a way boosts confidence in one’s own work, rather than having to do it because someone asked us to. Always try to convince people, or be convinced instead by their arguments. This has a positive effect that builds trust among valuable teammates.

Don’t play into confrontational conversations

Instead use conversations that promote collaboration

Another example scenario. Due to some reasons, feature A was removed, which was not communicated properly to everyone on the team. So person B re-adds feature A when they find that it’s missing. It’s easy to start a conversation like:

You: Hey, I removed feature A. You have added it back, why?

It’s very easy to get into I did it, you did it type of talks — which usually turn bitter quickly for one person or another. This is an example of one such. It can be expected here that the other person says I added it back to fix issue x. If you don’t want it, you can remove it again. It can be easily seen that adding a simple line of reasoning to this fixes the issue of confrontational conversation:

You: Hey, we removed the feature A but it looks like we failed to communicate it to everybody. Apologies. We faced a blocker in x,y,z so we worked around it by removing feature A. Will we be able to remove it, or is it absolutely necessary for something else that we are not aware of?

Don’t criticize needlessly or negatively

Instead provide constructive criticism and useful feedback

I do think criticism is a good thing, but it has to be constructive. While it helps us to improve ourselves from any and all feedback, the feedback that we provide to others should always be useful, and if negative, should most definitely be constructive.

The problem with negative feedback that is not constructive is that it is shunned, or causes harm to the receiver instead of helping them in any way. And if we can’t help them, why give feedback at all? I could try and elaborate, but why not use existing resources instead? This one is a fantastic article that you must absolutely go through to learn how to give constructive criticism.

Don’t play the blame game

Instead own up first, and set an example

When something goes wrong, don’t be ready to point fingers at someone and hope to be done with it. Sometimes, some people may genuinely be responsible for some bad things happening, but singling them out or blaming or shaming them is good for nothing. Instead, articulate a plan to fix the issue at hand, and share it with the team as a whole.

But if it’s you who are responsible, start owning up immediately and offering to fix the issues. This not only fixes the issue, but doesn’t allow others to play the blame game too, and will likely help others realize that committing mistakes is nothing to be ashamed of, and could even help them start owning up too. A team where people own up and fix their errors instead of playing the blame game has a thick bond of trust among its members, and we all should aim to be part of such a team.

This is an article I came across while writing this post, that deals with this issue.

Don’t respond with curt remarks

Instead be nice to everyone

Everyone is busy, everyone has their own shit to be worried about, and they still take the time to talk to people. This does not give us the right to respond curtly or insult them. Imagine how you would take a response like that from the other person, before you attempt to respond. Sometimes we might have better nerve than the average Joe — that doesn’t mean we cannot be nice to people.

Don’t disrespect other people

Instead treat them with the respect you demand

There can always be a lot of difference between what a person and another think of as being respectful — so this is walking a tight rope. In general, it is always better to err on the side of caution here, and never utter anything that we suspect the other person might consider disrespectful. Sometimes it’s a salution, sometimes it’s small lies — it varies from person to person. If you have a shred of doubt whether something might seem disrespectful, don’t do it!

Treating people with respect also means treating their work and their thoughts with respect. Reconsider the example scenario in “Don’t use I or You”. That’s an example of not respecting the other person’s work or thoughts. Because we didn’t even bother to ask the other person for the reasoning behind introducing something like B. It’s better we keep these little things in mind while collaborating, so that the collaboration remains a good experience to look forward to for everyone involved.

Don’t try to get everything right

Instead let mediocre work get through sometimes

This is the point I would least agree to — I admit, I’m a perfectionist. But, wiser friends and mentors of mine have told me this multiple times, and even though I find it hard to follow myself, I feel this should be here.

We can try to improve everything always, right? There’s no end to improvement on any front. Sometimes being so focused on perfection might cause us to question the quality of work around us. And that’s not always bad. But if that is always, then that’s bad. For everyone. Let me explain:

When we want to improve everything around us, we will never be able to go at it alone. We will be depending upon other people to get things done. And sometimes, they might not be to our satisfaction. We can keep at it, but it is wiser to let go a few times — just to let the other person also feel confident about their contributions. The more confident people around us are, the better their outputs will improve, even if they are not very good at the beginning.

Or at least, that’s what I was able to take out of this message when people told me. ;)

Don’t be a jerk

Hardly surprising, isn’t it? Oh, well

Yeah, so the titular point that we absolutely have to follow. What is being a jerk, you ask? An easy test to know if our behaviour is akin to a jerk’s is to ask ourselves how we would feel if another person behaved the same way to us. If the resulting feeling is not positive, we’re being a jerk. Again, a few of us have better thresholds for nonsense, but that doesn’t mean we can start being assholes to everyone else.

So, that’s it, I guess. Doesn’t all this sound easier than being a jerk to everyone and losing out on what they have to offer forever? Isn’t all this very necessary for people who are starting out and want to improve through collaboration?

Share your thoughts, ideas, and feedback via comments.

If you liked the article, don’t forget to like and share this to your networks.