Monoliths: A love story

Your architecture mirrors your organization. To fix your code, you must first fix how your teams collaborate.

#1about 4 minutes

The challenges of scaling a monolithic architecture

Rapid team growth in a single codebase leads to development friction, increased complexity, and slower delivery times.

#2about 4 minutes

The problems with a growing monolithic codebase

As a monolith grows, development slows down due to the need for extensive communication and alignment across many teams.

#3about 4 minutes

Why strict code ownership is a flawed solution

Assigning strict code ownership creates walled gardens, knowledge silos, and dependencies that hinder collaboration and slow down development.

#4about 4 minutes

How engineering culture shapes system architecture

According to Conway's Law, your organization's communication patterns will ultimately determine your software architecture, making cultural change a prerequisite for technical change.

#5about 4 minutes

Shifting from code ownership to inner sourcing

Move from a mindset of protective ownership to one of collective maintenance by allowing people to go to the work and adopting an inner-sourcing model.

#6about 4 minutes

Scoping change initiatives for maximum impact

Choose meaningful, visible projects that can be completed within a few sprints to ensure they are large enough to matter but small enough to manage risk.

#7about 3 minutes

Applying the scientific method to organizational change

Treat improvements as experiments by forming a clear hypothesis, testing it, analyzing the resulting data, and iterating based on what you learn.

#8about 4 minutes

Practical tips for implementing sustainable changes

Ensure success by making small, iterative changes, prioritizing easy rollbacks, and investing in documentation and code quality to support future work.

#9about 3 minutes

Focusing on modularity over architectural labels

Instead of debating monoliths versus microservices, focus on decoupling code and improving team collaboration to build a more modular and maintainable system.

#10about 3 minutes

Q&A: Documentation, team size, and onboarding

The discussion covers managing documentation through the definition of done, the ideal team size of four to six engineers, and using a buddy system for onboarding.