Conway's Law and Microservices

Keeping software architecture robust and aligned with business incentives is a tough problem faced by most software companies. As the size of an engineering team grows, its communication cost increases quadratically. This is a result of the growing number of communication links of people as described by Metcalfe’s Law - the number of unique possible links in a network is proportional to the square of the number of participants. Without a clear understanding of how the organization structure affects software development, a company is likely to experience difficulty scaling and iterating once they reach a certain size.

The presented issue does not become significant until launching features or fixing bugs requires a non-negligible amount of overhead. Assume an e-commerce clothing startup is planning to change the pricing of off-season products, but the engineering department is structured so that such an adjustment involves the UI team, the Database team, and the QA team. Once the project is complete, it just happens that they cannot launch the update because the Integration team is attempting to resolve an unrelated email notification issue that is currently blocking the release. Similar scenarios can occur regularly and lead to downstream consequences. In a world where startups succeed by optimizing iteration speed, especially for venture-backed startups, a company is at risk of losing market position if it tolerates expensive development lifecycle.

This leads me to believe that Conway’s Law is perhaps the most important law for modern software businesses.[1] The interrelation between system architecture and organization structure was formalized by Melvin Conway in his paper “How Do Committees Invent” back in 1967. The law states that any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. This generalization on the sociological behavior of system designers has a profound implication: loosely coupled organizations are more likely to produce modular systems with autonomous components bounded by both business and technical context.[2] To empower engineers to develop and maintain software with high productivity, it almost seems inevitable for a company to move towards a paradigm where a team (defined broadly as well) is responsible for the entire lifecycle of a system component, ranging from development to testing to deployment.

It does not mean there is not place for horizontally integrated teams to exist, but tradeoffs are to be made. There is occasionally pressure to horizontalize the teams to ensure consistency across different parts of the system. In a layered architecture, as mentioned in the above example of owning UI and Database teams, you end up with low velocity but high efficiency in terms of code and functionality duplication. This is, by and large, beneficial for maintaining shared utility. The bottom line is a company needs to prioritize iteration speed in a way for loosely coupled teams to succeed, such as creating a hybrid environment to have vertical and horizontal teams coexist in their bounded contexts.

Decision makers at a software company should always keep Conway’s Law in mind. This is to say that a top priority of the leadership team is to create a collaborative structure and low-friction processes that allow its engineers to operate in alignment with business goals. Many of the most renowned tech companies are aware of this issue and invest heavily into refactoring system architecture and restructuring engineering organizations for long-term benefits. But among all standard practices, this investment is most commonly manifested as service-oriented architecture migration. It signals an org-wide shift towards building microservices expected and necessary. Leveraging Docker and Kubernetes to create a flexible and cloud-agnostic service-oriented infrastructure almost becomes an industry-standard practice. In a sense it is like cargo cult science, where some companies do not understand the benefits of microservices but do it anyway (aka. microservice cargo cult). However, knowing that Airbnb, Uber, Tinder, and more all made this transition and it seems to work quite well with their distributed workforce, it is tempting to insert microservice architecture as part of the equation for building fast-growth startups.

In fact, the so-called “microservice cargo cult” actually makes sense theoretically for building an ecosystem of distributed ownership and high scalability for a software company. Conway’s Law validates the reasoning of leveraging microservices to ensure minimal communication friction for rapid prototyping and experimentation. Certain communication limitations of cross-regional engineering teams are also lifted as a result of granting full-cycle service ownership. It is not hard to see why this architecture style becomes the go-to scaling strategy for many San Francisco/Silicon Valley’s hottest companies, but it is also important to understand its costs than keeping more coarse-grained systems.

Applying Conway’s Law and microservices appropriately can create a powerful mechanism for achieving fast and scalable success. Although the duo has their limitations, learning, experimenting, then understanding them is extremely valuable to any software businesses. They are worth serious attention.


  1. There are a couple of laws that greatly influenced the advancement of the tech industry: Moore’s Law, Kryder’s Law, Linus’s Law, and so on. Each offers substantial value in their respective domains for evolving a system and making business decisions, but many relevant questions can be neglected or abstracted away with the abundance of cloud services, open-source frameworks, developer tools available to software businesses nowadays.
  2. Sam Newman discusses a few studies on the topics of organizational structure and software modularity in Chapter 10 of his book Building Microservices, supporting the claim that the organizational structure has significant impact on the system it produces with empirical evidence.

Thanks to Eugene Marinelli, Shahid Cohan, Rohan Varma, and Saad Syed for reviewing the draft.

Unorthodox Methods of Choosing the Right Startup

