> Markdown version of [/videos/164-monoliths-a-love-story](https://www.wearedevelopers.com/videos/164-monoliths-a-love-story). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Monoliths: A love story

Think microservices are the only way to scale? Learn why keeping your monorepo and embracing an inner-sourcing model solves architectural gridlock without creating organizational walled gardens.

- **Speakers:** Adam Mullen, John Collins
- **Event:** World Congress 2021
- **Published:** June 28, 2021
- **Duration:** 43:07
- **URL:** https://www.wearedevelopers.com/videos/164-monoliths-a-love-story

## Summary

Scaling a startup often strains initial monolithic architectures, leading to overlapping dependencies, slower deployments, and complex onboarding. While transitioning to microservices with strict code ownership seems intuitive, it frequently introduces "walled gardens," institutional protectionism, and conventional drift. Microservices alone cannot guarantee system modularity; without addressing underlying communication patterns, they can make interconnected dependencies more painful to resolve.

A counterintuitive but highly effective solution is to retain the monorepo while completely restructuring team interactions, acknowledging that system architecture will always mirror organizational culture per Conway's Law. Instead of routing all tasks to static teams, organizations scale better by bringing developers directly to the work, forming temporary problem-solving units around specific features. Shifting from rigid code ownership to an inner-sourcing model transforms teams from gatekeepers into maintainers who review and accept cross-team contributions, drastically minimizing operational friction.

Navigating this cultural shift requires treating organizational changes as empirical, agile experiments driven by clear hypotheses. Health metrics should capture actual developer friction, such as tracking the frequency of ad-hoc sync meetings, deployment rollbacks, or off-cycle planning sessions. By embedding thorough documentation and "deletable code" standards into the definition of done, and employing functional buddy systems for onboarding, engineering leaders can ensure that adding new developers accelerates user value delivery rather than compounding architectural gridlock.

**Keywords:** monolithic architecture, microservices migration, ruby on rails monolith, organizational scaling, conway's law, inner-sourcing, agile empirical process control, cross-functional buddy system, engineering onboarding challenges, code deletability, sync meeting reduction, monorepo strategy, scale-up transition, agile definition of done, team dependency management

## Chapters

1. **Managing engineering hyper-growth and team expansion** (00:03) — Scaling from a small startup to a massive organization introduces complex collaboration challenges.
1. **Growing pains in a shared single repository** (03:11) — As more teams contribute to a single codebase, coordination issues and conflicting features begin to emerge.
1. **Benefits of starting with monolithic architectures** (04:12) — Monoliths provide lower overhead, easier testing, and simpler onboarding for early-stage and co-located teams.
1. **Scaling challenges in large legacy codebases** (05:45) — Victims of their own success, massive monoliths lead to complex interactions and sub-optimizations among growing teams.
1. **Addressing increased lead times and delayed delivery** (07:40) — Slowing deployment speeds negatively impact both business goals and the daily motivation of software engineers.
1. **Measuring team health with deployment and meeting metrics** (09:58) — Tracking sync meetings, planning sessions, and deployment rollbacks helps visualize the effectiveness of team collaboration.
1. **The downsides of strict team code ownership** (11:20) — Assigning strict ownership can result in walled gardens, conventional drift, and negative protectionism among developers.
1. **Why microservices cannot guarantee true code modularity** (13:25) — While microservices limit individual scope, they can actually make poor modularity much more painful to manage.
1. **Prioritizing engineering culture over immediate architectural changes** (14:46) — Conway's law indicates that engineering culture and communication patterns will override forced changes to system architecture.
1. **Bringing the engineers to the problem domain** (17:11) — Forming small, targeted groups around specific issues aligns communication structures with the desired software outcomes.
1. **Adopting an inner-sourcing model for shared maintenance** (19:40) — Treating teams as maintainers rather than owners allows anyone to contribute while preserving overall code quality.
1. **Finding the right scope for engineering experiments** (22:08) — Process improvements should target visible tasks requiring a few sprints to balance motivation and execution difficulty.
1. **Cross-domain collaboration without extensive upfront planning** (24:11) — Bringing explicit domains together avoids prolonged planning cycles and directly addresses complex service integrations.
1. **Using the scientific method for agile process control** (25:58) — Treat organizational changes as spikes with clear hypotheses to gather data and confirm or pivot efficiently.
1. **Scaling successful communication changes to reduce overall risk** (28:33) — Regular retrospectives and deliberate iteration help spread positive communication habits and minimize broad organizational exposure.
1. **Practical tips for maintaining code quality during transitions** (30:40) — Focus on creating clear documentation, writing deletable code, and testing improvements safely in offline environments.
1. **Prioritizing modularity over the monolith versus microservices debate** (33:02) — Whether using monoliths or microservices, deliberate decoupling and collaborative maintenance are the true keys to success.
1. **Approaches to documentation, team size, and new onboarding** (36:30) — Clear definitions of done, manageable team capacities, and pairing systems ensure smoother operations and faster integration.

## Related Moments

- [Transitioning from a monolith to a microservice architecture](https://www.wearedevelopers.com/videos/242-microservices-how-to-get-started-with-spring-boot-and-kubernetes) (from "Microservices: how to get started with Spring Boot and Kubernetes")
- [The challenge of preventing modular monoliths from degrading](https://www.wearedevelopers.com/videos/100325-building-moduliths-that-last-patterns-for-sustainable-module-integration) (from "Building Moduliths That Last: Patterns for Sustainable Module Integration")
- [Modernizing legacy applications through proactive leadership](https://www.wearedevelopers.com/videos/1223-coffee-with-developers-babette-wagner) (from "Coffee with Developers - Babette Wagner")
- [Restructuring the operating model for software engineering](https://www.wearedevelopers.com/videos/444-ikea-story-transforming-an-iconic-retail-brand) (from "IKEA Story: Transforming an Iconic Retail Brand")
- [Overcoming challenges of scaling legacy monolithic frontend applications](https://www.wearedevelopers.com/videos/236-microfrontends-at-scale) (from "Microfrontends at Scale")
- [Technical debt and tangled architecture of the legacy monolith](https://www.wearedevelopers.com/videos/987-modulith-instead-of-monolith-pragmatically-towards-microservices) (from "Modulith Instead of Monolith - Pragmatically Towards Microservices")

## Related Articles

- [Never delegate the understanding](https://www.wearedevelopers.com/magazine/749-never-delegate-the-understanding)
- [Why You Shouldn’t Build a Microservice Architecture](https://www.wearedevelopers.com/magazine/118-why-you-shouldn-t-build-a-microservice-architecture)
- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)
- [Now is the time for industrialized software development](https://www.wearedevelopers.com/magazine/601-now-is-the-time-for-industrialized-software-development)

## Related Jobs

- [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub**
- [Senior Engineer, Infrastructure Platform](https://www.wearedevelopers.com/jobs/ext/328836-senior-engineer-infrastructure-platform) at **Intercom, Inc.**
- [Mid/Senior Full-Stack Engineer (Web-first)](https://www.wearedevelopers.com/jobs/ext/1210833-mid-senior-full-stack-engineer-web-first) at **SMG Swiss Marketplace Group**
- [Tribe Lead - ( Software) Engineering Centre of Excllence](https://www.wearedevelopers.com/jobs/ext/1475530-tribe-lead-software-engineering-centre-of-excllence) at **SD Worx**
- [Senior Web Designer, Growth](https://www.wearedevelopers.com/jobs/ext/102722-senior-web-designer-growth) at **Intercom, Inc.**
- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/15942-senior-software-engineer) at **GitHub**