In a dotcom startup that made it big? Were you a founder? Early employee?
Something like that. I designed a customer ticket tracking system that decreased customer-perceived latency of cases handled by email (using a novel scheduling technique derived from the Theory of Constraints), improved interdisciplinary co-operation across a physically and organizationally-distributed workforce, and enabled private-label support for OEM clients without needing dedicated staff for each client.
It made a huge difference to the ability to land private-label deals while keeping the overhead for each deal low, as well as easing product-line integration as the company expanded. In terms of value to the company, it was probably worth at least $20-30million during the time I worked there. I probably should’ve asked for more options. ;-)
And the skills required for this were? Programming experience and your innate intelligence, plus a modicum of business sense and what we would call rationality here?
And the skills required for this were? Programming experience and your innate intelligence, plus a modicum of business sense and what we would call rationality here?
I don’t think that much of what gets discussed here would’ve helped much or been particularly relevant. It was more a matter of knowing what I wanted and what the company needed, as well as my previous 12+ years practical experience about what people will and won’t do when confronted with a computer program that they don’t necessarily want to use in the first place.
It was a problem of whole-system design, including both social and HCI aspects. For example, many characteristics of the system were designed specifically to promote viral adoption of the software within the company, as well as to create subtle social pressures towards customer- or company-beneficial behaviors. I had previously apprenticed under a teacher who taught me the social dynamics of business, as well as the art of designing systems that merged machine and human information processing with social manipulation to achieve business goals. (Specifically, in the field of real estate office management software, but the lessons were pretty universal.)
In a way, you could say my understanding of irrationality was at least as important, if not far more important, than my understanding of “rationality”. (Though I learned a lot of instrumental rationality principles during my apprenticeship as well.)
For example, many characteristics of the system were designed specifically to promote viral adoption of the software within the company, as well as to create subtle social pressures towards customer- or company-beneficial behaviors.
That sounds interesting. Could you provide some examples?
That sounds interesting. Could you provide some examples?
Well, one of the more obvious social pressures was the WCD metric, which showed up at the case and queue levels as part of the normal display. Cases were advisory-locked by working on them, and this information was shown as part of the queue display, making it obvious who’s working on something that’s part of a case, and who’s not. The last person to send a response to the customer was visible, to encourage people to prefer to continue work on the same case, but to take over if the person isn’t around. The WCD metric was also designed so that a customer never had to wait in queue a second time due to needing to email back for clarification, since what WCD measures is how long customer(s) are waiting for the resolution of an issue, rather than the duration of a single pass through the queue, or how long the customer sat around between responses. IOW, WCD was a “chess clock” timer, such that a response by the company stopped the timer until the customer made another move.
One of the viral aspects was that it was extremely easy to do all sorts of interdepartment workflows, but nobody was penalized for foreign WCD. If you transferred a case that the customer’s been waiting three days on, every department that sees it is going to prioritize it as if it’s been waiting three days, even if they’ve only just seen it now. The ease of relationship made departments demand that any department they relied upon use it, since it meant they could immediately begin a customer response as soon as they got what they needed. And departments that were receiving delegations by email from other departments, wanted to get on it so they could track the stuff.
I arrived at these design features by starting with the fundamental design dynamic of groupware, which is that nobody will ever do any work to put information into groupware unless they perceive a benefit to themselves. ;-) (There are some other dynamics, of course, but they’re not coming to me at the moment. I do not really design by consciously factoring all these principles; my designs are the output of searching for ideas within an intuitive space roughly defined by the principles.)
I used a similar set of principles in the design of WSGI and setuptools, in the sense of taking into account certain social/investment dynamics for WSGI, and prisoner’s-dilemna/viral adoption principles for setuptools.
What does WCD stand for? (“whole case delay”?) Are we supposed to know? If you mean for it to be opaque, you could signal that by putting it in quotes (“WCD metric”) the first time.
What does WCD stand for? (“whole case delay”?) Are we supposed to know? If you mean for it to be opaque, you could signal that by putting it in quotes (“WCD metric”) the first time.
Hm, I could’ve sworn I spelled it out somewhere abovet, but can’t find it now. “Weighted Customer Delay”. It’s roughly analagous to TDD (Throughput-Dollar-Days) from the Theory of Constraints, only measured in customer-hours rather than dollar-days.
In a dotcom startup that made it big? Were you a founder? Early employee?
Something like that. I designed a customer ticket tracking system that decreased customer-perceived latency of cases handled by email (using a novel scheduling technique derived from the Theory of Constraints), improved interdisciplinary co-operation across a physically and organizationally-distributed workforce, and enabled private-label support for OEM clients without needing dedicated staff for each client.
It made a huge difference to the ability to land private-label deals while keeping the overhead for each deal low, as well as easing product-line integration as the company expanded. In terms of value to the company, it was probably worth at least $20-30million during the time I worked there. I probably should’ve asked for more options. ;-)
And the skills required for this were? Programming experience and your innate intelligence, plus a modicum of business sense and what we would call rationality here?
I don’t think that much of what gets discussed here would’ve helped much or been particularly relevant. It was more a matter of knowing what I wanted and what the company needed, as well as my previous 12+ years practical experience about what people will and won’t do when confronted with a computer program that they don’t necessarily want to use in the first place.
It was a problem of whole-system design, including both social and HCI aspects. For example, many characteristics of the system were designed specifically to promote viral adoption of the software within the company, as well as to create subtle social pressures towards customer- or company-beneficial behaviors. I had previously apprenticed under a teacher who taught me the social dynamics of business, as well as the art of designing systems that merged machine and human information processing with social manipulation to achieve business goals. (Specifically, in the field of real estate office management software, but the lessons were pretty universal.)
In a way, you could say my understanding of irrationality was at least as important, if not far more important, than my understanding of “rationality”. (Though I learned a lot of instrumental rationality principles during my apprenticeship as well.)
Very interesting. And you must have been, what, 30 when you did this? 35?
That sounds interesting. Could you provide some examples?
Well, one of the more obvious social pressures was the WCD metric, which showed up at the case and queue levels as part of the normal display. Cases were advisory-locked by working on them, and this information was shown as part of the queue display, making it obvious who’s working on something that’s part of a case, and who’s not. The last person to send a response to the customer was visible, to encourage people to prefer to continue work on the same case, but to take over if the person isn’t around. The WCD metric was also designed so that a customer never had to wait in queue a second time due to needing to email back for clarification, since what WCD measures is how long customer(s) are waiting for the resolution of an issue, rather than the duration of a single pass through the queue, or how long the customer sat around between responses. IOW, WCD was a “chess clock” timer, such that a response by the company stopped the timer until the customer made another move.
One of the viral aspects was that it was extremely easy to do all sorts of interdepartment workflows, but nobody was penalized for foreign WCD. If you transferred a case that the customer’s been waiting three days on, every department that sees it is going to prioritize it as if it’s been waiting three days, even if they’ve only just seen it now. The ease of relationship made departments demand that any department they relied upon use it, since it meant they could immediately begin a customer response as soon as they got what they needed. And departments that were receiving delegations by email from other departments, wanted to get on it so they could track the stuff.
I arrived at these design features by starting with the fundamental design dynamic of groupware, which is that nobody will ever do any work to put information into groupware unless they perceive a benefit to themselves. ;-) (There are some other dynamics, of course, but they’re not coming to me at the moment. I do not really design by consciously factoring all these principles; my designs are the output of searching for ideas within an intuitive space roughly defined by the principles.)
I used a similar set of principles in the design of WSGI and setuptools, in the sense of taking into account certain social/investment dynamics for WSGI, and prisoner’s-dilemna/viral adoption principles for setuptools.
Thank you, that’s very interesting. I need to remember those techniques, some of them may come in handy later on.
What does WCD stand for? (“whole case delay”?) Are we supposed to know? If you mean for it to be opaque, you could signal that by putting it in quotes (“WCD metric”) the first time.
Hm, I could’ve sworn I spelled it out somewhere abovet, but can’t find it now. “Weighted Customer Delay”. It’s roughly analagous to TDD (Throughput-Dollar-Days) from the Theory of Constraints, only measured in customer-hours rather than dollar-days.