Why Engineering Managers Use the Squad Model

🔥 We split our engineering team before it broke… and that’s exactly why it worked. The strange part? Nothing looked broken. Shipping was solid. Velocity was green. No fires. No drama. But under the surface… things were getting heavy. More cross-dependencies. More “quick syncs” turning into >10 people meetings. More context switching. More moments where 1 change required 6 people to “stay in the loop.” Classic signs of a team that’s too big to stay fast, but not broken enough to force change. We didn’t wait for the slowdown. We evolved the structure before the bottleneck became visible. Because growing teams need growing structures. And every seasoned CTO will tell you the same thing: after ~8–12 engineers, coordination becomes the real constraint. 🚀 So we made the call: two focused squads. Prospect → Lead discovery + intake (data pipelines, enrichment, integrations, workflow automation) Engage → Outreach + follow-up (campaigns, inbox, dialer, analytics, identity, chrome extension) Clear domains. Clear ownership. No overlaps. Two proper two-pizza teams that can move fast without tripping over each other. And for everything that didn’t fit neatly into either domain, infra work, shared tools, odd cross-team tasks, we carved out separate capacity so it wouldn’t derail the core squads. That one choice eliminated a ton of hidden drag. ⚡ The impact was immediate. Context switching collapsed. Engineers stay in one world per day instead of juggling six. PRs fly through. Decisions now happen inside the squad, not across the org chart. Planning became simple. Each squad runs its own backlog, its own cadence, its own momentum. Ownership went up. Every engineer is getting to know their domain end-to-end, and it shows in the work. The vibe changed. Same speed, far less chaos. More flow. Less noise. Actual calm execution. A month in, the signal is unmistakable: Splitting didn’t slow us down, it kept us fast as we grew. 🧠 The real lesson? If you want engineering to stay fast, you can’t just add people. You have to reshape the system they operate in. Small, focused teams with real ownership will always outship a single bloated group. We didn’t wait for a crisis to restructure. And that one proactive move preserved our momentum when it mattered most.

There’s Only One Team. The Company. Here’s the mindset shift that changes everything: stop thinking in departments. There’s no “Product team,” “Design team,” or “Backend team.” There’s only the company—and the only structure that actually ships is the squad. At 10Web, we organize around outcomes. Each squad is a small, multidisciplinary unit with one job: ship a result. When priorities shift, squads reform. It’s not a matrix. It’s not agile theater. It’s a working system. This mindset is how we shipped—in just one quarter—a full Website Builder API, an upgraded AI Co-Pilot, a redesigned Dashboard, new brand creation assets, and more. Why squads work: - Context stays intact. Handoffs between departments bleed nuance. - Squads keep the full picture from idea to launch.Focus is clear. - Squads aren’t built to exist—they’re built to deliver. - Hiring aligns from day one. When you hire for a “department,” you eventually have to renegotiate—are they ready to join a squad? Ready to move to another? But when you hire for the team—you hire directly into a squad-focused culture. This isn’t just about agile. It’s a mindset for startups serious about momentum. If you want to build fast, pivot fast, and scale without bureaucracy—start by building squads.

Org Design Shapes Impact Some of the most talented teams I’ve worked with weren’t held back by skill or intent. They were held back by how they were organized. In functionally aligned orgs (EE, ME, SW, etc.), two patterns keep showing up: 1) Conway’s Law meets communication drag When work spans across specializations, the default communication paths are engineer-to-engineer. But most engineers (yes, generalizing) don’t wake up excited to design human systems. The result: -->Assumptions instead of context -->Coordination friction -->Late or missing alignment In squad-based orgs, the onus of cross-functional communication shifts to PMs and program leads—people who enjoy and thrive on context and over-communication. That shift accelerates clarity and momentum. 2) Context switching erodes accountability Fractional allocations—25% on A, 50% on B, 25% on C—create confusion. The result: -->No clear ownership of outcomes -->Everyone’s busy, but impact is blurry -->Priorities get shaped by someone removed from the business need Even with good intent, you end up optimizing for activity—not results. *Squads are more than collaboration units-> They’re a dependency-minimizing construct.* If you mapped the same scope of work on a functional org chart, the dependencies and handoffs would be overwhelming. Squads can be drawn to cluster critical skills and minimize cross-team reliance—engineering velocity by design. //Here’s the heart of it: The best work happens at the intersection of ikigai. What we love. What we’re good at. What the team truly needs. Org design either enables that alignment—or fragments it. Org design is execution strategy. It’s team culture. It’s a multiplier. Break the silos! #OrgDesign #ProductLeadership #ProductStrategy #EngineeringLeadership #ikigai #crossfunctional #squads

💡 **On super charging execution with autonomous product squads** A lot of product teams today operate as 'product squads' - cross functional teams consisting of a PM, a few engineers, and a designer, working together to solve a customer problem. This model is successful because it gives product teams a lot of autonomy - which in turn leads to increased velocity of shipping, and velocity is a competitive advantage in fast growing markets. (Remember move fast and break things?) ❌ But lots of teams are doing the squad model wrong. If you're a product squad where the product manager has to write fully baked PRDs before the design or engineering team is brought in, you're missing out on utilising the superpower of this model. Product squads work best when every team member understands the customer problem deeply, and uses their specific functional expertise to contribute to the solution. The job of the PM is to bring the team close to the customer, set context for the problem, and create artefacts to involve the whole squad in the solution process. 📄 A great artefact to use here is the PRD. PMs should visualise the PRD as a living document, where the PM starts with context on the problem statement, identifies potential success metrics, and outlines a set of initial solutions. From here on, designers jump in to outline customer research or build quick wireframes and engineers break down the technical requirements, all while keeping the problem statement in mind. 👨🏭 The PMs job is to hold this co-creation process together, and the output is a problem solution document which the entire squad has contributed to, and hence owns very deeply - the perfect recipe to generate autonomy. Note 1: It's also helpful to visualise the working model of a product squad as a circular process of co-creation, instead of a linear process starting from PRD creation to design handover to engineering execution. (see attached image) Note 2: A more extreme analogy - the linear product development process is a leftover of the services mindset followed by large outsourcing companies. This is not where today's product teams want to be.