Written by Michael Liberty, CPO and co-founder of Signifyd
If you’re the sentimental (and geeky) sort, you no doubt know that this year we’re celebrating the 53rd anniversary of Conway’s Law.
And even if you’re not sentimental you might want to tip your hat to Melvin Conway, who in writing about systems and organizations in 1967 made an observation that should be regarded as the “Golden Rule” of building effective Product teams. What Conway said was, “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations.”
Conway was a computer scientist, but his observation was sociological. He recognized that programming is a social activity with many collaborators contributing to the development of any significant system. Thus, how you develop good software over an extended period of time is as much a sociological question as it is a technical one.
Conway’s Law (from Giulio Santoli)
I’ll propose a corollary to Conway’s law which reinforces its sociological nature: “Organizations which design systems… are constrained to have communication structures that are supported by their system designs.” In other words, communication structures and system designs are mutually reinforcing and tightly coupled. In the case of a software application, you cannot decide how to architect that application without deciding implicitly how the people building that software will operate. The question of design and communication are inextricably linked.
Implications for teams that want to be “agile”
“Agile Development” has nearly religious devotion and universal adoption among modern software companies. Declaring that you follow a “Waterfall” development methodology is a surefire way to kill your recruiting pipeline. Despite this devotion, too many companies ignore the implications of Conway’s Law for their Agile Development teams. First let’s briefly review what the Agile Manifesto actually says,
…[W]e have come to value:
It’s reinforced with 12 principles, including, “Working software is the primary measure of progress.”
Although it’s not explicit in the principles, “small teams function better than large ones,” is certainly implied. It’s simply harder for large teams to abide by, “Businesspeople and developers must work together daily throughout the project.” Or, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Like everyone else, we at Signifyd consider ourselves practitioners of Agile Development, but not because we’ve adopted Scrum or some other agile methodology. Rather, consistent with the spirit of the Manifesto, we believe teams perform better when each member has the full context of their project, as well the responsibility and capability to bring products from nascent idea to production service. And we believe that’s easiest to achieve with small teams.
Given that desired communication structure, what would Conway’s law tell us is the best system architecture? For us, the answer has changed over time, but today it is unequivocally a Microservice Architecture, defined as “designing software applications as suites of independently deployable services.”
When and why to adopt to microservices
Embracing a Microservice Architecture is not a free lunch -- it comes with significant extra technical overhead relative to a monolithic application, and it’s certainly possible to adopt it prematurely. However, at a certain scale, the overhead is worth it because of the intense clarity of purpose that microservices enable.
Consider Signifyd’s life story, so far, as an example. When the company launched in 2011, it was my co-founder Raj Ramanand and me. We knew, practically on a minute-by-minute basis, what needed to be done, who would do it and when it was finished. That applied to code, funding, hiring and ordering lunch for that matter.
A few years into our startup journey, I’d made a few thousand commits and added a million lines of code — and deleted around 900,000 lines. There’s no doubt that level of churn was due, in part, to my inexperience at the time in developing a SaaS application, but it also reflected that we were still trying to figure out what our application and business would be. We had to react quickly to our perception of customer needs, and often those perceptions were wrong. Raj, myself and our early employees were so tightly linked, that the communication structure of our organization could accurately be described as monolithic. And so was our tech stack. Our public API, web user interface, webhooks, fraud scoring, reporting, etc., it was all one deployable application.
As a startup, you have just one advantage over incumbents: speed. They have more money, more employees, more customers, more everything. The only correct answer to the typical VC question, “Couldn’t Google do this?” is “Yes, but we’ll do it faster.” All you have is speed, and that speed comes from intense focus and limited overhead. Decisions, engineering or otherwise, are made very fast. Our monolith was not a marvel of engineering (far from it!), but it did let us move fast without spending our limited resources on orchestrating lots of microservices.
With that being said, every startup hits a wall where its communication structure must evolve, when it’s untenable to continue as a monolith. When that happens, you must evolve your systems with the organisation, or they will block your progress. For us, I think we hit that wall at about 20 people in product and engineering, give or take.
RELATED: Belfast helps Signifyd become one of US' fastest-growing innovation companies
Don’t resist the inevitability of Conway’s Law
Twenty-person agile teams aren’t really a thing, so it was obvious we needed to break down into smaller feature teams. We had, and wanted to keep, a “build it, deploy it, monitor it” ethos in our engineering organization. A monolith is inherently mismatched with this structure. No matter how clean and decomposed your code is, if the application is a monolith, ultimately teams are building, deploying, and monitoring everything, not just their component. That’s a significant cognitive burden — if, when you go to deploy your team’s bug fix, you’re worried about inadvertently deploying another team’s major feature, you’re constantly distracted.
I think we at Signifyd were fortunate enough to understand the inevitability of Conway’s Law, so we were able to work with it rather than fight it. Doing so pointed us squarely at microservices. And lucky for us, the tools enabling a microservice architecture had advanced immensely since we founded the company in 2011— version 1 of Docker, Kubernetes, and gRPC hadn’t even been released back then. Nevertheless, the upfront cost of doing that migration was meaningful, and there were significant non-obvious challenges we encountered when doing that switchover. For example (and these are just a few),
For the past five years, and the past three in particular, we at Signifyd have been extracting pieces from our monolith and spinning up new teams that develop collections of microservices. The most important result of our work has been scalability — but not scalability in the traditional way engineers think of it.
RELATED: Pushing Code to Production on Day Two: My Experience Joining Signifyd
Engineers normally think about scalability in terms of the number of requests or the amount of data you can handle. Microservices help there, but what I’m most interested in is organizational scalability. We want the ability — and we’ve achieved it through a microservice architecture — to add more people to our team and see our output grow linearly.
Can your organisation scale horizontally?
If you anticipate rapid growth for your company in the years ahead, a question you must ask is, “Is my team horizontally scalable?” Do my system and organizational APIs, so to speak, align? Can you add to a team without becoming mired in the bureaucratic overhead that the Agile Manifesto was designed to combat: documentation, rigid development plans, etc.?
Signifyd has been growing rapidly, particularly in the last two years. Our global R&D centre in Northern Ireland, which opened just over a year ago, is building products and services essential to Signifyd's overall offering. In the last year alone, we’ve added 60 team members in Belfast, on our way to more than 150 in the next few years.
The idea from the start was to have the teams in Belfast operate autonomously with communication to, but no gatekeeping by, our US teams in Silicon Valley. That means “build, deploy and monitor” their own applications. That is not something we could do without our microservices architecture.
And while we didn’t make the move to microservices as part of our expansion into Northern Ireland, the success that our teams in Belfast are enjoying and the innovation that they are producing is a clear confirmation that both Conway’s Law and Signifyd are on the right track with the philosophy.
RELATED: Raj Ramanand, Signifyd CEO and Co-Founder, on Belfast’s building culture
