Building Software That Survives • Michael Nygard & Charles Humble • GOTO 2025
Michael Nygard, author of 'Release It!', discusses his experiences at Sabre and Nubank, offering deep insights into balancing autonomy and centralization, the practical implications of Conway's Law, and how architectural boundaries can reduce organizational friction and the need for constant alignment.
In a conversation with Charles Humble, Michael Nygard, Chief Architect at Nubank and author of “Release It!”, delves into the complexities of technical leadership, architectural strategy, and organizational design, drawing from his experiences with large-scale transformations at Sabre and Nubank.
The Genesis of “Release It!”: Bridging Dev and Ops
The influential book “Release It!” originated from Nygard’s time in an operational role before the term “DevOps” was coined. Tasked with managing production infrastructure, he was uniquely positioned between development and operations. This allowed him to diagnose systemic issues that developers, disconnected from production realities, often missed.
He observed that production failures fell into distinct classes, suggesting the possibility of categorical solutions. For example, he could trace an unresponsive application server back to specific code patterns, such as a thread acquiring a connection from a pool with no timeout, leading to a deadlock when another process failed to release its connection. This experience of seeing patterns in production failures and seeking robust, pattern-based solutions formed the core of the book.
Modernizing Legacy Systems at Scale: The Sabre Experience
At Sabre, Nygard was part of a major initiative to modernize a 50-year-old technology portfolio, move to the cloud, and adopt continuous delivery. The environment was characterized by immense technical debt, with applications running on everything from mainframes (including the rare, real-time TPF operating system) to every conceivable version of Linux, Windows, HPUX, and Solaris.
While the initial focus was on cloud migration, the team discovered the more significant challenge was modernizing fundamental development practices. A long period of underinvestment meant that the first hurdles were simply establishing automated builds, continuous integration, and automated testing. This foundational work was a prerequisite for any successful cloud strategy.
A Nuanced View on Autonomy and Centralization
Nygard challenges the simplistic view of autonomy and centralization as a single spectrum. Instead, he argues that one must consider autonomy with respect to specific activities.
“You have to talk about centralization versus autonomy with respect to certain activities that you do. What are the things that you can do independently and what are the things that you have to go through the decentralized authority for.”
- At Sabre, the transformation involved increasing team autonomy in some dimensions (like deployment and build processes) while simultaneously increasing centralization in others (like security monitoring and infrastructure choices).
- At Nubank, there is a strong cultural endorsement of autonomy. Hundreds of squads work on thousands of microservices, deploying on their own schedules. This is only possible because of robust supporting structures: a standardized build pipeline, an architecture that expresses service attributes as data, and tooling that validates services before deployment. These structures make it safe to grant high degrees of autonomy for activities like writing, merging, and deploying code.
Alignment, Boundaries, and Conway’s Law
For a scaled-up organization like Nubank, maintaining alignment across autonomous teams is a constant challenge. While tools like OKRs are helpful, they are not a complete solution, as different business units (e.g., Brazil vs. Colombia) can have competing priorities that pull shared platform teams in different directions.
Nygard’s focus is on using architecture to solve organizational problems. By establishing clear architectural boundaries, you can reduce the amount of effort required for alignment.
“I’m constantly looking for situations where architectural boundaries would enable more autonomy and therefore require less effort expended on alignment… Knowing the boundaries of where you can operate freely increases your autonomy within that area.”
This naturally leads to a discussion of Conway’s Law, which states that systems will mirror the communication structures of the organization that builds them. Nygard emphasizes the often-overlooked keyword: communication. A formal reorganization that doesn’t also change the underlying communication patterns will fail to produce the desired architectural changes.
He also highlights an insight from “Team Topologies”: excess communication can be a “smoke detector,” signaling an inadequate platform, a poorly designed API, or a missing abstraction.
Leadership Beyond the Org Chart
Nygard contends that formal reorganizations are highly disruptive and often not the most effective way to enact change. A leader can have a more profound and less disruptive impact through other means:
- Celebration and Storytelling: The behaviors you celebrate send powerful signals. It is crucial to celebrate the “fire preventers” and not just the “firefighters” who heroically fix outages. Glorifying overwork creates a toxic culture.
- Rewards and Recognition: Performance ratings and promotions are direct levers for change. “Whatever you reward, you get more of.”
- Modeling Behavior: Leaders are always on stage. They must be deliberate about the culture they model and the types of discourse they deem acceptable.
He also notes that senior individual contributors are significant role models for junior engineers, shaping their understanding of what it means to be a senior engineer within that organization.