A Measure of Your Team's Health: How You Treat Your "Idiot"

Really? by sethradio · 2014-06-02 05:40 · Score: 5, Funny

I can't rejects someones help on my open source projects? Linus Torvalds is really mean then.

--
"Nationalism is an infantile sickness. It is the measles of the human race." -Albert Einstein

Re:Really? by sethradio · 2014-06-02 05:41 · Score: 5, Funny

Considering my grammar, I must be the idiot in this case.

--
"Nationalism is an infantile sickness. It is the measles of the human race." -Albert Einstein
Re:Really? by OakDragon · 2014-06-02 06:02 · Score: 4, Funny

I was wondering if this is a case of "if you don't know who the team idiot is, YOU are the team idiot"...

--
Dark Reflection
Re:Really? by Penguinisto · 2014-06-02 06:13 · Score: 4, Insightful

Depends on the project.
Something as popular and heavily-supported as the Linux Kernel? Fuggit - Torvalds has his pick of talented people to choose from, and uses his rather entertaining personality to insure that the slackers and dullards behave themselves. Note that his commit refusals are usually well spelled-out (if it even gets to his level - usually one the the 2nd or 3rd-level maintainers will reject it for some reason or other, so if Torvalds gets involved, it's usually based on some architectural or philosophical reason, and that in turn is usually very well explained.)
Now for Joe Sixpack's Uber-l33t CMS Mod for Drupal? Umm, okay... you take what you can get and you'll like it, but honestly, the same method can apply. If someone pulls a boner and tries to commit it, you explain in precise and objective terms *why* the thing was rejected. If the reason is philosophical, you explain it in a neutral manner, promoting the philosophy in question, and explaining why the rejected change doesn't meet it.
Note that none of this applies to a professional environment, where the team members are being *paid* for their skills. Also note that there's a lot of reasons why the guy is the low-man on the team totem pole - few of them having to do with coding ability.
I mean it this way: if you have a team full of rockstars, the 'idiot' may well be a planet-crushing badass by developer standards, but isn't as good as the other guys on the team - sort of like a top-notch AAA athlete finding himself playing on a pro MLB team. Or, it may be that the 'idiot' is a coding rockstar in a team full of ordinary devs, but he's a bit anti-social, hates or cannot fully grok the team's particular interpretation of Agile/Waterfall/Whatever-your-team-is-using, or for some similar reason isn't the guy who looks as good in the scrum master's eyes.
Long story short - the concept would need a friggin' book to explain in full, and requires more than just light managerial skills.

--
Quo usque tandem abutere, Nimbus, patientia nostra?
Re:Really? by JoeMerchant · 2014-06-02 07:07 · Score: 4, Insightful

Too lazy to RTFA, I take the meaning of the summary this way:
Like a society can be judged by how it treats its elderly, infirm, and more fragile members, a coding project (open source or privately funded) can be judged by how it treats its least well regarded developer.
Are you Nazi Germany, do you show people the door based on the color of their eyes/hair, how tall they are, their GRE scores, or how they perform on some arbitrary admission test before you give a 15 minute in-person interview?
Are you Genghis Khan's Mongolia, do you abuse and then fire anyone who isn't running at the front of the pack? Rank and yank does not generally improve morale.
Are you the European Middle Ages, do you just ignore your weaker team members and let them be consumed by plague rats / drown in their own stinking code while you isolate the shipping product in the ivory tower?
Are you a more modern quasi-socialist society where you educate your weaker team members as best you can and enable them to contribute as they are capable?
There are cases to be made for the advantages and efficiencies of all approaches, but, generally, you need to be a strong development team to carry and build up the weaker team members - if everybody is too focused on product and producing to care about helping their fellow team members to improve, your team is overtaxed (too weak for the job at hand) and probably not able to perform well (provide a reliable living wage for the developers while producing and maintaining the product) in the long term.
Re: Really? by Anonymous Coward · 2014-06-02 07:43 · Score: 4, Funny

It is coincidence. Our team idiot is the company owner.
Re:Really? by gmack · 2014-06-02 08:54 · Score: 3, Interesting

Agreed. I have seem some devs treated badly who turned out to be pretty good developers once people stopped treating them like crap. I also had one kid fresh out of university who needed some hand-holding for his first few months while he gained some experience and gained some self esteem who turned out to be a one of the best programmers I've ever worked with.
Re:Really? by Darinbob · 2014-06-02 09:31 · Score: 2

Rejecting in this case I think means not accepting their work because they're too slow in producing it. In the corporate world, too slow often means not good enough to be useful (ie, we lost the customer by delivering late). You sort of have to accept that in open source that code will not be fast, because the volunteers are working on this in their free time only. In open source the dummy is one that submits buggy or inappropriate code.
For Linus' rejections those are often for code that is not necessarily bad code by itself but which is bad for other reasons: breaking existing code, is intended to promote certain side projects, is incompatible with existing style or APIs. A lot of that is actually rare in the proprietary world as you've got a manager handing out assignments rather than allowing everyone to pick their own fun projects.
Re:Really? by Anonymous Coward · 2014-06-02 09:31 · Score: 2, Interesting

Really? And here I thought programmers, especially the ones companies are afraid to let go, were the paragons of human empowerment, dispellers of unjust prejudice and generally seekers of higher communion with their fellow peers, lifting everyone to unprecedented levels of infinitely-looped feedback loops of learning and earning of epic proportions.
Companies are afraid to lose these, so as to miss out on all the value-add, right? Right??
OTOH, maybe if companies actually treated their devs with respect, more of us would want to touch it with something other than long telescopic pitchforks. If we could be allowed to have some pride in our work and have some degree of freedom for creative and innovative outlets, IT could yield more as an investment, rather than the cost center incompetent managers view it as today.
Re: Really? by Darinbob · 2014-06-02 09:34 · Score: 3, Insightful

If wealth is used as a measurement of intelligence then you'd be right. You'd also be right if the workers are only there in order to make money. However often a lot of tech workers are in tech rather than a lucrative profession because it is work that they prefer doing. For example, I am pretty confident that I am much happier writing code and designing systems than I would be as a manager or executive.
Re:Really? by mindriot · 2014-06-02 09:52 · Score: 3, Interesting

There are cases to be made for the advantages and efficiencies of all approaches, but, generally, you need to be a strong development team to carry and build up the weaker team members - if everybody is too focused on product and producing to care about helping their fellow team members to improve, your team is overtaxed (too weak for the job at hand) and probably not able to perform well (provide a reliable living wage for the developers while producing and maintaining the product) in the long term.
Yeah, I think that is the important -- and only -- message here. From the summary:

How your team members treat that person is a significant indicator of your organization's health
This, and only this. If your organization is doing well on the market, and very successful, it can afford to treat their "idiots" well. If times are rough, and everybody is struggling hard to get things done and achieve success, this will stop. In other words, if you're treating your "idiots" badly, it's probably because you're already in deep shit.
However, the converse is not necessarily true: it does not follow that just because you're nice to your "idiots", your team will be successful. Sadly, as much as I'd like to interpret such a feel-good message into TFA, I'm afraid it probably doesn't work that way.
My personal experience seems to indicate that yes, you do want to treat your "idiots" well simply because everybody likes a good work climate, and nobody likes assholes. And personally I'd rather not do as well but at least know that I'm not acting like an asshole trying to beat the team into performing better. But in the end, what motivation and performance you can instil in your "idiots" is unlikely to match what you could achieve by replacing them with individuals that are more capable of doing the required work.
Re: Really? by Aighearach · 2014-06-02 13:10 · Score: 2

I don't care if you're sitting there reading the article, Get Off The Lawn!
Re:Really? by Lotana · 2014-06-02 22:23 · Score: 3, Insightful

But in the end, what motivation and performance you can instil in your "idiots" is unlikely to match what you could achieve by replacing them with individuals that are more capable of doing the required work.
The summary is very careful to describe the lowest performing workers as: Every team has someone who at the bottom of its bell curve: an individual who has a hard time keeping up with other team members. Based on this definition, as you replace one, you will still have the lowest performer. Just your measure criteria will be higher. Thus unless you have a team that are all clones of each other, work politics will still find the "idiot" to hold.
Thus, the measure still stands: How do you treat your lowest performers is a good judgement of the company health. Your preference of "Not worth the time/effort. Replace them with someone better." is quite destructive. By following your solution, the team will be forever stuck with overhead of training up the new guy and loss of knowledge of the rapid turnover.
Re:Really? by mindriot · 2014-06-03 04:19 · Score: 2

The summary is very careful to describe the lowest performing workers as: Every team has someone who at the bottom of its bell curve: an individual who has a hard time keeping up with other team members. Based on this definition, as you replace one, you will still have the lowest performer. Just your measure criteria will be higher. Thus unless you have a team that are all clones of each other, work politics will still find the "idiot" to hold.

Yes, obviously someone else will take over the bottom spot. But remember that a bell curve has an important parameter: variance. Your "all clones" team has a variance of zero. Replacing the low performer with someone closer to the mean will not only raise the mean, it will also lower the variance.

Thus, the measure still stands: How do you treat your lowest performers is a good judgement of the company health. Your preference of "Not worth the time/effort. Replace them with someone better." is quite destructive. By following your solution, the team will be forever stuck with overhead of training up the new guy and loss of knowledge of the rapid turnover.

First of all, what I outlined in my post is by no means meant to be a "solution", much less "mine". Second of all, your rapid turnover conclusion is based on flawed premises. If you replace the lowest performer with a new guy who ends up at the very top of the bell curve, and manage to do that repeatedly, that is unlikely in itself. You're far more likely to find someone who will slightly raise your mean performance, but mostly reduce its variance, making the "next idiot in line" less likely to be as much of a problem as the last one. Also, being "forever stuck", as you state it, would imply that there is some magical, unlimited source of "better people" allowing us to keep raising the performance ad infinitum. Which is obviously not the case.
The real message here is: A large variance in your team's performance is a problem. If your team/project happens to be successful, for whatever reason, you will be able to tolerate a larger variance. But I would argue that the best team is one that performs consistently well, i.e. one with a high mean and a low variance; and in general any team with a low variance will have a better chance of performing well than a team with a higher variance.

The manager. by xxxJonBoyxxx · 2014-06-02 05:43 · Score: 5, Insightful

>> Every team has someone who at the bottom of its bell curve: an individual who has a hard time keeping up with other team members

The manager. Badoom-cha!

>> That's especially true for open source projects, where you can't really reject someone's help

New to open source, are we?

Depends by Ravaldy · 2014-06-02 05:46 · Score: 4, Interesting

Some organizations are large enough and organized enough to help employees grow in their current and future roles but some are too small and cannot afford the down time as they require expertise right away.

That said, in my experience individuals who struggle to get to the level of competence required are more loyal employees hence a reduced cost of employment long term. They are also more accepting of a slower career path.

My 2 cents.

Re:Depends by smooth+wombat · 2014-06-02 05:56 · Score: 3, Insightful

are more loyal employees hence a reduced cost of employment long term.

Are you factoring in the costs associated with the other people on the team having to do/redo this person's work or go over with them how to do something for the tenth time?

If after a sufficiently long period of time someone can't get up to speed, the folks at the top might want to suggest to them to find another career. Being loyal and friendly is fine, but if others have to constantly check and recheck their work, that is just wasted time and increased costs.

--
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Re:Depends by geekoid · 2014-06-02 06:07 · Score: 3, Insightful

And this is the problem and why the question is stupid.
No definition of idiot.
There will always be someone on a group that isn't as smart as everyone else.
So there is the person who can't not learn, and then there is a person who so a little slow. Widely different response to that issue.

--
The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Re:Depends by Trepidity · 2014-06-02 06:14 · Score: 2

Really depends on the company and type of work. In some companies, there are very large startup costs getting someone up to speed doing anything, so whether someone is likely to leave is a big consideration. A mediocre employee who sticks around in that case might be better than a superstar who has a 50% chance of leaving within less than 5 years.
Less often the case with pure programming jobs, especially on common platforms like web-tech and such, where good people tend to come in already knowing a bunch of the tools. But it's a fairly common situation in engineering, where companies often have extensive in-house stuff, ranging from in-house simulation software to proprietary chemical processes and equipment.

--
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Re:Depends by lgw · 2014-06-02 07:23 · Score: 4, Insightful

"Idiot" or "dummy" misses the point, I think. Never confuse activity with productivity, or "who cares how fast you go if you're going the wrong way".
I love programmers who may work slower, but are diligent and make sure they're doing the right thing. Follow coding standards, ask questions when they're not sure how to proceed, etc. I barely care if they contribute less than others, as long as it's predictable, as you'll size projects to the available staff anyhow.
I hate programmers who do work someone else has to fix. Ignore important coding standards, don't test, or simply solve the wrong problem. You pretty much have to count them as zero or negative in terms of team contribution, no matter how much code they may spew out.

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Depends by pla · 2014-06-02 09:10 · Score: 5, Insightful

"Idiot" or "dummy" misses the point, I think. Never confuse activity with productivity, or "who cares how fast you go if you're going the wrong way".

You describe two entirely different problems.

Yes, you have fast programmers who half-ass everything. And yes, you have slow programmers who carefully and methodically solve the problem correctly the first time.

Those fall on two orthogonal axes, however. You also have fast programmers who get it right the first time, and slow programmers who couldn't code their way out of a paper bag.

Obviously, falling on the "get it right" half of the plane counts as the better option. But TFA doesn't ask that. TFA asks how you deal with someone consistently slow and wrong. Rephrasing the question to something more PC ("Dumb kids don't exist!") doesn't address the real issue.

Personally, I've found that village idiots come in two flavors - Those who know it, and those who don't. The ones who know it, you can give them nice safe tedious shitwork like data entry, and they can handle it and everyone goes away happy (though depending on pay structures at your company, you might somewhat resent making the same as the guy doing nothing more than copying numbers from paper to Excel). The ones that don't know it, however... There be dragons! At best, you can try to give them seemingly important but secretly completely inconsequential projects to work on, and hope they don't annoy too many people asking for help along the way. And at worst, you write a custom check-in script that alerts their babysitter about everything they did so it can be personally validated and (more often than not) rolled back ASAP.

Yes, Virginia, dumb kids exist. And some of them manage to fumble their way into working as dumb programmers (though thank Zeus, they tend to consider that "hard" and usually prefer PolySci).
Re:Depends by lgw · 2014-06-02 09:34 · Score: 2

Slow and wrong is uninteresting though, you fire them and move on. This field is not for everyone. I've seen a big problem at large companies with favoring fast and wrong over slow and right, because distant management can measure "fast" easier than "right".

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Depends by sjames · 2014-06-02 11:42 · Score: 2

OR maybe not, maybe everyone just shoving coed out willy-nilly is more productive.
Not sure exactly what that is, but I think you can get fired for it. :-)
Re:Depends by lgw · 2014-06-02 12:02 · Score: 2

