ORG TOPOLOGIES 

The key question this article addresses is: How do we tell if a team is truly multi-function or just functional, and why does it matter for delivering end-to-end value? There has been a high-volume discussion exploring this and skill-related questions in our Slack community with great input from Aimé Flemm, Steve Alexander, Sven Müller, and Zoltán Dósa. I decided to summarize key discoveries in this article. TL;DR : Functional teams specialize in one domain—even if they have multiple subskills—while multi-function teams span multiple domains, letting them deliver end-to-end value without handoffs. The big difference is the team's mandate (an org design decision), which shapes how quickly and efficiently they can respond to customer needs. Embracing the Spectrum: From Functional to Multi-Function Teams (Updated) Organizations often struggle to explain the difference between functional  (“single-function”) and multi-function  (or “multi-skilled”) teams. On the surface, one might assume “functional” means a person can only do a narrow set of tasks, whereas “multi-function” means having a broad skill set. But what if individuals in a so-called “functional” team already use multiple subskills—like an Ops engineer proficient in networking, security, and disk management? The crux is not whether a person can do multiple things. Rather, Org Topologies  emphasizes the organizational mandate : what scope of customer problems is the team authorized and expected to solve, end to end , without formal handoffs? Functional vs. Multi-Function: The Scope of Mandate In functional  teams, members share a single overarching role or domain—e.g., front-end development, Ops, product management, or marketing. Yes, they might each have “subskills” in that domain (a front-end developer who knows React, Angular, CSS, etc.), but they remain in one function . To deliver new features involving other domains, they typically coordinate with separate teams (e.g., a back-end or product design group). A multi-function  team, by contrast, includes roles spanning multiple domains under one shared purpose—e.g., front-end, back-end, product management, UX design, marketing, and sometimes operations (DevOps). They can handle various tasks, from discovering customer needs to coding, testing, and promoting a feature. They reduce external handoffs because they already have the necessary expertise in-house. Why use “functional” instead of “single-skilled”?  Because “single-skilled” suggests someone only knows one tool or framework, which is rarely true. In reality, it’s about how the organization structures the team’s mandate, not the total number of frameworks each individual can handle. Why This Matters Below is a quick summary illustrating why the difference between functional  and multi-function  matters for delivering value: If a functional unit tries to build a truly new product feature and ensure customer adoption,  it typically lacks the product management, design, and marketing expertise to guarantee it’s desirable, user-friendly, and effectively promoted. They must hand off tasks to other functional teams or departments. On the other hand, a multi-function team   includes (or has access to) those complementary skills—so they can easily iterate, test with real users, market, and refine solutions without waiting in line for another team. This often leads to faster feedback loops and more holistic product outcomes. When the time to market and adaptation to change is critical, these distinctions can become make-or-break. A purely functional structure can bottleneck innovation if teams struggle to collaborate across organizational silos. By contrast, a well-supported multi-function team can operate like a mini-startup within the enterprise: they discover, design, develop, and launch features under one roof. An “Outside-In” Example One simple way to explain this concept to leadership is to focus on what the customer can expect  from a team rather than the internal skill sets: Functional Team : If the team can solve only one type of problem—for instance, handling front-end UI—then it’s functional (or single-function). Even though each member might know multiple frameworks, all of those subskills remain under “front-end work.” If the customer also needs changes to the back-end or advanced user research, that functional team has to reach outside for help. Multi-Function Team : If the team can solve a wide variety of problems across the stack—front-end, back-end, testing, infrastructure, UX—then it’s multi-function. They have the authority and ability to manage all key tasks end to end, meaning fewer handoffs and faster delivery. From an executive viewpoint , this outside-in framing underscores how quickly and effectively a team can satisfy customers. A multi-function team can deliver a “one-stop shop” experience, improving responsiveness and overall accountability. It’s About Organizational Design—Not Just Skills A major misconception arises when a functional team argues: “We’re already multi-skilled because we combine various tasks within our domain.” For instance, a front-end specialist might also do design tweaks and user testing. In reality, if the team’s formal organizational mandate  remains the front-end, they’re still considered “functional.” They have multiple subskills within one primary function but must hand off anything beyond that function. This distinction highlights an environmental  aspect: even if individuals possess overlapping abilities, does the organization  encourage them to apply those abilities collaboratively, or does it enforce silos through strict role definitions? Multi-function teams need organizational support —clear goals, decision-making authority, and a culture that fosters collaboration. Less Handoff, More Ownership Imagine you have: Team A : front-end Team B : back-end Team C : design and user research In a functional setup, a new feature request might bounce between these specialized teams, each handling their part. This can work if requirements are stable but slow iteration and discovery if the feature’s final shape is uncertain. In a multi-function setup , a cross-domain team includes front-end, back-end, and design expertise. They can talk to the customer, sketch a design, code it, and test reactions without waiting for separate teams. They have end-to-end ownership , boosting adaptability and speed of learning. Addressing Executive Concerns When explaining Org Topologies to executives, focus on: Reduced coordination overhead : Multi-function teams minimize handoffs by integrating key roles in one group. Faster innovation : They can swiftly adapt to user feedback because discovery, design, and delivery happen together. Contextual choices : Functional teams still excel in stable or compliance-heavy environments where deep specialization is needed. If rapid learning is crucial, multi-function teams often thrive. Forming multi-function teams requires a supportive environment: leadership support, psychologically safe collaboration, and well-defined missions unifying diverse roles. It’s not enough to place cross-domain experts in the same Slack channel—there must be a shared commitment to work as a single unit. Evolution and “Scope of Skills Mandate” Teams can expand  their scope over time, gradually incorporating product discovery, UX, or marketing capabilities. A front-end team might learn how to validate user needs. An infrastructure group might add DevOps or QA tasks to reduce external dependencies. As they grow their scope of skills mandate , they move along the spectrum toward multi-functionality. This is why functional vs. multi-function  isn’t strictly binary. It’s a continuum anchored by how many domains a single team is empowered to address. Org Topologies helps visualize these evolutions and clarifies how structural decisions align with organizational goals. My Key Takeaways Functional (single-function) teams  specialize in one domain. Members often have multiple subskills, but their mandate  is still narrow; they rely on handoffs to cover other domains. Multi-function (multi-skilled) teams  span multiple domains—front-end, back-end, design, product, and marketing—so they can build and deliver end-to-end solutions in-house. Why This Matters : When tasked with new features and adoption, functional teams may lack product, design, or marketing expertise. They must coordinate externally. Multi-function teams have these skills under one roof, enabling quicker iteration, testing, marketing, and refinement. An “Outside-In” Example : A team that can solve only one category of problems (e.g., front-end UI) is functional. A team that can tackle multiple parts of the stack (front-end, back-end, infra, etc.) is multi-function. Organizational culture  and authority  matter. Even if individuals have overlapping skill sets, they need an environment and mandate that allows them to perform cross-functional work seamlessly. Ultimately, choosing between functional and multi-function structures depends on your strategic goals  and related market context . Functional teams can be ideal in stable, specialized settings, while multi-function teams shine in fast-evolving markets where quick learning and customer responsiveness are essential. Understanding the difference—focusing on what the team can deliver end to end —is key to designing modern, adaptive organizations.

In today’s rapidly evolving technological landscape, organizations face increasing pressure to build adaptive, multi-skilled teams. Traditional career paths, however, often act as barriers rather than enablers, rewarding narrow specialization and promoting hierarchical roles as the only path to success. For those attempting to adopt frameworks like Large-Scale Scrum (LeSS)  or operate in dynamic environments, these outdated systems quickly become obstacles. Instead, organizations need “tailwind career paths” —career models that align individual growth with organizational needs, fostering flexibility, technical excellence, and mentorship without sacrificing clarity or fairness. Tailwind career paths reject the outdated notion that advancement requires climbing a managerial ladder. Instead, they create open landscapes for growth—where individuals deepen their expertise, broaden their contributions, and help others succeed. Organizations can foster cultures where technical excellence, collaboration, and mentorship thrive by focusing on multi-skilling, shared goals, and flexible structures. Real-world examples like Y Soft show that simplicity and transparency are key to success. Whether through peer-driven promotions, skill-mapping tools, or continuous mentorship, tailwind career paths create environments where employees feel empowered, valued, and inspired to grow. At the heart of a tailwind career path lies simplicity. Rather than fragmenting roles into granular job titles—front-end developer, back-end specialist, or UX expert—organizations can adopt broad, flexible roles. For instance, Y Soft offers a compelling example of a streamlined and empowering career path within a manager-less R&D environment . Roles are kept simple, progressing through clear levels— Junior → Intermediate → Senior → Principal —while promotions are employee-driven, transparent, and feedback-oriented. This eliminates artificial managerial hierarchies and empowers individuals to take ownership of their growth. For a tailwind career path to succeed, multi-skilling must be at its core. Teams that embrace skill mobility—where employees develop expertise in multiple areas—are far more resilient and adaptable. Implementing such frameworks may seem daunting, but organizations can follow core principles to design effective tailwind career paths: Communicate the Vision Continuously : Leadership must clearly articulate multi-skilling as a priority. Regularly reinforce this message through team events, company updates, and sprint reviews to create alignment and enthusiasm. Simplify Roles and Levels : Replace fragmented job titles with a broad role like Product Developer . Establish clear progression levels that emphasize skill depth, breadth, and influence—moving from team-level contributions to organizational leadership. Make Promotions Transparent and Peer-Driven : Implement a process where employees initiate promotions through self-evaluation and peer feedback, with reviews conducted by structured committees. At Y Soft, this ensures fairness while keeping employees accountable for their growth. Encourage Multi-Skilling Through Mentorship : Use tools like the back-me-up table  to identify gaps in skills coverage. Every specialty should aim for a specialist, a backup, and an apprentice. Pairing specialists with apprentices fosters mentorship while broadening organizational knowledge. Prioritize Team-Based Goals Over Individual Metrics : Shift focus from individual targets to team-based goals. Shared performance objectives promote collaboration and reduce unhealthy competition. Celebrate achievements in retrospectives and sprint reviews to reinforce this approach. Support Learning with Tools and Enablers : Provide access to resources like AI tools (e.g., Cursor) to help employees navigate new codebases and reduce the friction of learning unfamiliar domains. Facilitate Peer Learning and External Exposure : Encourage employees to connect with peers from companies like Y Soft, where innovative approaches are already in place. These exchanges can provide invaluable insights and inspire solutions tailored to the organization’s needs. Separate Compensation from Career Levels Initially : Avoid tying promotions to salary changes too early. Allow employees to experiment with the new model for at least a year before aligning it with formal HR compensation structures. Try Gamification and Avoid Over-Gamifying : Gamification can bring playfulness and ease when trying new ideas. It can help incentivize learning. So, it is a good idea to try some simple gamification techniques. It is important not to do more than necessary as gamification comes with risks, such as employees “gaming the system” rather than focusing on meaningful progress and intrinsic rewards—growth, mentorship, and collaboration. These principles create a framework that aligns personal growth with team and organizational success. By prioritizing simplicity, transparency, and adaptability, companies can replace headwinds with systems that propel individuals forward. Encouraging experimentation during the early stages of implementing a career framework is equally important. By initially decoupling promotions from salary adjustments, organizations can allow employees to explore and adapt without fear of immediate consequences. Celebrating progress becomes a cultural cornerstone: sprint reviews, retrospectives, and peer recognition provide opportunities to highlight individuals who step outside their comfort zones. Over time, these celebrations reinforce the value of multi-skilling and cross-team contributions. Allan Cyment shared an experiment with a “back-me-up” table used at one of his clients: a simple yet powerful tool for facilitating this growth. It allows teams to map out their skills, identify gaps, and ensure each area has a specialist, a backup, and an apprentice. Over time, employees broaden their expertise naturally, often through pairing or mob programming. Such practices encourage knowledge-sharing and mentorship, ensuring the team remains robust and flexible even as demands change. Companies like Y Soft demonstrate that effective career paths need not be complicated. Their transparent promotion process removes barriers, while a clear structure enables individuals to understand expectations and chart their growth. Promotions are not dictated by managers but driven by employees themselves through peer-reviewed evaluations. Salaries are adjusted based on value and contributions rather than rigid timelines or hierarchies. This approach builds trust while aligning individual motivation with organizational goals. The long-term success of tailwind career paths depends on clear communication and leadership commitment. Leaders must articulate the importance of multi-skilling as an organizational priority, ensuring employees understand how it benefits their personal growth and the company’s goals. For companies ready to embrace this model, the payoff is clear: resilient, innovative, and adaptable teams capable of navigating challenges and driving sustained success.

