The situation I've encountered is a jerk who was actually fairly mediocre in his abilities but whose bully characteristics and brash confidence had led many of the non-technical people in the company to believe he was extremely skilled.
I think one reason people become bullies is because they know they can't back up their decisions with skill. Linus is brash, but is quite able to work well with people and has the results to prove it.
Most people who adopt bully tactics are simply doing it for tactical reasons to hide their own weaknesses.
The myth of "brilliant jerks" is harmful because it lets any jerk pretend he's doing it because he's brilliant, when chances are he's just afraid of being unmasked as mediocre.
As a corollary, engineering culture should be very open to every member of the team learning and being very open to lessons learned (read: mistakes made) in the process. Bullies often intimidate by criticizing others' decisions, which creates an atmosphere of fear that prevents rational thought and stifles group learning.
This is certainly a problem I’ve seen. One employee was hated by almost all the technical people because he was a jackass and couldn’t work with others. He wanted everything done his way and wasn’t interested in the opinions of others (except as they may bolster how great his ideas were).
The truth is he wasn’t very good, at least not to the degree he tried to present.
Some of management loved him because he worked so hard. He was always there, always the one holding things together.
The truth was he was doing that because his methods were shoddy enough that things were always falling apart. He didn’t want others working on stuff because that would either lose his control/power or people would see how bad things really were.
In the end it became too much. As the company grew and things were done without him it became clear just how little he actually accomplished. New employee worked as well and were easy to get along with, not hostile to help.
But we had to suffer with him sabotaging things and dealing with his outbursts for YEARS.
There a lot of things that lead to this, including...
1) The whole 10x thing. The implication being that if you're brilliant, you're worth an entire team or more; if you're average, you're... worthless. Thus, you have to be better than everyone else to be worth anything
2) Classic bro culture - somebody who gets rewarded for being obnoxious, bullying, and "alpha" is a very "bro" thing.
3) Tech people tend to be people who put a lot of their self esteem in their intellectual - and work - abilities. This means they get more defensive when that ability is threatened.
It's a culture that rewards being brash and confident. Can you imagine someone saying that they are an average programmer but work well with a team to get done a lot?
There are definitely people who quietly get a lot of work done, and there are people who are "force multipliers" who make the rest of the team more productive (something I regularly try to do, incidentally). Depending on the culture these things can get ignored pretty easily - the 10x developer is an individual with limitless skill in the classic view.
There's not really a space for an "average" developer - everybody has to be a "Rock star" or "10x" developer. We only hire the top 1%, etc. So if you aren't, what else can you do but fake it?
I've been a smart jerk, dunno about brilliant but positive about the jerk part. More in the selfless camp, I cared about the company (Sun) a lot and ran rough shod over anyone who got in the way of my quest to make the company better.
I definitely hurt some people and, as a young guy, felt that making the company better trumped all of that. And I was a little clueless, I had ADD and no treatment and had no idea that communication happened non-verbally, just wasn't a thin g for me.
What made it better was when I added compassion and empathy to my thought process. Instead of barging into someone's office and yelling at them that their code was broken, I'd start with the people stuff. Ask if I could talk to them, ask how they were doing, ask if they knew about this problem in their code. More ask, less yelling. And in my head, i would ask myself is there anything going on in this dude's life that is negative? Sick kid? Divorce? Parent dieing?
I was still willing to come to the conclusion that the person sucked at whatever chunk of code it was that was in the spotlight but it took me a lot longer to get there because I was trying to see if there was something else going on that caused the crappy code.
Dunno if that helps, I'm sure people told me to think like that but it took me a while to get there. Maybe this shortens the path for someone else.
I am an Alice and I need some feedback as why is it a bad thing! I work in an environment when very small percentage of people know what are they doing. and people that know what is going on do not speak up because they are frustrated and know probably nothing will change.
in this environment I do speak up whenever I get a chance and I've been in arguments with managers 3 4 level above me.
everybody else wants to be politicians and please everybody! but I believe because no one wants to hurt other people's feelings we are in a shit situation we are in.
why am I wrong ? should I care less like everybody else?
PS: where I currently work is wasting public money and I feel obligated to do something as a Libertarian!
You are wrong because the vast majority of people take criticism personally. It turns out that when you tell people they are wrong and present them with reasons they are wrong, a surprising number of people double down. I'm sure you have heard this before, but you have to make them think it was their idea.
Edit Source: I make this mistake all the god damn time, and never realize it until the person breaks and finally snaps at me. The whole time I thought we were just having a reasoned argument. I think that I am constructively invalidating the other persons arguments, meanwhile they are feeling belittled and defensive.
Edit edit: This is even worse if, like me, you think arguments are pretty much the greatest most entertaining game it is possible to play.
You are wrong because you are ineffective. You want a good thing: you want your environment to change for the better. But if you find yourself getting into arguments with managers, then you are probably not effectively changing minds, and you will get frustrated. You already sound frustrated.
Speaking the truth straight out can feel good, but it is rarely a good rhetorical strategy. Instead, back up, and start with this: what do the people across the table want? What do they believe is good, and what do they believe is important?
Now, how do you recast your arguments to appeal to those goals? How do you frame your position in such a way that they will want to agree with you?
This is the foundation of convincing people: empathize, understand them, learn their communication patterns. Once you see how they communicate and think, you work down those routes but send the message you believe is important.
You can't be a superior engineering contributor unless you are honest with everyone, from superiors to peers, to reports. The key is how you present information. I just proactively scheduled a 1-1 with a Sr VP three levels above me for later this month to cover an important topic.
This is what I want to tell them:
Our core customer facing application is shit. The contractors who wrote it cut tons of corners and the marketing people who designed did a horrible job, the UI emphasizes features customers don't care about, and makes it extremely difficult for customers to actually reach and use the revenue generating sections of the app. Not only is the marketing leadership is disfunctional, and worse, you (the Sr VP) have created a disfunctional development organization, that makes me wonder if you understand how to develop commercial applications.
This is what I will say:
The weaknesses in our core application are costing the company millions of dollars a month. We are struggling with making quick, effective decisions and shipping new versions to address the major problems because we have "too many cooks in the kitchen" in our team meetings and planning. I will give specific examples and relate them to specific examples from my long history shipping quality commercial apps on time. I will finish by saying the team is demotivated and underperforming, which makes you, the Sr VP, look bad, and plead that we need to solve this, for them and the company both.
In your engagement with the senior folk, do you just complain? Or do you suggest changes that you know are affordable and achievable? Are you arguing so you feel better about trying or are you genuinely attempting to affect change?
Also, has it occurred to you that the higher ups might not be the fools and cowards they appear? Is it possible that they are operating with constraints that they just haven't chosen, or are prevented from, sharing with you?
Obviously I don't know your organisation and it is, of course, possible that its staffed with incompetents. And that by sheer good fortune just you and a small group of your immediate colleagues are the only rational actors. Or it may be something else.
The article points out the damage that being an Alice can cause - some people (most people, really) are affected by the way others treat them, so when you are right, and someone else is wrong (and you are certain of that ;) ) you can add a bonus to your technical contributions by mentoring that person. Winning an argument is hard and doesn't fix underlying problems with competency, but mentoring someone will build up good will. Instead of feeling like they have lost or been proven inferior, the "opponent" in this case will correctly believe they have grown technically.
The way to do that is all in phrasing, tone of voice, and general respectful treatment. If, like me, this is not something that comes naturally to you, it might be worth searching google for a few little tricks that will help you to resolve disagreements. The Socratic method - using questions instead of statements - can be effective. It has also helped in my experience to describe similar situations in which the course of action you support has proven itself.
When speaking with managers who make a bad suggestion, it is helpful to explain that the course of action they are proposing was considered, and why it was rejected. That will reassure them that you are on top of the situation, and (in the case of a good manager) show that you are able to do your work without your assistance.
Of course if your manager's ego is tied to his/her suggestions, which is common, you're probably SOL. The most effective way I have seen a team deal with that is to implement the bad suggestions as quickly and flexibly as possible in order to minimise the damage to the schedule, the project, and so on.
You are not wrong. There are lots of people who feel and act like you, and when they get together on the same team they can be very productive.
I feel that a lot of places have a culture of agreeability. They are focused on fixing disagreement rather than fixing the underlying problem. A truth-telling person isn't suited to those environments.
I also feel that a "no brilliant jerks" policy is an anti-neuro-diversity policy. It weeds out high-functioning autistic and psychopathic people. I think any homogenous environment created from such a policy would be a dangerous thing.
Acting without tact and diplomacy is probably hurting your end goal. You want to build allies in a common cause rather than alienate people that can help.
> I am an Alice and I need some feedback as why is it a bad thing!
Are you interested in the best outcomes, or addicted to behaving in the way you find easiest? If you are actually interested in outcomes, if you actually care you will learn that meeting people on their terms will produce better outcomes than communicating however you find easiest.
I appreciate it when people tell me that I'm wrong in a respectful manner and with solid reasoning to back it up. It's impossible to be right 100% of the time, and the only way to improve is when someone or something points out when you've erred. If Alice was respectful and knew when to let things go in the example, I would want her as a teammate any day of the week.
It seems the gut reaction in tech is that conflict is bad, but conflict is inevitable. It is better to respectfully resolve conflicts than try to avoid them at all costs IMO
You know how people talk about "soft skills"? Bringing people around to your viewpoint without straight up arguing with them is indeed a soft skill. If you're a PERL hammer you're going to go after most every problem with a PERL script, right? What if the manager 4 levels above you is a Python guy? Is he right? Is he wrong? Or does he just feel differently? What if he's a functional programmer instead? What if he's a LISP guy?
At some point you have to learn to appreciate other viewpoints and approaches to problem solving. You might want to argue things on strictly technical merits when someone 3 or 4 levels above you has completely different criteria to judge a solution. Maybe he sees less risk or less cost, maybe he just doesn't want to change the status quo. Maybe he simply sees a challenge to his authority.
There's a wide spectrum between being a politician and pleasing everyone and being a politician and working through a discussion and couching your position in a way the other person appreciates and accepts. But it's on you to figure out how to make that work, not them.
It might be helpful to change your style a little to accomplish the same goal with less conflict.
Always always give people a way to save face, this applies doubly in meetings. If people feel like the choices are being right or being responsible for an error they will fight to be right. If you give them a third option (past inexperience, blame someone that left, poor testing, changed requirements) that doesn't hurt their reputation, they no longer have to fight to be right.
Try to teach people the principal behind why something is wrong/broken/bad. This applies to things like code health that there are more subjective. Instead of saying "That method should not be 300 lines." Teach that you want small understandable functions that do only one thing. This gives them a metric to use in the future and makes your comment seem more well thought out.
Be helpful when you can be. If you are always causing problem people will remember that. People also will remember when you go out of your way to help them. A little bit of oil could help the other interactions run smoothly.
If someone does something wrong, Alice tells them plainly, and they get offended, whose fault is it? Some people say it's Alice' fault for offending; some say it's the person's fault for doing it wrong in the first place, and for subsequently getting offended.
I think we're conflating is and ought here. It's probably a fact of reality that most people aren't happy to be told they're wrong. But arguably people ought to accept the consequences of being wrong, e.g. feeling bad when they're told.
I've talked to lots of startups in San Francisco. Most are failing, just due to the nature of startups, but can survive if they reach a finite set of straightforward goals. They've found product/market fit, they know what they have to do, they just have to do it, and the correct 10,000 characters of code input into a computer would solve all their business problems. There's often a lot of handwringing about why they're failing: the process is wrong; communication is wrong; something or other. But the largest reason they're failing is that they're insufficiently good at technology. You know who'd be really good at fixing that? A team of Alices.
I think Alices get too much flak. Bob is genuinely a toxic character. But if your only fault is telling the truth, which offends people, and you're otherwise excellent at your job--- there's a huge opportunity for twenty Alices to get together, bypass the inefficiencies of being offended, and win big. Tech has an obvious historical example.
Edit: I reread the description of Alice. All right, maybe don't browbeat your point into others.
Alice is so vaguely portrayed here that I think it's impossible to draw conclusions, let alone call her a brilliant jerk.
As you mention, pointing out when things are wrong isn't being a jerk, it's doing your damn job. "Having little empathy for others" isn't describing behavior, so it's meaningless here. OK, "browbeating" might be bad, but what does that mean anyway? Is she repeating the issue a month later after the problem got ignored, or is she micromanaging it, or what? There's no indication here. Whatever it means, Equifax could have used some browbeating on security issues.
There's no indication about why people try to avoid working with her. Does that refer to other developers, or does HR try to avoid her they go around asking for donations for girl scouts or something? I don't see a real problem with the latter. If somebody had reputation for pointing out problems in code, I wouldn't be avoiding her, I'd be seeking her out.
>They've found product/market fit, they know what they have to do, they just have to do it, and the correct 10,000 characters of code input into a computer would solve all their business problems.
Or they can get a huge team of pleasant and great-looking people that will leave a very good impression and raise tons of capital to keep burning through cash for years without fixing any of those problems. As long as the investors are OK with this, people will keep on using it.
Early on in my career (DevOps/Virtualization/SDN/etc) I landed a role as a junior admin, a backfill for a more senior engineer who was moving up in the organization, but staying on the same team. It could be said he landed somewhere between "Alice" and "Bob", probably due to some mild autism. Without getting into excessive detail, working with him was hard, but by far the most rewarding, educational, and instructive years of my career. I learned more in that short time from that one difficult engineer than the next 3 years combined.
I'm not excusing his behavior, but if you're able to handle that style and develop a functional relationship "brilliant but difficult" folks can be an amazing resource. He's the Sr Infrastructure Architect for that organization now, and they've never been doing better. His ability to be difficult but brilliant keeps the overbearing management folks in check, and has allowed the technology platform to move forward dramatically.
The one downside (other than the constant testing of my self esteem and resolve) was that I let him teach me D&D and he was a pedantic dick of a GM.
I could work with such people when I was younger, relatively low confidence and inexperienced. It is when i learned nore and had enough experience to have own opinions and gained confidense when being expected to do constant "yes sir" no matter how much I disagreed bothered me way more.
Most of those people are much less briliant when you are not a junior. It is mostly that they are rewarded for being jerk.
"""
Cosgrove asked them to elaborate on the idea: "exile the knaves, but fight for the divas."
Rosenberg said maintaining Google's collaborative culture requires weeding out and getting rid of the knaves: Employees who lack integrity, who are jealous of their peers, take credit for others' work, and think only of themselves. "Nice humble engineers have a way of becoming insufferable when they think they are the sole inventors of the world's next big thing," they write in their book. "This is quite dangerous, as ego creates blind spots... Nip crazy in the bud."
Divas, on the other hand, display "high exceptionalism," Rosenberg said. If the divas are brilliant and doing a good job, they should be valued and allowed to do their jobs. "As long as ... the divas' achievements outweigh the collateral damage caused by their diva ways, you should fight for them."
"They will pay off your investment by doing interesting things," they write. "...Remember that Steve Jobs was one of the greatest business divas the world has ever known!"
""" [1]
By all accounts I've heard from friends working at Google X, Sergey Brin is the textbook definition of a "brilliant jerk". This probably has something to do with it.
I've been in a non-tech work environment (specifically, publishing) where management followed this philosophy. In that case it yielded a disgruntled workforce with terrible leadership who were variously ignored and exploited by the divas. Ultimately the place would have done better with a boatload of knaves and no more than 2 divas.
Sounds like a jerk is just a diva we don't like. Which, you know, that's fine, but starting off with the pejorative "jerk" inherently indicates they are not a person worth valuing.
This is a great article. It's a terrific opportunity for introspection.
I do however want to point out that some of these may be less about being an insufferably relentless jerk than other pieces.
> He is late to meetings, ... then looks at his phone or laptop while ignoring everyone around him
This is also a pretty common indicator for ADHD. Not to say that excuses being a "jerk", but there are people out there that have a fundamentally difficult time tracking and arriving at meetings properly, and it's not always easy to account for. It also goes hand in hand with a few other related issues here. It's also somewhat common in the world of software.
I have some semblance of issue arriving at meetings properly, and it takes sincere effort to correct for it. When I started my career (admittedly, not so long ago) I definitely displayed more pieces of what is described as brilliant jerk than I would like to have (though certainly nothing like gaslighting and exploitation of others around me - more those things in line with adhd).
On the other hand, I spent 3 years working especially hard on self improvement here, and I certainly appreciate the patience of those around me in helping me realize my failures. It took me a year of effort to really avoid interrupting others while talking - not as a matter of being a jerk, but simply because my mind gets lost in conversation and feels the need to begin talking with less cognizance than I wish I had that others were speaking. These days, I am quick to apologize upon realizing I've interrupted, and ask the speaker to continue. That's strictly worse than never interrupting, but it both publicly acknowledges that I know this is a problem for me in conversation, and helps move forward.
The best thing for some people who have some of these issues is to give them honest, direct, and proactive feedback regarding it. They may well have no idea the ways in which they're impacting those around them, and they may well be surprisingly proactive in self-improvement upon being spoken to.
It's non-proactivity in self-improvement that you should be far less accepting of, ADHD or not.
I was so Alice for much of my career. I know this is going to sound totally cliche because this book get's recommended everywhere, but How to Win Friends and Influence People really did help me.
I prefer working with "Alices". It's refreshing to see people actually called on their bullshit.
IMHO there's also a limit to how much you can spare everybody's feelings and still be effective at that ^^. I think the OP believed that there isn't a limit. I think he's wrong.
In a corporate environment, there's almost no value in actually being one though. Linus Torvalds would almost never be promoted and would frequently be unceremoniously terminated - as advocated for by Brendan Gregg.
I'm still part Alice, I think. The Carnegie book really helped me, for sure.
The difficulty though is that at some point if you believe something is important you may ultimately have to go through some kind of dialectic to make your case.
How to Win Friends and Influence People says never have an argument. If you follow this advice you will reap the benefits of the book. However what you're building in your team will trend toward a Least Common Denominator. Or else I don't know how to not let that happen in a world where you can't debate. (Any response that tries to say debate/argument/dialectic aren't all the same thing in this context I think is cheating. Or someone enlighten me.)
I'd add that from an engineering perspective, 'brilliant' jerks aren't even that brilliant.
An actually intelligent person is happy to prove his thinking via truthful argumentation (and unit tests, documentation, and so on), and also happy to get his points refuted by similarly reasonable peers.
I've worked with so many brilliant jerks. They're incredibly toxic. The Bob example is bordering on sociopathic, or is a sociopath.
I've worked with someone who ticks almost all of the Bob traits. He would actively try to get people fired who he didn't like, spending time gaslighting everyone around them until enough people disliked his victim where it was possible to fire them. He turned entire teams against each other, causing organizational issues that lasted years after he was eventually fired.
The problem is that he was legitimately brilliant, and he was incredibly productive. This made his gaslighting all the more effective. When we spoke about things and people, people listened. He was charismatic, funny, and had a long-standing reputation.
After firing this person, we found out he has a history of being abusive and getting fired. It's hard to know this because he's in leadership positions in a few important open source communities.
Thankfully this org is numerous years in my past and I've eventually moved past the stress associated with it, but it's an experience that stuck with me for a long time.
In my case, for most my teenage and short adult life I was always left "feeling positive and motivated" except I would always fall back into the same habits. I started to expect the gentleness and kindness. What I needed was a good ass whooping. If I look back at my life in hindsight, I learned the most when I was under the gun -- had to succeed, failure not an option -- not "motivated" and "positively influenced"
Maybe there is a "non-asshole" way to do that, but there needs to be a place for this in society as well. Some people respond to gentleness and nudges, some don't.
The person I think back early in my career when I was an associate and my first tech lead -- yes! he was the biggest asshole I met at that time -- but it would be remiss of me to not admit that I learned and stretched more on his team than I did the rest of my time at that company by a mile.
I would hire a brilliant jerk. Our company has 3. 2 of them I actually like, they fit the likable jerk archetype (common in sitcoms, I think Bill Maher is a good example), and they’re good. The other one is basically not interested in human interaction. This offends people somehow, but I’d rather work w someone who doesn’t want to talk to me than someone who I don’t want to talk to.
The real problem with jerks is that "you get what you role model". If you have senior technical people acting like jerks and getting away with it, you have junior people concluding that being a jerk is the way to get a leadership position. That creates a toxic workplace over the long haul. Jerk-like behavior is a performance management issue and managers that don't confront it dig their own grave.
I feel that the Kotlin community definitely needs a "No Jerk approach". I've recently been to a meet-up which was on the advantages of using Kotlin for Android development, the speaker exhibited many characteristics from this article.
1. Bob interrupts others, and ignores their opinions (When people asked questions, he downplayed them and in some cases declined to answer them)
2. Bob bullies, humiliates, and oppresses individuals. With non-technical people, he wins arguments by bamboozling them with irrelevant technical detail, making them feel dumb (When asked about Coroutines he started explaining irrelevant stuff like locks and guards and compiler level instructions without actually answering the questions)
3. Bob engages in displays of dominance in front of groups (He was quite assertive that his language is better than Java, no one could convince him otherwise)
4. Bob is negative. He trash-talks other technologies, companies, and people behind their backs (He trash talked Java)
5. Bob manipulates and misleads. Sometimes he misleads subtly, by presenting facts that are literally true in a way that is intentionally misleading. (He mislead people into thinking that null checks were just wrong and should be avoided altogether by writing code in Kotlin, he also indicated that writing data objects was not possible in Java)
6. Bob uses physical intimidation. Bob glares at those he doesn't like, and may invade people's personal space. (He said that if his team member was unwilling to learn Kotlin he was probably not worth his salt)
7. Bob gives great talks – about himself.
8. Bob refuses to change. (This was quite evident about him)
To sum up, he was arrogant and loved humiliating the audience, I and a few others left the talk after 30 mins.
I previously worked in a place with a Bob (who ticks 80% of the boxes there) and it really is super-toxic. He got plenty of "gaslight" because he had special treatment. He didn't need to follow the processes like everyone else. He got cool work. Hence my 'previously worked'.
I've never come across this problem, at least not in software 'engineering'. I have met the odd jerk from other departments, but 99% of people who try that stuff will back down when you push back. Dealing with jerks is a good skill to cultivate (one that I've only recently got the hang of).
If you have a chip on your shoulder, always have something to prove or want 'revenge' on an unnamed whole because you were bullied in school you are unlikely to work well with others and are going to be a liability in every single context.
Either you are brilliant or you are a jerk. Being able to respect and work well with others is a basic life skill.
Linus for instance respects and works well with thousands of people. Let's have the same transparency that someone like Linus works under for other CEOs before feeding into tabloid level sensationalist journalism that singles out one in tens of thousands of interactions.
Just being able to write a software program or doing what you were trained to do does not make anyone a genius and the vast majority of software is mundane.
[+] [-] grandalf|8 years ago|reply
I think one reason people become bullies is because they know they can't back up their decisions with skill. Linus is brash, but is quite able to work well with people and has the results to prove it.
Most people who adopt bully tactics are simply doing it for tactical reasons to hide their own weaknesses.
The myth of "brilliant jerks" is harmful because it lets any jerk pretend he's doing it because he's brilliant, when chances are he's just afraid of being unmasked as mediocre.
As a corollary, engineering culture should be very open to every member of the team learning and being very open to lessons learned (read: mistakes made) in the process. Bullies often intimidate by criticizing others' decisions, which creates an atmosphere of fear that prevents rational thought and stifles group learning.
[+] [-] MBCook|8 years ago|reply
The truth is he wasn’t very good, at least not to the degree he tried to present.
Some of management loved him because he worked so hard. He was always there, always the one holding things together.
The truth was he was doing that because his methods were shoddy enough that things were always falling apart. He didn’t want others working on stuff because that would either lose his control/power or people would see how bad things really were.
In the end it became too much. As the company grew and things were done without him it became clear just how little he actually accomplished. New employee worked as well and were easy to get along with, not hostile to help.
But we had to suffer with him sabotaging things and dealing with his outbursts for YEARS.
[+] [-] JimboOmega|8 years ago|reply
1) The whole 10x thing. The implication being that if you're brilliant, you're worth an entire team or more; if you're average, you're... worthless. Thus, you have to be better than everyone else to be worth anything
2) Classic bro culture - somebody who gets rewarded for being obnoxious, bullying, and "alpha" is a very "bro" thing.
3) Tech people tend to be people who put a lot of their self esteem in their intellectual - and work - abilities. This means they get more defensive when that ability is threatened.
It's a culture that rewards being brash and confident. Can you imagine someone saying that they are an average programmer but work well with a team to get done a lot?
There are definitely people who quietly get a lot of work done, and there are people who are "force multipliers" who make the rest of the team more productive (something I regularly try to do, incidentally). Depending on the culture these things can get ignored pretty easily - the 10x developer is an individual with limitless skill in the classic view.
There's not really a space for an "average" developer - everybody has to be a "Rock star" or "10x" developer. We only hire the top 1%, etc. So if you aren't, what else can you do but fake it?
[+] [-] luckydude|8 years ago|reply
I definitely hurt some people and, as a young guy, felt that making the company better trumped all of that. And I was a little clueless, I had ADD and no treatment and had no idea that communication happened non-verbally, just wasn't a thin g for me.
What made it better was when I added compassion and empathy to my thought process. Instead of barging into someone's office and yelling at them that their code was broken, I'd start with the people stuff. Ask if I could talk to them, ask how they were doing, ask if they knew about this problem in their code. More ask, less yelling. And in my head, i would ask myself is there anything going on in this dude's life that is negative? Sick kid? Divorce? Parent dieing?
I was still willing to come to the conclusion that the person sucked at whatever chunk of code it was that was in the spotlight but it took me a lot longer to get there because I was trying to see if there was something else going on that caused the crappy code.
Dunno if that helps, I'm sure people told me to think like that but it took me a while to get there. Maybe this shortens the path for someone else.
[+] [-] mars4rp|8 years ago|reply
why am I wrong ? should I care less like everybody else?
PS: where I currently work is wasting public money and I feel obligated to do something as a Libertarian!
[+] [-] fhood|8 years ago|reply
Edit Source: I make this mistake all the god damn time, and never realize it until the person breaks and finally snaps at me. The whole time I thought we were just having a reasoned argument. I think that I am constructively invalidating the other persons arguments, meanwhile they are feeling belittled and defensive.
Edit edit: This is even worse if, like me, you think arguments are pretty much the greatest most entertaining game it is possible to play.
[+] [-] spenczar5|8 years ago|reply
Speaking the truth straight out can feel good, but it is rarely a good rhetorical strategy. Instead, back up, and start with this: what do the people across the table want? What do they believe is good, and what do they believe is important?
Now, how do you recast your arguments to appeal to those goals? How do you frame your position in such a way that they will want to agree with you?
This is the foundation of convincing people: empathize, understand them, learn their communication patterns. Once you see how they communicate and think, you work down those routes but send the message you believe is important.
[+] [-] valuearb|8 years ago|reply
This is what I want to tell them:
Our core customer facing application is shit. The contractors who wrote it cut tons of corners and the marketing people who designed did a horrible job, the UI emphasizes features customers don't care about, and makes it extremely difficult for customers to actually reach and use the revenue generating sections of the app. Not only is the marketing leadership is disfunctional, and worse, you (the Sr VP) have created a disfunctional development organization, that makes me wonder if you understand how to develop commercial applications.
This is what I will say:
The weaknesses in our core application are costing the company millions of dollars a month. We are struggling with making quick, effective decisions and shipping new versions to address the major problems because we have "too many cooks in the kitchen" in our team meetings and planning. I will give specific examples and relate them to specific examples from my long history shipping quality commercial apps on time. I will finish by saying the team is demotivated and underperforming, which makes you, the Sr VP, look bad, and plead that we need to solve this, for them and the company both.
[+] [-] lucozade|8 years ago|reply
I'll bite.
Does it work? Is your approach effective?
In your engagement with the senior folk, do you just complain? Or do you suggest changes that you know are affordable and achievable? Are you arguing so you feel better about trying or are you genuinely attempting to affect change?
Also, has it occurred to you that the higher ups might not be the fools and cowards they appear? Is it possible that they are operating with constraints that they just haven't chosen, or are prevented from, sharing with you?
Obviously I don't know your organisation and it is, of course, possible that its staffed with incompetents. And that by sheer good fortune just you and a small group of your immediate colleagues are the only rational actors. Or it may be something else.
[+] [-] mighty_bander|8 years ago|reply
The way to do that is all in phrasing, tone of voice, and general respectful treatment. If, like me, this is not something that comes naturally to you, it might be worth searching google for a few little tricks that will help you to resolve disagreements. The Socratic method - using questions instead of statements - can be effective. It has also helped in my experience to describe similar situations in which the course of action you support has proven itself.
When speaking with managers who make a bad suggestion, it is helpful to explain that the course of action they are proposing was considered, and why it was rejected. That will reassure them that you are on top of the situation, and (in the case of a good manager) show that you are able to do your work without your assistance.
Of course if your manager's ego is tied to his/her suggestions, which is common, you're probably SOL. The most effective way I have seen a team deal with that is to implement the bad suggestions as quickly and flexibly as possible in order to minimise the damage to the schedule, the project, and so on.
[+] [-] Singletoned|8 years ago|reply
I feel that a lot of places have a culture of agreeability. They are focused on fixing disagreement rather than fixing the underlying problem. A truth-telling person isn't suited to those environments.
I also feel that a "no brilliant jerks" policy is an anti-neuro-diversity policy. It weeds out high-functioning autistic and psychopathic people. I think any homogenous environment created from such a policy would be a dangerous thing.
[+] [-] meheleventyone|8 years ago|reply
[+] [-] rodgerd|8 years ago|reply
Are you interested in the best outcomes, or addicted to behaving in the way you find easiest? If you are actually interested in outcomes, if you actually care you will learn that meeting people on their terms will produce better outcomes than communicating however you find easiest.
Technology is easy, people are hard.
[+] [-] jpzisme|8 years ago|reply
It seems the gut reaction in tech is that conflict is bad, but conflict is inevitable. It is better to respectfully resolve conflicts than try to avoid them at all costs IMO
[+] [-] technofiend|8 years ago|reply
At some point you have to learn to appreciate other viewpoints and approaches to problem solving. You might want to argue things on strictly technical merits when someone 3 or 4 levels above you has completely different criteria to judge a solution. Maybe he sees less risk or less cost, maybe he just doesn't want to change the status quo. Maybe he simply sees a challenge to his authority.
There's a wide spectrum between being a politician and pleasing everyone and being a politician and working through a discussion and couching your position in a way the other person appreciates and accepts. But it's on you to figure out how to make that work, not them.
[+] [-] Veelox|8 years ago|reply
Always always give people a way to save face, this applies doubly in meetings. If people feel like the choices are being right or being responsible for an error they will fight to be right. If you give them a third option (past inexperience, blame someone that left, poor testing, changed requirements) that doesn't hurt their reputation, they no longer have to fight to be right.
Try to teach people the principal behind why something is wrong/broken/bad. This applies to things like code health that there are more subjective. Instead of saying "That method should not be 300 lines." Teach that you want small understandable functions that do only one thing. This gives them a metric to use in the future and makes your comment seem more well thought out.
Be helpful when you can be. If you are always causing problem people will remember that. People also will remember when you go out of your way to help them. A little bit of oil could help the other interactions run smoothly.
I hope these little bits help some.
[+] [-] zzzeek|8 years ago|reply
do non-libertarians feel that there's nothing wrong with companies wasting taxpayer money?
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] jhjwe888|8 years ago|reply
[deleted]
[+] [-] _xhok|8 years ago|reply
I think we're conflating is and ought here. It's probably a fact of reality that most people aren't happy to be told they're wrong. But arguably people ought to accept the consequences of being wrong, e.g. feeling bad when they're told.
I've talked to lots of startups in San Francisco. Most are failing, just due to the nature of startups, but can survive if they reach a finite set of straightforward goals. They've found product/market fit, they know what they have to do, they just have to do it, and the correct 10,000 characters of code input into a computer would solve all their business problems. There's often a lot of handwringing about why they're failing: the process is wrong; communication is wrong; something or other. But the largest reason they're failing is that they're insufficiently good at technology. You know who'd be really good at fixing that? A team of Alices.
I think Alices get too much flak. Bob is genuinely a toxic character. But if your only fault is telling the truth, which offends people, and you're otherwise excellent at your job--- there's a huge opportunity for twenty Alices to get together, bypass the inefficiencies of being offended, and win big. Tech has an obvious historical example.
Edit: I reread the description of Alice. All right, maybe don't browbeat your point into others.
[+] [-] DavidWoof|8 years ago|reply
As you mention, pointing out when things are wrong isn't being a jerk, it's doing your damn job. "Having little empathy for others" isn't describing behavior, so it's meaningless here. OK, "browbeating" might be bad, but what does that mean anyway? Is she repeating the issue a month later after the problem got ignored, or is she micromanaging it, or what? There's no indication here. Whatever it means, Equifax could have used some browbeating on security issues.
There's no indication about why people try to avoid working with her. Does that refer to other developers, or does HR try to avoid her they go around asking for donations for girl scouts or something? I don't see a real problem with the latter. If somebody had reputation for pointing out problems in code, I wouldn't be avoiding her, I'd be seeking her out.
[+] [-] john_moscow|8 years ago|reply
Or they can get a huge team of pleasant and great-looking people that will leave a very good impression and raise tons of capital to keep burning through cash for years without fixing any of those problems. As long as the investors are OK with this, people will keep on using it.
[+] [-] s73ver_|8 years ago|reply
[+] [-] AcerbicZero|8 years ago|reply
I'm not excusing his behavior, but if you're able to handle that style and develop a functional relationship "brilliant but difficult" folks can be an amazing resource. He's the Sr Infrastructure Architect for that organization now, and they've never been doing better. His ability to be difficult but brilliant keeps the overbearing management folks in check, and has allowed the technology platform to move forward dramatically.
The one downside (other than the constant testing of my self esteem and resolve) was that I let him teach me D&D and he was a pedantic dick of a GM.
[+] [-] watwut|8 years ago|reply
Most of those people are much less briliant when you are not a junior. It is mostly that they are rewarded for being jerk.
[+] [-] mirceal|8 years ago|reply
[+] [-] 1001101|8 years ago|reply
""" Cosgrove asked them to elaborate on the idea: "exile the knaves, but fight for the divas."
Rosenberg said maintaining Google's collaborative culture requires weeding out and getting rid of the knaves: Employees who lack integrity, who are jealous of their peers, take credit for others' work, and think only of themselves. "Nice humble engineers have a way of becoming insufferable when they think they are the sole inventors of the world's next big thing," they write in their book. "This is quite dangerous, as ego creates blind spots... Nip crazy in the bud."
Divas, on the other hand, display "high exceptionalism," Rosenberg said. If the divas are brilliant and doing a good job, they should be valued and allowed to do their jobs. "As long as ... the divas' achievements outweigh the collateral damage caused by their diva ways, you should fight for them."
"They will pay off your investment by doing interesting things," they write. "...Remember that Steve Jobs was one of the greatest business divas the world has ever known!" """ [1]
[1] http://www.cleveland.com/business/index.ssf/2014/10/googles_...
[+] [-] exelius|8 years ago|reply
[+] [-] RGS1811|8 years ago|reply
[+] [-] draw_down|8 years ago|reply
[+] [-] bpicolo|8 years ago|reply
I do however want to point out that some of these may be less about being an insufferably relentless jerk than other pieces.
> He is late to meetings, ... then looks at his phone or laptop while ignoring everyone around him
This is also a pretty common indicator for ADHD. Not to say that excuses being a "jerk", but there are people out there that have a fundamentally difficult time tracking and arriving at meetings properly, and it's not always easy to account for. It also goes hand in hand with a few other related issues here. It's also somewhat common in the world of software.
I have some semblance of issue arriving at meetings properly, and it takes sincere effort to correct for it. When I started my career (admittedly, not so long ago) I definitely displayed more pieces of what is described as brilliant jerk than I would like to have (though certainly nothing like gaslighting and exploitation of others around me - more those things in line with adhd).
On the other hand, I spent 3 years working especially hard on self improvement here, and I certainly appreciate the patience of those around me in helping me realize my failures. It took me a year of effort to really avoid interrupting others while talking - not as a matter of being a jerk, but simply because my mind gets lost in conversation and feels the need to begin talking with less cognizance than I wish I had that others were speaking. These days, I am quick to apologize upon realizing I've interrupted, and ask the speaker to continue. That's strictly worse than never interrupting, but it both publicly acknowledges that I know this is a problem for me in conversation, and helps move forward.
The best thing for some people who have some of these issues is to give them honest, direct, and proactive feedback regarding it. They may well have no idea the ways in which they're impacting those around them, and they may well be surprisingly proactive in self-improvement upon being spoken to.
It's non-proactivity in self-improvement that you should be far less accepting of, ADHD or not.
[+] [-] mamoswined|8 years ago|reply
[+] [-] crdoconnor|8 years ago|reply
IMHO there's also a limit to how much you can spare everybody's feelings and still be effective at that ^^. I think the OP believed that there isn't a limit. I think he's wrong.
In a corporate environment, there's almost no value in actually being one though. Linus Torvalds would almost never be promoted and would frequently be unceremoniously terminated - as advocated for by Brendan Gregg.
[+] [-] wellpast|8 years ago|reply
The difficulty though is that at some point if you believe something is important you may ultimately have to go through some kind of dialectic to make your case.
How to Win Friends and Influence People says never have an argument. If you follow this advice you will reap the benefits of the book. However what you're building in your team will trend toward a Least Common Denominator. Or else I don't know how to not let that happen in a world where you can't debate. (Any response that tries to say debate/argument/dialectic aren't all the same thing in this context I think is cheating. Or someone enlighten me.)
[+] [-] moretai|8 years ago|reply
*By lasting changes I mean, do you feel like you've changed and valued being more sociable?
[+] [-] vemv|8 years ago|reply
An actually intelligent person is happy to prove his thinking via truthful argumentation (and unit tests, documentation, and so on), and also happy to get his points refuted by similarly reasonable peers.
Anything other than that approach is noise.
[+] [-] fizixer|8 years ago|reply
Totally makes sense.
[+] [-] sah2ed|8 years ago|reply
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
[+] [-] ryan_lane|8 years ago|reply
I've worked with someone who ticks almost all of the Bob traits. He would actively try to get people fired who he didn't like, spending time gaslighting everyone around them until enough people disliked his victim where it was possible to fire them. He turned entire teams against each other, causing organizational issues that lasted years after he was eventually fired.
The problem is that he was legitimately brilliant, and he was incredibly productive. This made his gaslighting all the more effective. When we spoke about things and people, people listened. He was charismatic, funny, and had a long-standing reputation.
After firing this person, we found out he has a history of being abusive and getting fired. It's hard to know this because he's in leadership positions in a few important open source communities.
Thankfully this org is numerous years in my past and I've eventually moved past the stress associated with it, but it's an experience that stuck with me for a long time.
[+] [-] davidkuhta|8 years ago|reply
> 1. Was it my intent to make his staff unproductive?
> 2. Do you think you could have told my engineer what you needed to, in a way that left them feeling positive and motivated to fix it?
> Always do that in the future, please.
[+] [-] darethas|8 years ago|reply
Maybe there is a "non-asshole" way to do that, but there needs to be a place for this in society as well. Some people respond to gentleness and nudges, some don't.
The person I think back early in my career when I was an associate and my first tech lead -- yes! he was the biggest asshole I met at that time -- but it would be remiss of me to not admit that I learned and stretched more on his team than I did the rest of my time at that company by a mile.
[+] [-] loblollyboy|8 years ago|reply
[+] [-] dbcurtis|8 years ago|reply
[+] [-] anad7|8 years ago|reply
1. Bob interrupts others, and ignores their opinions (When people asked questions, he downplayed them and in some cases declined to answer them)
2. Bob bullies, humiliates, and oppresses individuals. With non-technical people, he wins arguments by bamboozling them with irrelevant technical detail, making them feel dumb (When asked about Coroutines he started explaining irrelevant stuff like locks and guards and compiler level instructions without actually answering the questions)
3. Bob engages in displays of dominance in front of groups (He was quite assertive that his language is better than Java, no one could convince him otherwise)
4. Bob is negative. He trash-talks other technologies, companies, and people behind their backs (He trash talked Java)
5. Bob manipulates and misleads. Sometimes he misleads subtly, by presenting facts that are literally true in a way that is intentionally misleading. (He mislead people into thinking that null checks were just wrong and should be avoided altogether by writing code in Kotlin, he also indicated that writing data objects was not possible in Java)
6. Bob uses physical intimidation. Bob glares at those he doesn't like, and may invade people's personal space. (He said that if his team member was unwilling to learn Kotlin he was probably not worth his salt)
7. Bob gives great talks – about himself.
8. Bob refuses to change. (This was quite evident about him)
To sum up, he was arrogant and loved humiliating the audience, I and a few others left the talk after 30 mins.
[+] [-] quickthrower2|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] maehwasu|8 years ago|reply
I've had really good results hiring "jerks" and actually taking the time to understand them as people, and then put them into positions to succeed.
Calling out others as jerks is very often a power play to gain social leverage over people who aren't good at that game.
[+] [-] HumanDrivenDev|8 years ago|reply
[+] [-] throw2016|8 years ago|reply
If you have a chip on your shoulder, always have something to prove or want 'revenge' on an unnamed whole because you were bullied in school you are unlikely to work well with others and are going to be a liability in every single context.
Either you are brilliant or you are a jerk. Being able to respect and work well with others is a basic life skill.
Linus for instance respects and works well with thousands of people. Let's have the same transparency that someone like Linus works under for other CEOs before feeding into tabloid level sensationalist journalism that singles out one in tens of thousands of interactions.
Just being able to write a software program or doing what you were trained to do does not make anyone a genius and the vast majority of software is mundane.