XpdWiki: PairingInAStrictHREnvironment

Line 33 was replaced by line 33

- '''Update'''

+ __Update__

At line 35 added 2 lines.

+ __Further Update__

+ Joint and several responsibility was not acceptable, there has to be a named individual. So, the suggestion now is that the coach of a team will take responsibility for what happens on the pairing machines only, uner the shared login only, and during pairing time only, whomever was using the machine at the time. As one of those coaches, I'm pretty happy with this, since I do actually trust my colleagues not to surf porn (well, not to surf porn ''on the pairing machines, uner the shared login, during pairing time'' :), and I'm not afraid to stand up and say so. --KB

Line 37 was replaced by line 39

- * Musing on this Story

+ ''Seems like a perfectly reasonable solution that accomodates everyone. I'm intrigured by the test built in to the solution. Unlesss the XP folks, in this case you, Keith, actually trusted your colleagues as you were asking the MIS and HR folks to do, the solution would fail. You'd back off. Real solutions to balancing agenda often have this kind of "money where your mouth is" element to them. In this case, the development team has to exhibit the trust they were asking of others. The MIS / HR folks have to exhibit some willingness to acknowledge that their concern is to have _some one person_ responsible for each act committed on one of the machines they administer.''

Line 39 was replaced by line 41

- 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.

+ ''I'll be curious how this plays out. As much as it is an inescapable reality, the process bound have a hard time coming to terms with the fact that in the end, you have to trust somebody, to some degree, or nothing gets done. Even in a secure environment working with classified material there are instances of "trust" and of delegated responsibility. Fascinating tale Keith.'' -- JB

Removed line 41

- 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.

At line 42 added 6 lines.

+ !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 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 (sometimes willful) unawareness of other folks' concerns. These range from regulation and lawsuits (which unfortunately every business in a Developed nation must consider at all times) to simple costs. I've seen dozens, no hundreds of developers who insist on their own desktop configuration without considering the possible effect on a LAN which someone else is tasked with keeping available. These same developers are the first to complain when their computing environment is down. They usually don't recognize that the beleagured LAN staff are solving a problem very different from "optimizing one developer's coding." The LAN support staff are usually 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.

+

Line 47 was replaced by lines 54-57

- 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.

+ 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 around here. 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.

+

+ If in the end, my concerns and priorities are never considered, and there is no appeal, or no successful appeal, well, that's an important and useful piece of data.

+