Click on the Podcast logos below to listen: 6 June 2024 by Agile Focus Point: 16 May 2024 by it-agile: 2 Feb 2023 by Zuzi Sochova:

Ein innovativer Ansatz für adaptive Organisationsentwicklung In der heutigen schnelllebigen und sich ständig verändernden Geschäftswelt kämpfen viele Unternehmen damit, agile Methoden so zu implementieren, dass sie wirklich die versprochenen Vorteile in Bezug auf Geschwindigkeit, Flexibilität und Effizienz bringen. Klassische Skalierungsansätze wie „Agile Release Trains“ oder das Bilden von „Tribes“ stoßen an ihre Grenzen und erschweren weitere Anpassungen und Verbesserungen. Hier kommt Org Topologies™ ins Spiel, ein innovativer Ansatz, der darauf abzielt, Unternehmen durch eine durchdachte und adaptive Organisationsentwicklung zu unterstützen. Dieser Artikel ist in einer Ausgabe von agilereview.de erschienen. Was ist Org Topologies™? Org Topologies™ bietet ein Framework-unabhängiges Modell, das es Organisationen ermöglicht, ihre Struktur und Arbeitsweisen visuell zu bewerten und zu optimieren. Das Ziel ist es, eine Organisation zu schaffen, die sowohl effizient als auch anpassungsfähig ist und somit langfristig relevant für Kunden und Stakeholder bleibt. Die Motivation für Org Topologies™ Org Topologies™ wurde entwickelt, um Unternehmen dabei zu helfen, die Auswirkungen ihrer Organisationsstruktur auf die Produktentwicklungsleistung zu verstehen und kontinuierliche Verbesserungen zu ermöglichen. Der Ansatz basiert auf einer Kombination aus Mapping-Techniken und systemischem Denken, um die Dynamik innerhalb eines Unternehmens transparent zu machen und gezielte Veränderungen zu fördern. Die Achsen der Org Topologies™-Karte Die Org Topologies™-Karte nutzt zwei Achsen, um die Organisationsstruktur zu analysieren: die horizontale Achse und die vertikale Achse. Horizontale Achse: Vollständigkeit der Fähigkeiten Die horizontale Achse misst, wie vollständig die Fähigkeiten eines Teams sind, um eigenständig Wert für den Kunden zu liefern. Diese Achse reicht von Einzelpersonen mit einer einzigen Fähigkeit bis hin zu sogenannten „Fast-Flow“-Teams, die in der Lage sind, End-to-End-Lösungen schnell und effizient zu liefern. Vertikale Achse: Umfang der Arbeit Die vertikale Achse misst den Umfang der Arbeit, in dem organisatorische Einheiten zusammenarbeiten und Wissen teilen. Sie reicht von einem engen Aufgabenfokus bis hin zu einem umfassenden Fokus auf das gesamte Unternehmen. Die sechzehn Archetypen und ihre Bedeutung Org Topologies™ beschreibt sechzehn verschiedene Archetypen, die verschiedene Organisationsstrukturen und ihre Dynamiken abbilden. Diese Archetypen bieten eine gemeinsame Sprache, um spezifische Konfigurationen und Herausforderungen der Organisationsstruktur zu kommunizieren. Die Archetypen reichen von „Single-Skill Individuals“ über „Multi-Skill Units“ bis hin zu „End-to-End Fast-Flow Teams“ und werden in Kombination mit ihrem Arbeitsfokus analysiert. Die Macht der Sprache Diese Archetypen ermöglichen es, die Organisationsstruktur präzise zu beschreiben und bieten einen klaren Überblick über die Stärken und Schwächen einer Organisation. Dies ist entscheidend für die Planung und Umsetzung von Transformationen. Der Weg zu einer adaptiven Organisation Die Anwendung von Org Topologies™ erfolgt in mehreren Schritten, die jeweils darauf abzielen, die Organisation näher an einen Zustand hoher Anpassungsfähigkeit und Effizienz zu bringen. Schritt 1: Die aktuelle Struktur bewerten Der erste Schritt besteht darin, die bestehende Organisationsstruktur zu bewerten und zu verstehen, welche Archetypen vorhanden sind und wie diese zusammenarbeiten. Schritt 2: Die Lücken identifizieren Nach der Bewertung der aktuellen Struktur werden die „Capability Gaps“ (Fähigkeitslücken) und „Value Gaps“ (Wertlücken) identifiziert. Diese Lücken zeigen auf, in welchen Bereichen die Organisation ihre Fähigkeiten verbessern muss und wo sie Wertschöpfungspotenziale nicht voll ausschöpft. Schritt 3: Die Perfektionsvision entwerfen Der dritte Schritt ist das Entwerfen einer langfristigen Vision, die fast unerreichbar ist, aber als Leitbild für kontinuierliche Verbesserungen dient. Diese Vision hilft dabei, die Richtung der Transformation klar zu definieren. Schritt 4: Die Transformation umsetzen Der letzte Schritt ist die praktische Umsetzung der Transformation. Dies beinhaltet Experimente, Anpassungen und kontinuierliche Verbesserungen, um die Organisation Schritt für Schritt näher an die Perfektionsvision zu bringen. Praktische Anwendungen und Beispiele Org Topologies™ wird bereits in vielen Unternehmen erfolgreich angewendet. Die Methode hilft dabei, die oft starren Strukturen klassischer agiler Frameworks zu überwinden und eine wirklich adaptive und kundenorientierte Organisation zu schaffen. Beispiel 1: Eine große Bank Eine große Bank konnte durch die Anwendung von Org Topologies™ ihre Teams von eng fokussierten Einzelaufgaben hin zu umfassenden „Fast-Flow“Teams entwickeln, was zu einer erheblichen Verbesserung der Effizienz und Kundenzufriedenheit führte. Beispiel 2: Ein internationales Technologieunternehmen Ein internationales Technologieunternehmen nutzte die Mapping-Techniken von Org Topologies™, um die Zusammenarbeit zwischen verschiedenen Abteilungen zu verbessern und Innovationsprojekte schneller und effektiver umzusetzen. Fazit Org Topologies™ bietet einen revolutionären Ansatz zur Organisationsentwicklung, der weit über die Grenzen klassischer agiler Frameworks hinausgeht. Durch eine detaillierte Analyse und eine durchdachte Umsetzung können Unternehmen ihre Struktur und Arbeitsweisen so gestalten, dass sie langfristig erfolgreich und anpassungsfähig bleiben. Wenn Sie mehr über Org Topologies™ erfahren möchten, besuchen Sie Org Topologies™ und beginnen Sie Ihre Reise zu einer besseren, agileren Organisation.

