The Hidden Pitfalls of Team Architecture: Lessons from Adobe and Spotify

Introduction

Most engineering leaders inherit an existing organization whose hierarchy, reporting lines, and legacy decisions are taken for granted, yet the structure silently governs information flow, decision processes, responsibility allocation, and overall speed of operation. The author likens a flawed architecture to an unmaintainable codebase.

Inheriting Existing Structures

Only a few opportunities arise to design an organization from scratch—typically in early‑stage startups—while most leaders inherit gradually evolved systems, some deliberately planned, others sprawling like weeds. This reflects Conway's Law: "Organizations design systems that mirror their communication structures," and product architectures often reveal the underlying org chart.

At Adobe, the product engineering department was split by function: separate teams built back‑end systems, managed customers, core libraries, and infrastructure. A feature required reviews from four distinct teams, each on its own sprint cadence, stretching a simple change to months.

At Spotify, independent cross‑functional squads owned end‑to‑end feature development, deployed independently, and moved quickly. The modular system design stemmed directly from this team structure.

Both setups are reasonable in their contexts, but the lesson is clear: organizations must define their own architecture.

Design for Goals, Not Templates

Companies often copy templates such as Amazon’s “two‑pizza team” or the “Spotify model” without considering the cultural, strategic, and scale factors that made those models work. The real question is not "Which architecture should we adopt?" but "What problem are we trying to solve, and what design enables the team to solve it effectively?"

Effective architecture translates strategy into concrete design, aligning incentives, communication patterns, and ownership boundaries with goals, creating efficient channels where needed and clear boundaries where they are not.

Diagnosing Issues

Redesign is triggered by unsolvable problems, not by age. The simplest diagnostic is to trace a feature or story from conception to delivery: count how many teams handle it, how many handoffs occur, and how long it sits idle. Each delay hints at resource gaps, missing skills, unclear responsibilities, excessive dependencies, or trust deficits.

In Adobe, a simple change passed through four teams and took three months; at Spotify, the same work completed within a sprint because a single squad owned the whole flow—demonstrating the impact of intentional team design.

Insights from Team Topologies

Building on Conway's Law, the book Team Topologies offers four core team types:

Stream‑aligned teams own a product or workflow end‑to‑end.

Enabling teams improve tools or skills for other teams.

Complicated‑subsystem teams focus on specialized domains.

Platform teams create shared services to reduce cognitive load.

It also describes three interaction modes—collaboration, service, and facilitating learning—emphasizing language that shifts thinking from hierarchy to flow.

Common Patterns and Pitfalls

Typical evolutionary patterns include:

Functional silos : work well early but become brittle and inefficient.

Cross‑functional squads : boost autonomy and speed but raise staffing costs, as seen at Spotify where many mobile engineers were needed.

Centralized data or infrastructure teams : initially effective but later become bottlenecks.

Matrix structures : preserve continuity during team moves but add complexity unless responsibilities are crystal‑clear.

A frequent anti‑pattern is designing around individuals—building teams around a person's strengths or avoiding their weaknesses—which may work short‑term but becomes a burden as the organization grows.

Reorg as Refactoring

When an architecture fails, treat the change as a refactor, not a wholesale revolution. Make small, planned adjustments, clearly state the problem being solved, define success metrics, and have contingency plans if the change does not resolve the issue.

Leaders often err by reshuffling people without involving them in decision‑making; transparent communication about the why reduces resistance.

Design‑Led Leadership

Organizational design is an ongoing leadership activity. First, map the current system: identify communication paths, decision stalls, and ambiguous ownership. Then align the structure with strategy and culture.

Iteratively design clear interaction interfaces between teams, explain the rationale, and gather feedback. A well‑designed organization, like a well‑designed building, evolves continuously.

Viewing the company as a flow of information and work rather than a static diagram of boxes reveals hidden obstacles and energizes the system.

References

[1] The Hidden Architecture of Engineering – https://medium.com/@kevingoldsmith/the-hidden-architecture-of-engineering-6aa290d0b63c

[2] Conway's Law – https://www.melconway.com/Home/Conways_Law.html

[3] Two‑Pizza Team – https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team

[4] Spotify Model – https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

[5] The Spotify Model – https://blog.kevingoldsmith.com/2015/03/23/the-spotify-model-how-to-create-dissolve-and-remix-teams-to-be-more-dynamic-and-more-innovative

[6] Team Topologies – https://amzn.to/4nXiznc