I once worked with a CEO who was frustrated with his company’s slow pace of delivery and innovation. “We have all these talented people,” he said, “but it takes us forever to get anything done.”
His company, a 10-year-old scale-up, had grown rapidly over the past few years. What started as a nimble startup had evolved into a complex organization with multiple layers of management and rigid departmental silos. Decision-making had become nearly impossible because no one saw the bigger picture, and cross-functional projects were more about navigating through outdated technology than delivering value.
When I introduced the notion of cross-functional, empowered product teams, the CEO said it was exactly what they needed and immediately created a task force with three VPs to lead the change: the VP of Product, the VP of Engineering, and the VP of HR.
The VPs, too, loved the idea and promise of the squad model: autonomous, cross-functional teams aligned around specific missions indeed sounded like what they needed. But loving the idea wasn’t enough to translate it into reality. There were so many questions to discuss and gaps to close to do it right that we had to work closely and patiently on each one.
The promise of squads is to cut through bureaucracy and accelerate innovation. But there is no well-defined set of rules on how to do it right. The details matter, and truly getting to empowered teams requires much more than an updated org chart. Truly getting there requires a fundamental shift in how we think about leadership, accountability, and the very nature of how work gets done.
In recent months, many teams have approached me for advice on the practical side of transforming into empowered teams. As I find myself explaining time and again, simply reorganizing wouldn’t do the trick. There are best practices that you can follow, and on the other hand you have to set everyone’s expectations right. It’s not a magic card that would solve all of your problems. Tech organizations are complex by nature, and you will always need to make some trade-offs. One of the reasons it’s a tricky transformation is that the trade-offs are unique for each and every company, so you have to find your own way. Here are a few key points that I see repeating time and again to help you make the transition smoother and beyond that – make it a success.
Product Team Topology: There Is No Perfect Answer
The first step toward empowered product teams is to decide on the product team topology – how to split the responsibilities between various product managers. Put the engineering structure aside for now. We’ll deal with that later on.
From my experience working with dozens of companies on their team structure, there’s no one-size-fits-all solution. The ideal topology depends on your specific product, company culture, technology, team dynamics, and other constraints. Moreover, a perfect answer almost never exists. Any topology you consider would have its pros and cons, and finding the right balance between autonomy, depth, flexibility, and stability is an art more than science.
To start, consider a few options. Take everything the team does today and split it to product domains. You can go by functionality, customer segments, phases in the customer journey, strategic goals, or any other split that makes sense.
It’s important to look beyond surface-level divisions. For example, a cybersecurity company I coached initially had “integrations” as a standalone domain. However, this was too narrow and feature-focused. We reframed it as “ecosystem assimilation,” which encompassed integrations, reports, role-based access control, and potential new areas. This broader framing allowed the product manager to bring more strategic value and vision to their role.
Evaluate each potential topology by asking yourself these key questions:
- Does each product manager have a well-defined domain into which they can bring depth and vision? Another way to explore it is to check if a strategic roadmap for that domain makes sense.
- Are responsibilities clearly delineated, with a single owner for each initiative? Can you naturally tell where each initiative falls?
- Can teams operate with a high degree of autonomy while still maintaining alignment? In other words, how often would one PM depend on another PM’s work to deliver value?
This last question is where you will find most trade-offs need to be made. But that’s okay; we are not looking for 100% autonomy. It can never happen. But does it give you 80% autonomy? In other words, would the case of PMs depending on other PMs be the rule or the exception? We are aiming for the latter, of course.
Engineering Team Structure Doesn’t Have to Be the Same
Once you understand your product domains, it’s time to work on the engineering team structure. While it’s crucial that the engineering team topology matches the product team topology (we want each team to work with a single product manager and each product manager to have a cross-functional team that they work with), it doesn’t mean that the HR reporting structure needs to match the product team topology. In fact, my recommendation in most cases is to separate the engineering HR reporting structure from the team topology.
The traditional engineering structure—with separate backend, frontend, mobile, and other specialized teams—serves an essential purpose even in a cross-functional model. After all, even if everyone is full-stack, there will always be expertise in certain areas, and we want to leverage that expertise rather than dismiss it.
My recommendation instead is to keep this structure and map engineers to cross-functional squads to enjoy the best of both worlds.
Here’s how it works in practice: Engineers remain part of their specialized teams (e.g., backend) but are assigned to cross-functional squads. At any given point in time, an engineer is assigned to a single squad led by a single product manager. A product manager, by the way, can lead multiple squads (usually no more than two to leave room for good product work). The engineers bring deep expertise in their domain to the squad while maintaining connections to their core team. When working on complex changes, they can easily consult with their team lead (who acts as a domain architect) and fellow specialists to ensure system-wide integrity. They also represent the squad when working with the core team, so everyone knows at least a little about other things that are happening in the company.
This approach offers several advantages for easier transformation as well as a better outcome:
You can start with a single squad as a pilot without disrupting the entire organization, reducing resistance and allowing for iterative improvement. Core teams and team leads retain ownership over their domains, reducing the risk of breaking changes across squads. Engineers can be reassigned between squads more easily since their reporting structure remains stable, which in turn allows you to adjust the resource allocation per need and shift priorities without formal reorganizations.
While this hybrid approach may seem less powerful than a full reorganization into product teams, it actually offers a more sustainable pace. Even companies with formal cross-functional teams often allocate significant time (up to 20%) for cross-team alignment and reviews. By maintaining the engineering structure, you build natural touchpoints for this crucial collaboration.
By decoupling your engineering structure from your squad topology, you gain the agility and focus of squads while preserving the deep expertise and architectural oversight of specialized teams. This “meta-agility” allows you to adapt your organization more quickly to changing needs without sacrificing quality or long-term stability.
What It Looks Like in Reality
Engineers are based in a core team that masters certain professional skills (e.g., backend/frontend/data/AI/DevOps, etc.). This is the formal HR reporting structure. The team lead is an expert in that domain and can serve as an architect for anything that happens in that domain. Architecture design and code reviews are conducted within the core team.
Engineers are assigned to cross-functional squads. Ideally, all engineers are assigned to squads, but some engineers may be left out occasionally, allowing for focused work on cross-cutting concerns like infrastructure, scalability, or technical debt.
Squads are led by a product manager and a tech lead at least, ideally with a designer in the lead too. The tech lead could be one of the team leads or a senior engineer if you want to give them a professional development opportunity. Ideally the tech lead of the squad would belong to the core team that does most of the work for this squad, for easier leadership and collaboration.
Each engineer goes to two daily meetings: first, in the squad and then in the core team. This allows the squad to operate as a single unit that makes cross-functional decisions on one hand and the core team to operate as the domain owner of their code across squads. This is where conflicts naturally arise (for example, if one squad contradicts an effort done in another squad) and are caught in time to handle them properly, and where collaboration naturally happens between team members who might be working on similar projects coming from different squads.
The higher-level product leader and the engineering leader decide on the assignment of people to squads (typically, the product leader discusses the need and the engineering leader on the specific people. For example, the product leader might say that a certain squad needs more resources, specifically AI developers, and the engineering leader discusses the assignment of specific people who are about to finish a chunk of work in another squad and could serve as candidates for this transition). This allows your resource allocation to be more strategic on one hand (since you decide how to split the resources and not how to prioritize features) and more flexible on the other (because people can move between squads easily without it being a significant event like moving to report to a different manager).
When implemented properly, this model can do wonders for your organization. To succeed, allow yourself to shy away from perfect solutions and stick to the principles that motivated you to seek this change in the first place.