No one gets it right 100% of the time. Everyone has a percentage of the time that they get it wrong. Some people have a higher percentage than others.
Sure, but some people get it wrong most of the time. They just don't care. I hate that.

Being a really slow worker is a really bad thing. If you take 2 people that are right the same percentage of the time. One works twice as fast as the other. You have to be paying the slower worker half the salary of the fast worker to make the slow worker's employment as valuable as the fast worker.
We're not making shoes here. It's quite rare that "productivity per dollar of salary" really matters, at least not by a factor of 2. Predictably delivering high quality code on schedule as a team is what matters to me.

It doesn't matter to me if someone finishes a project in 2 days and it takes them 3 months to work out all the bugs, or if it just takes them 3 months to finish, if the end result is the same.

Not to me. The guy who checks in after 2 days and says "ship it, I'm done", and we're still finding bugs in production 3 months later is a disaster (arguably you should never depend on the coder to believe anything is done, but sadly as DevOps becomes popular, we're back to that BS). The guy who gets to the end of the iteration, says "I'm done", but his work isn't accepted (didn't really solve the problem, rejected by automation, etc) is a much bigger problem than the guy who half-way through realizes he'll only be half done.
Predictability counts for a lot. Quality counts for a lot. Management will hold the team accountable for delivering X amount by some date - with people who do it right you know where you are on that, with people who do it wrong it's anyone's guess, and everyone's problem when the project blows up at the end.
Sure, you can

