Another specimen my collection of explain it all frameworks.

By way of Making Light this list of nine ways to you can be an accessory to a sin.

• By counsel.
• By command.
• By consent.
• By provocation.
• By praise or flattery.
• By concealment.
• By partaking.
• By silence.
• By defense of the ill done.

This is actually one of a family of frameworks from the Catholic community; ways to keep the conscious vigorous.

For example here’s another your seven capital sins.

• Pride
• Covetousness
• Lust
• Anger
• Gluttony
• Envy
• Sloth

Just by intersecting those seven with the first nine you get 63 ways to get into trouble.

Generally Americans are a forgiving lot. Nixon can be McCarthy’s righthand man or Bush can waste his youth and latter we make them president. It’s almost required that our celebrities spend time in rehab so we can forgive them and welcome them back on the stage. We tend not to keep score about this stuff.

Sometimes, though!

This illustration is lifted from this talk by John Seely-Brown. It’s a nice illustration of how Moore’s friends are more potent than he is.

The order of the last term in that illustration, the value of the emerging network of connection, is very much still in dispute. Metcalf’s law? Reed’s law? Something else entirely. It is a question of what the systems that emerge above the network substrate look like; their topology. It’s a question about group forming. How much centralization, how much diversity, how many groups a single player participates in, how many firms an industry contains.

I’ve been playing with the thought that maybe this is about the outcome of the singularity. If the order of that term is smaller then the machines win; if it’s larger then mankind wins.

This is lifted from Alphie Kohn’s wonderful rant “Punished by Rewards”

• Rewards are only effective at producing compliance.
  • The more rewards are used, the more they are needed.
  • Rewards assume compliance is involuntary and control is necessary.
  • Rewards give power to the rewarder; and reinforces hierarchy.
• Rewards work best:
  • If the recipient is already dependent.
  • If used for short term results.
  • If not intended to alter attitudes or commitments.
  • If already alienated from the task.
  • If the task is simple, and measured quantitatively.
• Why rewards fail:
  • Rewards punish (when not received).
  • Rewards rupture relationships, erode cooperation.
  • Rewards ignore reasons/causes (only results count).
  • Rewards discourage risk-taking and innovation.
  • Rewards undermine interest in the rewarded task.
• Contests and competitions
  • Increase anxiety (by increasing risk)
  • Discourage some from making and effort (calculated loss).
  • Cause people to attribute results to factors outside their control (to maintain self-esteem).

I can’t quite believe that it’s taken me this long to realize this. Particularly because it was five or seven years ago that I spent a great deal of time trying to figure out exactly what it was about Erlang that was whispering in my ear; but now I think I know.

We are seeing the emergence of a third species of the operating system.

The first time this happened was the operating systems built at Parc. At Parc they found that if you wanted to X you needed to let go of Y given that there were limited resources at hand. To get a really fast user interface they had to give up a whole range of standard operating system design principles. The result was a machine that was quantitatively different. The first Macintosh repeated this design pattern. You could tell because experts in traditional operating systems and programming were agast at the corners the Mac folks had cut. Everybody else was blown away by what they had achieved.

A new species of OS emerged; the Desktop OS by mutating off of the real OS. This mutant rejoined the main stream, though it took 25+ years. These days we expect a rich UI, deep internationalization, human response visual time-constant interaction from all operating systems.

For the last five to ten years I’ve been interested in the emerging network OS. Aka: “The network is the machine.” Look! Two definite pronouns in one slogan: the network, the machine. Talk about monopoly! The key puzzle is who will own, or who will govern, that great network OS. Hence my interest in standards.

Aside about the structure of that problem … Operating systems are two sided network effects. They bridge between applications and hardware. Bridges are good places to put up a toll booth, a central authority, or a monopoly. So open standards are a way to try and keep the network operating system rasonably free. They are key to the maintenance of the end to end principle. Key to avoiding a single point of failure, and reliable. Key to a reasonably priced information super highway for the planet. So this particular OS is pretty contested turf.

Ok, so that’s two species of OS: the network kind, and the regular kind. What about this new kind?

New species arise when the environmental pressure take on a new shape and a niche exist long enough to tolerate the mutations With luck you get a totally new kind of beast. Of course at first it’s just an ugly mutation of the old beasts. The valuable mutations, for a new species of OS, are the ones that respond to powerful new pressures and the shape of the niche. I think you can see that happening at places like Google.

Go read these two postings, and then skim the third link. Rich Skrenta makes the case that Google runs the worlds largest computer and most advanced operating system. Then Jason Corace picks up the ball and thinks about what this OS has for major subsystems. Those subsystems (all the world’s public data, delivery platforms close to the clients, unique hardware muscle) are analagous to how the Mac had subsystems like resource management and windowing that at first blush seem just a plug-in but after a while totally change the nature of the game. Finally skim this list of papers, notice the domain name.

