Forming Autonomous Squads with Clear Missions
This skill teaches you how to define, staff, and launch cross-functional squads that own a clear product mission and can deliver value end-to-end without depending on other teams for day-to-day execution.
Start by identifying a discrete product area or user outcome that a single team can own end-to-end. Staff the squad with every discipline needed to ship independently, typically 6-8 people including engineering, design, and product. Write a one-sentence mission that defines the outcome the squad is accountable for, not the features it builds. Give the squad authority over its own backlog, process, and technical decisions within guardrails set by the broader tribe.
Outcome: You produce a fully defined squad with a named mission, a staffing roster covering all required disciplines, explicit ownership boundaries, and documented autonomy guardrails, ready to begin delivering independently.
Prerequisites
- Basic understanding of Agile team structures and cross-functional delivery
- A product or service with enough scope to divide into distinct outcome areas
- Organizational buy-in from leadership to delegate decision-making authority to teams
- Familiarity with the Spotify squad model and its core vocabulary (squads, tribes, chapters, guilds)
Overview
Forming autonomous squads is the foundational act of the Spotify Squad Model. Before you can organize tribes, run chapters, or build guilds, you need squads that actually work as self-sufficient delivery units. A squad is a small, long-lived, cross-functional team that owns a specific slice of the product and has the authority to decide what to build, how to build it, and how to release it. The squad is not a project team assembled for a temporary initiative. It persists across quarters and evolves its mission as the product matures. Getting squad formation right determines whether your adoption of the spotify squad model creates genuine autonomy or just rearranges org chart boxes.
The specific problem this skill solves is the ambiguity that plagues most attempts at team-level autonomy. Teams are told they are "empowered" but lack a clear mission, depend on three other teams for every release, or have no product owner making prioritization calls. The result is a squad in name only, with all the coordination overhead of a component team plus the expectation that it should somehow move faster. Forming squads well means scoping the mission tightly enough that the squad can ship without external blockers most of the time, staffing it with every discipline needed for end-to-end delivery, and writing a mission statement that makes prioritization decisions obvious.
The concrete artifact you produce is a squad charter: a short document (one page, not ten) that names the squad, states its mission as a user-outcome sentence, lists its permanent members and their roles, defines what the squad owns and does not own, and specifies the autonomy guardrails (what decisions the squad can make alone versus what requires tribe-level alignment). This charter becomes the reference point for onboarding new members, resolving ownership disputes, and evaluating whether the squad's work is on-mission. When you finish this skill, you will have a squad that can start its first sprint with a clear understanding of what success looks like and who is responsible for getting there.
The skill sits at the very beginning of the spotify squad model adoption journey. It feeds directly into organizing squads into tribes, which groups related squads under shared strategic goals, and into running chapters, which connects people of the same discipline across squads. Without well-formed squads, neither of those structures has a stable foundation to build on.
How It Works
The mental model behind squad formation rests on one principle: a squad should be the smallest possible group that can deliver a meaningful user outcome without waiting on another team. This is not the same as a feature team. A feature team builds whatever is next on a shared backlog. A squad owns an outcome and decides for itself what to build to move that outcome. The distinction matters because ownership changes behavior. When a squad owns "new user activation" rather than "build the onboarding wizard," it starts asking different questions, running its own experiments, and caring about metrics instead of just shipping tickets.
The mission statement is the single most important element of squad formation, and the one most teams get wrong. A good mission describes a user outcome or business capability, not a technology layer or a feature set. "Increase the percentage of new users who complete their first project within 48 hours" is a mission. "Build and maintain the onboarding service" is a component ownership statement. The difference is that the mission gives the squad a compass for prioritization. When two potential features compete for attention, the squad can ask which one moves the mission metric more. Component ownership gives no such guidance.
Staffing follows from the mission. Once you know what the squad must deliver, you can identify the disciplines required. A typical squad in the spotify squad model includes backend and frontend engineers, a designer, a product owner, and sometimes a QA specialist or data analyst. The exact composition depends on the mission. A squad focused on data pipeline reliability might not need a designer, while a squad focused on checkout conversion might need two. The key constraint is size: squads work best at 6-8 people. Below 6, you lack the breadth of skills for true autonomy. Above 8, communication overhead rises sharply and the squad starts to fragment into sub-groups.
The product owner role deserves special attention. In many organizations, product managers are spread thin across multiple teams. In the squad model, each squad has a dedicated product owner who is a full member of the squad, not a visitor. The product owner translates company strategy into a squad-level backlog, makes prioritization calls daily, and represents the squad in tribe-level planning. Without a dedicated product owner, the squad either drifts (no one sets direction) or stalls (decisions require escalation to someone who is in three other meetings).
Autonomy guardrails define the boundaries of squad decision-making. Full autonomy does not mean the squad can do anything it wants. It means the squad can make any decision within its mission scope without asking permission. Guardrails specify what falls outside that scope: shared platform conventions, security requirements, data privacy rules, release cadence agreements. These guardrails are not bureaucratic controls. They are the agreements that let multiple squads operate independently without breaking each other's work. The skill of balancing autonomy and alignment explores this tension in depth, but during formation you need at least a first draft of guardrails so the squad knows where its freedom starts and stops.
Step-by-Step
Step 1: Map Your Product Into Outcome Areas
Before forming any squads, list the distinct user outcomes or business capabilities your product delivers. " They are things users care about: onboarding, search and discovery, payments, content creation, notifications, reporting. Write each outcome as a short phrase from the user's perspective. Group related features and surfaces under each outcome.
You should aim for 4-12 outcome areas depending on your product's complexity. Each outcome area is a candidate squad mission. If you end up with more than 12, you are probably slicing too thinly, and some of those areas should be combined. If you have fewer than 4, your product may not yet need the full squad model structure.
Tip: If you struggle to map outcomes, start from the user journey instead. Walk through what a user does from signup to daily usage and mark every point where a distinct team could own the experience. The natural seams in the user journey often reveal the right squad boundaries.
Step 2: Write a One-Sentence Mission for Each Squad
For each outcome area, write a single sentence that describes what the squad exists to achieve. " The mission should be specific enough to guide prioritization but broad enough to last at least 6-12 months without a rewrite. Avoid naming specific features in the mission. If the mission says "build a drag-and-drop editor," it stops being useful the moment the editor ships.
Test each mission by asking: could two reasonable people disagree about which backlog item is more important for this mission? If the mission does not help resolve that disagreement, it is too vague.
Tip: Read all squad missions side by side. If two missions overlap significantly, you will get ownership conflicts later. Resolve overlaps now by making one squad clearly primary for the contested area and the other a contributor or consumer.
Step 3: Identify Required Disciplines Per Squad
For each squad mission, list every discipline the squad needs to deliver independently. Start with the baseline: at least one backend engineer, one frontend engineer, one designer, and one product owner. Then ask what the mission specifically demands. A data-heavy mission might need a data engineer or analyst.
A mission involving third-party integrations might need someone with API and partnership experience. A mission touching compliance might need access to legal review, though that person does not need to be a full squad member. Write out the minimum viable staffing and the ideal staffing. The minimum should be enough to ship a meaningful increment in a two-week sprint.
The ideal fills gaps that the minimum leaves, such as dedicated QA or a technical writer.
Tip: Do not staff for peak load. Staff for steady-state delivery. If a squad occasionally needs a skill it does not have (such as a data scientist for a one-time analysis), handle that through chapter or guild collaboration rather than permanently adding a role.
Step 4: Assign People to Squads
Map real people to the roles you identified. Each person belongs to exactly one squad as their primary team. This is critical. Splitting people across squads destroys the autonomy that makes the spotify squad model work, because the person becomes a bottleneck that forces coordination between squads.
If you do not have enough people to fully staff every squad, reduce the number of squads rather than spreading people thin. Three well-staffed squads will outperform six under-resourced ones. During assignment, consider both skill match and interpersonal dynamics. A squad that has all the right skills but constant interpersonal friction will underperform a slightly less skilled squad that collaborates well.
Talk to individuals about their preferences where possible.
Tip: If a specific discipline is scarce (for example, you have two designers for five squads), prioritize putting designers on squads whose missions are most user-facing. The other squads can pull design support through chapter rotations or guild consultations for specific projects.
Step 5: Appoint a Dedicated Product Owner for Each Squad
Every squad must have a product owner who is a permanent, dedicated member of the squad. The product owner is responsible for maintaining the squad backlog, making day-to-day prioritization decisions, representing user needs within the squad, and communicating the squad's roadmap to stakeholders. This person does not need the title "Product Manager" in the org chart, but they need the authority to say "we are building X this sprint, not Y" without escalating to their manager every time. If your organization does not have enough product managers to dedicate one per squad, consider whether a senior engineer or a designer with strong product instincts can fill the role.
The key requirement is decision-making authority, not a specific job title.
Tip: The biggest failure mode for product owners in squads is being pulled into tribe-level planning so heavily that they are absent from the squad's daily work. Block at least 60% of the product owner's time for squad-level activities: backlog refinement, user research, sprint planning, and pairing with engineers on scope decisions.
Step 6: Define Ownership Boundaries and Dependencies
For each squad, write a clear statement of what the squad owns and does not own. Ownership means the squad has the authority to change that code, that user flow, or that data pipeline without asking another squad's permission. Document shared areas explicitly: if two squads both touch the checkout flow, specify which squad owns the payment form and which owns the order confirmation. Then map remaining dependencies.
These are cases where the squad needs something from another team to deliver. Common examples include shared platform services, design systems, and data infrastructure. For each dependency, decide whether it is acceptable (the platform team provides an SLA and the squad plans around it) or a blocker that needs resolution (the squad cannot ship without a feature that another team has not built yet). Aim for no more than one or two hard dependencies per squad.
Tip: Draw a simple dependency diagram across all squads. If any squad has arrows pointing to three or more other squads, its mission is probably too broad or its boundaries are wrong. Redraw the boundaries until most squads can operate with minimal inter-squad coordination.
Step 7: Document Autonomy Guardrails
Write down the decisions the squad can make independently and the decisions that require tribe-level or company-level approval. Autonomous decisions typically include: what to build next from the backlog, how to implement technical solutions, which experiments to run, when to release, and how to organize their own work process (Scrum, Kanban, or something else). Decisions requiring alignment typically include: changes to shared APIs or data contracts, pricing changes, major UX pattern deviations from the design system, security-sensitive changes, and commitments that affect other squads' roadmaps. Write these guardrails as a simple two-column list.
The goal is to make it obvious for any squad member whether a specific decision needs external input. Review guardrails with the squad and adjust based on their feedback before finalizing.
Tip: Start with more autonomy than feels comfortable. You can always add guardrails later if problems emerge, but starting too restrictive signals distrust and undermines the squad's motivation to take ownership. The default should be "the squad decides" unless there is a concrete reason for an exception.
Step 8: Assemble the Squad Charter
Compile everything into a one-page squad charter. The charter includes: squad name, mission statement, team roster with roles, ownership boundaries (what the squad owns and does not own), key dependencies, autonomy guardrails, and the primary metric the squad uses to evaluate its progress toward the mission. Keep the charter to one page. If it is longer, you are over-specifying.
The charter is a living document that the squad revisits quarterly. Share the charter with adjacent squads so everyone knows who owns what. Store all charters in a shared location (a wiki, a Notion workspace, a shared drive) where any employee can find any squad's charter in under 30 seconds.
Tip: Include a "last reviewed" date on the charter. Stale charters cause confusion. Set a calendar reminder for the squad to review and update their charter every quarter, even if nothing has changed. The review itself reinforces shared understanding.
Step 9: Launch the Squad with a Kickoff Session
Bring the squad together for a kickoff session lasting 90-120 minutes. Walk through the charter together. Discuss the mission and make sure every member can explain it in their own words. Review the ownership boundaries and flag any ambiguities.
Agree on initial working agreements: when standups happen, how the squad communicates (Slack channel, in-person, async), how decisions are made when the product owner is unavailable, and what the squad's first sprint goal will be. End the kickoff by having the squad identify its first three priorities from the backlog. This is not a ceremony to repeat. It is a one-time launch event that aligns the squad before it starts delivering.
After the kickoff, the squad owns its own process and does not need external facilitation for daily work.
Tip: Ask each squad member to share what they are most excited about and most worried about regarding the squad's mission. This surfaces hidden concerns early and builds psychological safety from day one.
Examples
Example: Early-Stage SaaS Startup with 20 Engineers
A B2B SaaS startup with 20 engineers, 3 designers, and 3 product managers wants to move from a single monolithic team to squads. The product is a project management tool with distinct areas: onboarding, task management, reporting, and integrations. Leadership wants teams to move faster by reducing coordination overhead.
The head of engineering maps the product into four outcome areas: new user activation, core task management, analytics and reporting, and third-party integrations. With 20 engineers, they can staff three squads of 6-7 (keeping one squad unstaffed for now). They prioritize by business impact: activation, task management, and integrations each get a squad. Reporting is deprioritized and its small backlog is absorbed by the task management squad temporarily.
Each squad gets one designer and one PM as product owner. " Ownership boundaries are drawn around code repositories and user flows. Charters are written, shared in Notion, and reviewed by all three squads together to resolve two overlap areas (the signup flow, which is split between activation and task management, is assigned to activation). Each squad runs a 90-minute kickoff and starts its first sprint the following Monday.
Example: Mid-Size B2C Company Splitting a Large Team
A consumer mobile app company has a single 30-person product team building a fitness tracking app. Releases are slow because everything goes through one backlog, one PM, and one release train. The VP of Product wants to adopt the spotify squad model to parallelize delivery. The app has clear user journeys: workout tracking, nutrition logging, social features, and premium subscription management.
The VP maps four outcome areas aligned to user journeys. Each squad gets 7-8 people from the existing team. Staffing is done by asking engineers which area they are most interested in, then adjusting for skill balance. Two engineers requested the social squad but the nutrition squad had no iOS engineer, so one engineer moves to nutrition after a conversation about growth opportunities.
Four product owners are designated: two existing PMs each take a squad, one senior designer with product instincts takes the social squad's PO role, and one engineering manager transitions into the premium squad's PO role. " Dependencies are mapped. The premium squad depends on the payment platform maintained by an infrastructure team outside the squads, so an SLA is negotiated: payment API changes have a 5-business-day response commitment. Charters are stored in Confluence.
The company runs a single all-hands to announce the new structure, followed by individual squad kickoffs the same week.
Example: Enterprise Organization Forming Squads Within a New Tribe
A large financial services company is creating a new tribe of four squads to rebuild its customer onboarding platform. The organization has 300 engineers across multiple business units. The tribe will have 30 people pulled from different departments. Many have never worked together before. Regulatory requirements add complexity because certain changes require compliance review.
The tribe lead starts by mapping the onboarding journey into four outcome areas: identity verification, account setup, initial funding, and compliance documentation. Each area becomes a squad mission. Staffing is assembled from volunteers across departments, with the tribe lead negotiating with department heads for dedicated allocation (no splitting). Each squad gets 7 people: 4 engineers, 1 designer, 1 PO, and 1 QA specialist.
The compliance documentation squad also gets a part-time legal advisor through a guild arrangement. Autonomy guardrails are more detailed than in a startup: squads can make any UX or technical decision within their area, but changes to data retention, encryption, or customer-facing legal language require a 48-hour compliance review. This is documented as a guardrail, not an approval process. The squad submits the change, and unless compliance flags it within 48 hours, it proceeds.
Charters include a dependency section noting that all four squads share a common design system maintained by a separate platform squad in another tribe. The tribe lead runs a combined kickoff for all four squads, then each squad runs its own internal kickoff the next day. Within two weeks, all four squads are running independent sprints with their own cadences.
Example: Remote-First Company Forming Distributed Squads
A fully remote company with 45 engineers across four time zones (US Pacific, US Eastern, Western Europe, and India) wants to form squads for its e-commerce platform. The challenge is ensuring squads can operate autonomously despite geographic distribution. The product areas are catalog management, checkout and payments, order fulfillment, and customer support tooling.
The VP of Engineering maps four outcome areas and adds a constraint: each squad must have at least 4 hours of overlapping working time among all members. This rules out staffing a single squad with both US Pacific and India-based engineers. Squads are staffed with time zone compatibility as a hard constraint and skill match as a secondary criterion. The checkout squad has 3 US Eastern engineers, 2 European engineers, 1 European designer, and 1 US Eastern PO, giving 5 hours of daily overlap.
The fulfillment squad is US-Pacific plus India with overlap from 6:30-10:30 AM Pacific. Each squad establishes a persistent virtual workspace: a dedicated Slack channel, a daily async standup bot, and two synchronous meetings per week during overlap hours. Missions follow the same outcome-based format. " Ownership boundaries are drawn around services and database schemas.
Guardrails include a shared API versioning policy (no breaking changes without a two-week deprecation notice) and a requirement that all squads use the same observability stack. Charters are stored in a shared GitHub repository as markdown files, making them version-controlled and searchable.
Best Practices
Keep squads between 6 and 8 people. Below 6, you lack the cross-functional coverage for real autonomy, and the team becomes fragile when someone is out sick or on vacation. Above 8, communication overhead grows quadratically, sub-groups form naturally, and the squad loses its cohesion. If a mission demands more than 8 people, split it into two squads with distinct sub-missions.
Write missions as user outcomes, not feature lists. A mission like "improve trial-to-paid conversion" gives the squad a durable compass that survives any individual project. A mission like "build the pricing page redesign" expires the moment the page ships and leaves the squad without direction. Outcome-based missions also make it easier to measure squad impact with a single metric.
Assign each person to exactly one squad. Splitting people across squads introduces coordination overhead, creates scheduling conflicts, and dilutes individual ownership. If someone is on two squads, they are effectively on zero squads because neither team can rely on their full attention. Reduce the number of squads if you lack the headcount for full staffing.
Ensure every squad has a dedicated product owner who spends the majority of their time with the squad. A product owner who visits the squad once a week for backlog grooming is a stakeholder, not a team member. The squad needs someone who can answer prioritization questions the same day they arise, not next Tuesday.
Review and update squad charters quarterly. Missions evolve as the product matures. Ownership boundaries shift as new squads form or existing ones merge. A charter that was accurate six months ago may now be misleading. The quarterly review keeps the charter useful and surfaces organizational drift before it causes conflict.
Make all squad charters visible to the entire organization. Transparency in ownership prevents duplicate work, reduces "who owns this?" questions, and helps new employees understand the team structure quickly. If finding a squad's charter requires asking three people, you have a discoverability problem that will generate recurring coordination overhead.
Co-locate squad members physically or establish a persistent virtual space. A squad that shares a Slack channel, a video room, and a task board operates as a unit. A squad whose members communicate only through formal meetings and email threads operates as a committee. The informal, daily, low-friction communication is what makes autonomy practical.
Resist the urge to reorganize squads frequently. Squad stability builds trust, shared context, and velocity. A squad that has worked together for six months can move twice as fast as a newly assembled one. Reorganize only when the product strategy fundamentally shifts, not because of quarterly planning convenience.
Common Mistakes
Defining squad missions around technical components instead of user outcomes
Correction
When a squad is defined as "the database team" or "the API team," it becomes a service provider to other squads rather than an autonomous delivery unit. The squad cannot prioritize its own work because priority depends on which other squad is asking loudest. You can spot this mistake when a squad's backlog is mostly requests from other teams rather than items the squad chose. Rewrite the mission around the user outcome the component supports: instead of "own the notification service," try "ensure users are informed about events that matter to them within 60 seconds."
Splitting individuals across multiple squads to cover skill gaps
Correction
This happens when a scarce discipline like design or data science is spread across more squads than it can support. The symptom is people attending standups for two or three squads and never being fully present for any. The real cost is that each squad plans around uncertain availability, leading to blocked work and frustration. Instead, reduce the number of squads to match your staffing reality, or use chapter and guild structures to provide part-time specialist support without splitting anyone's primary team assignment.
Launching squads without explicit ownership boundaries
Correction
When two squads both believe they own the same area of the product, conflicts emerge during implementation: duplicated work, contradictory changes, and escalation battles. This usually happens because leadership announced squad missions but never mapped those missions to specific code, data, and user flows. Catch this early by requiring every charter to include a "we own / we do not own" section and reviewing all charters side by side before launch. Any overlap must be resolved with a clear primary owner before the squads begin their first sprint.
Making squads too large to stay cohesive
Correction
Organizations often create squads of 10-15 people because they want every possible skill represented. The result is a team where most people are passive in meetings, decisions take longer because more voices must be heard, and sub-groups form that operate independently anyway. Watch for signs: standups exceeding 15 minutes, members who rarely speak, or informal sub-teams emerging with their own backlogs. Split the squad along a natural mission seam and give each half its own charter.
Two squads of 7 will deliver more than one squad of 14.
Treating the product owner as a part-time role filled by a manager
Correction
When a director or VP tries to serve as product owner for a squad while also managing a department, the squad's backlog stagnates. The product owner is unreachable for daily questions, sprint planning gets rescheduled, and the squad defaults to building whatever the engineers think is most interesting. The fix is to delegate the product owner role to someone who can spend at least 60% of their working time with the squad. This may mean promoting a senior IC, hiring specifically for the role, or reducing the number of squads to match available product talent.
Setting guardrails so restrictive that autonomy is theoretical
Correction
Some organizations adopt the spotify squad model vocabulary but require squads to get approval for architecture decisions, release timing, sprint scope, and even tool choices. The squad has all the accountability of ownership but none of the authority. You can detect this when squad retrospectives repeatedly surface "waiting for approval" as a blocker. Audit the guardrails list and ask for each item: has this guardrail ever prevented a real problem?
If not, remove it. Default to trusting the squad and add guardrails only in response to actual incidents.
Other Skills in This Method
Organizing Squads into Tribes for Strategic Alignment
How to group related squads into tribes, set tribe size limits, appoint tribe leads, and maintain alignment across squads without sacrificing autonomy.
Scaling Agile Practices Using Spotify Structures
How to use the Spotify organizational model as a scaling framework, including when to split tribes, spawn new squads, and evolve governance as the company grows.
Evaluating Spotify Model Tradeoffs and Common Pitfalls
How to assess the pros, cons, and known failure modes of the Spotify Model so you can make an informed adoption decision and avoid cargo-culting.
Building Guilds for Cross-Tribe Knowledge Sharing
How to create and sustain voluntary, company-wide guilds that share knowledge, tooling, and best practices across tribe boundaries.
Balancing Squad Autonomy with Organizational Alignment
Techniques for setting guardrails, defining loose coupling and tight alignment, and using OKRs or mission briefs so squads stay autonomous yet strategically coherent.
Adapting the Spotify Model to Your Organization
A step-by-step approach for implementing and customizing the squad/tribe/chapter/guild structure to fit your company's size, culture, and existing processes.
Running Chapters to Build Discipline-Specific Excellence
How to establish and facilitate chapters—groups of specialists across squads within a tribe—to standardize practices, mentor members, and manage career growth.
Frequently Asked Questions
How do I decide the right number of squads for my organization?
Count the number of distinct user outcomes your product needs to serve, then compare that to your available staffing. Each squad needs 6-8 dedicated people. If you have 25 engineers and identify 6 outcome areas, you can only staff 3-4 squads properly. Form fewer, well-staffed squads rather than many under-resourced ones. You can always add squads later as you hire. The spotify squad model works better with 3 strong squads than 6 weak ones.
What should I do when I don't have enough product managers for one per squad?
The product owner role requires decision-making authority and daily availability, not a specific job title. Senior engineers, designers, or team leads with strong product instincts can serve as effective product owners. The key test is: can this person say "we are doing X instead of Y this sprint" without escalating? If yes, they can fill the role. Invest in coaching them on prioritization frameworks and stakeholder communication. Do not split one PM across two squads as a workaround.
How long should a squad's mission last before it changes?
A well-scoped mission should last 6-18 months. If missions change every quarter, they are probably scoped at the project level rather than the outcome level. Rewrite the mission to focus on a durable user outcome rather than a specific deliverable. That said, missions should evolve as the product matures. An activation squad might shift from "get users to first value" to "get users to habitual usage" as the initial activation problem gets solved. Review missions quarterly and adjust only when the strategic landscape genuinely shifts.
Should I form squads before or after organizing tribes?
Form squads first. Tribes are groupings of related squads, so you cannot define tribe boundaries until you know what squads exist and what they own. Start by mapping your product into outcome areas and forming squads around them. Once you have 3-5 squads that share strategic territory, group them into a tribe. See [organizing tribes for alignment](/skills/organizing-tribes-for-alignment) for the next step in the process.
How do I handle a squad that has too many external dependencies to operate autonomously?
First, check whether the dependencies are real or artifacts of organizational habit. Many dependencies exist because people are used to asking permission, not because technical coupling requires it. For genuine dependencies, you have three options: redraw the squad boundary to absorb the dependency, negotiate an SLA with the providing team so the squad can plan around it, or create a shared service with a clear API contract. If a squad has more than two hard dependencies that regularly block its sprint, its mission scope is probably too broad and should be narrowed.
Why does my squad's autonomy keep getting overridden by management decisions?
This usually happens because autonomy guardrails were never documented, so both the squad and management have different assumptions about who decides what. Write down the guardrails explicitly: which decisions the squad makes alone, which require consultation, and which require approval. Share this with leadership and get explicit agreement. If leadership continues overriding documented autonomy, the issue is organizational trust, not squad formation. Address it directly with the decision-makers, ideally by showing examples where squad-level decisions led to better outcomes than top-down ones.
Can a squad be smaller than 6 people and still function?
A squad of 4-5 can work for tightly scoped missions where the squad genuinely needs fewer disciplines, such as an internal tools squad staffed with 3 engineers and 1 PO. But below 4, you lose resilience (one person on vacation halts progress) and cross-functional breadth. If you find yourself forming squads of 3, consider whether the mission is too narrow and should be combined with a related area. The spotify squad model assumes squads can deliver independently, which requires enough people to cover the full delivery cycle.