--
Socialism: a lie told by totalitarians and believed by fools.

The summary defines the problem. by Virtucon · 2014-06-02 05:50 · Score: 2

Sorry, calling or dealing with somebody as a dummy or an idiot is not constructive. If other team members look down on an individual because their skills aren't the same then that's the teams problem and it's basically representative of an obnoxious mentality. While we all might laud our own abilities, in someone's eyes they're less than competent because it's all a matter of perspective.

Sure, there's people with deficient skills and that's a training issue. There's also my old favorite from WWII: "First you instruct, then you advise and if that doesn't work, you hospitalize."

--
Harrison's Postulate - "For every action there is an equal and opposite criticism"

Re:The summary defines the problem. by preaction · 2014-06-02 06:05 · Score: 3, Insightful

Disclaimer: I did not RTFA.
You seem to believe that everyone is capable, and indeed wants to push themselves to do above-average things. I've got at least one co-worker whose skills were born of the COBOL days and though the language he writes in has changed, he feels obsolete and has little desire to compete at the level of, say, me (and I don't blame him, he has a family and his free time is a lot more valuable than the time I spend reading technical manuals and doing programming for fun). He gets his work done, though he may not do it up to my own personal standards, I am not his boss and will not dictate how he does things.
That said, he is reliable, he converses with clients well, he understands the code that the more-advanced developers create and can fix bugs in it just fine. He's great at small solutions to relatively small problems, but I wouldn't trust him to start a major new project requiring a stable, flexible API that has lots of interlocking/interchangeable parts.
Yes, calling them an idiot or a dummy or indeed any disparaging adjective is not constructive (and is probably outright false), but if the boss has a large, complicated project that cannot go wrong (must deliver on-time and under-budget), the boss will not pick the person who can't deliver. Yes, the title of this article says more about the author than it does the people the author is describing, but we're not all "rockstar developers", and we can't all be treated as such.
Re:The summary defines the problem. by Opportunist · 2014-06-02 06:23 · Score: 4, Insightful