This is not just Google! Every one of the massive apps on the web – Amazon, EBay, Yahoo, AOL, HotMail, Passport, DoubleClick, etc. etc. – are solving an analagous problem. These apps create the demand for a new species of operating system. One with massive pools of computers. One where mind bogglingly large amounts of data. One with extremely cheap cpu/bandwidth/storage. One distributed globally. Possibly most interestingly one with a deep invasive model of their users.

Since each of these examples is each emerging inside their own bubble we are likely to get more than one of these – at least for a while. Each one of these is a network hub for some aspect of the culture/economy/internet. They all have to tackle similar design problems; just for example getting fast response for the entire long tail of the power-law curve.

So there it is. Three species of OS. Traditional, Network, and Hub. Each with it’s own niche that’s sufficently different that they should evolve very different beasts.

Three phases of creating a public good.

• Getting the parties into the room.
• Reaching a bargain: Keeping the parties in the room.
• Maintaining the agreement after the fact.

In the first stage the key is to find sufficient common cause that the parties are willing to invest in the enterprise. I can’t count how many meetings I’ve attended where some people thought they were at the second stage, since they were in a room, but in fact they were still in the first stage.

In the second stage the key is to know what’s fungible. The challenge is to search for things that can be rearranged. Again I’ve often gotten people in a room only to discover that all the resources are immovable. At that point you need to revisit the urgency of the situation.

The first and third stage are curious because both of them depend upon a common understanding about how things work. A commitment to along term agreement and it’s maintenance over time.

I’m amused by the parallel that can be drawn between these other triplets: exit, voice,and locality; or culture, market, structure.

See also: Getting to yes

This is a list of various “rights” regarding projects that firms need to allocate to one or more parties. That’s a design problem that when poorly solved leads to too much or too little conflict. I gleaned this list from a paper I was reading yesterday (thanks Karim).

• Right to make decisions
• Right to initiate projects.
• Right to ratify projects.
• Right to implement projects
• Right to monitor projects.
• Right to evaluate projects.
• Rights to own or capture the residuals created by projects.
• Rights to stop projects.

Most institutions are in a continually renegotiating these things; it’s exhausting. Most of the literature on stage gates is an attempt to provide people with a template for taking the conflicts implicit and by proscribing a ritualized version of them reduce the amount of resources expended renegotiating them.

The paper gets to talking about what I call “swooping;” i.e. where management swoops down like a seagull grabs your dinner out of your hand and takes a crap on your head. In the paper it’s call “selective intervention.” The problem with swooping is that it causes the subordinates to raise their hurdle rate and back off their investment in the task at hand. Stage gates are, for all there many flaws, a way to try and frame up a contract about swooping, monitoring, evaluating.

I’m forever fascinated by how hard it can be to get the right to stop a project.

I must have read  “Implementation Games: What happens when a bill becomes law” 20 years ago; it  enumerates all the various ways that big projects can implode.  It is a useful list.

The list is based on the author’s study of some large projects.  These projects are the really hard ones.  For example, trying to create jobs in a poor section of town.  Tough problems are the ones that culture, structure, and markets have all failed to solve.  The ones where Government is left holding the bag, trying to create public goods from scratch.  Needless to say most projects like this fail.

The author grows kind of pessimistic toward the end of the book. I don’t think he appreciated how hard the problems he studied really are.  That said, he collected quite a list of syndromes.  They help in diagnosing when things are going south. Avoid these tar pits.

One of the syndromes he names is “piling-on.”  It is the tendency for projects to accept an increasingly long list of goals and requirements overtime until such time as there isn’t a chance they can successfully execute on any but a small subset. This syndrome combines well with “Budget Games” since each time a new goal get’s added it is often possible to capture a bit more budget to help pay for it. Together they can make for some really amazing failures.

• Diversion of Resources
  • Easy Money
  • Easy Life
  • Budget Games
  • Pork Barrel
• Deflection of Goals
  • Piling On
  • Vague Mandate
  • Keeping the Peace
• Limits to Administrative Control
  • Tokenism
  • Massive Resistance
  • Incompetence
• Dissipation of Energy
  • Stubbornness
  • Turf Battles
  • Not our Problem

I doubt it’s still in print, so if you want to read this you probably have to go do a good library or possibly in the used book market.

I’m a sucker for these models of a messy real world thing that attempt to explain it all; particularly if they include a drawing.

Anecdote of the Jar
Wallace Stevens

I placed a jar in Tennessee,
And round it was, upon a hill.
It made the slovenly wilderness
Surround that hill.

The wilderness rose up to it,
And sprawled around, no longer wild.
The jar was round upon the ground
And tall and of a port in air.

It took dominion every where.
The jar was gray and bare.
It did not give of bird or bush,
Like nothing else in Tennessee.

Ken Coar’s cute B-School model of the universe of acquantances reminded me of this little catagorizing framework.

While I’m at it I might was well toss in this model of the stages of a project
I picked up somewhere and then reengineered for to explain to my children how to go about carving a pumpkin.