When ‘API’ means ‘Advisory Partner Interaction’

Profile picture for user Peter Coffee By Peter Coffee August 18, 2015
Summary:
Let’s build vocabularies of advisory partner interaction that are at least as powerful as our machines’ APIs, says Salesforce's Peter Coffee.

[caption id="attachment_6249" align="alignright" width="300"]Peter Coffee Peter Coffee[/caption]

When people talk about becoming a “digital firm,” or talk about so-called “Millennial” workers/customers as being “digital natives,” they’re often talking about the technologies that people and companies use – and sometimes, the ways that people and (more rarely) companies behave. They often stop at first-order observations of individual people and isolated teams.

Are we missing the point, and leaving much of the value on the table, if our individual nodes of digital innovation are interacting as if it’s still the 1990s? Should we ask if the digitization of the person or the company is no longer the frontier of highest return? Should our view now, perhaps, zoom out to look at changing higher-order choices?

Sometimes, the ‘natives’ are clueless

Breathless use of the d-word often leaps too far, as if knowledge of methods implies mastery (or even just a basic understanding) of key principles. Digital natives? “Young people’s engagements with digital technologies are varied and often unspectacular,” found one unsparing study of this notion.

For that matter, if a “native” of an environment is defined in part by distinctive knowledge of local threats and opportunities, then we should take note of other findings that university students “have very low digital security skills”; that “the biggest gap between perceived [Internet] skills and actual skills is persistently found among young people (15-29 years old).”

If the natives (of any age) overestimate their individual competence, it seems even more likely that they underestimate their failures as groups. We know, in particular, that problem-solving teams equipped with impressively “digital” tools make higher estimates of their own performance than other teams not so equipped – even when the tool-users produce “significantly worse” results.

Human nature is hard to change, but perhaps there’s hope in devising different models of interaction among people – and among the organizations that they compose. Ironically, after decades of complaining that computers are too impersonal, we might find that we can learn things from machines that help people work better.

From arm’s length, to arm-in-arm

It’s certainly not common to say, “Let’s see if we can learn from the machines.” Rather, we have a long human tradition of building machines that badly mimic nature: of trying to build the first crude airplanes as flapping-wing contraptions, or of using paddle-wheel propulsion for early steam ships that was consciously (but inefficiently) modeled on ducks’ feet.

Such nature-inspired engineering, or “biomimetics,” has been more successful of late with observations like those that led from burdock seeds to Velcro—or from sharkskin to faster sailboats and lower-friction pipe linings—but what if we looked at some of the ways we’ve found to improve machines? What if we asked if human nature could be enhanced by machine behaviors, instead of the other way around?

What’s especially worth considering is a lowering of taken-for-granted boundaries between traditionally separate companies. We’re used to the idea of arms-length relationships between buyers and sellers. We’ve long had a Latin phrase, caveat emptor—dating from sometime in the early 1500s—to describe that separation of interests.

We act as if adversarial negotiation is the least bad way to maximize overall benefit – but there’s a common scenario, the so-called “Prisoners’ Dilemma” thought experiment, that’s long been used to highlight the “worse for everyone” outcome of “best for me” behavior.

Interestingly, a simple modification of the basic game offers participants the option of letting a (potentially automated) mediator play on their behalf: the outcome can be no worse if only one player chooses that option, but the payoff improves substantially when both players do so. Is that a crack of light showing through an opening door?

We’re already using some machine-world ideas to enable such improvements in collective performance. We rely, for example, on the “backoff” algorithm of the Ethernet to get our data sent faster…by waiting for others’ transmissions. On limited-access highways, we rely on the counterintuitive “wait a moment” of the ramp metering signal to increase average speed.

How else might we lower our defenses, to our overall advantage?

Open to interaction

We’re starting to take more seriously the idea that former “vendors”—against whom we used to defend ourselves—might better be seen as cooperative and even advisory “partners.” In the same way that today’s applications are becoming orchestrations of APIs, we’re seeing today’s companies becoming confederations of service providers who each contribute distinctive (and costly to duplicate) expertise.

Increasingly, we’re not even aware of those confederations’ boundaries: we don’t care, and we don’t need to care, that the spare parts we urgently needed were delivered more quickly because FedEx was optimizing their pre-positioning. To the customers, that faster delivery is an attribute of the brand with which they chose to do business, which in turn chose background services and delegated the domain-specific decisions. There’s no reason not to think that way.

bungled-personal-flight-attempt-1
Some ideas just don't fly

Service marketplaces, whose offerings are individually available to everyone, can still be shopped and combined and configured in ways that create real competitive differentiation for in-the-middle brands. Moreover, these economics are extending their reach, as the frictional losses of company-to-company service interoperation continue to decline.

Some will argue that it’s always possible to achieve decisive advantage precisely by doing everything differently than anyone else: by taking the position, “If anyone can use it, how can we be the best?” It’s possible, but it’s probably not cost-effective.

In fact, programmers of a certain age will recognize this as precisely the argument that was made for building applications in low-level machine language, rather than accepting the perceived performance drawbacks of a more machine-agnostic tool like the C programming language (back when that was still a new thing). It quickly became apparent that the ability to hire those machine-level coders, and to innovate in the quicksand environment of that low-level code, was more myth than reality.

When your shopping trip is a safari through a wild jungle of predatory vendors, you’ll behave in ways that make sense in those conditions. If you wear the same protective gear (and carry the same kinds of weapons) in an urban shopping mall, you’ll be considered eccentric at best and may even be barred from the premises entirely.

We work today in a much less hostile environment than the one that gave birth to “let the buyer beware.” Let’s build vocabularies of advisory partner interaction that are at least as powerful as our machines’ APIs.