Sunday, September 8, 2002

Economic Operating System (eOS) Revisited I had lunch with two intelligent women today, my wife Tamara Bavendam and a former student of hers, Soojin Park. They're both high-functioning physicians, each with their own network of similarly high-functioning friends. We wondered what fraction of people are so pleased with their jobs that they aren't seeking a better situation. Among Soojin's circle, she felt less than 30% are satisfied, including herself. Tamara feels that perhaps 10% of people are pleased, again including herself. We all agreed that Tamara's estimate seemed more accurate. If we consider the economy as our real-world Operating System, this one has some serious defects for most of its users. Deconstruct the eOS and ask, who programmed this system, and why is it so buggy? Perhaps it's because each economic protocol is designed by a seller or an employer. There are two primary relationships in an economy, seller/buyer and employer/employee. When rules or customs are formalized, it is invariably by the seller in a purchase transaction, or the employer in a job situation. Of course not all employers and sellers can make their biases stick, since the other party is free to seek alternative employment or purchases. But in those new circumstances, the rules will also be laid down by the employer and seller. These protocols are bound to favor the protocol-maker, so we'd expect each transaction to be less than glorious from the viewpoint of the buyer or employee, and that jibes with our collective impression. Since there are more employees than employers, and more buyers than sellers, we should expect the majority of participants to be dissatisfied. But there's a disconnect here. All the work is produced by the employees, who are the biggest expenditure in the economy, so most of the money is in their hands as they play their role as the buyers. They have great influence, but their influence is not organized to make the rules of engagement so their transactions remain unsatisfying. The Xpertweb protocol is aimed at the smallest unit in our eOS, the individual transaction. Xpertweb is designed to expose the quality and history of each transaction to scrutiny after the fact. It's a laboratory, really, though one that's designed to be viral enough to grow rapidly. Xpertweb transactions are service-oriented, and it is never assumed the transaction is satisfactory until the buyer says so. Therefore, the service is delivered, no strings attached, to the buyer who must grade and comment on it before payment is due. If the grade is low enough, the price may be reduced, or the work rejected. What's to prevent a buyer from downrating a transaction in order to get a lower price? It's a good question that we'll look into tomorrow. 8:10:31 PM    comment []

© Copyright 2006 Britt Blaser. Last update: 4/17/06; 11:25:43 PM.