31 August 2010

xbox live adds content!

unfortunately, i can't use any of it. espn3 is coming soon, so i could conceivably catch OSU games. unfortunately, time warner sucks megadong and won't pay the extortion fee enabling my access to the stream. xbox is also adding hulu plus, which itself requires a separate subscription—none of the free content will be available. these extra features will cost me an extra $10 per annum, which is fairly cheap if were to use them.

18 August 2010

the incentive trap

i'm certain many folks are already familiar with Dan Pink's TED talk on the science of motivation.

the key elements of motivation are
  • Autonomy – The urge to direct our own lives
  • Mastery – The desire to get better and better at something that matters
  • Purpose – The yearning to do something that we do in the service of something larger than ourselves.
my first session at Agile2010 was with Simon Bennett, who ran a hands-on exercise to illustrate the same concepts. we were split into four teams: two with somewhat standard roles and pay-for-performance plans (taken from actual companies), one organized as a group of volunteers donating to a charity, and the last (mine) run as a self-organizing team with a simple, evenly split pay structure.

the work for each team, it was revealed after the experiment, was exactly the same (math problems with varying complexity), with exactly the same calculations for value delivered. the only difference, other than the pay structure, was that the volunteer team was actually playing for a real donation to their charity, though they did not know that ahead of time, i think. the results were amazing, even after having read on the subject and seen the video above. my team (self-organized) achieved a value of 54 with average pay and highest pay of 13.5. the first team of old-school roles and pay achieved a delivered value of -19, though their average pay was 13.5 and highest pay topped out around 25 or so. the second old-school team achieved a value of 0 with fairly low pay results, due mainly to a lack of work management, which was itself affected by the pay structure. the volunteers delivered a value of about 19 though their pay was fairly low (sorry, Doctors Without Borders).

the most interesting part of all of this is that no one actually made any real money, but the effects were measurable nonetheless.

in discussion, we decided that almost everything about a standard model of a corporation is wrong: from the language of a job description or role to the often cross-competitive pay structures for those different roles. secrecy itself, required to mask vast differences in pay, can hinder the delivery of value.

at the end of the day, incentives can only reveal priorities or demotivate workers by blocking intrinsic motivators or creating feelings of inequality. so our lessons as leaders are
  • inspire purpose
  • remove demotivating forces
  • grow expectations of success
  • promote connection over competition
these lessons appear obvious, but they are always given short shrift.

ticket system as anti-pattern

what drives a company or business unit to install a ticket system? to be sure, there are benefits to be recognized from the use of a system to track work items. similar to a backlog, a ticket system prevents ideas or requirements from escaping the established business process. it offers a means of examining the history of work through trending analysis, or just aggregating the thoughts of numerous individuals.

so why is it that ticket systems are often such a pain in my ass? the answer lies in the ridiculous behavior teams or organizations often apply to their use. based on personal experience, most often ticket systems introduce barriers between communities, encouraging delay and disconnection. further, they are almost always used to enforce a metric of time-to-resolution, without regard to any concept of value provided. a necessary consequence of such thinking is the optimization of the "delivery" of bad software or service.

let's consider a recent example. in my team room, we have a wonderful multi-function device (MFD) that i wanted to map as my default printer. it is ten feet from my usual desk. (i won't get into why i have a usual desk in a team room. that's a topic for a different rant.) by convention, our printers have a pad of sheets near them, usually mounted on the wall or side of the device, that offer the details necessary to use them from windows. this printer did not have such a pad and had only a phone number to call, which was not answered.

all i needed was the network name of the printer. naturally, i called the help desk. (i know ticket systems suck, especially those that have a preface page that suggests strongly that one call the help desk because one's issue is statistically more likely to be resolved in hours rather than days.) the helper on the other end of the line gave me a ticket system (one of many) to use to submit my request. furthermore, he gave me the Topic i needed to select such that the correct "resolving agency" would answer my question: Request a new pad for printer. (i would note that this particular ticket system requires a user to select among hundreds of Topics before submitting a request. good luck if you don't know the language and domain of the appropriate resolving agency!)

navigating to the request form, i noted that the first field required the network name of the printer. i dutifully filled out and submitted the information, using "unknown" as the name, confident that i could use this printer once i returned from my week-long conference.

eleven days after i submitted my ticket, i received an email from a random woman stating that hers was not the correct resolving agency since this was an MFD and not a printer, but she would enter an appropriate ticket for me. not very long after, i received an automatic notification that the new ticket was Resolved. being the curious sort, i strolled over to the MFD to find the magic pad. no pad.

the result: i have one phone call and two tickets through three different failure demand pathways and no value to me. metrics: phone call over and done in two minutes max, one ticket done in minutes, another done in 11 calendar days. good? bad? indifferent.