Rob and I were sitting in a coffee shop on Castro. I’d come to him for career advice and he immediately made my dilemma worse by describing what he was doing with Mechanical Orchard. Would I be interested in joining?

‍

As he described the Mechanical Orchard model I got increasingly excited. Here was a way to directly connect excellence in software engineering to superior business results (more on that in a later post).

‍

Digging deeper into Mechanical Orchard’s build/run model, I’m struck by how many different ways this is a superior model. I gain confidence from the double/triple/quadruple validation. Today I’m digging into an aspect of the model that dovetails with some of my other work on business relationships: responsibility.

‍

Consequences Flow to Power

I recently got miffed reading posts proclaiming “I take full responsibility…” when it didn’t look like anyone was taking responsibility in any way I understood that word. Responsibility to me is when consequences flow towards power. The sign in the glass store declaring, “You bump it, you bought it,” that’s responsibility.

‍

You bump it, you bought it

‍

Mechanical Orchard is in the business of reviving vintage software. We replace vintage applications piecemeal, then operate those applications as long as the client wants us to.

We don’t offer the only way to replace vintage software. Let’s look at a couple of alternatives from the perspective of responsibility. The key question is, “Where do consequences flow?”

‍

Big Bang

Consequences flowed away from power

‍

You go to a big consultancy. You buy a “digital transformation” package. Hundreds of programmers swarm to code up a wholesale replacement of your vintage applications. You try to put it into production. It just doesn’t work. You throw it away, lick your wounds, and try again in a few years.

‍

What went wrong? One explanation is that consequences flowed away from power. The developers weren’t responsible, in the sense I’m using that word here. The programmers made lots of decisions, but they didn’t have to live with the consequences of those decisions, you did.

‍

The programmers don’t have to be sloppy or greedy for this arrangement not to work. They simply don’t have a feedback loop that encourages them to learn what to do and what not to do. Even the best intentions can’t overcome a flawed relationship structure.

‍

The diagram above is the extreme form of handoff. We mitigate the risks with gradual handoffs, service contracts, and so on but the structural problem remains–overall consequences do not flow to power.

‍

Pivotal

… the balancing act of operating the software while continuing its evolution

‍

The Pivotal Labs model recognized the lack of responsibility in the Big Bang relationship. Rather than have development be the sole responsibility of the consultancy, Pivotal contracts specified co-development with the client. Pivotal developers would pair with client developers so when the time came, client developers would be better prepared to deal with the consequences of the decisions they were making.

‍

‍

The Pivotal model was popular and successful, building a billion dollar business and growing to thousands of employees. However, the structural weakness remained–the consequences for development decisions mostly flowed to someone who hadn’t made those decisions. Clients were not always prepared for the balancing act of operating the software while continuing its evolution.

‍

Build/Run

MO’s expertise is incremental replacement and effective operations

‍

Mechanical Orchard replaces vintage applications one at a time, then operates those applications while evolving them. The timelines looks like this:

‍

‍

If the software is difficult to operate, if it’s unreliable, if it is difficult to change, Mechanical Orchard pays the cost. (I like to look at this positively–the better job MO does, the more successful our business.)

‍

This model won’t be applicable for all clients. However, for clients hobbled by the inflexibility of their core software and without the desire to create superior software operations, we align who develops and who experiences the consequences of development decisions. We take responsibility.

‍