Business people, generally speaking, are pretty dumb. Most of them are salespeople or customer success managers or whatever who don’t really know much about how the tech works. They are there to keep the client happy and make the sale. But that’s what generates revenue for the company and thus drives the business.
One problem with that attitude is that developers that don’t expect to stick around tend to produce a lot of technical debt, because they won’t be the ones paying for it. Devs that expect to be around in several years are more likely to produce better code, tools, and processes in order to help their future selves. Of course, this requires both devs and management to think long-term.
Sure, but management doesn’t want to think long term. They want to bring in some consultants to build some system and then have them leave.
That’s been one of the most frustrating things about half the places I’ve worked. We have a million engagement managers and account managers and sales reps and all sorts of other client-facing people. But we can’t find a single person to do the actual technical work.
Yeah any company who thinks they can just churn out the bad employees with these tactics clearly already has the bad employees in management.
I ran what anyone would objectively call an elite industrial research group in an esoteric technology. Which means not only was the majority of the group hand-picked, heavily recruited scientists, but there weren’t that many people in the world with the background and training to do the research.
My little group reported to the VP running a 3,000 person engineering organization. I had ~50 people reporting to me. The next smallest organization reporting directly to him had 500 people.
We were in the year-end “rating and ranking” meeting and it was pointed out that my ratings did not meet the required percentages. I was told that I would have to adjust my ratings to get the right percentages (I had to many high ratings). I explained the makeup of the group. Didn’t move him. I told him that he was the boss and he could probably do whatever he wanted, but I would not put my name to any ratings but the ones I had done. He stared at me. I stared back. Finally, he turned and asked the next director to present his rating statistics. My ratings stood.
I never got a personal rating from him better than “meets expectations” (i.e. mediocre) after that. I never regretted it.
I never understood why companies always expect all their employees to “exceed expectations”. If your expectations are actually higher than “meet expectations”, why not set those as the “expectations” to meet.
It’s the same reason they do the forced ratings. They want employees to constantly worry that their jobs are in jeopardy if they aren’t working hard enough.
Actually a lot of this comes from Deming, who was convinced that in manufacturing most employees are exactly the same and should be rated that way.
To elaborate on what Peccavi said, the Pareto principle assumes a distribution. But if a workforce follows this distribution whoever does hiring should get fired. A non-clueless hiring manager can hire lots of people in the top 10% of the job candidate pool, so immediately assuming this top distribution is mediocre in the employee population is a recipe for trouble.
Sure some people are not good matches, and some slack off, but that doesn’t mean you need a forced distribution.
At Bell Labs we didn’t have any such thing. Reviews were run by the second level manager and reviewed by a third level manager, and we had a raise pool that had to be followed, but ratings should match talent, not forced distributions.
That does mean that hiring managers must be able to get good people - but considering how badly most recruiting is done, that isn’t too hard.
I have seen both the 10X and the 100X number printed before. I think the difference is that 10X just looks at things like lines of code per unit time and that sort of thing, while the 100X takes into account other costs like schedule slip when a low performer fails to deliver, expensive bugs introduced by poor programmers, etc. If you accept the Pareto principle that 80% of bugs come from 20% of the programmers, you can see how you could get a big number for what they cost. A really bad programmer on your team is far worse than not having one at all.
Iterative development and Agile probably mitigate this somewhat, but in the old days it wasn’t uncommon for a programmer to claim that he was doing fine, getting his work done, on top of things… for months. Then when it’s integration time you find out that the guy had done almost nothing or produced a bunch of unusable crap, and the whole release slips.
In Tracey Kidder’s “The Soul of a New Machine”, he described a guy like that. A genius microcoder who kept telling everyone he was right on track, and it turned out he was totally blocked and hadn’t written a line of code in months. As the deadline neared, he rented a hotell room and locked himself in it for a few days, and emerged with the microcode. But if he hadn’t done that, he would have caused a long schedule slip on a very, very expensive project (the Data General 1 minicomputer). Guys like that may be geniuses when it suits them, but they are/were a substantial risk.
We had an architect on one product who did not belong anywhere near architecture, and chose a wholly inappropriate technology as part of our key stack. No amount of arguing by many developers would change his mind, and he had clout to make his decision stick. That choice dogged us for years as we had to develop workaround after workaround to avoid the performance issues inherent in the tech. Finally people in power got sick of the delays and authorized a rewrite and we spent huge effort ripping out that whole subsection of the product and replacing it with something that worked.
Yeah, I agree. In fact, as an aging software developer myself, I think sometimes your productivity drops unless you devote a lot of your spare time to keeping up with the industry. I used to do UI work in Javascript back in the day, and the rule of thumb was that Javascript was too slow to do any kind of serious processing, so almost everythiung was done server-side, with Javascript only used for manipulating UI bits like disabling buttons or validating client-side input where possible.
Then I went off and did years of C/C++ development on industrial software, and later on was assigned to build out the web UI for a project. I wasted a lot of time setting up a bunch of server-side code like I used to, when a younger developer said, “Why are you doing that? Just do it in the client.” I said Javascript would be way too slow, and he said, “Not a chance. It’s plenty fast for everything you want to do.”
Then there is the constant learning curve. Young programmers come into the shop already highly familiar with Angular, NodeJS, Docker, Git, REST design skills, web services, cloud computing, yada yada. For an old guy who spent decades working on thick applications in C/C++, all this stuff required a lot of relearning and re-alignment for how to do things the best way, and you have to do all that learning while trying to keep up with the coding rate of smart young people with fresh educations, a lot of drive, and all kinds of free time. It’s not easy.
Oh, I agree. The Pareto principle is based on the bell curve, and just doesn’t apply at all to small groups. GE did deal with that, though. They wouldn’t just rate by team or even necessarily by office, but they’d have managers do their own ABC ratings for their direct reports, then it would all get submitted higher up and corrections were made at a subsequent meeting of all managers. Several times I was on a team that consisted of nothing but ‘A’ employees. The last team I was on, everyone on it except two of us were staff engineers, and the other two were seniors. Not a weak person in the bunch.
One common issue is that sometimes your best programmers get handed the hardest things to code. So if some weak manager decides to rate them by lines of code or function points or something, the best programmers would get rated lower than the average guys given fairly boilerplate interface code or something that you can crank out like lightning.
But that’s true of all metrics. Programming is complex, and reducing skills down to lines of code or how many function points you wrote is ridiculous. A true rating needs a very hands-on manager who not only knows how much you are working, but the quality of your code and the difficiculty of the tasks you take on.
We went through a management phase where they tried to count lines of code and rate developers that way. That was a disaster. Then they thought function point counting would be better. Also a disaster.
I’d say the biggest problem with A,B,C ranking is that it can be very hard to determine who belongs in what category, especially in the real world of both good and bad managers. Sometimes the ‘C’ guys are bloody obvious, but it can be hard sometimes to sort out the A’s from the B’s.
A programmer can fall behind on his commitments, then you find out that the reason is because he’s the ‘go to’ guy who spends a lot of time fixing other people’s problems or helping them through difficult tasks. An ‘A’ employee who looks like a ‘B’ at best if you just look at metrics.
Then there are the ‘inconsistent A’s’ - people whose productivity seems to be driven by their internal mental state, and they can go through fairly long periods where they aren’t doing anything more than anyone else, and maybe less. But then they have flashes of insight which motivates them and they singlehandedly refactor a troublesome module and make the whole product better. It’s very hard to rate people like that.
There is always churn. People retire or quit for better jobs, new people are brought in. And also, people are not consistent. I have seen employees go from ‘A’ to ‘C’ between projects. Sometimes it’s attitude, some times it’s a life issue, Sometimes it’s burnout. I think most employees who make it to ‘A’ status don’t do it year after year, but sometimes excel due to the right circumstances of manager, project, their own personal goals, etc.
The whole reason for Performance Improvement Programs is to recognize that sometimes a ‘C’ employee just sort of gets lost, or frustrated, or isn’t managed well. A significant percentage who get a PIP wind up rejoining the ranks of the B’s, and sometimes become ‘A’ player once they clue in to what they’ve been doing wrong and how close they came to being shown the door.
But by and large I agree that the rigid ABC ranking system and blindly following it is a bad idea. GE did get rid of it, after all. But something like it is done in most companies - they just don’t make it explicit. But everyone is on the lookout for the best people to promote or give more responsibility to, and for the ones who need to be carefully managed and perhaps eased out the door if they just can’t cut it. Same thing, but with less fixation on numbers. That’s a better way to go.
Yeah, I agree. See my previous message. GE wasn’t that stupid, and did try to aggregate and correct reviews across a large number of people with all the managers gathered to compare notes. It was up to your manager to defend your ranking in those meetings.
The problem with that is that’s a very hard thing to do. Lots of managers think their employees are the best, or at least represent them that way to make their own management look better. So there is a lot of information lost in those meetings. That’s probably one of the reasons why GE dumped that. It’s one thing to rank people if they all do the same job, such as in a call center where you have 500 people doing the same thing and you have hard metrics on things like calls served, customer complaints, etc.
But in engineering where the tasks are so varied and the teams small, I think there’s no substitute for plain old human judgement and manager reviews with the employee. Although I understand manager reviews are now going away as well.
Before our office closed, we had switched to ‘peer review’, because HR told us that ‘Millennials will not tolerate being criticized by a manager.’ So we had a system where we were supposed to manage each other in helpful ways by sending comments like, “Do more of this”, or “You might want to learn about X”, or whatever. Nothing negative allowed.
That system was failing hard when we finally closed. Engineers are not good at this stuff. No one was telling anyone else a damned thing.
That kind of thing works for the Deming method. Most people doing assembly line work are indistinguishable. But it got applied to Engineering. I’ve worked in places where the GE method was applied rationally, and in places where it wasn’t.
I’ve experienced the peer review system, but since people had so many peers they got to choose some. Which made the process totally worthless.
Managers defending employees might sound good, but sometimes it is part of the problem. If someone gets a bad review their manager is not about to defend them. The biggest complaint we had about this is that managers didn’t even know what some of their people did. We required that the employee’s report of their activities get included for the review to stop this.
It helped in our case that lots of people moved between groups or worked on multi-group projects so that in some cases other managers defended someone. It also helped that our boss wasn’t a jerk.
Really? Because my experience in corporate America was that PIP’s were the mechanism to get rid of employees. Put someone on a PIP, set impossible to achieve goals, and shortly there’s a reason to cut them loose. I never knew anyone put on a PIP that wasn’t out the door in six months.
Maybe it was the companies I worked for at the time.
When I was a newish manager some clowns promoted me twice in the early years of my career so that I went from Newly Minted Financial Analyst to 26 year old manager with 11 direct reports, most of whose work I knew nothing about.
In the first year’s performance reviews, I put someone on a PIP, with every intention of helping her improve with peer support. I seemed to be the only person who didn’t think I was trying to “manage her out of the company”. I was operating strictly out of the 4 hour HR class I had taken on Performance Management for New Managers. No one told me the real purpose of a PIP.
The HR business partner was shocked that I was not making arrangements to protect the company WHEN we terminated the employee in six months. The employee was shocked that I actually expected better performing peers to help her. The peers were even more shocked.
I had monthly meetings with her, not on her performance, but on the performance improvement actions. I was literally using photocopies of the worksheets from my training manual!
She did improve and retired from that company 25 years later. I left almost 20 years ago and have worked for a couple of other large companies since (all three with over 25,000 employees). We are still in touch. Neither of us have ever heard of or seen anyone ever coming off a PIP successfully in all this time.
I know of people who have moved internally to different jobs because everyone knew that the only reason they were on a PIP was illegal discrimination of one kind or another by someone in their management chain. I know people whose bosses were fired for sexual harassment (in one case sexual battery) after a legal complaint. I know someone offered an early retirement package while on a PIP. But I don’t regard any of these as “successfully completing a PIP”
Possibly - because except in a very few situations involving contracts , there’s nothing in the US preventing the company from simply terminating the person without putting them on a PIP except the company’s own policies.
That’s interesting. I knew two people who were put on a PIP, and both stayed in their jobs. The PIPs were honest attempts to fix what was wrong and get them back on track, and at least in the two cases I knew, it worked.
Sometimes you put someone on a PIP and you just know it’s not going to work, and yes that’s mostly a formality…but other times you can be surprised as people give themselves a good shake & pull it together.
The worst - and I’m thinking of one guy in particular - is the person who survives a PIP & does fine for say a year, then starts to slide again, then recovers on a PIP again, etc. Those are hard people to manage out, but god you want to.
I had someone who worked for me on one, and it worked because he recognized he was having problems. In fact he gave me a good rating in the upward evaluation process. He eventually retired early, which was good for everyone, but he was out of the PIP when he did.
I’ve found that in professional services where I work, “performance” is largely arbitrary. Sure, billable hours are a solid metric. And I’ve had consultants on my team who have had issues with particular clients. But to be honest, I haven’t really figured out what makes someone "successful " at most of the places I’ve worked. As far as I can tell, it really comes down to whether a particular manager likes or dislikes me and whether a project I’ve been assigned has been positioned for success.