Why You Can’t Manage Humans Like They’re Software

Early on at Amazon, CEO Jeff Bezos famously issued a memo about how software was to be built at the company. Teams would share their data through service interfaces, or APIs, the same way that they would share it with an outside customer. That meant that a developer on one team didn’t need to know anything about how another team operated in order to integrate the product it made—he or she could follow the documentation and use that product as though it were an external service. Ultimately, this ease of cooperation became extremely efficient and is what paved the way for  Amazon Web Services—a $6.7 billion business that powers huge parts of the web (including Netflix).

Georgetown University computer science professor Cal Newport recently argued that a similar idea could be applied to humans, or the way that leaders put together teams. By defining each person’s work as a collection of inputs and outputs, leaders could define communication protocols to reduce the overhead of collaboration (often measured in meetings) and allow for greater efficiency in communication across teams and more “deep work.”

This is the kind of extreme stance that Newport is known for—the kind of thing that makes him well known and successful as a theoretical computer science academic and author. I learn a lot from what he writes; I never apply it to the same extent.

When I thought about this idea of “humans as APIs,” I thought of the teams it’s been hardest to work with: How nice it would be if they could just offer an API that I could ping to find out what is going on, or a notification server to which I could subscribe in order to receive well-defined and structured priority updates. What a relief that would be.

But in the end, I don’t think that humans can ever be managed like APIs. Nor would we want them to be.

APIs do have some role in human management. We don’t call them APIs, of course. We call them “social norms,” or “culture,” or —gasp—processes. They’re how we operate effectively, knowing how we get the information we need when we need it.

For example, how do you know the status of a project and what you need to do next? On my team, which organizes projects into two-week chunks called “sprints,” it looks like this:

• As an IC (individual contributor): You go to the GitHub project and pull the next task from this sprint.
• As a tech lead (leading one team working on one project): You look at the overall progress of the sprint, the results of the spike (time-boxed investigation that determines approach) that will influence the next sprint, maybe start thinking about adjusting scope.
• As an engineering lead (someone who manages collections of teams rather than just an individual team): You look at the overall progress versus timeline (however you report that) and either feel good that things are on track, or start asking hard questions.

There are clear processes that determine what the state of things is, which means we don’t need to talk about it to have a clear agreement. Questions can focus on why that is the state right now, how people feel about the state, and discrepancies between expectations and reality.

We don’t just do this with technical things, but softer things, too. A stranger approached me at a an event to tell me that someone from the mobile team had shared with her my practice of responding “have you told them?” whenever someone tells me that they’ve received help from someone else. Over time, the responses I got to that question changed from, “no, and I should” to “yes.” Our culture changed to one of appreciating each other more actively.

Or, think about how we respect organizational hierarchy. As a manager of managers, it’s tempting to ask individual contributors to do something “small,” but it’s appropriate to go to their managers and ask them first—they have a depth of context you don’t (hopefully, and if not, that’s a different problem), and when you go straight to the ICs, you risk overwhelming them and undermining their managers.

But can these “APIs” totally run an organization? I’m skeptical.

The fundamental limitation of human APIs in an organization is that they’re great for sharing information (most of us have them already, though they’re usually undocumented), but they’re poor for decisions. And they miss a key point—trust.

One of the most shocking and exhausting things about stepping into a leadership position for me was the sheer volume of decisions that hit me every day, and the range they encompass: The big ones (Should we hire this person? How many people should we hire? What projects should we commit to? Who do we put on what project?) and the small ones (Can someone take a week off two months from now? What time should the team call be? Do I need to attend this meeting when the last one was pointless?).

There’s no API for these decisions, and the only way I’ve found not to lose my mind is to push some of the decisions down and give people the sphere to make them. Does this bug merit a point release? If someone’s asking me that question, probably yes, but my question back to them is, what makes you ask? Why do you think it might, and what is stopping you from going ahead and taking that action?

Unfortunately, there’s no clear API for coaching either.

Which brings me to the final point—trust. If I ask a computer to add two and two, I can feel very confident that this task will be done to my satisfaction. If I feel it’s necessary, I can add a unit test to validate it.

But the things we ask of humans are messier, more complicated, and not well defined in mathematics. If I follow the information API and learn that a project is off-track, and it’s a team or lead that I trust, I will start with “how can I help?” If there’s no trust there, especially when it’s something we need to rely on, or this kind of thing has happened too many times before, it’s tempting to start with “What on earth is going on?”

There’s a comfort for the mathematically inclined in returning to the certainty and understanding of mathematics, to think in systems and optimize for efficiency of communication between them. These things work, up to a point, but they are too static for the messiness of humans and the chaos of growth. If we leave out trust, and we leave out developing each other, we will never scale.

Cate has led the mobile team and Jetpack engineering at Automattic.