It seems almost an accepted wisdom in Software Engineering today that small, empowered, cross-functional teams are the best way to build software and products. You can’t have design be separate from product be separate from engineering. Good products are about making the correct choice on hundreds, if not thousands, of tradeoffs. If you solve for your silo’s perceived constraints, versus the actual constraints, you won’t make the correct choice.

I’d posit that some recent Software Engineering concepts have risen out from this insight: mainly Microservices. The biggest improvement Microservices promises is not cleaner code, or ease of development (I’d argue that it hurts both), but that it allows individual teams to make progress on their product independently of other teams. Microservices enables us to actually make progress in a world where nobody knows the whole system, but everybody knows some small piece.

In some ways, the Microservices trend is really just a modern extension of Conway’s law, which states that the code produced by an organization will inevitably reflect its communication structure. Once we understand Conway’s law and that a small team per a product is good, then Microservices is just a solution to the question: How do we speed up development given these constraints?

I think reframing Microservices as a communication tool rather than an engineering tool reveals a lot. When should a new company move to a Microservice Architecture? Well, reframe Microservices as a communication tool, and the answer clearly doesn’t have anything to do with how complex your application is (“Surely adding versioned-networked APIs will make this easier!”) but rather when your team is too big to communicate effectively. When your team can no longer “just know” what everyone else is doing, then it’s time to start thinking about Microservices.

Not as an engineering solution, but a communication one.