Cross-Functional Team

Modern product organizations almost universally run on cross-functional teams. The best-known implementation is the Spotify-style squad model, but the pattern is older and broader (Toyota's production-line cells, military combat teams, startup scrappy teams). The benefit is alignment — the team owns the outcome end-to-end and doesn't need to coordinate across 4 hand- offs to make a change. The cost is that each functional discipline needs some way to maintain standards across teams — or the cross-functional teams produce inconsistent work that looks nothing like each other.

Take a 1,500-person software company organized into 35 cross-functional product squads. Each squad has 5-8 people — typically 2-4 engineers, 1 designer, 1 product manager, sometimes a data analyst. The squad owns a specific product area and has end-to-end responsibility — design, build, ship, iterate. Functional leaders (engineering, design, product) don't own the squads operationally but own the craft — career development, hiring standards, technical architecture. Each functional discipline has a regular cross-squad sync for consistency. Individual contributors have a dual reporting structure — tribal leader for craft, squad lead for day-to-day work. Tensions between the two are managed explicitly.

Cross-functional teams fail in two predictable ways. First, they become "you're on two teams now" — employees with unclear priorities between their functional team and their cross- functional team, burning out trying to serve both. Second, the cross-functional team captures talent so completely that the functional discipline collapses — no one is responsible for engineering standards, and the codebase diverges across teams until it's unmaintainable. The organizations that get the pattern right are explicit about which decisions live where (mission and priorities live with the squad lead; craft, career, and technical standards live with the functional leader) and make that structure stable.

In tech, the squad/tribe model is near-universal for product organizations. Variations exist but the pattern holds.

In media and entertainment, cross-functional teams form around specific shows, campaigns, or franchises.

In professional services, project teams are cross-functional by nature but temporary, which changes the operational dynamics.

In manufacturing and heavy industry, cross- functional teams appear at the line level (operators, quality, maintenance co-located) and at the project level (new-product launches) but the ambient structure is often more functional.

In healthcare, multidisciplinary care teams (clinicians, nurses, social workers, case managers) have always been cross-functional though not always called that.

In retail, category teams are cross-functional (buying, planning, marketing, operations) and the pattern has been standard for decades.

AI changes cross-functional team dynamics in 2026 in two ways. First, functional-discipline consistency becomes easier — an agent can review outputs from multiple squads against standards, flag deviations, and propose reconciliation without the functional leader having to attend every squad meeting. Second, the cross-functional roles themselves blur — engineers do more design, product managers do more data analysis, designers do more prototype implementation, because AI fills in the specialized capability gaps. The team structure persists; the internal role structure changes.

• Dual reporting without clarity. Two bosses, unclear priority ordering, burnout follows.
• Functional standards collapse. Cross- functional teams without functional governance diverge into inconsistent outputs.
• Over-proliferation. 50 squads when 20 would do. Overhead grows, coordination gets worse.
• Squad composition static. Treating a squad as permanent when the work shifts produces poor matches. Periodic rebalancing required.
• Mission scope creep. Squads that start focused and accumulate responsibilities over time become small functional departments with all the same problems.