Pretty much this.
I don't have an "idiot" on my team. I have a handful of people, all with various advantages and disadvantages. My best analyst is horrible at writing reports. But I have someone who is a rather mediocre analyst but can write reports in such a way that it fits like a glove to the intended audience (as you may expect, you write differently for techs and management).
The trick is to put the right person to the right job. Yes, that means you have a bit of overhead where they have to interface, but the end result is PERFECT rather than mediocre.

--
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Re:The summary defines the problem. by UnknownSoldier · 2014-06-02 06:38 · Score: 2

It depends.
There is a time to enable -- that is, be patient -- with others, and there is a time to NOT put up with disruptive behavior. Sometimes tough love involves calling a spade a spade.
Often it is better to help nurture the person and help them grow to overcome their weaknesses. Sometimes the fundamental problem can be "resolved" with communication -- put them on probation and see if they are willing to improve.
Other times the problem comes down to productivity. When the "idiot's" lack of quality starts effecting other people's work then sometimes the best course of action is to jettison the idiot. That is not being "obnoxious"; it is instead about "focusing on getting the job done with the least possible amount of delays." You can have idiots in design, in management, in development, in ops, etc. You usually can't control people outside your group, but if you are a manager and there is someone who is dragging the rest of the team down by causing everyone else to redo their work, etc. sometimes the best wake call is to fire their ass.
People who lack critical thinking is not a training issue. As they say "You can't fix stupid."
There is no "silver bullet" because the situations aren't always "black-and-white."