Einige behaupten „Agilität ist tot!“.  Bekannt ist, dass viele agile Transformationen scheitern bzw. aus Sicht der Sponsoren nicht die erwartete Wirkung haben, nicht das erwartete Ergebnis bringen oder aus Perspektive der Teammitglieder als Cargo Cult erlebt werden, ohne Perspektive auf Verbesserung. Warum ist das so? Ist das, was wir in unzufriedenen Organisationen sehen, denn überhaupt Agilität? Wird hier gegebenenfalls eine gescheiterte agile Transformation als tot bezeichnet, obwohl sie nie agil war? First Agile Wave: „Agile Teams” Für viele Organisationen bedeutet „agile Transformation“ die Bildung „agiler Teams“ in der Hoffnung, dass damit alles besser wird. Dabei wird sich viel zu oft fast ausschließlich auf einzelne Teams konzentriert, anstatt den kompletten Wertestrom im Blick zu behalten und auch auf die Abhängigkeiten zwischen den einzelnen Teams zu achten. Es ist aber unmöglich, einen höheren Grad an Agilität zu erreichen, ohne dass man die Organisation als ganzheitliches System und dessen Wechselwirkungen betrachtet. Aus Sicht der Sponsoren ist es wichtig, dass die Organisation Wert liefert und flexibel auf Kundenwünsche reagiert. Die Erwartungshaltung der Teams geht oft in die Richtung, unnötige Meetings und Prozesse loswerden zu können und sich mehr auf die Wertschöpfung zu konzentrieren. Second Agile Wave: Autonome Teams mit eigener Wertschöpfung Um mehr Wert liefern zu können, benötigen wir wachsende Autonomie auf Teamebene. Das hat zur Folge, dass Abhängigkeiten nicht durch immer „bessere“ Prozesse gemanagt werden dürfen, sondern, dass immer mehr Teams in die Lage versetzt werden müssen, unabhängig von anderen Teams Wert für den Kunden liefern zu können. Wovon letztlich beide Parteien profitieren. Hier startet die „Second Agile Wave“. Es geht nicht mehr darum, viele „agile“ Teams zu haben, sondern autonome Einheiten mit möglichst breitem Produktverständnis zu etablieren. Der Ansatz der Org Topologies™ hilft uns zu identifizieren, wo wir mit unserer Transformation aktuell stehen, was unser Zielbild ist und wie wir dorthin kommen.  Der Ansatz von Org Topologies™ Org Topologies™ definiert ein Modell mit 16 Team-Typen und den folgenden beiden Entwicklungsachsen: Completeness of Skills Scope of Work Completeness of Skills zielt auf die zunehmende technische Unabhängigkeit der Teams ab. Teams sollen in die Lage versetzt werden, über den gesamten Technologie-Stack Lösungen umzusetzen, Ergebnisse schneller und in einem konstanten Fluss End-to-End zu liefern.„End-to-End“ bedeutet, dass Teams keine blockierenden Abhängigkeiten untereinander haben (kein Warten, keine Übergaben, keine unklaren Verantwortlichkeiten).  Wir sehen, dass sich Unternehmen am meisten auf diese Dimension konzentrieren: die Schaffung besserer Teams. Scope of Work bezieht sich auf eine produktorientierte Ausrichtung der Teams. Je breiter die Teams bzgl. Produktorientierung aufgestellt sind, desto geringer sind die „Switching Costs” für die Organisation. D.h. die Teams können sich viel schneller und mit weniger Hürden an neue Prioritäten oder Anforderungen anpassen, da sie im besten Fall das ganze Produkt schon kennen. Kennen Sie nur einen Teil oder nur einzelne Features, sind die Transaktionskosten oder Nachteile für die Organisation deutlich höher, da sich die Teams unter Umständen oft erst in ein Thema einarbeiten müssen, das sie noch nicht kennen. Entlang dieser beiden Entwicklungsachsen sind nun 16 verschiedene Team-Typen in einer Matrix angeordnet.  Hier sind vier Beispiele aus der Matrix der verschiedenen Team-Typen: Y1 beschreibt eine Gruppe von Personen, die einzeln oder in Untergruppen Task für Task abarbeiten, ohne irgendeinen Blick auf das Gesamtprodukt zu haben oder zu wissen, wie ihre Tasks auf dieses Produkt oder den Nutzen beim Kunden einzahlen. Das wird in Organisationen dennoch oft als Team bezeichnet. A2 beschreibt ein Team, das gemeinsam Features (d.h. alle zugehörigen Tasks dazu) umsetzt, aber noch auf andere Teams oder Einzelpersonen angewiesen ist. Alle haben das gleiche Ziel im Auge und es ist verstanden, was das Feature für den Kunden an Mehrwert bringt. A2-Teams haben aber nach wie vor Abhängigkeiten zu anderen Einheiten, um wirklich Wert liefern zu können. Als Beispiel kann hier ein SCRUM-Team dienen, welches seine Aufgaben von einem Business Analysten erhält und außerdem zum Deployment noch auf ein anderes Team angewiesen ist. C0 beschreibt eine einzelne Person mit einer speziellen Fähigkeit, die aber wiederum das ganze Produkt kennt. In Organisationen trifft das sehr oft auf System-Architekten zu – sie kennen das ganze Produkt/System, haben darin aber eine sehr spezielle Rolle und können alleine gar keinen Wert zum Kunden liefern. Im SAFe-Kontext kann das je nach Komplexität des Produkts der Release Train Engineer oder der Solution Train Engineer sein. C3 beschreibt ein Team mit kompletten Produktverständnis und den Fähigkeiten, dieses End-to-End umzusetzen. Solche Teams trifft man oft im Kontext von Startups an. Diese können voll autonom arbeiten und haben keine Abhängigkeiten zu anderen Einheiten im Unternehmen. Die Typen A1, A2, Y1, Y2 werden als „Lower Level Archetypes” bezeichnet und mit der „First Agile Wave” erreicht. Diese Teamtypen sehen wir in Organisationen, in denen von ,gelebter Agilität’ gesprochen wird, aber der Frust über fehlenden Outcome nach wie vor groß ist.  Wie oben erwähnt, reicht die Verbesserung der Leistung einzelner Teams nicht aus, um ein gutes Kundenerlebnis zu bieten, da sie schnell an systemische Grenzen stoßen, die sie selbst nicht ändern können. Wir wollen weg vom Abarbeiten einzelner Tasks oder Features hin zu einem breiteren Fokus auf das ganze Produkt in einem Team. Ein zu kleiner Fokus im Team führt zu sehr zu lokalen Optimierungen und lässt das eigentliche Produkt und das Kundenerlebnis ins Hintertreffen geraten. Teams, die wissen, was der Kunde möchte, die das komplette Produkt verstehen und im Blick haben, fällt es signifikant einfacher, sich auf einen neuen Kundenwunsch anzupassen als Teams, die nur einen kleinen Task davon bearbeiten ohne zu wissen, wozu und in welchem Kontext es vom Kunden gewünscht ist. Um diesen Zustand zu erreichen, benötigen wir die Weiterentwicklung in der „Second Agile Wave” . Ist-Stand ermitteln und das passende Ziel finden Org Topologies™ macht es einfacher zu verstehen, wo eine Organisation und ihre Teams in ihrer agilen Transition „stecken geblieben“ sind und öffnet neue Perspektiven in Bezug darauf, wo man eigentlich hin möchte und was man erreichen möchte. Passt mein Org-Chart zu den Zielen meiner agilen Transformation und dem, was ich erreichen möchte?  Wo stehen denn meine Teams in ihrer Transformation?  Wo haben wir Abhängigkeiten zwischen einzelnen Teams, die wir eigentlich gar nicht haben wollen?  Wo entsteht ein hohes Risiko durch Wissen oder Aufgaben, die nur an einzelnen Personen hängen? All diese Fragen können mit dem Modell von Org Topologies™ analysiert werden, um einen Weg in die „Second Agile Wave“ zu finden.

TL;DR Many people still see the challenge of creating a better value-creating organization as black-and-white: it is either waterfall or agile. But in fact, when the second dimension is added (the vertical axis “scope of work”) we suddenly have more options. That makes the path toward true business-wide agility much clearer. This article explores three fundamentally different organizational ecosystems through the lens of Org Topologies™. This understanding will expand your organizational design options by providing you with a shared visual language that you can use to define the long-term vector of your organizational development. The writing of this article is inspired by a talk by Jurgen De Smet Mastering Agile Evolution: Strategic Agility Ahead . Not Yet Another Team Maturity Model The mission of the Org Topologies™ is not to develop another team maturity and assessment model but to expand our systemic view on the entire value-creating landscape. The essential questions that the Org Topologies™ explores are: How can we build an organization where the synergy of all the teams equals the performance of the organization itself? This means elevating the collaboration of the teams to the highest level by eliminating all unnecessary levels of indirection and management. How can we create a team of teams that is capable of discovering and delivering value to the customers? Meaning, expanding the collaboration of the teams on all fronts (which is referred to as 'left-shifting' - blending discovery & delivery) and getting to zero distance to the customers. Which org archetypes need to be put in place to realize the maximum potential of the people in the organization? This means uplifting people to the most humanistic and human-centered organizational design that helps people grow. All these questions are not about individual teams and their solo performance. The scope is rather on designing organizations for tight collaboration as a holistic value-creating ecosystem. This article explores some of them. Ecosystems Thinking Org Topologies Mapping 's most prominent benefit is to provide a visual language to model ecosystems - groups of work units cooperating to get things done. Comparing and contrasting such models might serve as a powerful source of insights on finding the true-north vector for the long-term development of your organization. Let's look at three very recognizable yet distinctive ecosystems that prevail in the digital product development space. Ecosystem Type 1: Pre-Agile (Matrix Organization) As depicted in the image above, such an ecosystem consists of the low-level delivery-oriented archetypes (Y0-A1) which are either task-focused single-skill individuals or feature-focused functional groups. Because none of these archetypes can produce end-to-end customer value independently, they require each other plus the special higher-level archetypes to perform upfront analysis and discovery work. Such a setup typically results in analysis work being handed over for implementation in the form of thorough requirement specifications followed by heavyweight upfront planning and estimating, followed by identifying and then tracking the numerous dependencies. From the lean thinking perspective, such a process results in overcomplicated big batch processing that contributes to all kinds of inefficiencies and waste . From the process perspective, such an ecosystem will have to master the sequential staged development process, also known as waterfall. To manage this excess complexity, organizations that are organized in such a pre-agile ecosystem need to rely heavily on the practices of traditional project management. The presence of a dedicated project management office (PMO) is not rare. It would act as an intermediary between the business-oriented and delivery units of the ecosystem, thus contributing to the inherent lack of transparency and effective business-to-IT collaboration. With such a strong focus on inner concerns (i.e., managing projects), these ecosystems would have to optimize for what they can measure and manage: that is, utilization of existing skills instead of customer value impact. This creates a strong focus on resource utilization and prescribed process culture. So no surprise, Ecosystem 1 is usually contrasted with "agile". But is it so black and white? Ecosystem Type 2: Agile Teams (Fast Local Flow) This ecosystem upgraded its delivery units to 'agile teams', essentially forming cross-functional units with a focus on fast flow. That is a great improvement compared to the pre-agile setup (see Ecosystem 1 above). Such teams (Y2-A3) are better fit for fast delivery and reacting to feedback - fast flow of change within a narrow scope of ownership. This kind of transformation we call "the first wave of agile" - moving the delivery box to the right. Getting faster with better flow. Creating such an ecosystem has been the main focus of many agile change agents for the last few decades. A series of frameworks and methodologies  have emerged to provide practices and tooling for creating and sustaining such constructs, with a strong focus on increasing the 'flow of change'. Discovery and delivery are separated. Resulting in what some people call a "dual track agile". That is a half-measure, a half-baked agility. Thinkers and doers are separated. That is the same old Taylorism. Unchanged paradigms. Sloppy thinking. Maybe some things have slightly improved compared to the matrix world of Ecosystem 1, but in general, it is naïve to expect a drastic organizational improvement with such an org design. So, no surprise: Last year [2022], over seven in ten respondents (72%) said they were satisfied with the Agile practices in their company, while this year, that has dropped to three in five (59%). – 17th Annual State of Agile Report In such ecosystems, the so-called 'agile practices' mainly affect how delivery is being run, but they failed to introduce systemic changes to the power structures and the way delivery learns what to work on. Traditional top-down analysis with dedicated 'discovery groups' is a very prevalent way of managing requirements engineering in such ecosystems. Separating Dreaming, Thinking, and Doing is the deadly sin of large organizations. It will lead to Coordination Chaos: fragmentation, waste, and underperformance.– Ari Tikka from gosei.fi Result? Big batch processing, hand-offs, queues, waiting... No surprise, countless organizations that invested in creating so-called "agile teams" still have to fall back on traditional project management practices to deal with dependency management and execution concerns. That's why there is still a "projects" box in the illustration above, the same as in the pre-agile ecosystem. Unless you elevate the whole ecosystem (simplifying and integrating it), some notion of projects will still need to happen to provide some even illusionary understanding of control. In this ecosystem, projects have to support the need for scoping agreements between business and IT, plus decent dependency management. The more teams are added, the more dependencies will emerge, and the more efforts need to be spent on managing such a system. Because of the above: such an ecosystem scales badly. Thus creating a fruitful market for so-called "agile scaling solutions". Aiming at streamlining the complexity of management at scale. But the root causes that create that complexity and difficulty of scaling remain unsolved. Long-term effect? Unsatisfied business stakeholders (things are still slow from their global perspective), and demotivated members of the agile teams due to lack of empowerment and constant micromanagement. More investments into such an ecosystem won't necessarily result in more impact. ROI is problematic. We should see how organizations that have been creating such ecosystems will deal with the ongoing light financial crisis. Unfortunately, we will see more layoffs but as a result, hopefully, more systems thinking. Ecosystem Type 3: Business Agility (Team of Teams with Co-Ownership) This last ecosystem that we are discussing in this article merges "dreaming, thinking, and doing" into one holistic workflow. This is what we call "the second wave of agile". This is a true upgrade, uplifting of the whole ecosystem. Such change is to enable the "cooperative game of invention and communication" as the co-creator of the Agile manifesto, Alistair Cockburn, nicely put it in his industry-changing book "Agile Software Development: The Cooperative Game" . Structurally, to create the preconditions for such rich collaboration, an organization needs to introduce the notion of a team or teams. This is a scaled concept - where a collective of agile teams work together with each other and with the customers, business stakeholders, and subject-matter experts to outlearn the competition. In the Org Topologies language, we call this an elevated ecosystem - a true enabler of business agility. This can be made possible by investing in both directions: flow and learning. While growing teams horizontally is common practice, making the teams move up is not. This can be achieved by allowing the agile teams to co-own the business/customer domain, by growing their "scope of work", on the Y-axis of the Org Topologies map. Making teams co-own and thus truly co-create, requires removing all artificial boundaries that would otherwise cause the "us-them" mentality and result in a "not our job" culture. The B2-C3 archetypes of the Org Topologies are gaining the best of the two worlds by combining flow efficiency with outcome orientation (see the illustrations above). This is the space of Business Agility. The Elevating Terminology. Elevating an Organization in the context of Org Topologies™ refers to the ongoing process of improving the organizational ecosystem to close capability and value gaps. This involves adopting new mindsets and structures to enhance business agility and overall adaptability. The goal of elevating is continuous improvement and innovation across the organization. ​ ​ Elevating Structures™ are the guides (tools, templates, workshops, patterns, examples) developed and collected by Org Topologies™ to help organizations implement practices of higher archetypes, promoting systemic changes rather than local optimizations. This approach helps organizations become more adaptable, innovative, and resilient. ​ Learn about the Elevating Structures™  to discover the ways to elevate your ecosystem and gain the true benefits of agility.

