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.
Concern #2: Human APIs would kill creativity.
It’s commonly believed that creativity requires free-form discussion and thinking. Accordingly, too much structure around work processes would suppress this spark.
I think this concern is based on an overly-limited vision of hAPIs. One could imagine, for example, an hAPI that includes regular, unstructured, in-person discussions, or provides a clear mechanism for instigating a brainstorming session when inspiration strikes.
Nothing about the hAPI concept requires that communication be restricted to succinct, asynchronous, electronic missives. If anything, the exercise of understanding clearly what type of communication and coordination is most useful, and thinking about how to optimize this behavior, could help creative teams reach a new level of effectiveness.
Concern #3: Human APIs would limit human interaction (making everyone miserable).
Some fear that structuring communication would impede the casual conversation and serendipitous encounters that play a key role in modern organizational life.
To me, however, there’s a clear difference between formalizing standard communication and eliminating casual interaction. An organization that deploys hAPIs could still encourage chatter over coffee and in the lunchroom, or shooting the breeze in a friend’s office to recharge after a hard work session.
Making regular communication more effective doesn’t require that you squash the irregular variety.
Count me in the group that thinks hAPIs should impractical, stultifying and well nigh impossible to actually function. However, I can easily imagine that I’m thinking of something fairly different from you. Perhaps a detailed example would help close the gap.
I fully agree with the points about bureaucracy and creativity – but saying that on a day to day basis all staff will be able to…
1. Differentiate “regular communication” from “irregular communication” and…
2. Avoid gradually slipping into the habit of treating the two types the same way
…looks a little bit wishful at first glance.
I am with an organization where human interaction is currently being formalized and regulated. An unanticipated side effect is that informal interaction is suffering due to time constraints. Originally this informal interaction was one of the main goals of the organization, but the powers that be want things to be more efficient. I am curious to see how things will turn out as this social engineering experiment continues.
All valid criticisms and potential risks.
Correct me if I’m wrong. You’re only talking about the thought experiment of limiting communication to certain streams/modes. Not advocating for specific communication streams. As you specified, this communication does not have to be digitized. The process for communication could be specified as having to occur in person. One example I used to employ at an automotive plant was to say “if you didn’t verify with the person face-to-face, you didn’t communicate.” It was procedure for certain tasks that they HAD to be communicated in-person or they “didn’t count.” Other items were handled with, if you didn’t send an email and copy me, then you didn’t truly do it. Honestly, putting those requirements in place was a big piece of turning things around.
Overall, isn’t this just an extension of your earlier articles/ideas about workflow and limiting email and social media?
Dear Cal,
have you ever considered ethics behind some of the efficacy methods…
for example Jeff Bezos keeps “pioneering” cost cutting ideas without considering their human costs,( well after all he has made billions by that and even has been admired for having modern day slavery ( most people working in amazon make less than minimum wage according to Vice news journalists) any thoughts? I feel like this obsessions with efficiency at times goes too far and I hate to see you join the club.
https://www.theonion.com/jeff-bezos-tables-latest-breakthrough-cost-cutting-idea-1824144898
#atetheonion
huh?
https://www.urbandictionary.com/define.php?term=Ate%20the%20Onion
The Onion is a satirical publication. To “eat the Onion” is to mistake satire for news.
I am aware of that ( though didn’t know the what ate the onion means!) ,however from the time of George V , satire was sharply used to point out painful realities that were ignored by the masses and in this case experts. when I mean modern day slavery I do not literally mean that….well anyways you get the gist of it hopefully.
Hi there, I think this is a very interesting idea; however i believe it has a major flaw. No human is the same, and some people communicate best through writing, while others through face to face interaction. I work for a state government agency developing policies and procedures, and I’ve seen many communication issues resolved by switching the mode of communication to one that better suits the other party.
Dear Cal,
I’m sure I’m not the only subscriber of yours who doesn’t have a clue what “human API” means.
Would it kill you to define such terms so you can bring all your readers along with your thinking?
I subscribed to your content because I read and appreciated (and wrote about) one of your books. But I won’t last on your list if you use such opaque insider language that is foreign to me.
Hi Marcia! That’s such a good point. Not knowing the terminology can be a turn-off. I’ve not explained this before but: An API stands for Application Programming Interface. It refers to the constraints of code when two different elements (a website or an app on a phone) of code speak to each other. Such as logging into a website using Facebook or adding a calendar invite to Google from event ordering software.
When you log in on a website with Facebook, the website you’re on sends a call to Facebook asking if this user exists. Facebook answers back yes, info correct and you are able to log into the site.
Hope that helps!
“APIs enable software applications to request information or perform tasks in other software applications.” – https://medium.com/@alasaarela/the-human-api-f725191a32d8
I think in this context he’s talking about enabling people to request information or to perform tasks, in a thoroughly defined way.
I’m with you Marcia. I’m not native, but I do read in English, I write scientific papers in English, but recently I feel lost here not knowing what it is all about.
Thank you for pointing that out!
Creativity often thrives with limits. Going into a design project with a “do what you think is best” attitude from a client can be overwhelming. While I certainly impose my own constraints at that point, there can be a delightful challenge to going into a project with a “do what you think it is best within these constraints”. It’s kind of exciting – like the scene in Apollo when they have like 20 items on board the ship to fit a square into a circle. (sans people’s lives on the line)
Sounds like a delightful excuse to produce a massive document that no one reads.
Sort of like company wide code standards at a company I once worked for.
I think it would make most sense for each person to intentionally create an hAPI for themselves based on their goals and their environment, that can evolve. Having been to a high school which took pride in “enforcing discipline and obedience” (read as enforcing hAPIS) at the expense of destroying students’ innate interest in learning, I would be against a top-down one size fits all hAPI. I would ideally prefer a more bottom-up hAPI, in an environment where everyone respects each other’s hAPI. Top-down APIs could be allowed only after sufficient consensus and understanding of the reasoning behind it. Sometimes new bottom-up hAPIs may take time to put in place, so each individual could request the organization or his/her environment to keep him/her accountable.
Managing Oneself by Peter Drucker is a great article which has some practical strategies on this thought of creating your own hAPI: https://sbuweb.tcu.edu/jmathis/Org_Mgmt_Materials/Managing_Oneself.pdf
hAPI sounds good in theory but the person who is able to create side channels through contacts and water cooler interactions would gain an advantage in such a system
When you are into this you need to break your inner self and mix some from your subordinates just to create a great out come.
To truly thrive, what we all need to focus on is the “human API”
What is an API?
Would a project management methodology like SCRUM be an example of a hAPI?
It creates a common protocol for a team.
It creates regular scheduled communication with clear expectations of actions to be taken before the next meeting. It is optimized for action…specifically the next action.
I looking for a concrete example of what we can observe in our our world today that would be a good example.
APIs do not exist in a vacuum. They are strictly defined interfaces to accomplish interoperability between independent and atomic units of objectives. Morning Star, the tomato processing company, has Colleague Letters Of Understanding (CLOU) that mediate contractual relationships between independent units within the company. Human APIs mandated within a hierarchical structure would, of course, be stultifying and repressive because it is another layer of control on top of the visible hand of management. I think the correct software analogy is a restricted file format, not an API. On the other hand, establishing standardized protocols for contracts between independent and empowered teams is I think a great idea.
This idea reminds me of the Core Protocol by Jim and Michelle McCarthy, which I read about in their book _Software For Your Head_ (https://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566) . May be worth a look to see how others have designed this API.
given your information help to reduce the communication bugs. project management method is the most important thing because by the help of it we get success. it tells about any project status to clients and management.
https://onlinewritersuk.blogspot.com/2019/03/4-technologies-to-introduce-in.html
Can’t agree more. All the three points are greatly explained. If you could have explained in video, it would have been much better. https://abstract.tube/