How does Conway’s Law impact the way we build effective internal communication within API-first companies?

When we write about web APIs, we inevitably focus on one of two things: The technicalities of building the application itself, or the target market and user base that consumes the API.

Something that is often forgotten, however, is the network of people in place to support the product. The company structure and culture behind an outward facing API is important, but is often lost among your average employee who may rarely encounter these support networks. In many (but not all) cases, API product teams represent anywhere between one and a handful of developers assigned to keep an eye on the application.

These days, companies are increasingly focusing on the people behind the business. The result of this is that marketing, sales, operations, support, and development teams are encouraged to take an active interest in what other departments are doing.

Despite this, APIs that aren’t core products often remain a mystery to other employees; they may be seen as something highly technical and untouchable, or as a quirky side project that a couple of developers love to tool around with.

When a team appears to act in a silo, with other employees having very little idea of what their APIs do, the implications for their development are troubling; there’s a significant disconnect between API team(s) and the rest of the company. Below, we’ll be looking at how to address this.

Beyond Conway’s Law

Conway’s Law was defined by Mel Conway, a famous computer scientist who defined a seminal theory on organizational structure:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
– Mel Conway

To put it another way, “the way we communicate has an impact on the things that we build.” That’s how Ronnie Mitra, director of API Design at the API Academy, put it in his talk at our 2017 Platform Summit:

Ronnie adds that what we build can’t change on its own: “We haven’t gotten to the point where things that we deploy can change because requirements change. Change only happens because people make change happen.*”

He stresses this by making the point that everything in a business is interconnected. Especially in today’s microservices architectures, our communication structure is embedded into the tooling we provide:

Organizational structures for microservices architectures certainly follow Conway’s Law. Source: Microservice Architecture, O’Reilly.

Mitra explains that this is a key reason why we MUST be more “empathetic towards people who build products.” Without that empathy, there’s a risk that API developers will build products that don’t represent the needs of their company, its employees, or its users.

Embracing Autonomy

In his talk, Mitra provides examples of several successful companies – including Netflix, Amazon and Spotify – that are champions of autonomy; “the people who do the work are able to have authority over what they do.”

But there’s a lot more to that process than just pushing all decision making from C-level execs, to whom Mitra refers as enterprise architects, to service developers; the idea of centralized vs decentralized decision making is, as Mitra believes, vastly oversimplifying things. Nor does it address the fact that other employees may view (API) devs as a silo.

He uses an existing model of decision making…

…to build a model for activity mapping, Ronnie’s homegrown method for distributing responsibility, and for identifying where talent is needed. In this model, we can see that most decisions (and the context that informs them) actually involve several different groups of people. According to Ronnie, this model grants us a way to address the concerns of control and risk while still providing some autonomy.

API’s Got Talent

Halfway through his talk, Mitra states that “increased autonomy requires better talent.” It’s difficult to argue with that statement, given that previous experience provides a more rounded approach to software development (or any other discipline for that matter).

But, whether it’s down to budgets or time-intensive hiring processes, companies rarely get the chance to stock their roster with only A+ talent…at least, not right away. It’s for that reason that distribution of talent is critical.

Activity mapping can help identify what the most important decisions are, but you probably already have a pretty good idea of which decisions concerning your API have the biggest influence because they’re the ones that keep you up at night.

• Which languages should we use?
• Should I build new versions or deploy continuously?
• Is the API we’re building better suited to public, private, or partner use?

And, if you really want to put your executive hat on, where is the money for doing X, Y or Z going to come from? Successfully answering these questions also helps to clarify the purpose of an API and make it more accessible to the company as a whole.

Improving Efficiency

In his talk Mitra mentions a book titled Time, Talent, Energy that talks about “organizational drag,” or the accidental complexity of interaction. In most cases, he says, this refers to meetings and those endless email chains that seem to take hours to resolve.

Mitra jokes that, for most developers, talking about improving efficiency can be a little scary. “Or it scares me anyway,” he says. But along with motivation and energy – which we’ll look at more closely below – time is a huge factor when you’re trying to put out a great product.

We’ve already mentioned autonomy above, which is obviously a key factor in speeding up API production; the more you trust staff to make decisions, the more hands off you can be with them. However, there’s more to using time effectively than just that.

The idea of getting in sync with your team to improve efficiency can almost seem like an oxymoron, as the former implies an array of meetings and updates that can negatively impact the latter. The real trick here is to find a way – whether it’s using Slack, limiting your emails to weekly updates, or running through everyone’s tasks at the beginning of the day – get in sync in a way that works for your team.

Motivation And Energy

As Mitra points out, “it’s impossible for everyone to have the top 1% of talent in the world.” But people who care about the work they’re doing, and are excited to invest their time and effort in it, will always outperform unmotivated stars. What’s more, they’ll get other people excited about it too.

But let’s consider another way to get things done for a second. Bill Gates once (in)famously said that “I choose a lazy person to do a hard job because a lazy person will find an easy way to do it.”

To be clear, we’re not suggesting that there’s a secret slacker way to build and maintain an API. It’s interesting to note, however, that many of the best APIs were created to automate or simplify a process that would otherwise be very time intensive.

These types of employee-employer relationship require a huge amount of transparency – if an employer won’t let his employees, say, work from home because he doesn’t trust them or an employee is too worried about getting fired to explain how they would improve things, you end up with stories like this one.

Final Thoughts

Mitra says that we as developers need to “start building a people platform that we architect in the same way as we architect our technology systems.” We all know the stereotype – “don’t bug the developer when he has his headphones on or before he’s had his coffee.” But that works both ways.

Developers must be plugged into the needs of the organization and its employees, as well as the needs of the users of the API. Without that dialogue a beloved API might, for example, end up being shuttered because it’s seen as a money pit by everyone else in the business.

It should be pretty obvious that transparency and autonomy are vital to effective development, of APIs or otherwise, but in order to get to that point you need trust, efficiency, and talent.

In other words, you need great people communicating effectively with each other. And, in that respect Conway’s Law is as relevant today as when it was written 50 years ago back in 1967.