XpdWiki: PairingInAStrictHREnvironment

At line 31 added 18 lines.

+

+ '''Update'''

+ Now that the "simple" solution (they tell us what to do, we do it) has not worked, and the ball is back in MIS/HR's court to assess our suggestion, the whole problem suddenly seems to have become much less important, and we have an instruction to carry on as usual until they get round to it...

+

+ * Musing on this Story *

+

+ Lots of folks are interested in free policies - free for them to implement. Anyone who's job includes managing risk but not results is at - er - risk of this. HR, for example, which is tasked with avoiding lawsuits and other legal claims but not with producing something. They will absent some perspective myopically make policies. They are ignorant, and managed to narrow goals vs. malicious. My personal favorite example of this involves computer security people who in the end are biased toward the total security of a computer locked in a darkened room connected to nothing. Such a computer is close to perfectly safe, but useless. Sometimes I have to point this fact out to them: All use of a computer to do some good includes associated risk to security.

+

+ Folks tasked with getting something done, even software folks, often engage in their own accidental or willful unawareness of other folks' concerns. These range from regulation and lawsuits (which unfortunately every business in a Western nation must consider at all times) to simple costs. I've seen dozens, no hundreds of developers who insist on their own personal desktop configuration without considering the possible effect on a LAN which someone else is tasked with keeping up. These same developers are also the first to complain when their computing environment is down. They usually don't recognize that the beleagured LAN support staff are solving a problem very different from "optimizing one developer's coding." The LAN support staff are often managed as a cost, so their problem is keeping some minimum service up at all, for a big pile of people, at the least possible cost. They are chronically under-staffed. It's a crummy job most of the time.

+

+ The trick is to bring the concerns together. Rather than see the HR policy and it's abandonment as sinister or inconsistent, why not simply see it as everyone doing their job. If it's free, HR & MIS have a perfectly legitimate concern to meet with the one-login policy. And why would they consider groups of people sharing a keyboard as dynamically as in pair programming? That's not what they are used to seeing. The development team also has a perfectly legitimate concern to assert about the policy, specifically: "This isn't free." So now someone has to make a tradeoff decision.

+

+ There's nothing necessarily sinister, or even myopic here. It's simply people who are new to each other working together in a business. HR and MIS folks, especially LAN administrators do tend to have an unfortunate communication style when it comes to policies. In part that's the mindset that fits people to such jobs. In part that's the crap that these people have to put up with. "New" folks to an organization will walk head-first into old assumptions in that organization. That's part of the price of being new, and of changing things.

+

+ The lesson that I'm inclined to take from this story has two parts. First, if I want to do something unusual, the support organizations may not be set up to accommodate that. Second, that I can give them the opportunity to be part of the solution. I can't count - literally can't count - the number or "uncooperative" and "reactive" LAN or Network support teams I've co-opted simply by starting out with: "I want to do something that I suspect is unusual. Let's figure out what it will take for you to support it . . . " If I'm flat out stiffed, which happens sometimes, I have a very interesting fact to kick upstairs to one of those trade-off decisions.

+

+ But that's just me. -- JimBullock