The Org Chart Is the Codebase

Con·way’s Law /ˈkɒn.weɪz lɔː/ n.: Any organisation that designs a system will produce a design whose structure mirrors its own communication structure. — Melvin Conway, 1968

Update (2026): Since this article was written, Monzo has grown to serve over 10 million customers in the UK and achieved its first full year of profitability in 2023. SwiftKey was rebranded as Microsoft SwiftKey in 2023.

Abstract

Organisational structure is strongly tied to how a company scales. However, there is no ‘one size fits all’; the structure may need to evolve with the company as it grows in order to remain effective.

Too much structure in an early-stage startup can hinder innovation, while companies with large-scale products often have complex architectures that require more organisational structure (such as formalised best-practices and defined communication protocols) to continue iterating efficiently. In a large company, you cannot simply turn around and talk to all your employees at once. We discuss factors that have influenced Monzo and SwiftKey’s organisational structures as they have scaled.

Case Study: Monzo

Monzo developed their organisational structure with the goal of building the first online smart banking solution¹, making it critical for their services to be available 24/7. Monzo noticed that large internet companies had faced problems scaling both their products and teams when using a monolithic architecture. Banking systems are also well-suited to a modular approach: there are a wide variety of services they need to integrate (e.g. Visa, Mastercard, Apple Pay), and keeping them separate improves resilience². These observations drove Monzo to develop their backend as a collection of microservices from day one, an unusual decision for a startup.

When Monzo released their first public beta in 2016, they had around 100 microservices³, which has since grown to around 1,600 by 2020⁴. They attribute much of their success in scaling to how they are structured⁵, with the founders prioritising a flexible way of working, meaning each team would have full control over how they operated, to “let [their] organisation flex and scale as [they] grew”⁴.

They achieved this by working in small interdisciplinary teams, where each team owns a set of features or services. Each service is small and tightly scoped, which allows ownership to be well defined and minimises the risk of change. Teams can then independently deploy services to iterate quickly, and decide how they want to work with autonomy⁶. This structure is reflected in the asynchronous messaging used between services in their backend architecture³, a direct expression of Conway’s Law, where system design mirrors organisational design. When an engineer joins Monzo, they only need to understand the small subset of services they are responsible for, making onboarding smooth and efficient.

Case Study: SwiftKey

SwiftKey, a virtual keyboard app, started with quite a different vision than it has today. Founded in 2008, they planned to license out predictive text technology to handset vendors⁷. These technologies applied cutting-edge research in a novel context (the smartphone keyboard), meaning SwiftKey couldn’t predict the components it would need in advance, and had to make multiple pivots.

In 2009, SwiftKey’s founders pitched to original equipment manufacturers (OEMs) in the mobile industry. The OEMs wanted proof the technology was useful before investing, leading to the development of the SwiftKey app⁷. In 2010, SwiftKey was released to Google Play, where it shot to the top of the rankings, shifting their business plan from licensing to building their own consumer app⁷.

We spoke with Alice, a software engineer at SwiftKey, to learn about the effect this had on their organisational structure. Although there was now an Android team in addition to SwiftKey’s 3 existing teams, “everyone worked very close together” to the extent that “you could hear everything being said at all times”. Little formal structure was needed for teams to communicate. The focus of all 4 teams was unified: “generating revenue from the SwiftKey app, so everyone worked close together in developing solutions for this use case”. By minimising formal procedures, throughput could be maximised.

This gradually changed after Microsoft acquired SwiftKey in 2016, as their focus broadened and shifted towards promoting Microsoft products in the keyboard and knowledge sharing⁸. Although the teams have stayed the same over the years, Alice explained they have grown further apart, both physically as the office expanded and in terms of focus. This weakened communication and resulted in the teams evolving independently, adopting different methodologies: some take a highly structured waterfall approach while others are more lean. This allows each team to work most efficiently for their purpose, though it can cause challenges on cross-team projects. Alice explained SwiftKey tried the Spotify model and found it worked well in some cases, but prefer a dynamic approach, adding communication structure between teams only when needed, to minimise waste.

Conclusion

From Monzo’s inception, they have effectively leveraged their microservice architecture to inform how their teams are divided, through Conway’s Law. By building services that are granular and easy to understand, they can work flexibly, respond quickly to customers, and scale⁶. At SwiftKey, their broadening focus led them towards more formal procedures, with a small number of teams working autonomously. In both case studies, we see the companies grew to a point where the most effective way of working is through autonomous teams owning and developing a defined set of features.

Written by me together with two of my Imperial College London classmates, Guji and Amelia