A Measure of Your Team's Health: How You Treat Your "Idiot" 255
Esther Schindler (16185) writes "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. How your team members treat that person is a significant indicator of your organization's health. That's especially true for open source projects, where you can't really reject someone's help. All you can do is encourage participation... including by the team "dummy.""
The manager. (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?
Re:Depends (Score:4, Insightful)
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.
Re:How Would the Author Know? (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:The summary defines the problem. (Score:4, 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:even more telling... (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:Depends (Score:4, 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.
Re:Really? (Score:5, 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.
Re:The summary defines the problem. (Score:5, 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.
So very true!! (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.
Re:Sometimes the "idiot" isn't the problem. (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.
Re:Really? (Score:5, 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:Depends (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".
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.
We treat ours grand! (Score:4, 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.
Re:Depends (Score:5, Insightful)
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: Really? (Score:4, 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? (Score:4, 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.