How Would the Author Know? by Collective+0-0009 · 2014-06-02 05:50 · Score: 2, Interesting

As soon as I read this paragraph, I stopped listening to anything she had to say:

I’ve been very lucky. Over the past several decades, in different industries and roles, I’ve worked on quite a few teams that seemingly had a perfect balance of skills and personalities. That’s not to say that every project was successful – outside influences sometimes made them fail – but the experience always was deeply rewarding.

You catch that? The only time one of her projects has failed in decades, it was due to external reasons. Nope, not her fault, or the team, but "them".

I am willing to bet she has that same attitude about the people on her team. Nope, not her fault, but the "idiot" on the team. She was probably the idiot a few times, but was unable to recognize her own odor.

--
I finally updated my sig, but now it's lame.

Re:How Would the Author Know? by Anonymous Coward · 2014-06-02 06:00 · Score: 3, Insightful

and this:
"He never quite realized it when he handed in substandard work (such as newsletter articles I always had to rewrite; since the published articles said what he meant, he didn’t realize they’d been rewritten)."
Or he knew this person was a completely full of themself asshole but lacked the balls to confront them for fear of losing their job or beating the crap out of them
Re:How Would the Author Know? by werepants · 2014-06-02 08:38 · Score: 2

You aren't reading that correctly. The author considered herself lucky to work on many teams that were well balanced and capable. Even in that situation, with a good team, failure sometimes happened. There's nothing in there that suggests evading fault.

Sometimes the "idiot" isn't the problem. by Dzimas · 2014-06-02 05:59 · Score: 4, Interesting

I've had the delightful experience of being treated as the team idiot simply for declaring that the emperor had no clothes. It was one of those death march instances where a company decided to write a "version 2.0" of their extremely good program from the ground up. They brought in extremely skilled and expensive technical leads who developed a complicated new back end that was designed to be as "infinitely versatile" and then deployed a front end to match. The result was that they took a very good user experience and turned it into an arcane and slow -- but insanely flexible -- system. Client users absolutely hated the preview releases because they simply didn't let them do their work. I was the unlucky sap who had to provide feedback to the dev team. I decided not to pull punches and deliver a factual summary. The end result? The project lead declared that, "The consulting team simply doesn't understand how the system works" and proceeded to try to ice me out of the company. The organization ultimately failed because the project was such a mess. Unpleasant, but I'm glad I stood my ground and called a spade a spade. It took a while to regain my confidence after that, but my subsequent projects have all been successful and even award winning.

Re:Sometimes the "idiot" isn't the problem. by Anonymous Coward · 2014-06-02 06:53 · Score: 4, Insightful

In some ways you were the 'team idiot'. Not a technical idiot, but a political one.
Being in a team is not just about the product. It is also about managing your teammates.
If it had been me I would have couched it something like "here is our feedback from our end users it is not pretty" "we have created a system that the end users no longer understand and we will end up with large amounts of wasted time and support issues that may not have anything to do with technical problems" "we have lots of work to meet our customer expectations if we do not meet those they will toss us out on our ear" "training is usually code word for I am ignoring my customers (you know the people paying the bill) and know better than them" Sometimes you do. But in this case it sounds like a technical boondongle.
You had bad feedback and then took on the bad feedback onto yourself. This made you a target. The target should be the software. You tried to make it the team. They shed you as fast as they could.
Some people consider this 'mamby pamby' but someones feelings are hurt and they have instantly become an unproductive person. In some cases they will lash out and do whatever damage they can to deflect blame from themselves.
Its not 'right' but it is the way many people work. Know the system you have been put into. It is a process that can be hacked just like a program. But it takes more than 2 seconds to change a line of code. It takes months of beers, humor, and time. Sometimes the best practice is to be very quiet and listen, then speak.

