One of the most underrated parts of working at any job is interacting with people. It is amazing how much humans achieve via collaboration and also how fast relationships can degenerate. The following paragraphs cover real-life experiences and propose a model for kind influence – especially for senior team members.
I am right and you are wrong!
A couple of years back, while reviewing a pull request, I clashed with the author on the usage of some hard-to-follow patterns. Although I love elegant code, I still prefer easy-to-grok code over abstruse cleverness.
Looking back, I was so convinced of my correctness that I went overboard trying to get my colleague to do it my way. Eventually, I stopped by for a conversation and immediately sensed the engineer’s defensiveness. Thereafter, I compromised a bit and we finally agreed on a few adjustments.
What did I gain? Probably 50% compliance with my views.
What did I lose? A chance to build a long-lasting relationship to influence and communicate ideas.
Up to this day; I still kick myself whenever I remember that and wish I didn’t make that mistake. On the flip side, it was a learning experience and I try not to make the same mistake again.
Perspectives
A: “B is so wrong because doing XYZ is such a painful nit”B: “I like XYZ and A doesn’t know what he’s talking about; why is A trying to force his views down my throat?”
Outcome: Frayed relationship and potentially difficult future interactions
I will never approve your PR!
And this time I was on the receiving end. I was implementing some critical feature which touched the whole surface area of our products. With such a huge scope, it was almost inevitable that some things would go wrong.
Consequently, I discussed with as many stakeholders as possible to get multiple viewpoints and did my best to address all concerns. However, some strongly-opinionated engineers (and I respect them for that) felt uneasy about the changes and bluntly declined to review the PR.
While it is OK to decline PRs, what I felt was not OK was going up the chain to prevent the feature from shipping. That, to me, is strange – at least help get the issue fixed rather than throw a spanner in the works.
The authoritarian approach creates more problems than it solves. There are two possible outcomes:
- You win: You prevent the engineer from moving ahead with the feature however, that experience rankles the person at the receiving end and such unpleasant memories last for a long time. You lost the opportunity to influence and teach him/her the right way to engineer and design things. He most likely won’t come back to you and might tell his peers to avoid working with you.
- You lose: The engineer ignores you and finds a bypass: someone else/ some other way to get his feature in. Well, you can wash your hands clean and say “I refused to approve that” but when things go south, everyone is impacted – the customer sees a broken product and doesn’t care about who caused what. Moreover, you might even get pulled in to repair the same code!
Perspectives
A: “B’s work is so horrible that I can’t waste my time on this – I’ll tell B to redo everything or not send me review requests anymore”B: “Why is A trying to sabotage my work? At least, I would appreciate some help and guidance in addressing some of these issues”
Outcome: “B starts avoiding A and loses the opportunity to learn from A’s experience; B tells people of his experience and A inadvertently gains the reputation of being ‘that guy'”. A might never get a chance to explain his side of the story…
Oh, I think this is wrong and I will tell everyone about it!
Yes, this was me at the receiving end again!
I had spent several weeks on one of our top customer asks. This feature ranks as one of my most challenging projects ever: I had to deal with compatibility issues across different platforms, misleading documentation and tons of other issues.
The approach had a couple of issues since it leveraged various tricks to deliver the best customer experience possible. A complex solution might have eliminated a few of these challenges but it would take longer, lack interactivity and be more bug-prone.
I love feedback so I highlighted the various issues once I got it working. Alas, some top shot didn’t like the fact that it wasn’t engineered the ‘perfect’ way. Thus, he sent an email up the chain criticizing the architecture.
That set off the thread reaction: a few folks jumped in with ‘ideas’ and ‘suggestions’. I had the most expertise in that domain so I could immediately poke holes into every suggested fix. My weeks of poring into the nitty-gritty details of poorly-documented APIs, confusing implementations and orthogonal platforms had revealed many details that most outsiders wouldn’t know. Furthermore, I had already tried implementing some of those ideas in the past and ran into dead ends.
My manager and teammates did a great job in making me feel appreciated and also appeased the top-shot by making him know that he was heard.
Perception is not reality
A few weeks later
I got asked in the hallway about the feature by some other engineer. I felt the only way he could have known about it was because of the thread. The ‘perception’ was that the top guy was right and something was wrong with the approach.
3 years later
That feature has been in use for 3 years and has been quite stable. None of the proposed engineering rework has ever been done. So maybe something definitely was right about it.
Perspectives
A: “B’s implementation is totally wrong because I have seen company XYZ do the same thing using my proposed approach”B: “A thinks he knows but he really doesn’t know. Company XYZ’s approach doesn’t work because of ABC”
Outcome: “A thinks poorly of B’s skills and B thinks poorly of A’s judgement. Outsiders might think A is right and B is wrong”
Seek to understand
From the top; it is easy to express your thoughts and think you are right. Chances are you can be wrong every now and then. Moreover, it is highly likely that you don’t know as much as the engineer doing the grunt work. Thus, listen to their views and seek to understand before you forcefully push and advocate your opinions.
Repeated Games, Tit-For-Tat and Toxic cultures
I took a great multi-agent course in Grad School. Some of those theoretical concepts apply in real life; for example interactions between team members can be modelled as repeated games. I hereby propose a theory of why authoritarian smackdowns and harsh feedback can fuel the growth of toxic team cultures.
The tit-for-tat strategy in repeated games was quite successful in Robert Axelrod’s two tournaments (it won both times). Tit-for-tat is awesome when everyone cooperates and also great at punishing opportunistic strategies. However, its Achilles heel is that it can lead to a death spiral. For example, it can lead to a never-ending feud since two players can end up punishing each other in repeated rounds.
Emergent behaviours
Assuming engineers employ this strategy, it is possible for a team’s culture to degenerate into toxicity. How?
Engineer A is the ‘hard’ brilliant top-shot engineer who wants to win every argument regardless of whose ox is gored. Most times he is correct however when he is wrong, there are few folks who can stand up to him without getting put down.
Young engineers start emulating the top-shot since they assume that is what ‘successful’ engineers do (i.e. win all battles totally and pound your opponents into submission aka brilliant jerks). Rankled engineers also look for ways to get their own pound of flesh at every opportunity. Over time, clans emerge organically and the team is split along party lines.
Relationships matter
Several interactions at multiple jobs across 3 continents have made me realize that most people don’t have malicious intent. Most ‘so-tagged’ jerks lack empathy and communication skills; thus they do not realize the impact of their actions on their co-workers. It is very easy to label someone a jerk after one or two interactions and that message tends to spread.
I know of brilliant and great engineers who swapped teams because they were at the receiving end of some of these ‘treatments’. Whenever I reflect on these experiences and events, I always see them as lost teaching opportunities and missed growth chances.
I am not advocating for constant compromises and sweetness – that just leads to mediocre products. It is great to have opinions and argue vehemently about what you are passionate about. However, denigrating, belittling or attacking others is wrong – learn to respect colleagues and consider their emotions.
We can all agree to disagree respectfully: ideas are meant to be discussed logically and dispassionately. I don’t think anyone intentionally comes up with a bad idea, rather everyone attempts to do their best and sometimes make mistakes.
Clarify and make people understand. Without clarity, the same mistakes will be made again. At the very least, interactions should end without any ill feelings. Although you might disagree, you understand the opposing viewpoints and concerns.
Would there be times when you have to wield authority? Yes but I strongly believe this should be the exception and not the norm. Moreover, with proper communication, it is possible to make the impacted folks understand why.
I personally value relationships a lot since they offer a better platform for influence. Also, people tend to remember how you treated them for long. Authority can be taken away, influence? Not so easily. Don’t be that person no one wants to run into. Don’t burn bridges.
Conclusion
My kind influence principles
- Seek to truly understand before pointing out flaws
- Know that you can be wrong – no one knows it all
- Have empathy – you can teach and get your message across without hurting the feelings of others
- Genuinely care about the growth of your team – a rising tide raises all boats
What kind of engineer would I want to be? A kind engineer. I would love to know that people truly enjoy(ed) working with me. If you remember me with a smile, would want to work with me again or have me on your team again, then I think I’d be more than happy.
CodeKraft 
TL;DR: “Don’t be Sheldon Cooper!” 😉
Your points are all good advice, but you mostly sidestep what I think is the main issue: Psychology. What you are suggesting as helpful is really about being mature, self aware, and aware of others. Empathy and compassion are aspects of this. You don’t learn any of that from interacting with concepts and machines. You learn it from interacting with people, and in the case of compassion, from long suffering.
Many technical people find it much easier to deal with machines than with people. I have a specialized diet and when I used to eat out a lot, I got very frustrated having to explain things every time – often to the same person. Damn, why couldn’t I write a macro for that?
When people are less socially adept (as tech people often are), they tend to misread or ignore clues like body language. Some also tend to be socially insecure which can be expressed as brashness or defensiveness.
The first thing to do is to focus on the fact that you’re talking to another person. Once you get that interface working, and have some idea of what they value and what motivates them, you can speak to them on their terms and bypass having to deal with a lot of their “stuff”.
This is way easier said than done and mostly comes from experiences such as those you relate above.
The tendency to try to reduce issues to their technical/logical impersonal details can be self defeating if all the other person “feels” is “You don’t value me.” or “You don’t listen to me.” or all they “hear” is “You’re wrong.”
It’s better if you can explore their ideas, noting the good points and then adding, “Have you thought about what would happen if “this” situation/input… occurs?” or “How will that interface with all the other stuff done this other way?”
This approach takes more time and, especially, patience, but think of how you would feel if you were on the other end of it.
Ideally, you want to improve not only the product, but also the person producing that product. That’s done by treating them with respect and dignity and persuading rather than dictating.
LikeLiked by 1 person
Well written with a lot of lessons, not for engineers alone.
To bond a storming team (I will assume entropy is the default), team must adopt the team spirit displayed by sportsmen; anything short of winning the game is unacceptable. And we must do that without sacrificing the limbs of any of us. Each member must be empathetic without being emotional and judgemental. We would hold ourselves up and still get the best out of that, striking the right balance and thinking about the long term impact on us as individuals, our product/service, and our team.
LikeLike