• Another PM Day
  • Posts
  • The Future of Teamwork: Mastering Modern Squad Dynamics

The Future of Teamwork: Mastering Modern Squad Dynamics

Reimagine Team Dynamics

In partnership with

Looking for unbiased, fact-based news? Join 1440 today.

Upgrade your news intake with 1440! Dive into a daily newsletter trusted by millions for its comprehensive, 5-minute snapshot of the world's happenings. We navigate through over 100 sources to bring you fact-based news on politics, business, and culture—minus the bias and absolutely free.

My favorite weekly finds

🛠️ Tools

  • Convo interviews your users in their language, giving you instant insights from hundreds of conversations at once.

  • With Brainnote, a powerful AI voice-to-text to summarize your ideas in seconds

  • Kick automates your bookkeeping tasks, like categorizing transactions and finding deductions (you can sign up + apply for the free tier to start).

  • Question Base is a Slack bot that acts like a team FAQ. Perfect for user docs. It saves answers to common questions and automatically shares them when the same questions are asked again.

  • Command AI helps your users understand your product by providing interactive tours, personalized tips, and a helpful assistant that shows how features work.

📰 News

👀 ICYMI

  • How AI Agent Platforms are Transforming Products (Listen or read Link)

  • 8 Key Points for Designing an AI Product (Listen or read Link)

  • The risk of ‘just executing’ as a Product Leader (Listen or read Link)

The Future of Teamwork: Mastering Modern Squad Dynamics

Why should I care?

If your company feels stuck, with slow progress and endless red tape, it’s a common problem. Many growing companies face this, and breaking through is critical to staying ahead.

A founder I worked with felt the same way. “We have all this talent,” he said, “but nothing gets done quickly.”

His tech company had grown fast but got tangled in management layers and siloed teams. Decisions took too long, and projects became more about managing old systems than delivering value.

I suggested empowered, cross-functional product teams. The CEO loved it and created a task force to lead the change.

The VPs liked the squad model—small, focused teams sounded great. But it wasn’t as simple as reorganizing. We had to overcome several challenges to make it work.

Squads promise faster innovation by cutting red tape, but there’s no single formula.

Truly empowering teams means changing leadership and accountability, not just org charts.

I tell teams that reorganizing isn’t a quick fix. Tech companies are complex, and each faces unique trade-offs. You’ll have to find your own path.

Here are a few tips to help make the transition smoother.

Let’s dive in.

1- Product Structure: No One-Size-Fits-All

The first step toward empowered product teams is deciding on your team topology—how you’ll split responsibilities among product managers.

Leave the engineering structure for later.

From my experience, there’s no one-size-fits-all solution. The best structure depends on your product, company culture, technology, and team dynamics. And even then, there’s no perfect answer.

Every setup has trade-offs, and balancing autonomy, flexibility, and stability is more art than science.

Start by splitting the team's work into product domains. You can organize by functionality, customer segments, stages in the customer journey, or strategic goals—whatever fits.

Think bigger than surface-level divisions. For example, a healthtech company had “integrations” as a domain, but it was too narrow.

We reframed it as “ecosystem assimilation,” covering integrations, reporting, role-based access, and more.

This gave the product manager a broader strategic role.

When evaluating your structure, ask yourself these key questions:

  • Does each product manager own a well-defined domain with room for vision?

  • Are responsibilities clearly assigned, with a single owner for each task?

  • Can teams work independently while staying aligned? How often will one PM depend on another?

Complete autonomy isn’t possible, but aim for 80%.

Ideally, PMs relying on each other should be the exception, not the rule.

2- Engineering structure can be different from Product

Once you understand your product domains, it’s time to focus on the engineering team structure.

While it’s important for the engineering topology to align with the product team structure—ensuring each team works with a single product manager—the HR reporting structure can be separate. I recommend decoupling the engineering HR structure from the team topology.

The traditional engineering model—with separate backend, frontend, and mobile teams—still serves a vital purpose. Even if everyone is full-stack, expertise in certain areas is essential.

Instead, keep the traditional structure and assign engineers to cross-functional squads for the best of both worlds.

Here’s how it works: Engineers stay in their specialized teams (e.g., backend) but join cross-functional squads. Each engineer works within a single squad led by a product manager, who can lead up to two squads. Engineers contribute their expertise while staying connected to their core teams.

When tackling complex tasks, they can consult their team lead and specialists to ensure system integrity. They also serve as liaisons, keeping everyone informed about ongoing projects.

This approach offers several advantages for smoother transitions:

  • You can pilot a single squad without disrupting the whole organization, allowing for iterative improvements.

  • Core teams retain ownership over their domains, minimizing the risk of breaking changes.

  • Engineers can be reassigned between squads easily since their reporting structure remains stable.

While this hybrid model might seem weaker than a full product team reorganization, it provides a more sustainable pace. Companies with cross-functional teams often spend significant time (up to 20%) on alignment. By keeping the engineering structure, you create touchpoints for essential collaboration.

Decoupling your engineering structure from your squad topology gives you the agility of squads while maintaining expertise and oversight.

This “meta-agility” helps your organization adapt quickly to changing needs without sacrificing quality.

3- What’s happening in reality?

Engineers belong to a core team that specializes in skills like backend, frontend, AI, or DevOps. This is the HR reporting structure, with a team lead serving as an expert and architect. Architecture design and code reviews happen within this core team.

Engineers are assigned to cross-functional squads. Ideally, all engineers join squads, but some may focus on key areas like infrastructure or technical debt.

  • Each squad is led by a product manager and a tech lead, and ideally includes a designer. The tech lead could be a team lead or a senior engineer for professional development. It's best if the tech lead is from the core team supporting the squad for better collaboration.

  • Engineers attend two daily meetings: one in their squad and another in their core team. This setup allows squads to function as cohesive units while the core team manages code ownership.

  • Conflicts can arise (e.g., if one squad's work contradicts another's), but these are addressed early. This structure also encourages collaboration among team members on similar projects across different squads.

  • The product leader and engineering leader decide squad assignments. eg instance, if a squad needs more AI developers, the product leader identifies this while the engineering leader suggests candidates nearing completion of other tasks.

  • This allows for strategic resource allocation—splitting resources rather than just prioritizing features—while enabling flexibility as team members can move easily between squads.

When implemented correctly, this model can greatly enhance your organization.

Remember, focus on the principles that drove your desire for change instead of seeking a perfect solution.

Key Takeaways to Keep!

Here are 4 key takeaways from the article:

  1. Empowered Teams: Transitioning to cross-functional product teams helps overcome bureaucratic obstacles and accelerate progress.

  2. Unique Topologies: There’s no universal structure for product teams; the best approach varies based on company-specific factors.

  3. Broader Domains: Define product domains with a wider perspective to enable more strategic roles for product managers.

  4. Separate Engineering Structure: Distinct HR reporting for engineering teams fosters stability while allowing for cross-functional collaboration.

  5. Focus on Principles: Prioritize the principles that drive change over seeking perfect solutions for successful implementation.

Get 1% Better Every Day. Execution Matters Most!

Reply

or to participate.