Business Agility is similar to the agility we observe at the team level—it helps a work unit deliver faster, learn faster, and adapt more quickly to change, but as the name suggests, it extends across the business. Most companies aim to outperform their competitors and remain relevant to their customers and stakeholders for as long as possible. The promise of Business Agility is like an elixir of life , essential for preventing stagnation and fostering rejuvenation. When obtained, Business Agility allows organizations to fluently and effortlessly absorb changing market trends, quickly jump on selected opportunities at no additional cost -- be agile in the broadest sense of this word. This blog describes how Business Agility can be achieved in relation to the work of Product Managers and Product Owners. The Org Topologies™ map helps us understand this concept and guides us on the path. If you are unfamiliar with Org Topologies™, the tool for strategic organizational development, you can get started here . The Difference between “Product” and “products”? Large, complex Products are ... large and complex. We want to split them into smaller parts because managing smaller products  appears  to be easier. So, usually, what large organizations identify as products are steps in the funnel, parts of a customer journey, features, applications, or components... They are parts of a larger Product. Those smaller products are typically poorly understood by the customer and business stakeholders. The sub-products are parts of a bigger whole. Only when that  whole  is put together can we address customer needs, enable a business model, make a true impact, and get a return on investments. "Dividing an elephant in half does not produce two small elephants." -- Peter Senge, "The Laws of Systems Thinking" Note the distinction between “Product” with a capital “P” and lowercase “products” in the paragraph above. We will apply this capitalization throughout this article. The difference between Product and product is essential. Org Topologies™ defines that difference as the “Product Gap” : It usually comes as a surprise, but the size of the Product Gap in an organization profoundly affects the whole organization, its design, and its operating model. In other words: A Product Gap is an essential characteristic of an org design. The idea that every piece of the whole (each sub-product) needs an “owner” is common in the industry. This is probably due to the popularity of Scrum terminology. Let us paraphrase that slightly differently: Most organizations have far too many product owners! Now, what do those product owners (in lowercase) exactly “own”? What is Ownership? When ownership means owning the whole Product, the impact a Product Owner can make can be measured by the improvements to that Product over time. As discussed above, a Product is developed to solve customer needs and enable a business model. As a consequence, the impact of a Product Owner must be measured in those terms as well. The results of their work are visible to the business stakeholders and customers and can be measured and optimized. But what happens when the whole Product is broken down into parts, and it is the parts that are owned but not the whole? Then, the impact of the work of the product owners (lowercase) becomes less connected to what business stakeholders and customers understand and care for. Results become harder to observe, the impact becomes harder to measure, and efforts and investments become harder to justify. Working on the parts does not guarantee a meaningful positive impact on the whole. Therefore, predicting and measuring  returns  and  profits  is difficult or even impossible when owning only a part. What is easier to observe and measure when individual parts are owned separately are the efforts and costs . And this is more dangerous than it sounds. Large organizations distinguish between “profit centers” and “cost centers” . Sadly, business stakeholders and accounting see many product owners and their teams as mere “cost centers”. If you are the costs, you will be minimized. Sad but true. In the absence of working towards something outer-focused (e.g., the impact of the Product on customer needs, a business model), owning a product part (lowercase) usually boils down to a sequence of inner-focused activities: preparing work, slicing work, detailing work, assigning work, tracking work, coordinating work... Work, work, work. Output, output, output. This is an obvious downfall of product management. The noble goal of Product Management is to maximize outcomes and minimize outputs , and that is challenging when the parts are owned separately. To make matters worse, teams quickly get used to their “helpful” and “available” product owners. Teams start to expect and rely on them to do all this preparation and coordination work. This inevitably only makes the downward spiral more vicious. In such environments, the true ownership of impact is replaced by managing work and output. Product owners (lowercase) become synonyms for project managers, requirement engineers, and team coordinators. They are team output owners , really. Levels of Ownership In the Scrum-dot-Org Professional Product Owner class, there is an exercise where a picture (displayed below) is shown, and the students are asked to plot themselves according to the different ownership levels. Most product owners who attend such classes plot themselves on the left side of this image as 'scribes' and 'proxies'. Ownership of the parts is rooted deep into how we do things these days (at least in the software industry). Typically, such product owners have either task- or feature-focus and are given a single development team to work with. With Org Topologies, we map this level of Product Ownership in the lower part of the map (Y—and A-levels). They are output-driven. Business Agility Cannot Be Attained ... ... When There is No Business Involvement   The “Product Owner” role was invented some 30 years ago as a response to a common problem - business in most organizations has been separated from Product Development (IT, R&D). Business people were neither involved nor controlled investments in software product development at the right level of granularity. That created a huge swamp for organizational dysfunctions such as internal fixed-scope projects, annual budgeting for IT, and countless orphaned products that someone once requested but no one really wanted. By giving a Product Owner's role to a business stakeholder, we bring Business and IT closer together and teach them to collaborate in a win-win game. In this setup, Business and IT work together daily to maximize value (more outcome) and minimize the amount of work not done (less output). And here lies the first impediment to Business Agility: the role of product owners (lowercase) is unlikely to look sexy to someone from the Business. Remember: a product owner owns a part of the Product: a step in the funnel, a part of a customer journey, a feature, an application, a component. And business people are not interested in tactical management of the parts but in strategic management of the whole. Hence, in many organizations, the role of product owners will be fulfilled by IT folks, not business representatives. Essentially, product owners in most orgs are team-level business analysts who take care of details so the teams don't get distracted from coding. Now we have just returned to square one: Business stays outside, not taking an active part in creating products, is uninvolved, and is not controlling investments. Eventually, in such an environment, the only way to control anything for Business is to fall back to the old-and-tested management practices of threats and bribes (deadlines and bonuses). Goodbye, Business Agility! ... When There is No Whole Product Focus Meet Billy, a product owner of the Billing Engine, and she works with a Billing Engine Team. Billy can optimize her team’s output when there is work regarding the Billing Engine. It is her focus. She scans the organization for useful work in the Billing Engine and brings it to her team. And when there is no work coming from the outside? She has a list of things that need to be improved in the Billing Engine. (Isn't she sometimes making up the work to keep her team busy? She would never agree to this statement. So, let's assume this never happens...) The trio: Billy, the Billing Engine and the Billing Engine Team are a tight knot. Billy owns the Billing Engine. The Billing Engine Team specializes in the Billing Engine. They all need each other. Their world is small but comfy. They can focus and specialize. They can be super-efficient  when it comes to the changes of the Billing Engine. Note: These are not just some universal laws: no one is born owning and knowing a Billing Engine. This is an org decision someone made some time ago. These are the principles of how that org is set up. “Efficiency Through Specialization” and “Focus Equals Efficiency” are the company's values that are written in the hallway. Billy can even try to make her team more efficient and achieve a nearly hundred percent resource utilization. But will it make the whole company agile? Agile as to “fluently and effortlessly absorb changing market trends, quickly jump on selected opportunities at no additional cost”? That is a rhetorical question. How many product owners with dedicated teams are in the org? Five, ten, twenty-five, a hundred?... All the product owners are strongly focused on their product parts, as Billy is. All the teams are deeply specialized in their product part. “Efficiency Through Specialization”. “Focus Equals Efficiency”. Imagine that Billy and her colleague product owners all need to contribute to larger business initiatives, bets, objectives, programs, projects, and epics (whatever they are called in that organization). These initiatives are usually created and prioritized by business stakeholders. And this quarter, there are five big company-level bets. One is a “Customer Retention” project on top of the other things. In the scope of that objective, customer retention needs to be increased, and those changes affect the Catalog (and the Catalog Team), the Product Search Engine (and the Product Search Engine team), the Billing Engine (and the Billing Engine Team), ... Which team will handle that epic? Before anyone can take it, it needs to be decomposed into work tasks according to the specialization and focus of the teams and their product owners. For instance, the Billing Engine Team must receive the tasks for the changes in the Billing Engine for the “Customer Retention” epic. The same goes for the Product Search Team and other teams. Again, why? Because “Efficiency Through Specialization” and “Focus Equals Efficiency”. Because someone has designed a company like that. And that's not the only project there is. How many other projects are the teams juggling simultaneously in that company? Five, ten, twenty-five, a hundred?... In that context: what are the odds that the “Customer Retention” project-epic-initiative-bet will be started and done in the next sprint by all the team working on it together? That probability is close to zero. Such organizations cannot work as one, they are fragmented and look more like a group of small sales boats than a well-build nice-looking cruise ship. Everyone is busy, everything is slow. Business Agility cannot be achieved through specialization and focus. Those things can even harm it. Business Agility requires stronger cohesiveness between the teams: a shared focus and broader specialization . Elevating to Close The Product Gap In case you missed it, the latest hype in the agile space is about Product. Many people are talking about Product Management, Product Managers, Product Leads, Empowered Product Teams, etc. The so-called “ Product Operating Model ” is the latest promise to solve our digital product development problems. This is a promising model, and we want to subscribe to the hopes it brings. However, we also believe that culture follows structure and that specific organizational design changes will make the application of the model more successful. Org Topologies™ offers a set of guides and practices called Elevating Structures . In this context, we discuss elevating the product owners and the teams. Elevating The Product Owner Role Many organizations that recognize that they are in the field of product development have an established position called a Product Manager (PM). PMs have a rather holistic view and speak the customer and business language. We can say they live on the Business side of the company. They must be visionary and responsible for delivering a Product that addresses a real need and represents a viable business opportunity. They implement the company's strategy through the Product and work on product-related tasks such as pricing, packaging, releasing, innovating, branding, advertising, etc. As per the Org Topologies™ map, the Product Manager is located in the upper left part of (C0/C1) the map - they oversee a large scope. However, because of the dysfunction of the product owners (lowercase) described above, those PMs were structurally separated from real ongoing product development. They are not driving features. They are not collaborating with the teams. The product owners take the space between the PMs and teams. It's time to change that. To close the Product Gap, we need to connect those PM directly to the teams. In other words, remove the product owners, and make the PMs the Product Owners. They shall act like mini-CEOs and manage a strategic Product Backlog. In many companies, such a Backlog already exists but has different names (a Product Portfolio, a List of Company Bets, OKRs). Instead of playing the role of a tactical business analyst, the Product Owner is a strategist. They will spend most of their time managing stakeholders and prioritizing for value. Teams then can learn to work directly with the customers and stakeholders to collect the details they need. Elevating the Teams Elevated Product Owners will own the Products, not the teams. That means Product Owners must embrace working directly with many teams. To move the teams within the reach of the Product Owners, we must elevate the teams by creating Teams of Teams with a business problem scope. Each business problem scope needs a single Product Owner and a Team of Teams. Such an organizational constellation can be called a Product Group. It is a holistic unit that has an end-to-end responsibility for a certain business impact. Creating a Team of Teams is similar to creating a cross-functional team with individuals but at a higher level of abstraction. Instead of combining individuals to solve problems at the feature level, we combine teams to solve problems at the business level. Each Team of Teams must have all the capabilities to solve any problem within their sphere of shared ownership.  Elevating the Sprints Having a single business-level Product Backlog with Teams of Teams creates the opportunity for teams to abandon the isolation of their team-level sprints. The business-level Product Backlog contains big and important items that are best addressed through the collaboration of multiple teams. They study and do the work in a shared cadence - a Product Sprint. We all know that a common goal makes the difference between a group of people and a team. By working in sync, dependencies between isolated teams turn from interruptions into opportunities for collaboration within the Team of Teams. In addition, the value delivered in each Sprint will be a business-level outcome. Stakeholders will benefit from attending an overall Sprint Review to inspect the return on their investment. Elevating Engineering Practices An important prerequisite to getting the best out of this approach is shared multi-team code ownership. This implies we need to break the team-feature coupling and broaden the team's scope of work from tasks or features to the whole company domain. (If a company is too big, we define parts of the business domain that are independent of each other). The goal is for all developers to work on many components, and ideally, they can change all the code. Most people say this is impossible and undesirable because this will create chaos. On the other hand, the results of private code ownership aren’t great either: complex code and standardization problems. So why not give it a try? Shared code ownership can be achieved gradually and thoughtfully. How about opening those repositories that need to be changed most of the time for most of the developers? Many approaches are available to make this prerequisite less scary (shared standards, stack simplification, automation, to name but a few).  And What About the Team Output Owners?  There are many options depending on what those people are skilled in and what they want to do in the new org. But in most cases, product owners (lowercase) possess great knowledge about some given product parts, they understand certain aspects of business processes, know how to analyze and split large requirements, some even still can code... That would make them great team members, no? Summary Business Agility means that a company can decide to work on what is most important at any given moment at no additional cost.  Business Agility can be structurally enabled by: Closing the “Product Gap” Elevating Product Owners to the level of the Product Elevating teams and forming Team of Teams Elevating the Sprint Elevating the Engineering Practices Forming Product Groups where people collaborate jointly on the challenges of the Product Learn more about the Elevating Structures™  to discover more ways to elevate your ecosystem and gain the true benefits of agility. © 2024, Roland Flemm and Alexey Krivitsky