If you have known me for a while you probably know that I get uncontrollably passionate when it comes to the topic of startups. There is just something intrinsic that is fascinating to me about a group of ambitious people working tirelessly to create a reality closer to their imagination. However, the truth is most startups fail. And this is the exact reason why most people are turned away and choose a steady career instead. If working at Google/Facebook has a higher expected value than joining a startup, why risk working longer hours with lower compensation at a place with so much uncertainty?

There are many reasons why people choose to join a startup: equity, impact, culture, location - you name it. Whatever the incentive is, I believe one’s goal of joining a startup is to find the right fast track to reaching your career objectives compared to taking the alternative paths. It is an opportunity to work on things levels beyond your current credentials. Working at a startup is locally optimal if you are given responsibilities above your market value, but you are mentally eager and intellectually curious to overcome the inevitable hurdles. Therefore, when defining what a “right” startup is for you, it boils down to to one question: can joining this company catapult you towards the success you are looking for?

The startups in consideration need to be able to offer you massive opportunities for personal growth. This growth can come in many forms: building a scalable and reliable video streaming system, leading client negotiation to get a contract signed, launching new products in a niche market with a team of three, and so on. At a company where human resources are limited, you are more likely to get assigned to tasks that you are unqualified for, and it is up to you to rise up to the challenge and deliver value.

An index I often consider for evaluating personal growth is individual I/O (input/output) - input as the amount of information you are learning and output being the value that you are producing. You want to put yourself in an environment with high throughput of this type of I/O.

There are tons of startups out there. You will have to make the call on which one looks promising and can help you get closer to your goal. The younger a company is, the more analysis you will have to do. Here are some thoughts to help you evaluate a startup before signing that offer.

Commit to a mission you truly care about. A young startup is like clay waiting to be molded; no one has a definite answer as to what it will look like eventually. Oftentimes business directions are unclear and management could be messy. You want to believe in the work that your organization is producing, otherwise you are likely to be affected by doubts from time to time.

With that being said, you should pick a mission that you’re passionate about - one that you’ll find yourself thinking about in the shower. Since the structure of a startup is usually flat, your voice would naturally carry more weight, so that your ideas are more valuable to the mission.
People are the most important asset of a company. They are the key ingredient that make or break all other parts of the business. Therefore, you want to identify the people you want to work with, with the goal of becoming a core part of that community.

There are numerous channels to learn about the people affiliated with a company. LinkedIn and Crunchbase are good gateways for collecting information about the founders, team, and investors. Ask yourself whether you see yourself working with these people.

At a Series C or earlier stage startup, you usually have the chance to build a personal connection with the founders and executives. Schedule a phone call or one-on-one with them to get a glimpse of their thoughts about the company’s future.
Work on projects that have a high impact on the business. Your value is correlated to the return on investment of the project that you contribute to. Always talk to your hiring manager beforehand about team assignments and product timelines, and aim to reach agreement in your expectations for one another.

If the startup has a blog, read about their recent work so you have a better sense of what the company is actually working on.
Find a startup with crazy upward trajectory in multiple areas: revenue, headcount, users, new products, market share, etc. You want to be at a startup where things are going to, if not already, grow exponentially. You can usually inquire about these stats from the company once granted an offer.

If the startup has not yet reached the growth stage, but you believe it has great potential, there are many more questions you have to ask before making a logical decision. Has the company already figured out the product market fit? How do they plan to scale given the current state of operation? What can I bring to the table that will help the company accelerate growth?

There are two things you shouldn’t overemphasize on: profitability and funding. Word on the street is telling us blitzscaling trumps everything. Over 80% of 2018 IPOs are unprofitable is the market trend we are observing, so you should have the confidence to join a place with high growth and high burn rate. And speaking of funding, if a company has recently raised a large round of financing, it only tells that the company has a longer runway before having to raise again or reach self-sustainability. Actual growth stats should be weighted more in your analysis than the amount the company has in the bank account. So remember that these numbers do not tell the whole story.
You get rich by owning things. Calculate what percentage of the company you are going to own. Negotiate for higher equity and lower base salary if you can. Even if the stocks could be worthless, equity is always a better motive for personal growth than cash is. (a16z has a great intro explaining how stock options works if you are new to this subject - link)
Last but not least, join a startup where you would enjoy working. If you are going to spend most of your time on weekdays, and possibly weekends, at a fledgling startup, you want to make sure that you can sense the joy of being there, otherwise burnout is hard to avoid. What kind of culture did you feel during onsite? If you are going to disrupt an industry, you might as well have some fun doing it.

The described method is purely derived from my personal philosophy and experience, as the word “right” varies per individual. I do hope that this essay can at least serve as a guideline to help you make a decision, or get you start thinking about joining a company you would not have considered before. If you are looking for a place to start, below is a list of accredited resources on high potential startups:

Thanks to Aleksander Bello, Rohan Varma, Rinko Shen, and Austin Poore for reading the draft and giving feedback on my writing.