September 25th, 2018 · 26 comments
An Idea Revisited
Last week, I wrote an article exploring the idea of using human APIs to optimize value production in knowledge work organizations. It generated fascinating discussion both in my email inbox and the post comment thread.
To help prod this discussion forward, I thought it might be useful if I try (not necessarily successfully) to respond to a few of the more common concerns I heard about the hAPI concept…
Concern #1: Human APIs would induce stultifying bureaucracy.
The idea of implementing strict routines for professional interaction conjures hellish images of TPS reports and forms filled out in triplicate.
This is a reasonable fear. To create a bureaucracy, however, requires more than just a commitment to systems, but also an obsession with these systems that becomes divorced from the actual objectives of the organization. This requires special circumstances, such as an organization becoming large and slow enough, with sparse enough competition, that it can support ranks of career bureaucrats without promptly going out of business.
It’s perfectly consistent to imagine a firm that embraces the structure of hAPIs, but also maintains an obsessive focus on producing value, dynamically adjusting these protocols as needed whenever they notice undue friction or discover a more effective alternative.
Keep in mind, for example, that the original Ford assembly line was incredibly systematic and rigid as compared to their older method for building cars, but this structure yielded, at least at first, a much more profitable and dynamic company.
Read more »
September 18th, 2018 · 30 comments
The Bezos Mandate
In 2002, Amazon founder and CEO Jeff Bezos sent a mandate to his employees that has since become legendary in IT circles. It reads as follows:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn’t do this will be fired.
- Thank you; have a nice day!
This directive, which some informally call Bezos’s “API Manifesto,” transformed Amazon.
To be sure, transitioning to these formal APIs made life harder in the short term for its engineers. It was also expensive, both in terms of the money spent to develop the new interfaces, and the time lost that could have been dedicated to projects producing immediate revenue.
But once the company embraced Bezos’s mandate, it was able to operate its systems much more efficiently. It also enabled the launch of the public-facing Amazon Web Services, which now produces a much needed influx of profit, and allowed Amazon’s web store to easily expand to encompass outside merchants, a key piece in their retail strategy.
The impact of the API Manifesto has since expanded to the IT industry as a whole. From start-ups to massive organizations, the idea that information systems are more valuable when interacting through clearly specified and well supported API’s has become common.
Last week, for example, the cofounder of an IT firm told me the story of how he helped a large financial services firm implement an API for a set of services that were previously accessed in an ad hoc manner (think: batched FTP).
It cost the firm a little over a million dollars to make this transition. He estimates it now helps them earn an additional $100 million in revenue each year through a combination of cost savings and the new customer acquisition applications enabled by providing a clearly specified and accessible interface for these services.
On Attention Capital
When I heard about the API manifesto, a provocative thought popped into my head: could these same underlying ideas apply to communication between people?
Read more »
September 11th, 2018 · 23 comments
As I transition from the slow freedom of summer to the constrained energy of fall, my thoughts have been gravitating back towards nuts and bolts productivity issues. One topic that keeps catching my attention is the distinction between habits and workflows.
When most people talk about personal productivity, they tend to focus on improving the habits they deploy to wrangle their work. For example, batching email, or deploying time blocking to control the flow of their day (which, as longtime readers know, I highly recommend).
There is, however, another relevant layer: the underlying workflows that dictate what you work on and how this work is executed. For example, if you’re a project manager at a consulting firm, and you spend much of your day emailing back and forth with your team members to get answers to questions from your clients, this behavior is an implicit workflow that dictates that asynchronous, unstructured messaging is your preferred method for extracting relevant information from your team.
Read more »