One thing I learned some years ago is to always avoid being the agent for someone else's humiliation. Even if that person is blatantly wrong, all you'll do by calling them on it is create an enemy.
One trick I've used many times to correct someone without embarrassing them is to couch my own feedback in conditionals, something like "You've been studying this a lot more than I and I'm sure you're probably right but I seem to recall reading a bit ago that an md5 sum isn't a sufficient way to hash a password, you need to do more processing."
That then gives them an out "yeah I looked into that and I'm pretty sure this is best practice but I'll check again" or somesuch. Probably 80 percent of the time, when I frame it like that, I'll see a followup saying that they've gone back and discovered the right way and will be doing it that way.
The really nice thing is that people are appreciative when you treat them that way, and far from creating a new enemy you'll have earned respect and trust from that person.
Yes! Helping people save face is more useful than jockeying for nerd dominance. Other approaches to do what you suggest:
"I think I read an article that compared a few different password hashing strategies, I'm interested in your thoughts..." (and then follow up with a good comparison that makes the point)
"Have you compared X, Y and Z?" Tone is important with this one, but it can be the most straightforward.
"At the last place I worked, the paranoid guy insisted that we do X because he thought it was better -- it was just as easy to implement, is that something you'd be open to?"
When all else fails, you can follow up in private!
I think the key in any of these exchanges is to offer new information in a way that doesn't question the judgement of the other individual. Basically, assume that everyone is rational and differences in judgement are due to differences in information/experience. Then, when someone makes a judgement different from yours, you are merely giving them the information that lead to your decision -- but leaving them to make up their own mind. Most people are more ego-identified with their judgement than with the information they have.
In general I agree, but in your specific example (assuming that there's a universal coding convention that everyone is expected to follow), I think your "Bad" is better than your "Good". If something is obviously wrong, call it out, simply and factually. Chances are it was a simple oversight, and "Why did you decide to go against our naming conventions?" sounds passive-aggressive.
I find questions most useful when the issue really is a matter of opinion, and they're just as likely right as you. For example, "why did you decide to key this webpage's data by content hash instead of by URL?" This is a sincere question - there may be arguments for both approaches, and the point in asking is to tease out those arguments and figure out what actually is the truth. It's an acknowledgement that you might be wrong, and not an attempt to paper over the certainty that you're right with diplomatic phrasing.
Part of why I try to avoid SAYING I told you so, or even giving smug looks. IME you don't have to say anything and if you don't rub it in but keep quietly trying to be correct, you can start to make headway.
This coincides with that great article on "How To Ask Questions The Smart Way" (http://www.catb.org/~esr/faqs/smart-questions.html), because it is often the case that the most effectively a question is asked, the more effectively the question is mitigated (and subsequently discussed).
It's interesting how great a baring the quality of the question has on the quality of the answer. Good questions get (usually) good answers. I regularly get caught in the crossfire resulting from poor questions resulting on poor answers.
This is a really great article. Her experience mirrors mine in a lot of ways - not that I've ever been an executive of anything, just that I've had the experience of winning a battle at work, but winning in a way that alienated my team. A lot of technical people are like that - we know we are right, and we probably are, but when you shove the raw data and facts down your team's throat in the wrong way, people will resent you for it.
Unfortunately, a lot of people are idiots, but you can't just call them that. This is something I'm struggling with, and I wonder if anyone has pointers for me. Not that I call people an idiot, but just that, if I know my facts are correct, and I disagree with them, it's basically the same thing - you're saying "I'm right and you're wrong," which might be true. How do you get someone to agree with you without making them feel like an idiot? Please, tell me, I'm dying to know...
We have this idea that teamwork is this beautiful thing where people always get along and nobody is ever mad at each other. That's bullshit. To do the right thing, you have to piss people off sometimes.
I really suggest you read the "No Asshole Rule". It goes into details about who's an asshole and how not to be one. And it's very clear about the idea that just because you disagree with people doesn't make you an asshole. A few relevant points:
1. Focus on the argument and not the person.
2. Argue like you're right, listen like you're wrong. In other words, really try to make sure that you really understand their point and that they understand your point.
Even if you do those things, you're still going to make people angry. Remember, being stubborn and argumentative is only a vice if you're wrong or you're doing it for your own personal enrichment rather than the good of the team. If it really is a simple case of you being right and them being wrong, and yet they're still arguing with you, is it really you that has a problem?
When you say that "people are idiots", it seems to assume that there is a thing called "intelligence." Well, there is no "g", or general intelligence that anyone can pin down.
Let's take the simple view and say that people's actions and judgements are a product of the information they have gathered, the habits they have, their ability to analyze and combine that information, their ability to optimize within constraints and their ability to recognize and evaluate constraints.
If someone is clearly wrong, then they have some bad information or bad reasoning. Learning their bad conclusion, many people then go on and do a "well, i'm right and if they heard my reasoning then of course they would agree with me!" That can work within relationships that have a high degree of trust and rapport (not most relationships.) Outside of those relationships, it is too self-centered.
Changing someone's mind is like fixing a bug in a foreign code base. You don't just look at the erroneous output in order to debug, you also look at the source and the input. Similarly, to effectively communicate with someone who disagrees with you, you should seek to understand the information and reasoning that lead them in a different path.
Understanding where they went wrong (in addition to their erroneous conclusion) gives you a great level of preparedness. When you know where they went wrong, you can usually get them to change their own mind by asking them to teach you about how their model of the world is consistent even though you have seemingly contradictory information.
For instance: "oh, how is delivery guaranteed if there isn't a confirmation echo?"
Basically, you take the stance of being wrong, and "use" them to teach you about where you are wrong. If their answer seems to ignore information you have, you can ask "How does this relate to the stats they released last week?"
This "please teach me" questioning approach doesn't undermine their judgement or threaten their ego while giving you control of their thought process (or at least more insight into it, which translates to having more control ultimately.)
This takes a long time, but when you start learning to model other people's reasoning ( a skill unto itself) you will get better at asking the right question that guides them to the right conclusion without telling them what the right conclusion is.
One of my favorite videos on youtube is the one where Neil deGrasse Tyson expresses disagreement at Richard Dawkin's methods [1].
He says: "... persuasion isn't 'here are the facts and you're either an idiot or you're not.' It's 'here are the facts and here's a sensitivity to your state of mind.' And it's the facts and the sensitivity that when convolved together, creates impact. I worry that your methods and how articulately barbed you can be, simply being ineffective..."
I have always supported a philosophy of patience when it comes to being right. When entering a new organization, make your case(s) known, but don't push them. If you are proven to be often correct, over time people will see the pattern, and you will earn respect. Even more so if you don't say "I told you so."
On the flip side, if you are pushy and turn out to be wrong, you just shot yourself.
Eh, I dunno how much my experience confirms this. I worked for a pretty spastic, rudderless company for awhile. I'd make my case for the right direction. I'd be shouted down.
Months later, exactly what I described would be pitched as a new direction, as though it was someone else's idea (and it definitely was their idea, for all practical purposes – I wasn't listened to, so they got there independently). This repeated itself a few times.
Now I work somewhere else and it's much better. I'm still not a dick. But maybe the lesson is that if you're continually in disagreement and no one is listening, you're in the wrong place.
Now I work somewhere else and it's much better. I'm still not a dick. But maybe the lesson is that if you're continually in disagreement and no one is listening, you're in the wrong place.
It's good that you're sticking by your principles. These sorts of matters are a two-way street after all-if the other side isn't willing to work as hard as you in seeing eye to eye, then it's time to leave as you did. The trouble I always have is deciding when enough is enough.
The best way to get people to implement your ideas is to convince them that they were their ideas all along. It sounds like you successfully steered the technical direction of that employer. I understand that it can be unrewarding if no one credits you and you're almost certainly better off at your current gig.
It seems like that there has to be a certain minimum level of manager competence for this to work. If the manager is too blind, he/she will never learn that your ideas are sound.
If you're going to place a pop-over ad for the iPad HBR app, please make sure that said ad doesn't annoy the hell out of iPad users by taking too long to load and being impossible to load.
Yesterday, I fired one of my PHP developer. It is his 13th month. His team leader reported me that "He got average skills". Shame on me., Because, I hired him. After 13th month we fired him. Problem is really the hiring people (HR, CEO or anyone else). Now., I am preparing interview questions with twists & logic implementations.
Average skills? There was an article recently - I think by Joel on Software - that everyone thinks they're hiring in the top 1%. I have to admit I'm kind of curious as to what you were looking for in your team when you hired the guy, I can't tell unless you elaborate more. In addition, I agree with danilocampos: the problem might be in your hiring process. I'm not sure that throwing out puzzles or whatever will help you reduce your number of false positives.
"average" compared to what? your own team? that'd mean you've got people even below the person you fired. 'average' compared to the team leader's experiences? That's a bit... dangerous.
Frankly, an 'average skills' developer in a strong, supportive team can still be a great asset. They can do the work, but perhaps don't always know the best way to do something. However, they may be fine with being given direction. Many people I've worked with aren't good at taking directions from others - I'm not great at it myself in many situations. So the 'average skill' developer can be a blessing in many circumstances. But perhaps not on your team, which may say as much about your team dynamics as that developer.
Exactly. In fact, you NEED average people on your team to play the roles that the superstars are unwilling to play. Places like Facebook where the dirty and boring work is respected and rewarded (according to a Quora post by Yishan Wong) are rare. In a lot of places, the superstars do the superstar thing, and other people do the other stuff.
Good teams will always find a place for people. Ironically enough, this sometimes may even mean promoting someone with poor technical skills to management, among various other drastic measures. Their technical skills may suck, but their interpersonal skills and organizational skills may be off the charts, and they'll still have enough technical background to understand what the heck they're managing. That kind of thing.
When my friend first started at Google, he commented that there seemed to be a lot of underlying impatience and discontent because Google only hired superstars, and so many superstars had to stay on the bench. Not everyone can go do the glamorous job. Various anecdotal blog posts seem to have given us that even Google hasn't been able to 100% figure it out.
One trick I've used many times to correct someone without embarrassing them is to couch my own feedback in conditionals, something like "You've been studying this a lot more than I and I'm sure you're probably right but I seem to recall reading a bit ago that an md5 sum isn't a sufficient way to hash a password, you need to do more processing."
That then gives them an out "yeah I looked into that and I'm pretty sure this is best practice but I'll check again" or somesuch. Probably 80 percent of the time, when I frame it like that, I'll see a followup saying that they've gone back and discovered the right way and will be doing it that way.
The really nice thing is that people are appreciative when you treat them that way, and far from creating a new enemy you'll have earned respect and trust from that person.