Org Topologies™ is a mapping of recognizable organizational archetypes in product development. We are using the following two axes for creating the two-dimensional map: Grow team-level capabilities – by deepening cross-functionality to become fluent in delivering value fast. Grow customer-centric capabilities – by broadening understanding of the problem space. Being organizational consultants and field practitioners, we ( Alexey and Roland ) have assembled and generalized our recollections of many organizations that we have worked with. As the result, we've come up with seven archetypes. Each of them has a recognizable name and a description of its longing—an optimizing goal. If you've been in the industry for at least a few years and have met several companies that differ in culture, you shall be able to recognize and guess most of these seven archetypes Less generic and more recognizable names of these archetypes are: Y1: projects and task work Y2: component development with narrow-specialized teams A2: hopeful yet entangled teams A3: proud and autonomous teams B2: dependent teams tied up on business value B3: interdependent teams collaborating on business value C3: holistic product development Here is how they are mapped along the two axes of the Org Topologies™ map from bottom left to top right by an increase in organizational adaptivity, innovation, and therefore resilience. Caution (for Systems Thinkers) The next chapters will describe the most recognizable archetypes of work units (groups and teams) as, we believe, this provides a useful language that we all can learn and start sharing to better communicate org design ideas. Yet we don't imply one needs to work on improving those work units independently of each other if you have many of them within the organization. This would be a trap and a lack of systems thinking. Those archetypes don't exist in isolation, they interact and influence each other. They actually reside in those boxes (Y1, A2, etc) and are hard to improve exactly because of the interactions among them. So don't work on them separately - learn to see a system (interacting parts) and approach your transformation as a systemic one. Below is an example of mapping a real ecosystem that contains three groups/teams and one individual (architect) - the dotted lines represent relationships and reinforcements. Individualistic Work Project and Task Work (Y1) Optimizing goal of this archetype: “optimizing for resource utilization of cost centers”. Meet the 1st lowest group work archetype, located in the Y1 box of the map. That is a sad place to be. Still, we have it on the map because for some organizations it is a starting point on the journey. And we are welcoming them! Such an organization operates on the lowest level of value definition – the task scope. It knows how to manage the flow of work at the level of individual single-skilled workers. Despite being at the lowest level of the map, the managers are overloaded here. They do everything – from collecting and analyzing the requirements, to breaking them down to tasks and allocating them to skills, from control of task execution to work integration and conflict management. They are so busy and bogged down with micro-work, then they don't have the time to stop, think and change the system. Because of this dynamics and other factors in play, this archetype is very sticky. Organizations can live in such a state for many years without being able to implement a real, deep change. By the way, all other archetypes that we are describing here are also sticky, but each for its own, different reason. Component development with narrow-specialized teams (Y2) Optimizing goal of this archetype: “optimizing for narrow ownership”. At this level, an organization recognizes the value of people working together as a way to accomplish more work. See the Y1 box of the map. Here organization has created narrow-specialized component-oriented and function-oriented groups are got formed. That can be a “back-end service team” or a “testing and automation team”. But they are not yet teams in the way Richard Hackman defines them: These groups are lacking compelling direction , as their scope of work is at the lowest level – the task scope. No customer requirement can be fully done by any of such groups, so they keep working almost blindly on some parts of features, receiving and passing work like on a conveyor belt. These groups are also not real teams, as they depend upon external specialists who break down requirements into tasks for them, manage and then integrate those pieces together. Such structure is not enabling team's self-management. As eventually, there are numerous business and system analysts, architects of different kinds and dependency managers meddling with the groups. The life-cycle of a customer requirement development looks very much like a sequence of touch times from different narrowly specializing groups. A waterfall. Implementing Scrum with such an org design is truly impossible without changing the structure. Summary of Task-Level Archetypes (Y1 and Y2) Y1 and Y2 are very recognizable organizational designs. Lacking a definition of customer value, such organizations focus on what they see and can manage – “busy-ness” of its employees. As we know, being busy has almost nothing to do with learning and delivering value. So, we call these two archetypes non agile-friendly. As their principles of operation contradict just about any value and principles from the Agile Manifesto . The mission of Org Topologies™ is not to criticize, but to enlighten on the path to undertake. Therefore, these organizations in order to become agile-friendly need to realize two paradigm shifts: shift to multidisciplinary work (a move right on the X-axis) shift to user focus (a move up on Y-axis) Meet the Teams Hopeful yet entangled teams (A2) Optimizing goal of this archetype: “optimizing for quick wins and conflict avoidance”. From the previous two archetypes, we are now jumping one level up and on step to the right. Such organizations understand customer requirements at the level of features (user stories, if you will). They have learned how to manage work at that level, delegating lower level task-related concerns to the teams. For this to happen, they had to assemble stable long-living multidisciplinary teams. So, the moves to the right and to the above on the map support and reinforce each other. This is the A2 box of the map. Referring to Richard Hackman and his definition of 'being a real team': The elements that are required to ensure a team is 'a real team' are: the members have a shared task, the team boundaries clearly state who is inside or outside of the group, and the group membership is stable. Such an organization now has real teams. They can do Scrum and learn to ship fast. This creates “quick wins” as it states in the optimizing goal of the archetype. Work in such teams is now more fluent on both axes of the Org Topologies™: in delivering and learning value. Yet, this is still far from the perfection-vision as there are glitches and blockages in work of such teams. What is causing them? Such teams might occasionally be missing some skills and responsibilities. Those have not yet been transferred to the teams and are still occupied by individual specialists, specialist groups, or component teams. Breaking down barriers will inevitably create organizational conflicts for which the organization is not ready yet. This issue is highlighted by the part “conflict avoidance” in the archetype's optimizing goal. This short video explains this archetype with an example of mobile development done by a freshly assembled “mobile team”. Proud and autonomous teams (A3) Optimizing goal of this archetype: “optimizing for feature ownership and team throughput”. Moving one step to the right and realizing the paradigm shift of 'multilearning end-to-end teams', an organization has created proud and autonomous teams. Throughput of individual teams is higher than ever before. And it is likely measured as a team's velocity. This is a dream of many engineering and DevOps coaches – to be able to form and sustain teams that can work on user featured end-to-end. “You built it, you run it” – as a mantra for such teams. How do you know your organization is at this level? Because of the strong belief in feature ownership, the teams will likely be named after the things they are kept accountable for. You're likely to see an “iOS team”, a “search team”, a “data science team”, etc. Ownership is a great thing. Such org design allows people to show love and care for the things they officially own. But it is also a double-sided sword: they don't care of the rest. As the rest seem to be taken care of by the others. This creates ours – theirs mentality. A “not our job” kind of culture. This may not have been an issue in another industry, but in digital product development, most of the complex issues happen at the boundaries of sub-systems. In between “ours” and “theirs” – in the space that probably nobody owns. That causes occasional friction in delivery, but not every time. Eventually, an organization learns to live with these issues. And that is why this archetype as sticky. It is stable in the way that an organization can live in it for many years without seeing the need for a radical change. The next short video summarizes the wins of such an org design. But, as everything under the Moon, solving one problem eventually creates another higher level of problems. “We are constantly moving towards better problems”, one can say. Summary of the Team-Oriented Archetypes (A2 and A3) Creating better teams, the so-called “agile teams”, is a target for many organizations that we have worked with. Progressing along the X-axes, and investing in the teams to grow their engineering capabilities, is a great and vital direction. But we believe, in order to realize its true potential – the highest levels of agility (adaptivity, innovation, and resilience), an organization needs to progress along both axes. One key reason of creating the Org Topologies™ was to show creating great agile teams, it not all that an organization can be dreaming of and strive for. As we concluded in our detailed analysis of Team Topologies : Value of teams can be only measured by value of their work. So let's explore higher definitions of value that teams can be focused on to serve a higher cause. Meet the Team of Teams Dependent teams tied up on business value (B2) Optimizing goal of this archetype: “optimizing for managing dependencies”. This archetype and the two remaining ones can be considered as high-maturity ones. If B2 is done right, the teams do work collaboratively on higher definitions of value. Here, a group of teams can be focused to work on an end-to-end customer journey. For instance, helping a buyer to go from learning about the brand to selecting and configuring products, to purchasing and coming back for service. Having such a holistic view of an end-to-end customer journey, teams will be optimizing for better customer experience, not just individual features. That will inevitably contribute to having easier sales and higher customer retention. Important business metrics. Thus, the teams should define, measure and own such metrics. This helps teams to make a transition from being delivery team to becoming product teams. Marty Cagan writes a lot about empowered product teams (that's a reference of our analysis of that idea). The idea behind forming team around broader value areas might some familiar to those familiar with the Spotify's Tribes and Squads model (a reference to our analysis). But take a look at the video below – the idea of teams sharing the end-to-end customer journey only works if they shared a single backlog. Interdependent teams collaborating on business value (B3) Optimizing goal of this archetype: “optimizing for control of business goals and customer experience”. This short video addresses the issue of the previous archetype and goes further in creating well-functioning value areas with multiple teams collaborating. Summary of B2 and B3: Towards Better Silos Optimizing goal of this archetype: “optimizing for adaptivity in learning and delivery”. This level of fluency of value delivery and learning takes and organization closer to the unattainable perfection vision of higher adaptivity and innovation. At this organizational maturity, the team-level silos have been systemically fought and almost gone. There are no more walls between specialists and teams. All the teams within a given value area work as one. They are now, what we like to call, a team of teams , where multiple teams work as one and form a collaborative ecosystem. Notice how the understanding of team-ness changes in widens as an organization progresses on the map: A team of teams in a value area is fantastic as it speeds up delivery and learning at the organizational level because of fewer barriers between the individual teams. This creates more transparency for empirical control and improvements. But are there no walls at all? We can't say that without knowing the context of an organization. But generally speaking, from what we have observed in many organizations, there are high chances, that the value areas are implemented as org units – departments. New kind of departments, value-oriented and customer-facing. However, still departments. And that means new walls and new separation. Yet better walls and better separation because the space in between the walls is now bigger, it can hold more teams, many skills and is a context for collaboration. Will there always be silos and walls, no matter how well we improve? A Company is One Team Holistic product development (C3) and Beyond At the level of C3, there are no fences in the flow of value within a given organization. All teams are One Team. Owning the product with all its sub-products, parts, and services. Is that real? Can you go that far? Is such a state sustainable? Won't the local tendencies and desires of individuals go against such a high-state org design? See it more as a journey than the target, then the path itself becomes the goal. If you're familiar with LeSS , then one of its 10 principles of the whole-product focus will ring a bell, and there are also dozens of LeSS-inspired case-studies on this. Another great source of inspiration is Cesario Ramos' " Creating Agile Organizations " book and guides. And if you're not Scrum-biased, then the FaST agile approach might be your path toward the higher archetypes. Conclusion: Org Topologies™ as a Map With this, we are concluding the overview of these key archetypes that comprise the Org Topologies™. We've demonstrated how they are mapped along the two fluency axes. We truly believe this map can serve you on your journeys in search for a better organizational design. © Alexey Krivitsky and Roland Flemm.

Part 1, improving an A-level ecosystem with horizontal scaling. The organizational archetypes of the Org Topologies™ map can be used to plot organization designs that we refer to as ecosystems . This article describes an A-type ecosystem for (software) product development, the prevalent dynamics in it, and the solutions to improve performance using Org Topologies™ mapping. If you are unfamiliar with the Org Topologies™ approach, you can read this article to catch up and have a basic understanding of Org Topologies™ . Example of an A-type Ecosystem The A-level ecosystem is a combination of organizational archetypes where the A-level archetype is most prominent. At the A-level, as per the Org Topologies™ map, the work is done by the teams at the feature level. This means that their Product Backlog contains features, rather than tasks or business initiatives. However, customers do not think about application features, they have a “job to be done”, a need to be met. For example, a user might need to find the best option to travel from A to B. We can help the user by offering a product that will allow them to select a mode of transport based on relevant selection criteria (time of itinerary, cost, scheduled departure or arrival times, etc). This product consists of a series of features: set selection criteria, search, show travel options, select travel options, see itinerary details, manage profile, price alerts, etc). In the A-level ecosystem, there will be one or more teams assigned to build and maintain (a set of) features. In our example, the A-level teams are of type A2, which means not all capabilities are available in the teams to deliver a Done product. They depend on other organizational elements for shipping value to the customer. In other words, to provide a fully operational solution to the customer, we need multiple organizational elements to collaborate. This is a common situation in software development groups. In our example, this is an enterprise business analyst group (which can be mapped to archetype C0, an individual with a whole product focus). After decomposition, the feature-level work is further refined by the analyst group before the work is picked up by the A2-level teams. Each of the teams is responsible for building a certain feature(set). There is a travel team, travel feed-engine team, customer data team, and itineraries team. These teams work with Scrum. The analysts are not organized as a (Scrum) team. They are grouped into a department based on their expertise. (This is a Y1 archetype). After the features have been tested, we need an integration team to assemble the features into one working product, the user experience team will test the integrated product for consistency, and the performance and security team will need to verify the product before handing it off to the maintenance team for going live. These teams have a whole product focus but they have a single skill as they perform only a step of the complete product development process. Below is a visual representation (an Org Topologies™ mapping) of the ecosystem. Dynamics of this Ecosystem Each A2 team has its own Product Owner and Product Backlog. The specifications of the customer needs are prepared by the analysts and spread across multiple Product Backlogs. The development of features will be performed asynchronously. This is because each Product Owner can individually decide on priorities. Also, there are variations in team speed. And asynchrony is inevitable because the amount of work for each team varies. The Customer team might have little work creating a login screen and a customer profile page, while the Travel Feed team might take much more time to disclose information from a large number of external sources. Another interesting observation is that teams will not stay idle after delivering the required functionality for a certain customer journey. They will remain busy by adding functionality to their feature that their Product Owner deems valuable (face recognition maybe?). Also, the team might propose to upgrade their code to the latest frameworks and software patterns. Strictly speaking, this does not necessarily add value from the customer's perspective, nor might this be beneficial for the other teams. Doing work that is not adding value at the whole product level is also known as ”local optimization”. Before a working product can be shipped, the work has to pass through the C1 groups and maintenance department. There is a lot of information going back and forth (round-robin) between the elements of the ecosystem that needs to be coordinated. The dynamics can be summarized as follows: Information scattered across many backlogs Asynchronous dependencies Local optimization High-frequency round-robin of work Need for coordination roles Looking at the performance of this system, we see that there is low predictability on the delivery at the business initiative level (or customer need level). Also, we see that over time, there is a growing need for coordination due to the growing asynchronicity of the work. Transaction costs are increasing due to increasing lead times. Resolving problems the fast way The company’s leaders want to have clarity on the possible delivery dates of new initiatives. This is difficult due to the high number of handoffs, round robins for rework, and isolated feature focus of the teams. Which such an organizational design, the likeliness of not meeting anticipated delivery dates is high. Once this happens, a common procedure is for the leadership to summon the coordinators to report on possible causes for the delay and present plans for improvement. To speed up, it is not unlikely managers will propose to add more teams. However, there is ample evidence this does not work: “Adding human resources to a late software project makes it later.” This is Brooks’ Law which teaches us that adding teams will make the system perform worse. As a result, managers will push harder on the teams, team members will get frustrated, and leadership will be aggravated because the increased cost of additional teams does not give better results. These dynamics might be familiar to you. Resolving problems in a systemic way with horizontal scaling We should address this problem by looking at how the elements of the whole ecosystem interact. Managers should not waste energy trying to optimize the existing system. They can invest their time and energy more wisely in understanding the system, discovering the root causes, and considering options to redesign the system. All ecosystems are sticky. Its elements will try to stay in equilibrium and maintain the status quo, even when it is under pressure. How does this work? First of all, people want painless and fast solutions, as opposed to finding and implementing a deeper solution which will take more time and effort. Secondly, the coordinators will be tasked by higher management to improve the system. But what if the coordinators are a part of the problem? They will most likely not see themselves as a cause for the poor performance, as this implies self-sacrifice. In our example, we see a large amount of dependencies between teams. This problem was addressed by appointing coordinators to handle them. But was that the right solution? Did we address the root causes for having dependencies? No, we did not, because the fix did not make the dependencies disappear. Instead, we institutionalized them by appointing dependency managers, aka coordinators. We need to think deeper and look for a solution that results in a system without dependencies, or at least reduces the most important ones. For this, we must study how information flows go back and forth when developing a product. We need to understand why these information flows are a problem. We should start by looking at the dependencies of the A2-level teams because they are at the core of delivering customer value. The analysts, A2 teams, integration, security and performance, and maintenance groups are tightly coupled. The information between the groups round robins at high frequency: A development team hands off their work to the integration group, they raise bugs that need to be fixed by the developers, and so on. This kind of dependency often occurs and is also known as “Reciprocal dependency”. We want to reduce them as much as we can. We don’t care too much about dependencies that only pop up every so often. After all, we do not want to optimize the org design for exceptions. We need to contain the reciprocal dependencies inside a single team or (product) group. Possible solutions to achieve this are: Existing team members learn the missing skill (obtain knowledge) We give the mandate to the team to perform the missing skill (obtain permissions) Automate and create a self-service solution (self-service, no-code/low-code solutions) We add someone with the missing skill/knowledge to the team We create new teams by mixing the existing single-skilled teams into teams that contain the reciprocal dependencies The result: In the given example, we choose to change the organizational design by recreating teams that are better set up to deliver a Done increment every Sprint. This means that each A2 development team should be expanded with the missing skills to deliver a working product. . This will dissolve most of the other groups. By doing this, we will have contained a large number of unwanted dependencies in the teams. The teams will become A3-type teams (multi-learning with flow) and will lower the need for coordination drastically. After all, the teams do not work at the customer problem level. Learn More Visit Org Topologies Academy . © Alexey Krivitsky and Roland Flemm

