The Process Myth
randsinrepose.com
randsinrepose.com
For instance take the transfer process that was being extolled. The incentive now is for managers to evaluate their best employees poorly, and mediocre ones highly so they will keep their best and lose their worst. Many people who have worked in large companies have seen this first hand.
Secondly there is a very real problem of fit between the person and the job. If a person is not doing well, and the problem is fit, then the transfer restrictions will leave no place for that person to go but out of the company. As a concrete example I offer SRE at Google. They need an unusual mix of "able to program, but sysadmin mentality". So Google tends to hire one skill set and hope that they get the other. But when they don't they may get a perfectly good software developer in a role where they won't do well. This is a loss for everyone.
The result is that even well-intentioned and supposedly good processes result in routine bad decisions. If this bothers you, then you probably do not want to work in a large company.
This is an actual process in my group at the company I work for.
Process doesn't have to be heavy and invasive.
And what's the alternative? Zero process? Everybody has to "wing it" all the time? I can't see any possibility for a perverse environment there!
Furthermore there is a type of person who enjoys asserting power through language lawyering. That kind of person will see that policy as a golden opportunity to acquire influence, even though the cost may be unnecessary conflict to little point. If such a person manages to assert control of a process element like that, you can easily get a type of teamicide that drives away good developers who don't want to deal with the BS of figuring out whether their essay was good enough to avoid an email lecture.
As for the alternative, I thought I was clear on that. Large groups cannot work without process, small groups can mostly get by on common sense. The imperfections of processes do not change their necessity in many cases. But if you, personally, do not enjoy dealing with process, then you should find opportunities to work in more congenial small groups.
For example lets say the rule is that "C# code must be compiled before it is run." The incentives are to declare code compiled when it is not, to declare that you are not running code when you are, and to declare code to not be written in C#.
(I expand on this idea on my blog[2], if you are interested.)
1.http://en.wikipedia.org/wiki/Gray_goo
2. http://softwaremaven.innerbrane.com/2010/03/preventing-proce...
And then Rands touches on something important: every time there's a new policy addition in the office engineers groan. Why?
* Because a manager is going to try to "fix" something (and will probably make things worse). ("Yes, we know the bug tracker sucks, but (sarcasm) yes blame the _developers_ when the requirements change half eay through implementing the ticket")
* "If you listened to us in the first place... We wouldn't be overworked and making these mistakes you're compensating for"
* The "green lieutenant" problem. (see any war movie for this)
See enough of those and yeah you'll roll an eyewhensome manager bursts into the door with a great idea... Especially when asking "why?" too mny times certainly will get you branded as a trouble maker.
If you're not an execrable fascist, you realize that performance review history part of the transfer packet is a Bad Fucking Idea. This Enron-style "innovation" was intended to intimidate people into working harder. What it actually did was give managers incentives to give inaccurately bad reviews: keep the fuckers captive with negative ratings. Bonus points if people don't know what their exact ratings are and therefore can think they're receiving acceptable ratings (cf. Google's secret calibration scores).
I'm sorry, but the absolute first thing you need to assess when it comes to process is: how will this shit be abused? If the system entrusts a single individual (in the internal mobility case, an employee's manager) to be ethically decent, with serious consequences to others if he's not, it will probably fail.
The real purpose of these bad HR practices (transfer blocks, global stack-ranking, political-success-I-mean-"performance" review history as part of the transfer packet) is to create a false objectivity that leaves badly-treated employees falsely believing they have no legal or publicity recourse.
The vast majority of terminations don't go to court, but companies want to avoid bad publicity as well. The real purpose of a severance is to leave the employee feeling good about the company, despite the separation. The purpose of a PIP is to make the employee feel bad about himself. This is because people are most likely to seek recourse when they perceive a sort of moral superiority. HR's job is to frame events so that people don't have this sense of righteous indignation. A severance brings the company up; "we can still be friends". A PIP brings the employee down; "you have no recourse, because you're shit and I'm champagne".
People who look at bad HR practices and ascertain noble or neutral intent are missing the bulk of the picture. Most powerful people in most companies are just bad human beings whom a less emasculated society would do something about. It really is that simple.
Should I aim to explain the values that we're upholding (code quality, documentation quality, test quality, etc.), in every step?
Agreed on the quality of the article. As always, Rands manages to put the right perspective on the topic. I'm forwarding to quite a few process-averse folks I work with.