Different skillsets by msobkow · 2014-06-02 06:00 · Score: 5, Interesting

I've worked on teams with a variety of skillsets over the years ranging from fresh-out-of-college new grads to seasoned "dinosaurs" with 50 years experience. Everyone had something they were good at and could contribute to the project, though many times what they could contribute wasn't technically the role they were hired for.

There was only one exception: a fellow way back in the early '90s who got a job on the project I was on because he'd supposedly done programming for AT&T after graduating from Bowling Green.

The first time we reviewed his code, we realized it was bullshit. Before every single stdio function call, there was a "#include <stdio.h&gt" statement. Every single call!

Further investigation proved that his degree was a fraud -- Bowling Green had no record of any student by his name.

Despite that, he was stuffed in a corner and allowed to "work" the remainder of his six month contract by "reviewing" documentation and marking spelling and grammar corrections with a red pen.

He couldn't even do that -- his English sucked.

But firing him would have put the company at risk of a lawsuit, so they had him make the documentation binders.

So even the worst team idiot can do something "useful" if you've got no choice but to keep them busy with something. :P

--
I do not fail; I succeed at finding out what does not work.

Re:even more telling... by chipschap · 2014-06-02 06:05 · Score: 5, Insightful

As a former technology manager, I can say that (at least as I saw things) the challenge and responsibility of management is to understand the capabilities of the staff and get them into roles in which they can succeed. If someone is underperforming in a certain job, then the manager must get them into a job in which they can perform. Everyone wins in such a case. The organization doesn't need to go through a fire/hire cycle, and instead ends up with an employee who contributes. The employee keeps his/her employment and, as a real contributor, definitely feels better about him/herself. (This needs to be done without a salary cut, which is destructive to everyone's morale, not just the staffer.)

This is, of course, if the employee is at least making an effort ... laziness or not caring is a different issue.

Re:even more telling... by Ultracrepidarian · 2014-06-02 06:06 · Score: 3, Funny

He is the manager.

So very true!! by Evtim · 2014-06-02 06:24 · Score: 5, Insightful

I played the role of the village idiot in my team for almost 2 years. It was due to an unique and very unpleasant set of circumstances [outside work, mostly family and health stuff] that totally destroyed my motivation, concentration and even my will to live. Now this might be somewhat different than what the fine article is talking about, as the condition was temporary and everyone knew I could perform above expectation even bordering on excellent.

Nevertheless, only my direct supervisor was aware of all the facts of my case and he never shared them with the MT [because I asked him not to]. Thus for the MT I was a case of lost motivation, reasons unknown. Despite that, considerable effort was executed both on team level as well on MT level to help me out.

More or less the action was as follows:

- Instead of doing long-term project with uncertain result they put me on important but short-term project so I could see the positive effect of my work immediately and boost my self-confidence.
- Every time I did something good, an MT member would drop by the office to congratulate me in front of everyone
- I never heard a single nasty word about me; no-one spoke about my performance and very importantly they all avoided in making me feel patronized. In line of this I did get negative evaluation for one of those years and was punished financially. I wanted this as I was afraid that if I get a "hand-out" I might loose some of the motivation to get better again.
- They send me working part-time to 4 different teams and also contractors outside the company - meeting and working with many new people on very diverse projects really helped getting back on my feet.
- When they saw the recovery progressing really nicely they threw me on the most urgent project in the whole company where I contributed substantially, gained more "fame" than ever before and was rewarded financially offsetting the previous punishment and then adding some to my career growth.

I count all this experience as a resounding success and I have told them many times how grateful I am.
This is Europe and more importantly the Netherlands. As I have stated here before, there is a bunch of neocon-like politicians in NL [alas, they have the power ATM] that are just itching to destroy the management system of the country, more commonly known as the "the polder model".

They claim the model is not profitable but what they mean is that it is not profitable for their corporate friends. Society as whole wins BIG TIME by using that model and it is CHEAPER (again, if you look at the whole country, not a single company or industry). What would be the profit for society if they kicked me out and I spiraled in misery and depression? Would I ever recover? Would I ever get another job? Could it be that I'd turn into complete burden for society, incapable of supporting myself. In such desperation people turn to drugs and suicide becomes a viable way out.

