Organizational Design — A Modern Approach
Harmonizing Tech Industry Frameworks and Navigating Organizational Growth
Preface
From time to time, new ideas emerge from thought leaders around organizational design that cause me to wonder if the author’s goals are too aspirational for the current industry. The adapation of their ideas into something pragmatic seems at the discretion of the reader.
In this article, I will be taking an architectural viewpoint by breaking down the current state and a desired future state. The method of exploration will be walking backwards through time and reviewing various vintages of organizational design principles.
Modern Organizational Design
In the following sections, I will illustrate four styles of organizational design from some of the industry’s most influential thought leaders. We will inspect the principles behind each design and see some common themes surface and some common pitfalls.
The following interpretations are my own but the ideas and insights from these authors are borrowed.
Design 1 — Empowered Design (circa 2020)
In the book Empowered: Ordinary People, Extraordinary Products, author Marty Cagan takes a product-centric view of the qualities that create empowered teams and organizations.
The first Empowered concept is cross functional teams that have all members required to deliver end-to-end. The balancing of three related goals is at its heart: ownership, autonomy, and alignment.
- Ownership — which drives motivation
- Autonomy — which drives self-agency to solve problems
- Alignment — which drives focus by reducing dependencies
The second Empowered concept is categorization of two types of teams: Experience Teams and Platform Teams.
- Experience teams — responsible for consumer and customer apps, UIs, solutions, or journeys
- Platform teams — responsible for shared, common services to build re-usability and organizational leverage
The final Empowered concept is orientation of mission. The term “Value Stream Aligned” speaks to removing impediments, reducing dependencies and managing complexity for teams.
Types of Value Streams
- By User Type or Persona
- By a Market Segment
- By Customer Journey
- By Sales Channel
- By Business KPI
- By Geography
Design 2— Team Topologies Model (circa 2019)
In the book Team Topologies by Matt Skelton, Manuel Pais, the authors take an engineering-centric view to organizations and further breakdown the types of engineering teams.
The style of teams breaks down into more technically nuanced structures:
- Stream Aligned — similar to empowered, value stream aligned teams with cross functional capabilities
- Enabling — experts that fall into certain common domains like architecture, testing, etc
- Complicated Subsystem — specialists in deep areas of knowledge like identity, financial money movement, etc
- Platform — focus on reducing developer’s cognitive load and empower teams to delivery autonomously
Building on the Empowered organizational design, you can further break down the Empowered Platform Team concept into platform archetypes of Enabling, Complicated Subsystem and Platform.
Design 3— Spotify Model (circa 2012)
In 2012, the Spotify Model was introduced by Henrik Kniberg and Anders Ivarsson as a tech-centric operating framework when they published their white paper on Spotify called Scaling Agile @ Spotify.
We continue to see similarities with Spotify’s priority on cross functional teams that desired high ownership, autonomy and alignment but with unique naming such as squads & tribes. Tribes represent a collection of squads that have context boundaries sharing high cohesion and stream alignment to a mission.
The management strategy that Spotify originally introduced to take on the complexity of working in a matrix organization was through Chapters. Functional disciplines would gather under a line manager who has experience in that discipline to run the “community of practice” and also act as their direct managers.
One flaw in the Spotify model was their chain of accountability for delivery. While the Line Managers were also deployed to squads, their roles were not ones of authority.
There was no single person accountable for the engineering team’s delivery or who could negotiate prioritization of work at an equivalent level of responsibility.
— Jeremiah Lee
It prioritized skill development and weakened alignment with holding team members accountable for business delivery. A reference that breaks down this accountability issue can be found here in Jeremiah Lee’s article, Failed #SquadGoals.
One final organizational component of Spotify was the concept of Guilds. These constructs were centered around “communities of interest” where anyone, regardless of discipline, could participate.
Design 4 — Two Pizza Teams (circa 90s-2000s)
Jeff Bezos was credited with the idea of Two Pizza Teams early in Amazon’s growth days. While this is not a holistic organization design, it is an honorable mention as a design principle to counter the Ringelmann Effect: a tendency for individual productivity to decrease in larger groups. This early organization style also shared the goals of ownership and autonomy.
Word of caution for considering the design choice here. As of this writing, Amazon employs over 35,000 engineers and the foundation of this organizational design choice is that each team is kept small and own a narrow scope but own it well. They follow the Single Responsibility Principle (SRP) and Single Threaded Leadership (STL) model. Although the principles are grounded, not many company’s have the business style, technology focus and massive number of resources to achieve this design.
Organizational Architecture
Borrowing on the prior art above, my final organization architecture may look something like the above illustration. Optimized for values streams, high cohesion of mission and efficiency in leveraging a DRY platform & services strategy.
- Teams are grouped logically aligned to their Value Stream
- Related Teams are grouped together for hard dependencies (solid arrows)
- Inter-related Teams have minimal soft dependencies (dotted arrows)
- Common functionality used across all value streams are grouped into platform functions
Anti-Patterns
Anti-patterns that I have seen emerge is usually caused by Conway’s Law in which teams have a propensity to build systems that mimic communication patterns. If your team is siloed in communication, then systems will behave with limited knowledge or collaboration with other systems causing poor system integrations, data integrity or platform consistency.
Ultimately, your architecture will constrain future scale due to growing systems that are tightly coupled with poor domain boundaries.
- Creeping Hard Dependencies — when the number of teams and initiatives grow. Clarity of focus and ownership gets lost and delivering for the value stream requires a growing array of dependencies.
- Lack of Cohesion with Value Stream — coordinating efforts to efficiently deliver values streams reduces waste and refactoring as teams can build overlapping functionality.
- Lack of Platform Investment — at best this causes each team to duplicate efforts across the organization, at worst unique capabilities will cause hard blockers eventually (ie, imagine multiple teams building out their own source of truth for user records)
Closing Thoughts
The key is being vigilant at each stage of company for when Conway’s law begins to work against your teams and look for opportunities to re-organize.
Inverse Conway Maneuver — design the organization you want, the architecture will follow, kicking and screaming
A natural course correction is to explicitly re-organize to a desired state (aka, Inverse Conway Maneuver). Positioning your teams to reduce dependencies and improve collaboration around the mission stated for their value stream.
If you have made it this far, I hope you can see some principled patterns that have emerged and stayed consistent in the past two decades; cross functional, autonomous, highly aligned.