TL;DR Is Agile dead? It depends on what you mean by 'Agile'. If you mean that the organizations are not getting the promised benefits because they were focusing too much on the team-level agile "ways of working" instead of systemic global improvements -- then we are in agreement. It is a misunderstanding of Agility that led us down a dead-end. At Org Topologies , we see bright sparks -- the signs of the 'second wave of Agile' as we call It. The emphasis is shifting towards both in-team and inter-team collaboration. Team autonomy and broad product ownership. And we want to support and amplify this movement. " We are uncovering better ways of developing software by doing it and helping others do it." Preface to the Agile Manifesto. And we still are! The discourse is on We hear constant whispers and loud voices saying: "Agile is dead!" While such statements could be dismissed as mere hyperbole, they open up a fascinating discourse. Is the Agile movement truly dead? Or has its meaning been relegated merely to represent team-level agility? We've discussed this topic on LinkedIn, and the quoted below post attracted thousands of views and hundreds of reactions: What's the buzz? Understanding the Shift The essence of agile for many of us, practitioners has always been centered around teamwork and creating great teams. The scrum boards, stand-up meetings, and constant feedback loops were crafted to propel teams into a state of perpetual productivity. However, as solutions evolve, they often give birth to newer problems. The very emphasis on team-level agility has inadvertently spawned the necessity for scaling. Scaling: A Self-Inflicted Conundrum By concentrating predominantly on micro, team-level agility, we've managed to sidestep a crucial aspect – system thinking. The inevitable need to scale becomes a challenge rather than a solution, a self-afflicted issue born from a tunnel-vision focus on the immediate team. The Emergence of Business Agility In this chaotic scenario, a new buzzword has gained traction: 'business agility'. The concept posits that agility should not be confined to development teams but should envelop the entire business entity. But this raises a question - hasn't agility always been meant for everyone: developers, customers, and other stakeholders? "Business people and developers must work together daily ..." - claims the Agile Manifesto signed more than 20 years agoo. The fact that we've reached a point where we need a term like 'business agility' is a stark indicator of a systemic failure. Org Topologies: Charting a New Course At Org Topologies, we hold a different view. We staunchly believe that agile is neither dead nor confined to business agility. What we need is a rejuvenation, a second wave of the agile revolution. Our emphasis should not just be on in-team dynamics but also on inter-team collaboration. Merely focusing on team-level metrics like the flow of change isn't sufficient. It's time to expand our horizons and appreciate value-creating ecosystems . Org Topologies serves as an excellent tool in this context. It provides a comprehensive mapping of different organizational archetypes in their relationships to organizational adaptability, acting as a catalyst for introspection and path determination. Navigating the Journey with Org Topologies Using Org Topologies, organizations can identify their current position in the agile journey. It becomes a catalyst for conversations about where the organization aspires to be, thereby allowing organizations to chart their path towards perfection. Conclusion: Sparkling the Second Wave by Creating Space for Collaboration In conclusion, agile is far from dead. But we need to broaden our perspective. We must start understanding "agile" beyond team-level agility and embracing a holistic view encapsulating in-team and inter-team collaboration, then we can truly ride the second wave of agile. Let's not see business agility as a separate entity but as an inherent part of a much-needed agile revolution. With tools like Org Topologies, we can strategically navigate our journey, ensuring that agile principles remain vibrant, relevant, and, most importantly, value-driven for everyone involved. We are uncovering better ways... Let's keep learning and improving beyond dualistic ideas. Let's keep creating adaptive organizations that bring resilience to business and fun to work.