Ohh yhea, I just noticed that I imply in the beginning of the last paragraph that the polder model might not be so profitable if you look at specific business. That is false - the company also wins since if I had not recovered they'd have to spend tens of thousands finding and educating a replacement for me [I did the math, our solution was cheaper indeed than hiring another person]. So, apparently the polder model is not profitable for a very small group of people within companies who probably get their bonuses based on very short-term performance so that the long-term negative effects of fucking your employees is not visible at the moment.

even a team of editors by frovingslosh · 2014-06-02 06:40 · Score: 2

"Every team has someone who at the bottom of its bell curve...." . Even teams of moderators and editors, right samzenpus?

--
I'm an American. I love this country and the freedoms that we used to have.

Hard Course by ADRA · 2014-06-02 06:57 · Score: 2

I've been with many people over the years, and generally hovering a little above the mean, I've met a fair number of dev's that have struggled for various reasons (I've been many of these from time to time as well):

1. The boat anchor -- They have no idea what they're doing and they waste everyone else's time by having correct their lousy work, answering questions (usually the same ones over and over and over), and just generally fristrating to teach anything new to.

2. The lifer -- Not interested in learning anything new and rarely bother unless it makes their carreer on shaky ground -- These people work at a stable though generally slack pace and learn to develop the same way and will never both to investigate new ways of doing things. They are generally a stabilizing force on the team which is often torn between jumping from one paradigm to the next and those that refuse to change anything. Training them to use new tech can be a drag on the team depending on how stubborn they are

3. The free radical -- Generally younger and more naive though not always, the free radical will always try to escape from whatever constraints you attempt ot place them into, and will fight vocally and loudly to get what they want. They will often quote material from a blog or big name in the industry without caring at all how it affects the job or workspace they actually occupy.

4. The well wisher -- Those developers that really really want to do a good job and work hard day in and day out do better themselves, but due to lack of understanding, natural talent, or whatever have a hard time grasping concepts and new areas. You want to help them so badly, and they generally do get better with training, but will never free think themselves out of a problem and will almost always need some level of supervision (and generally they like that).

5. The paycheck -- They check into work to get paid, and although amazingly brilliant or a complete dullard, will never aspire to anything because they're just there to warm the seat and to get paid. Don't get comfortable with them though because they will almost certainly be the first to jump to the next company.

I'm sure there are many more I could add to the list, but I have a meeting to jump off to. Hope this rings some truth.

--
Bye!

even more telling... by globaljustin · 2014-06-02 07:18 · Score: 2

to me the more telling thing would be **how they define the "idiot" **

is it a team of jackasses? in those situations, the person trying to actually get work done will be in constant friction with other team members

so if a team of 5 has 3 idiots and 2 regular workers, and only 1 of the 2 is the type to speak up in groups...

that *one* person will be the constant voice of oppposition

and they become the "idiot" in a team of idiots...

--
Thank you Dave Raggett

Re:even more telling... by nitehawk214 · 2014-06-02 07:37 · Score: 2

is how management treats said person.

Probably pretty well, considering management usually is the idiot.

--
I'm a good cook. I'm a fantastic eater. - Steven Brust

If your team is distributed like a bell curve... by hsthompson69 · 2014-06-02 07:51 · Score: 2

...then your hiring practices suck.

Normal distributions are expected when doing random sampling. If your interview and hiring process ends up with a random sample, you're doing it wrong.

Bell-curve performance management systems are predicated on this odd idea, that hiring ends up with a random sample.

http://www.linkedin.com/today/...

Re:even more telling... by Anonymous Coward · 2014-06-02 07:54 · Score: 5, Interesting

Mod parent to top. I'm in my 50s now, and in a management role in a fairly well-known British financial software development firm. The idea that you can rank people on some one-dimensional scale is laughable bullshit - not much more sophisticated than the phrenology of yore. My job is to find out how people work, and to give them what they need to make them thrive.

It is extremely rare for me to find someone who is genuinely dull - I'm much more likely to have a group of closed-minded people who think the "different" guy is stupid, only to find out a year later that he's a stellar performer given the right conditions. I'll go so far as to say sometimes it's straight prejudice: a few years ago we had a top graduate with very little programming experience who was constantly asking questions. He was also black and his English wasn't very good - two things that were mentioned more than once in the office by others when he wasn't around, as part of discussions suggesting that he lacked competence. Fast forward to today, and he's leading a team of financial modellers. He still slips up on engineering, but he's one of the most mathematically talented chaps we've had. He's much better at communicating than he once was, but it's really a case of his brain not thinking the same things are "obvious" that other people think are so. I've heard no nasty remarks on his heritage anymore, either - which, in a team full of public-school-educated white boys, is my idea of progress.

We treat ours grand! by Karl+Cocknozzle · 2014-06-02 07:58 · Score: 3, Insightful

