The team structure defines what will be delivered. And more than that: it defines whether what will be delivered truly solves the business problem. In this post, we explore how to assemble, size, and manage high-performance squads.
1. What a squad needs to be strategic (not just technical)
The difference between a technical team and a strategic squad is the same as between a group of talented musicians and a band. Musicians may be individually brilliant, master their instruments, and have a deep knowledge of music theory. But if each one plays a different song, the result is noise. A band has a shared vision, a common purpose, and most importantly: understands that success is not measured by the technical complexity of the execution, but by the audience's reaction. Strategic squads don't exist to write elegant code. They exist to solve business problems through technology.
The first requirement for a strategic squad is autonomy with accountability. Autonomy without accountability is anarchy. Accountability without autonomy is micromanagement. The delicate balance happens when the squad has the freedom to decide the "how" but absolute clarity about the "what" and "why". Netflix exemplifies this with its "context, not control" principle. Squads receive rich context about business objectives, constraints, and acceptable trade-offs, then have complete freedom to find the best solution. This requires squad maturity and leadership courage. Many companies say they want this but back down at the first mistake.
The focus on outcomes instead of outputs completely transforms the squad dynamic. A traditional technical team receives requirements and delivers features. A strategic squad receives problems and delivers solutions. The difference seems subtle but is fundamental. When you ask to build a login system, you get a login system. When you ask to reduce friction in user conversion, you might get social login, simplified onboarding, or complete elimination of registration. The strategic squad questions the problem before jumping to the solution. Often, the best technical solution is not to build anything new, but to eliminate something existing.
The concept of "missionary teams vs. mercenary teams," popularized by John Doerr, captures another critical dimension. Mercenaries build what they're told, charge by the hour, and leave when the project is finished. Missionaries believe in the mission, feel ownership of the result, and stay to see the impact. Strategic squads are always missionaries. They not only understand the business, they care about it. They celebrate when business metrics improve, not when deployment happens without bugs. They feel pain when users complain, even if the code is technically correct.
Proximity to the real problem is inversely proportional to the organizational distance from the user. Squads that never talk to users inevitably build solutions for imaginary problems. Strategic squads have direct and frequent contact with those who use the product. Engineers participate in support calls. Product managers work one day a month in customer service. Designers observe real users using the product in a real context. This proximity generates empathy, and empathy generates better solutions. It's impossible to be strategic operating in a vacuum.
The size and composition of the squad determine its strategic capacity. Amazon's two-pizza rule isn't about saving money on food, it's about communication dynamics. With five people, there are ten communication channels. With ten people, there are 45 channels. With twenty, there are 190. The complexity of communication grows exponentially, but human processing capacity does not. Strategic squads remain small not for economic reasons, but for effectiveness. Small enough so that everyone knows what everyone else is doing. Large enough to have the necessary skills. Generally between five and nine people.
2. Profiles and roles: beyond devs and QAs
The traditional composition of technical teams — developers, QA, and perhaps a Scrum Master — is a remnant of an era when technology was a support department, not core to the business. Modern squads that deliver real value need diversity of perspectives and skills that go far beyond writing and testing code. The mistake is not having developers and QAs. It's having only developers and QAs.
The role of the Product Manager in a strategic squad is fundamentally different from the traditional Product Owner. A traditional PO translates business requirements into technical stories, manages the backlog, and accepts deliverables. They are essentially a translator and administrator. A strategic PM is the CEO of the product. They define the vision, prioritize ruthlessly, say no more than yes, and are accountable for the product's success or failure. They don't manage the squad, but lead through influence and clarity of purpose. The best PM is the one who makes the squad successful, not the one who delivers the most features.
Design in the strategic squad it is not about pretty screens. It's about creating beautiful screens. It's about solving problems elegantly. The designer doesn't receive wireframes to embellish. They participate from the problem definition, question assumptions, and propose solutions that sometimes don't involve any interface at all. The best designers in squads are those who understand enough code to know what's easy and difficult, enough business to understand trade-offs, and users deeply enough to defend their interests. They are the user consciousness embedded in the squad.
The presence of a Data Analyst embedded in the squad completely transforms the quality of decisions. It's not someone who generates monthly reports. It's someone who answers questions in real time, identifies opportunities in data that others don't see, and above all, questions metrics and interpretations. When the PM says conversion dropped 10%, the analyst asks: in which segment? Is it statistically significant? Does it correlate with any event? Is it seasonality? Without this voice, squads operate in partial darkness, making decisions based on superficial interpretations of poorly understood numbers.
The most underestimated and frequently absent role is what I call the "Domain Expert". This is someone who deeply understands the business context in which the product operates. In fintech, it might be someone with a banking background. In healthtech, a healthcare professional. In edtech, an educator. This person prevents the squad from reinventing the wheel, violating non-obvious regulations, or creating technically perfect but practically useless solutions. Spotify has musicians in recommendation squads. Airbnb has hosts in experience squads. This expertise cannot be googled or learned in a sprint.
The most recent evolution is the inclusion of specialized engineering profiles that traditionally remained in silos. Embedded DevOps engineers ensure that the squad can deploy independently. Embedded security engineers ensure that security is not afterthought. Embedded machine learning engineers when the product has AI components. The alternative—relying on centralized teams—creates dependencies that kill speed and ownership. The cost of having these specialists in each squad is high, but the cost of not having them is often catastrophic.
3. Knowledge Management and Continuity
Knowledge in technical squads has a short half-life. People leave, context is lost, decisions are forgotten, and eventually nobody knows why the system works in that specific way. It's reverse archaeology: instead of discovering how ancient civilizations lived, we try to find out what developers from six months ago were thinking. Active knowledge management isn't a nice-to-have; it's a matter of survival for squads that want to maintain speed over time.
The fundamental problem is that critical knowledge usually resides in unstructured form in people's heads. John knows why that API has that specific timeout. Mary remembers that we tried microservices and it didn't work because of latency. Peter knows all the edge cases of the payment system because he debugged each one of them. When these people leave, the knowledge goes with them. The squad not only loses a member, but loses years of accumulated context. It's like organizational amnesia.
Documentation-as-code is the only approach that consistently works to keep documentation up-to-date. Documentation in separate wikis inevitably rots. Nobody remembers to update it. Worse, nobody trusts that it's up-to-date, so nobody consults it. When documentation lives alongside code, in the same repository, in the same pull request, it has a chance of surviving. README files, ADRs (Architecture Decision Records), inline comments that explain the why, not the what. Self-documenting code is a myth. Code can explain what it does, but it never explains why it exists.
Pair programming and mob programming are not about code quality or finding bugs. They are about knowledge distribution. When two people write code together, two people understand the decisions. When the entire squad works on a complex problem together, the entire squad shares the context. It's inefficient in the short term but essential in the long term. Knowledge redundancy is insurance against the bus factor. If only one person understands a critical part of the system, you don't have a squad, you have a walking single point of failure.
Deliberate rotation of responsibilities within the squad prevents the formation of knowledge silos. The backend developer who always takes care of the API needs to occasionally work on the frontend. The payments specialist needs to handle the notification system. It's not about everyone being a generalist, it's about everyone having an understanding of the whole. When each person only understands their part, no one understands the system. Systemic problems become invisible. Opportunities for global optimization are lost. The squad becomes a collection of specialists, not a cohesive team.
The concept of “institutional memory” goes beyond technical documentation. Why did we choose this architecture? What alternatives did we consider? What assumptions did we have? What has changed since then? These questions are impossible to answer without deliberate recording of decisions and context. Companies that maintain this well have superpowers: they can reassess decisions when context changes, avoid repeating costly mistakes, and onboard new members with a depth of context that normally takes years to accumulate.
4. How to measure delivered value (not just hours spent)
The software industry has a morbid obsession with activity metrics. Story points delivered, lines of code written, bugs fixed, commits pushed. These are metrics that measure movement, not progress. It's like measuring the success of a trip by the distance traveled, ignoring whether you're going in the right direction. Squads can have very high velocity while building features that nobody uses, optimizing systems that aren't bottlenecks, refactoring code that worked well. Activity theater: lots of action, little impact.
Real value is measurable change in business outcome attributable to the squad's work. It's not what the squad delivered. Recommendation system. The recommendation system increased engagement by 15%. It's not that we implemented a new checkout. It's that the new checkout reduced cart abandonment by 8%. It's not that we migrated to microservices. It's that the migration reduced time-to-market for features by 40%. The connection between technical work and business results needs to be explicit, measurable, and ideally causal, not just correlational.
The problem is that attribution is complex in complex systems. When ten squads work on the same product, who gets credit for the success? When multiple initiatives happen simultaneously, how do you isolate the impact of each one? The answer isn't to give up on measuring, but to be sophisticated about measurement. Controlled experiments, feature flags, cohort analysis, difference-in-differences are techniques that allow you to isolate impact even in complex environments. Squads that can't demonstrate impact can't justify their existence.
Leading indicators vs. lagging indicators is a critical distinction that few squads understand well. Revenue is a lagging indicator. When revenue falls, the problem happened weeks or months ago. It's too late to fix. Activation Rate, feature adoption, and user sentiment are leading indicators. They predict future problems while there is still time to act. Strategic squads obsessively monitor leading indicators and act proactively. Reactive squads wait for lagging indicators to worsen and then go into firefighting mode.
The concept of "impact per engineer" is controversial but important. It's not about making engineers compete. It's about understanding leverage. An engineer maintaining a legacy system that processes millions in transactions can have more impact than ten building experimental features. One who automates a manual process that saves a thousand hours a month has more impact than one who optimizes an already efficient algorithm. Talent allocation should follow opportunity for impact, not technical interest or organizational politics.
North Star metrics for squads need to balance ambition with controllability. A very high metric in the value chain (such as revenue) is influenced by many factors outside the squad's control. A very low metric (such as uptime) does not connect with business value. The sweet spot is metrics that the squad can directly influence but that clearly connect with business outcomes. For an onboarding squad, it could be "users who complete their first "Value action in 7 days." For the payments squad, "transaction success rate." For the infrastructure squad, "cost per transaction."
5. Allocation Models That Generate Direct Impact
How you allocate people to squads fundamentally determines what your organization can achieve. It's not just about the quantity of resources, but about the configuration of those resources. It's like the difference between having one hundred soldiers in a disorganized mass versus having the same one hundred soldiers organized into specialized tactical units. Structure determines capacity.
The feature teams versus component teams model is the most fundamental debate in allocation. Feature teams are organized around user journeys or product capabilities. They can deliver end-to-end value without dependencies. Component teams are organized around technical parts of the system. They are experts in their area but need to coordinate to deliver value. Spotify started with component teams, migrated to feature teams (squads), and found a hybrid where some squads are feature (focused on user experience) and others are component (platform squads that serve other squads). There is no universal answer. Context determines optimal configuration.
Stream-aligned teams, a concept from Team Topologies, represent an evolution of the feature team model. They are squads with ownership of a specific value stream, from concept to customer. They have all the necessary skills to deliver continuously. But they recognize that they cannot be experts in everything. Therefore, they are supported by enabling teams (which help to raise capabilities) and platform teams (which provide self-service). It's an acknowledgment that total autonomy is a myth. Well-managed interdependence is more realistic than total independence.
The dynamic versus static allocation model is another critical trade-off. Static allocation means fixed squads working in fixed areas indefinitely. It generates deep expertise and strong ownership, but can lead to local optimization and tunnel vision. Dynamic allocation means reconfiguring squads based on priorities. It allows maximum focus on the most important problems, but loses continuity and accumulated knowledge. Amazon uses a hybrid model: two-pizza teams are relatively stable, but people rotate between teams periodically. It maintains the benefits of stability without ossification.
The decision between dedicated versus shared squads for support functions such as DevOps, security, or data has profound implications. Embedding specialists in each squad maximizes speed and ownership but is expensive and can lead to fragmentation of practices. Centralizing specialists in support teams saves resources and standardizes practices, but creates dependencies and bottlenecks. The "enablement" model is a smart compromise: centralized specialists who work temporarily embedded in squads to increase capabilities, then move to the next squad. It's a teach-to-fish approach that scales expertise without creating permanent dependencies.
The concept of the "inverse Conway maneuver" suggests structuring squads to mirror the desired system architecture, not the current one. If you want microservices, create small, autonomous squads. If you want a modular monolith, create larger squads with overlapping responsibilities. The organizational structure inevitably manifests itself in the technical structure. Trying to change the architecture without changing the organization is like trying to change a shadow without moving the object. Companies that understand this reorganize squads as the first step in technical transformation, not the last.
Conclusion: Squads as living organisms, not allocable resources
The fundamental mistake organizations make is treating squads as fungible resources that can be allocated and reallocated like chess pieces. This mechanistic view ignores the fact that squads are complex living organisms with their own culture, unique interpersonal dynamics, and accumulated tacit knowledge that cannot be transferred or replicated. A high-performing squad is not the sum of talented individuals. It is an emergent system where the whole is dramatically greater than the sum of its parts.
Building a truly strategic squad takes time. Bruce Tuckman identified the phases of forming, storming, norming, and performing. Most companies dismantle squads before they reach performing, constantly resetting the cycle. It's like planting trees and uprooting them before they bear fruit because you decided you want different fruit. Investing in squad stability pays compound dividends. Squads that work together for years develop a shared language, implicit trust, and execution capabilities that new squads take months to develop.
The role of leadership is not to manage squads but to create conditions for them to thrive. This means protecting them from constant changes in priorities, organizational politics, and micromanagement. It means providing rich context but resisting the temptation to provide solutions. It means accepting that squads will make different decisions than you would, and that this is a feature, not a bug. Leadership that fails to do this will not have strategic squads, but rather disguised feature factories.
Measuring the success of squads needs to evolve beyond productivity metrics to impact and sustainability metrics. A squad that consistently delivers for years is worth more than one that experiences a burst of productivity followed by burnout. A squad that develops and retains talent is worth more than one that depends on constant hiring. A squad that continuously improves its processes and practices is worth more than one that always operates at its limit. These are values that are difficult to quantify but fundamental to long-term success.
The future of strategic allocation of technical teams is not about finding the perfect model, but about developing the capacity for continuous evolution. Markets change, technologies evolve, business needs pivot. Squads that thrive are those that maintain their identity and purpose while adapting practices and composition. They are antifragile: they get stronger with stress, they don't just resist it. Companies that cultivate these squads not only deliver better products. They create organizational capabilities that are impossible to copy and impossible to buy. It's the ultimate sustainable competitive advantage in a world where technology is a commodity.
Our company, Nous ,specializes in transforming groups of developers into high-performance, strategic squads. We combine decades of team-building experience with proven methodologies to create organizational structures that deliver consistent and measurable value.
