The debate over how to organize product and technology teams never seems to end: Should we structure around technical capabilities? Strategic objectives? Product lines? After years of building tech products and leading transformations at companies like Crimson Hexagon and True Fit, I've seen firsthand how the evolution from project-based work to a squad model can revolutionize product development. Here's what I've learned.

Project based work

In the early 2000s, our technical organizations operated mostly on a project basis. Engineers and product managers were allocated to multiple projects simultaneously, often being assigned to a dozen initiatives at once. While this approach seemed flexible on paper (anyone could join any project as needed), it created several challenges:

  • Constant context switching for the worker
  • Unclear accountability for the project velocity
  • Difficulty tracking actual progress and determining delivery timelines
  • Hard to evaluate opportunity costs and tradeoffs
  • Overwhelming coordination overhead

The Squad Model

During my time at Spotify, I gained firsthand knowledge of their now famous Squad based organizational structure (as it existed in the early 2010s) which sought to embed all the resources needed to execute an initiative (Product, Engineer, Design, Analytics) into one working team. They thought of it as a mini-startup within the organization - the squad owns its roadmap, makes technical decisions and is accountable for its outcomes.

From this organizational model I found that the product development process gained:

  • Focus on key roadmap initiatives and goals
  • Clear ownership of systems and features
  • Relative ease in tracking project progress and predicting delivery
  • Straightforward determination of tradeoffs
  • Reduced coordination overhead required with the rest of the organization

As I moved forward in my career, I brought these learnings to my new companies to see if we could gain the operational efficiency I found at Spotify. While every organization is going to be different, and you need to tailor the approach to your environment, I believe that this general organizational concept can have a positive impact on most product development teams.

A Real-World Transformation: The Crimson Hexagon Story

When I arrived at Crimson Hexagon, we faced a classic case of project overload. With a team of about 50 engineers and 6 product managers, we were tracking over 50 projects simultaneously "in flight", with some engineers assigned to 15+ projects at any given time. The results were predictable: overwhelming coordination overhead, missed deadlines from unrealistic expectation setting and stressed teams.

There was an executive mandate to institute change in the process, so I worked with our CTO to set up a new operating dynamic and we decided to replicate much of what I had seen at Spotify. First, we defined the company’s Strategic Pillars / areas of needed investment with the idea that each of these would form the basis of a new squad. We then drafted concrete mission statements, OKRs and systems ownership for each of these areas in order to eventually route maintenance, tech debt and support into the team. We distributed our set of active projects and roadmap wish list items to each of these new squads, and laid out “resource allocation” estimates (eg. the number of engineers / designers / PMs we believed we needed to have to execute on the roadmap, and for which we believed should be allocated based on the impact/priority of the squad goals on the overall company). Being somewhat conservative, the CTO requested that we introduce one new squad as a trial within the existing group before changing the entire org structure. We formed that squad, outlined the new operating expectations and instituted a fairly standard scrum-like set of meeting ceremonies and cadence.

The most striking change from our trial? Each engineer went from juggling multiple projects to focusing on one clear initiative at a time. The clarity this brought to our development process was transformative.

After a couple of sprints, we pushed forward with implementing the new structure across the organization. Within one quarter, we reduced meeting overhead for each team member significantly and our high priority projects were gaining new momentum. After our second quarter, we were able to measure an overall 3x gain in feature delivery! Sprint predictability increased, and crucially, team member satisfaction / happiness rose dramatically as they saw their productivity improve.

The True Fit Evolution

At True Fit, we faced a different challenge: the team had created a set of new products within our platform which needed to be maintained and expanded, and at the same time we experienced a change in strategic direction. In addition, the roadmap planning process was slow and painful and sometimes non-existent; when it did happen, the entire team would walk through every proposed project, discuss details and try to force-rank priority for the entire backlog. Further, once we did have the outline of a roadmap, getting executive sign-off was a barrier to implementation which dragged the process on even longer. It was not uncommon to be at the end of a quarter without official guidance on the actual roadmap content. Lastly, when any new item came up for consideration, it would need to be vetted across that forced ranked list of items for the entire company, making it very time consuming and difficult to provide feedback on the opportunity costs of taking on the new initiative.

After a few months at the company, I was given the reins to enact changes to the process. I walked our technical leadership through a very similar exercise I had developed at Crimson, developing strategic pillars and lining up roadmap projects and systems ownership around those new pillars.

True Fit also experienced positive results from this transition! We saw an increase in team focus and commensurate increase in feature delivery velocity. We gained an ability to better estimate feature delivery dates (without additional planning overhead), we were able to better estimate the tradeoffs needed to take on new work, and we were able to implement an efficient roadmap refresh process that was more easily digestible by the executive team and accelerated cross-functional sign-off. We saw product development team satisfaction scores grow as team members appreciated the reduction in planning and coordination meetings; and we also realized improved customer satisfaction (from both retailers and from internal teams: sales, customer support, marketing, etc.) due to being able to introduce product improvements into the market faster and provide greater clarity on the company product strategy.

Benefits of the Squad Model

Enhanced Focus and Productivity

The smaller squad group provides greater focus as they only need to focus on just a few features and projects at a time. This allows for more efficient sprint planning and a reduction in the team’s context switching during execution.

Improved Ownership and Innovation

With more focus and less context switching, the team feels more ownership over the features they are working on and more autonomy in coming up with new ways to deliver on the goals that have been set out. Engineers provide more feedback on the roadmap and more input into new features.

Better Portfolio Management

With structured system ownership and roadmaps assigned to the squad, it is generally quite easy for Product and Engineering Leadership to evaluate opportunity costs and potential delivery dates for initiatives. The squad structure also makes it fairly straightforward to determine the amount of resources that you are devoting to each initiative.

Common Challenges and How We Solved Them

While the squad model provides a whole lot of benefits, there were some common pitfalls that I’ve observed over time:

Knowledge Silos

With more inward focus by the squad, there was a reduction in cross-squad communication. This was mostly by design to gain focus, but there needs to be a minimum amount of communication across squads to maintain alignment. We addressed this through squad leader level reviews after roadmap planning, end of sprint demos for the entire team and open distribution of product requirements and technical designs

Local Optimization in Roadmap

Because the squad is given a set of goals, and freedom to design ways to achieve those goals, there are always more ideas to pursue! However, the squad lacks the ability to understand the value of the work they are looking to perform vs. the value of the work scheduled / defer in other squads. When this happens, its incumbent on leadership to identify the issue early and either re-distribute resources to higher value work, or adjust the remit of a given squad to make their impact higher. Performing these evaluations with every roadmap refresh should be a priority.

Squad Imprint on the Product

Because of the inward focus and the knowledge silos, and the concept that each team should be self-sufficient, you also tend to see the squad structure reflected in the overall product and platform. This might be OK when you are building out distinct feature sets, but it is less OK when you want to build a unified user experience. Comprehensive UX design reviews and strategy planning by the Product Management group are the best ways to mitigate against this phenomena.

Conclusion

While the squad model isn't perfect, in my experience across multiple organizations, its benefits significantly outweigh its challenges. The key to success is understanding that it's not a rigid framework, but rather a flexible approach that should be adapted to your organization's needs and culture.

The model brings focus, clarity and agility to product development while creating natural alignment between strategy and execution. When implemented thoughtfully, with attention to potential pitfalls and active measures to address them, it can transform how your organization delivers value to customers.