TL;DR This is a series of articles (among them are Team Topologies and Marty Cagan's Empowered Product Teams ) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions. We assume you might already be familiar with seven archetypes of the Org Topologies . In this article, we will analyze the famous “Tribes and Squads” model (also known as a “Spotify model”) in terms of where it fits on the archetype map. The promise of the Spotify model: The Spotify model sounds promising as it offers a fresh view of old problems. It has also made it to the large market thanks to large consulting firms . What is the promise of the model? Your organization will become agile by defining value areas and creating autonomous fast to deliver teams working in them. And there are cases like the one of ING that seem to prove that it works great to create a culture of delivery and innovation. What we're concluding: On paper it might really look promising, the reality, though, is different. We've met companies after they've “accomplished their transformation to Spotify”. We see many non-autonomous teams owning some internal concerns like components and services. These teams are bogged down with interdependencies. They work in what is called “value areas” with an Area Lead being almost like a real Product Owner for the area. But each team has its own team-level backlog and a team-level output owner. This kills the idea of managing at the Value Area level because, with work defined at the team level, each team has its focus and agenda. And what's even worse is that such an organization might truly believe that it has transformed. But in fact, they are only using some new terminology like tribes and squads, but internally, it is all the same. Low adaptivity, low innovation. A culture of execution and dependency management. We've also seen cases when SAFe applied with the Spotify model to deal with the inter-team blocking dependencies. Our classification is likely A1-A2. When the teams are truly great, customer-facing, and autonomous: A3. Archetype Map of Org Topologies™ If you are familiar with the concept of organizational archetypes – feel free to jump to the next part of the article, where we analyze the Tribes and Squads. Otherwise, here is a quick recap. The map below represents two essential dimensions along which an organization can mature its design. The first dimension, the horizontal axis, is fluency in delivering a single customer value item . Simply put, it is how much flow there is when working on a given feature: a) are teams getting blocked along the way with technical dependencies, sequencing the work? or b) are they self-sufficient and work end-to-end with the high flow? In Scrum terms, this is how mature the Definition of Done is. The second dimension is the vertical axis, and it represents fluency in learning the whole product . It is nice when the teams are end-to-end. But if the teams are only given some low-level product work, and it is the work that they feel 100% comfortable with. You might agree that working on what you already know does not necessarily mean that you are constantly working on the highest value possible. In fact, almost certainly, the opposite is true: working on the same thing forever (or very long-term) means ignoring the business priorities. This “product fluency” axis is the most overlooked in coaching organizations. This is why we've created the Org Topologies™. In the Agile & DevOps space, there are plenty of talks and books on team efficiency, autonomy, and team-level topologies. We claim that a high velocity of individual teams doesn't mean the entire organization succeeds at discovering and delivering customer value. High team velocity means no more than that the organization is successful in keeping the teams busy . Is that what your organization optimizes for? Hopefully not. If we want to create innovative, adaptive, and resilient organizations, then we should stop paying so much attention to the team-level metrics and start optimizing for long-term product and business success. So, what is more important: the teams or the product? There is no wrong choice here. We simply need both: team-level fluency and product-wide fluency. This integrated organizational capability, essentially, is adaptability . It means how fluent (fast, easy, cheap, painless) an organization can discover new value and then work on it. In contrast, busy and interdependent teams with their overloaded team-level component-oriented roadmaps make it way harder and more painful to adapt to changing business priorities. So, we need to think in two dimensions: 1) product (or customer value) – around what we build the teams, and 2) teams – how good, flexible, and improving the teams are. Now that we have a two-dimensional space, we can map different archetypical organizational designs to measure how fluent they are. So let's explore the Tribes and Squads. Firstly, let's start clearing off the fog from these fancy names. Essentially, a squad is a team . A team on a mission, one can say. And a tribe is a group of teams sharing some kind of high-level common goal. For instance, taking care of the needs of a specific customer segment or the success of some customer journey(s). Essentially, a Squad serves a given business line. A more generic name for this would be a value area . And it is easy to conclude that the teams in a value area should share and work off a single tribe-level product backlog ordered by a tribe lead (product owner). Ideally, all the teams in a product organization should share all the customer segments and all the journeys. That would be the C3 box on the Org Topologies map. But this is not what the Tribe and Squad model is optimizing for. It is made for creating business-oriented groups of teams (squads) to serve a business line. So let's stick with this optimization goal of the Tribe and Squad model. Mapping Tribes and Squads: X-Axis Where do tribes-and-squad organizations belong on our map? Let's start with an X-axis (“fluency delivering a customer value item”). We have a range of options here depending on the teams' maturity. If the teams are dedicated to some architectural elements of the product (components, subsystems, services, platforms), then they are so-called “component teams”. Such teams don't deliver customer value on their own. In order to provide some real value, someone (a manager external to the teams) needs to break down a customer request, assign its parts to individual teams, and then engage in managing inter-team dependencies to get an integrated product feature. That is the first column on the map – the land of component teams and resource management. If the teams are more advanced and fluent at delivering features independently of each other, then they can span all the way to the 3rd column. And it is a goal of each scrum master, an engineering manager, and first of all the teams themselves to make them as great as possible. So to conclude our analysis of the Squads and Tribes model, the X-axis: maturity of such an organization is anywhere from the 1st to the 3rd column on the Org Topologies™ map. In other words, it is very much contextual. Mapping Tribes and Squads: Y-Axis Now, let's consider the product dimension. The higher an organization is on the map, the more customer-centric concerns the teams can deal with. Let us explain. In the A-row—those concerns are what is mainly known as “technical tasks” and “user stories”. The teams here are given requirements (scope) to work on. This is the lowest level on the Y-axis, as the teams don't have enough view to see how that work impacts the users and the business. Therefore, such teams can rarely measure the value of their changes and improve on those ideas. They can, of course, measure their velocity (the amount of work done per timebox), but this has nothing to do with delivering value. Working fast doesn't mean delivering what is needed. The teams (squads) in such an organization are in execution mode. This is like a factory, where some special people think and decide, and the others simply work on the orders. This is a major under-utilization of human capital in any organization. Do you recognize your organization yet? We hope not! How does a more mature organization function? Teams of an organization that is one level higher on the map (in the B-row) deal with broader things. Their work is more directly linked to the impact. Those teams are aware of user personas and their customer journeys within a somewhat narrow business line (business area, value area – synonyms). They understand the customer domain within this business area and know how to talk directly with users. The teams speak the customer's language. Therefore, they are aware of how their work impacts users' behavior. Therefore, they can measure and iterate to improve their solutions. The innovation here is high, and so is the impact and learning. It is a creative environment. But can we get any higher? The teams in an organization, that we map in the C-row, deal with business objectives. The things that are items on their overall, shared, single-product backlog are formulated in a business language. The teams understand and work on the things like higher customer retention, deeper market penetration, expanding new customer segments, and so on. The teams speak the business language and can refine those objectives-oriented backlog items together with the users, experts, and business stakeholders to ideate product hypotheses and feature experiments. Here everyone and every team dreams thinks, experiments, measures, and learns. Note how different this world is from the A-row. The following map illustrates this idea: So, where do we put Tribes and Squads finally on the Y-axis? You can probably answer this question already yourself for your context. Because each implementation of the Spotify model is different. We will share our generalized observations below. What we see in the industry is that the vast majority of the Squad/Tribe adoptions are at the lowest level along the Y-axis. That is sad news. In those organizations, there are “customer discovery” and “business analysis” specialists and roles. They understand the customer domain and the things like product impact and customer journeys. But one of the cornerstone management beliefs there is that it is “expensive and inefficient” to involve developers in discovery and analysis. And developers themselves start to believe they are not good at communicating with the customer and are happy to “delegate” that work to others. This drives a system where middle-men specialists prepare output-level backlogs for teams. This isolates teams from the world of customers and business. They stop learning. See a map below on output-driven vs. outcome-oriented organizations. Our Conclusion It is not up to us to judge your org transformation… But if all the above is true and the squads (teams) are kept focused on the outputs and have individuals backlog, then they have a very limited understanding of the outcomes. Such an organization is clearly in the A-row of the Org Topologies™ map: from A1 to A3. Agile Transformations: Expectations and Reality Interestingly, if you read some well-written materials on the model of Tribes and Squads , you see there things like “a team structure mostly aligned to customer and … user journeys” and “dedicated teams to grow selected businesses”. Such an org design would classify at least as an outcome-driven B-row of the map. In reality, though, when we go and talk to organizations after their “transformation projects” are “successfully accomplished” and the consultants (and the budgets) are gone, we see unexpected things. We see the structures and processes that are incompatible with the ideas of “teams aligned to customer user journeys to grow selected businesses”. We see low-level maturity on both dimensions. Often there are teams working off individual backlogs full of “pre-groomed” low-level “stories”. Stay there for a sprint or two, and you will notice that the teams frequently get blocked by each other. They are not end-to-end cross-component teams, so there is a lot of waiting, groaning, and wasteful dependency tracking. A lot of managers-coordinators-and-pushers too. Moreover, because each team is led by its team-level work-output owner, those teams are kept busy working on narrow aspects of a product. Be it a component, a subsystem, a product capability, or a microservice. Have you seen teams such as “search service team”, “mobile team”, “user registration team”, “reports team”, “data mining team”, and “instant messaging team”? These are just some examples. Those names imply that the teams are fixed (forever or at least long-term) to those product parts. This means that the teams will be working only on what they already know. That may sound alright as the teams have a steady, narrow focus and can apply their existing skills effectively. But do the search, the messaging, or some other product parts always need to be worked on and improved? But what if those backlogs are full of work only because they exist? Or because it is someone's full-time job to fill those lists in? And do we assume that all the changes and improvements of those product parts (like reports, mobile apps, microservices) are always and equally top priority from the viewpoint of the customers and the business? That can't be true. Priorities do change. Users change their minds. Business expectations mutate. Strategies shift focus. Generally, in such organizations, each team's focus is very narrow, but the organizational focus is spread too broad. Things are moving slowly, and a change is hard. Don't get us wrong. Organizations with such a design function. They do deliver value to their customers and stakeholders. But because of everything that is said above, they are lacking constant market innovation, sharp business focus, and high organizational adaptability. Every change of strategy is a tragedy, not an opportunity. Your organization can do better. And we as an industry can do so much better, too! Towards Better Organizations (with Empowered Product Teams) The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for another maturity assessment model. Not at all. The mission of Org Topologies™ is to help you , a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation, and therefore overall organizational resilience are a great place to grow towards. So, are we against squads and tribes? Of course, not! If you can envision your target state, any intermediate state can be a good next step. We just want you to keep going, keep growing. Below is some advice on how not to get stalled, stuck, or lost on your agile transformation journey toward perfection when applying the Tribes and Squad ideas: Manage the product backlog at the tribe level by someone who is a knowledgeable and respected domain expert with power and budget. Make that leader the tribe's only product owner who gives work to teams . Promote analysts and other specialists back to the squads as team members. Having the above-mentioned in place, strive for creating an environment where all squads of a single tribe work together, have a feeling of shared work. Squads then should meet regularly to agree on how to pull items from the single outcome-oriented backlog, respecting the product owner's priorities. This way, the squads will be sharing work and learning together , enriching organizational capability to innovate and adapt. The squads and its product owner (the tribe) and the general management of the organization should work together to remove systemic impediments – things that are getting in the way of implementing the above five points. This way, the tribe as a whole will be improving over time. And so is the organization. © 2022, Alexey Krivitsky and Roland Flemm. Org Topologies™.

