I see a lot of confusion about how to create healthy and effective cross-functional squads inside scaleups and large companies.

Here are some key principles to keep in mind...

Missions, not projects

Example missions include: User onboarding, billing & accounts, discovery, sharing & collaboration
Avoid “Innovation” Squads - everyone should be innovating all the time
Avoid Catch-all squads - every squad should have a clear mission that is broad enough to encompass many product changes over months and years while being specific enough to understand what is “in scope” and “out of scope” for the squad.
Avoid Agencies - Squads should be building principles, tools, frameworks, services, and products for customers (internal and external) to use. They should NOT be regularly building one-off things for other squads like some kind of development agency.
Be sure to include Platform Squads - These are Squads that serve internal customers with generalized services/capabilities.

Cross-functional & diverse

Cross-functional squads are not just filled with PMs and Engineers - they should also include Product design, Product Marketing, Data Science, and even special roles unique to your business (E.g. ProdOps)

Full stack ownership and operations

Squads triangulate, design, build, operate, measure, and iterate on their products. They are not just “delivery teams” that get instructions from others or hand things off to someone else once they’re built.

Autonomous but aligned

Squads should be empowered to come up with their own plan and execute without relying on other squads
They are aligned through planning cycles
They are aligned through Group and CXO leadership reviews & escalation
They are aligned through healthy (non-blocking) collaboration with other squads (see below)

Custodians, not Owners

Squads shepherd given surfaces/services/outcomes - but do not block changes
High bandwidth communication between EMs, PMs, and Engineers across squads as needed is essential. A graceful degradation strategy is useful. Specifically…
- Rely on 3rd party squad’s existing tools where possible/desirable
- If the existing tool is insufficient, suggest a change to the 3rd party squad
- If the change is not on the 3rd party squad’s near-term roadmap, the 1st party squad can make a change to the tool (3rd party squad reviews diffs)
- If the change does not fit within the 3rd party squad’s existing tools, 1st party squad should build their own

Supported by service leadership and escalation.

Well-meaning peers in different squads will have a difference in goals and perspective. Reasonable disputes will arise.
Everyone should be encouraged to escalate to leaders who have a broader perspective to make “executive decisions” and decide on trade-offs

Function-based communities/tribes/guilds create consistency across squads

Individuals in a function report to someone in the same or similar functions (E.g. Engineers report to engineering leaders, not to PMs - and vice versa)
Each function should engage in cross-squad culture building (shared principles, regular meetings, all-hands, social events, etc.)

Funded by the business

New business initiatives/missions mean the funding and creation of new squads
Squads become more granular with time, budget, and complexity of the business and the product
Squads can be assigned more headcount and they can help hire for themselves

Accountable for outcomes