In the early days of tech, the default team structure was simple: organize by craft. You had the backend and frontend departments, QA org and the system admin, DB or DevOps team. While this looked clean on an organizational chart, it created a fragmented reality that often stifled innovation.
Today, the industry has pivoted toward cross-functional teams, a shift that prioritizes business outcomes (external impact) over functional excellence (internal activity). But not everywhere, and this article is for them.
What’s Wrong with Functional Silo?
You may have experienced this yourself: you’re a backend engineer and need to create an S3 bucket for your feature, so you submit a ticket to a “DevOps team” that needs to be convinced why it’s needed, learn about the use case and then execute when they can prioritize, and during this time, you context-switch to something different.
When an organization is divided strictly by function (frontend, backend, mobile, infrastructure, etc.), this structure introduces several critical friction points:
Ownership gap: when no single team owns a feature from end-to-end, no one feels truly responsible for the business outcome. Success is measured by output, i.e., “completing tickets,” not solving the customers’ problem.
Orchestration tax: progress is constantly stalled by hand-offs. A simple UI change might wait two weeks for a backend API, which then waits another week for QA and another for a release team.
Varying incentives: each team has its own goals and incentives, and this “us vs. them” mentality fosters resentment and silos information.
Inflexible scaling: it is notoriously difficult to scale functional teams up or down based on shifting business priorities, which do shift very frequently. If the company needs to pivot to a mobile-first strategy, the backend-heavy department becomes a bottleneck. If the next quarter’s best bet is backend-heavy, what do other functions do during this time?
A Brief History: From Spotify to Team Topologies
The journey toward cross-functional teams has been iterative.
The Spotify Model (2012): Spotify popularized the concept of “Squads” – small, autonomous teams. Many organizations attempted to implement “Chapters,” where squads were often temporary or composed of volunteers. While innovative, these early iterations sometimes suffered from a lack of continuity. Once a squad dissolved, the “orphan code” left behind lacked clear ownership, leading to long-term maintenance headaches. Getting into sexy, prestigious squads or keeping out of boring, unpromotable work ones used to be a highly political battlefield.
Team Topologies (2019): Matthew Skelton and Manuel Pais refined this with Team Topologies, introducing the Stream-Aligned Team. Unlike the short-lived squads of the past, these teams are permanent and fully own a specific domain or “stream” of value.
To prevent these teams from being overwhelmed, they are supported by three specialized structures:
- Platform Teams: reducing cognitive load by providing internal tools. They also support and consult teams and are sometimes responsible for governance.
- Enabling Teams: helping bridge knowledge gaps (e.g., an Architecture or Security team).
- Complex Sub-system Teams: handling math-heavy or highly specialized components (e.g., a video codec engine).
The Power of the Domain-Centric Team
The Stream-Aligned team is responsible for a specific business domain end-to-end. This means infrastructure, backend, frontend, mobile, data, on-call, quality, analytics and anything that’s needed.
There often goes hand in hand with DDD – Domain Driven Design – that is an architectural pattern to organize business domains, including conventions within each domain, a translation between domains and modeling business expert knowledge directly in the code.
Shifting to stream-aligned teams transforms the engineering culture from a “feature factory” into a value-driven engine. A feature factory refers to a work mode that focuses on delivering features within deadlines (set by Product or leadership, possibly taking the team’s estimations into account).
What do we gain from stream-aligned teams?
Speed and continuity: by eliminating hand-offs, teams move very quickly and provide incremental customer value. Because the team stays together, they build institutional memory of their domain, ensuring business continuity. The teams have cohesive incentives to create value.
The Product Engineer: in this model, the line between Product and Engineering blurs. Engineers aren’t just waiting for “100% clear requirements” (precise tickets or PRD) from a Product Manager; they are talking to customers, analyzing data, and suggesting solutions. This means more intimate knowledge of customers’ needs and current priorities, in contrast to only controlling the technical solution for the requirements in the feature factory mode.
Skill acceleration: when a backend engineer pairs with a mobile developer to ship a domain goal, “T-shaped” skills happen naturally. The growth of engineers, even when they remain focused on their original function, is expedited – technologies, paradigms, languages, techniques, approach and maturity. Mastery isn’t just about the code, but also the customer’s pain points.
Additional Considerations for the Transition
While the benefits are clear, moving to cross-functional teams isn’t a “free lunch.” Organizations must consider:
- Cognitive load: you cannot expect one team to own a massive domain. Managing the size and scope of the domain is critical to prevent burnout and ensure effectiveness. On the other hand, a team may own several small domains.
- Management: if an engineer reports to a Backend Manager but works in a Marketing Domain team, who handles their career growth? Most modern orgs have “Engineering Managers” within the domain to ensure incentives stay aligned, regardless of the functional expertise.
- Consistent standards: without functional departments, there’s a risk that every team will choose a different database or coding style. This may actually be the appropriate thing to have – each domain has the freedom to choose the best tools for the job. In other orgs, a list of allowed technologies and conventions and/or “Communities of Practice” are established to keep the tech stack and conventions from fragmenting into chaos.
- Cross-cutting initiatives: there are different solutions for initiatives that require the work of more than a single team. RFCs (Request for Comments), Architecture Decision Records (ADRs), a committee that decides on priorities and involved teams, direct negotiation between teams, predetermined decision rules or wider programs with a directly responsible individual.
Conclusion: Empowerment Over Coordination
The move toward cross-functional, stream-aligned teams is ultimately a move toward trust. By giving a group of “Product Engineers” a clear domain and the autonomy to solve problems within it, organizations trade the illusion of control (functional silos and features decided by leadership) for the reality of impact. In 2026, the most competitive companies aren’t the ones with the best backend department – they are the ones whose engineers understand the customer and deliver incremental value based on frequent feedback.
Leave a Reply