...We promoted him to Director and now he sits in his office being distracted by shiny things, allowing the rest of us to accomplish the actual business of operating our department.

Try it sometime! The only way it can backfire is if the person has actual-authority over something important--then the company might go out of business. But other than that I'm drawing a blank on negatives.

--
Who did what now?

Rockstar dev? by TiggertheMad · 2014-06-02 09:55 · Score: 2

I would say that a Rock Star Dev only lives up to the title if they can lead and educate.

A dev that crank out large volumes of code, but is unable to articulately communicate or work with others might be skilled, but is hardly a 'Rock Star'.

--

HA! I just wasted some of your bandwidth with a frivolous sig!

Re:Maybe the Arrogant Assholes Are the Issue by UnknownSoldier · 2014-06-02 10:18 · Score: 2

> My point was that arrogant and abusive assholes are the real problem.

Uhm no. Lack of communication, and lack of accountability is the problem. How the message gets delivered isn't going to "magically" change someone who doesn't grok it.

> If you find you actually have a bonafide MORON who is lacking in overall intelligence, then why were they hired to begin with?

You've never done any hiring have you? News flash! Not every resume is honest, sadly.

I've worked with people who while had excellent knowledge in an extremely narrow field but out complete idiots outside it. Mathematicians and Physicists tend to make shitty programmers -- they don't understand the importance of writing simple, clean code. They tend to over-engineer every solution, etc. You don't make them programmers, you use them best what they are good at.

There are people who are prima donna's who can't socialize and interface with the team, etc. Allowing them to keep trash talking isn't going to get them to change.

Then there is the crusty old person who has been at the company for years but hasn't kept up to date with newer technology and is unable to add anything constructive to the team because they are set in their ways. You provide ways for them to advance their career and stay up to date. If they aren't willing to have something of value to ADD then they won't be missed.

Sometimes you end up with a complete free-loader / slacker who has been completely overlooked.

The situation can come up in many different ways.

> So, a perfectly capable person who comes up short in any category is now an "idiot" and should be treated as trash.

No one is saying that ! Everyone has strengths and weaknesses. The problems comes about when none of the idiot's strengths are not able to utilized and their weaknesses are a detriment to the team and outweigh whatever positive contributions they could make. THEN it is time to cut the dead weight.

It is like the cheap customer who is never happy -- constantly complains. Sometime it is better to refuse to do business with him as they are costing you time and money for little or no gain. Let the competition waste their time dealing with them.

This isn't rocket science. First, you try to see if the team can utilize the "idiot's" strengths. Second, you try communicating with the person to get them to be a more productive member. They can't change their behavior if they are unaware of it. Third, you give them some time to change. Lastly, you get rid of them if nothing else works.

Clinging to some dogmatic stance is completely unpractical. People who enable other people bringing the team down simply because "We can't offend little Johnny's feelings" are part of the problem. They are the pussies. Usually the situation can be resolved diplomatically, if not, then you use "force" by removing them. Sticking your head in the sand, ignoring how a person is dragging down the rest of the team is unproductive and idiotic.

Emotional Intelligence - searchterm or buzzword? by jago25_98 · 2014-06-02 11:26 · Score: 2

Such warm and fuzzy articles aren't welcome here. We're interested in evidence.
We wonder whether it's best to cut a member loose or support. What about the top end of the bell curve? How are they treated? Are they operating at max? Perhaps that's something the idiot might be able to notice while everyone else is busy producing?

Without a decent study, who's to say?
I would like to link to an article and contribute something of substance but I'm not quite sure what to search for. I'm finding studies confirming leadership - need to search more to find anything referring to a group.
Perhaps the search term (buzzword?) for the article should be 'Emotional Intelligence'?

Going along that line the article is part of a group of ideas that people management is more important than technical skills. Both can be taught but our teaching skills are better at the technical. Maybe that's why knowledge is hoarded, damaging a company. In those smelly, fuzzy hippy companies where people, you know... have a good team feeling dare we admit the potential is better there?
- or is that just trendy to say that?

Like I say, need more info. It is out there but engineers don't like to admit it. It's good to just say how you feel without feeling inhibited - just totally honest. You should be able to do that at the same time as being good and fair. It's not an easy skill to learn. Women and gay men do a better job? Maybe but can be pretty catty too.
It's a real joy to meet people who are both technical and socialable. Even more a joy to be at ease with those people so you can just get on well. People who listen, and where you can treat each other rudely but we all know it's OK.

I do agree with the article that the idiot treatment is a marker - they're not saying anything more than that.

My own view - treat a weak member positively, everyone has something to give. And fire them if that's the right decision.

--
A blog I run for the wealth

Slashdot Mirror

A Measure of Your Team's Health: How You Treat Your "Idiot"

47 of 255 comments (clear)