Slashdot Mirror
A Measure of Your Team's Health: How You Treat Your "Idiot"
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.""
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.
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.
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.
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>" 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.
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.
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.
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.
Yeah, I think that is the important -- and only -- message here. From the summary:
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.