Mind The Gap Between The Train And The Platform! In the rush to platformization, organizations often create a chasm between the platform and its customer-centric parts. This divide can lead to misaligned priorities, inefficiencies, and stifled innovation. Mind the gap! Caution This topic is highly contradictive as many consultants advice for exactly the opposite — to focus on platform development. That is probably why recent LinkedIn post on avoiding platformization has triggered a lot of attention. In this detail article I’m going beyond this false dichotomy (i.e. to platform or no to platform) and aim to advise for a balanced view on this subject with a preference to focus on the whole product. Problem Statement Imagine an architect who discovers that several stream-aligned teams share a common concern that could be extracted and reused. Thrilled by the opportunity, the architect identifies an important task ahead. The default reflex is to design a platform to address this shared concern. However, each stream-aligned team has its own roadmap and is busy with their tasks. The proposed solution seems simple: create a new team dedicated to this platform. Thus, a platform team is born. The architect collaborates with this platform team, spending weeks meticulously designing and implementing a platform solution, complete with beautifully published APIs. The next step? Mandate that all the stream-aligned teams integrate and utilize this new platform. This seemingly straightforward approach, however, is fraught with challenges and often leads to unforeseen issues. This modus operandi assumes that all variables can be anticipated through extensive analysis and design, a notion that often proves unrealistic in the dynamic environment of software development and organizational operations. The Pitfalls of Platformization in Software Development and Its Effects on Org Design Platformization, particularly in software development and organizational design, often stems from misguided priorities and expectations. While platformization aims to achieve economies of scale by standardizing processes and creating reusable components, it can paradoxically lead to inefficiencies if not approached correctly. The key is to balance the pursuit of economies of scale with the need for flexibility and customer focus. Viewing the "platform" as a separate product or value stream can lead to prioritizing internal efficiencies over delivering tangible customer value. Instead of focusing on what customers truly need, organizations may fall into the trap of building elaborate platforms that do not align with actual market demands. Despite the broad spread of populist ideas that promote platformization and the need for dedicated "platform teams", the long-lasting undesired effects of premature platformization cannot be overstated: Hindering Adaptability and Innovation Leading to Lower-Level Org Topologies Archetypes Overengineering and Waste Creating Internal Silos and Dependencies 1. Hindering Adaptability and Innovation Emphasizing platformization can stifle organizational adaptability and innovation by creating monolithic structures resistant to change. This contrasts sharply with higher-level archetypes within the Org Topologies model, such as B2, B3, and C3, which champion adaptability, cross-functionality, and a shared focus on customer outcomes. 2. Leading to Lower-Level Org Topologies Archetypes For instance, dedicating separate teams to platform development can lead to a "not our job" mentality and hinder value flow. This issue aligns with lower-level archetypes like Y2 ("component development with narrow-specialized teams") and A2 ("hopeful yet entangled teams"), known for their siloed nature and struggles with dependencies. These archetypes often lack the fluidity to adapt quickly to changing market needs, which is critical for innovation. 3. Overengineering and Waste Premature platformization frequently results in overengineered solutions. Without a validated business model or clear customer demand, organizations risk investing heavily in features and functionalities that are not actively sought after. This approach can lead to significant waste of resources and effort. 4. Creating Internal Silos and Dependencies Dedicating separate teams solely to platform development can create unwanted silos within an organization. This isolation often leads to misaligned priorities, communication breakdowns, and a "not our job" mentality, ultimately hindering the overall flow of value creation. Such internal silos can disrupt collaboration and efficiency. Alternative Approaches to Mitigate Platformization Risks To mitigate the risks associated with platformization, several alternative strategies are recommended: Validate Your Business Model : Prioritize building successful, customer-facing products first. Only consider platform development when a genuine need for shared services emerges from these validated products. Promote Shared Ownership : Avoid dedicated platform teams. Instead, encourage a collaborative approach where product teams contribute to platform development as a shared effort. This fosters a sense of collective ownership and ensures the platform evolves in alignment with real-world needs. This resonates with higher-level archetypes like B3 ("interdependent teams collaborating on business value") and C3 ("holistic product development"), which prioritize shared ownership and cross-functional collaboration to deliver customer value. Focus on Emergent Architecture : Allow the platform to emerge organically based on actual usage patterns and requirements. This iterative approach supports adaptability and prevents overengineering by ensuring development remains closely aligned with real-time needs. Consider Shared Code Libraries/Services : Instead of building a full-fledged platform, start with reusable code libraries or services that any team can create, co-own, and co-develop. Whole Product Focus : Avoid creating "value streams" dedicated to internal non-customer-facing concerns, such as platform or infrastructure development. Concentrate on delivering a complete product or its vertical slice that meets customer needs comprehensively. This involves integrating various components and services seamlessly, ensuring that the final product provides a coherent and valuable experience for the end-user. By focusing on the whole product, teams can avoid fragmented efforts and ensure that platform developments align with broader business goals and customer expectations. Key Takeaway Approaching platformization as a primary goal is ill-advised. Instead, a more customer-centric, adaptable, and collaborative approach to organizational design and software development is recommended. By prioritizing validated business models, shared ownership, emergent architecture, reusable code libraries, and a whole product focus, organizations can mitigate the risks associated with platformization and create a more agile and responsive environment for delivering customer value. Additionally, this approach allows for the realization of economies of scale in a lean manner without sacrificing adaptability and innovation. This approach doesn't say imply that platforms are not necessary or wasteful in general. This is just a just caution that premature platformization can harm organizational adaptability, innovation and resilience due to the gap between the platform-creating and customer-focused parts of the organization.