Roles in a Product Engineering Squad

The roles in any Product Engineering Squad are always going to vary a little bit. There isn’t a single pattern that can be copy and pasted. There are some roles, however, that we want to be firm on and others where we can flex depending on the situation and area of focus.

I’ve worked in a wide range of different squads over the years, from a 5 person squad running a daily Scrum sprint cycle (yes, daily), to a 12 person squad operating with Kanban. Remember, Product Engineering Squads are cross-functional, mission-driven teams that work together to solve customer problems. I am primarily focusing on the digital space in these posts but many of the principles apply to physical product development just as effectively. This post outlines and explores the roles in a Squad. If you want more on the Product Squad principles and attributes check out my previous post.

Normally a typical Squad will be 8 people, plus or minus 2, and will never exceed 12 individuals. This creates an environment for efficient constructive discussion and timely decision making. It’s the classic two New York pizza-sized team, as described by Amazon’s founder Jeff Bezos.

Roles in a Squad typically include:

• Product Manager
• Engineering Lead
• 3–6 Engineers

Roles will often include:

• Product Designer
• Business Domain Specialist
• Data Analyst

Let’s explore these in a little more detail:

• Product Manager — There is a single Product Manager per Squad, responsible for establishing the strategic product vision, understanding the user, their pain points and unmet needs. To do this they need a strong commercial understanding that allows them to make and enable prioritisation and scope decisions as they work towards finding product-market-fit. Aside from championing the user, above all else they serve as the organisational catalyst for getting stuff done. The exception to this rule can be a Platform Squad or deeply technical Squad where the Engineering Lead may additionally take on the key facets of the product role(s). It’s important to note that there is no parallel Business Analyst (BA) role in the Squad, and if a Squad’s complexity and size is getting too large, then it is preferable to split into two smaller Squads rather than adding a BA role distinct from the Product Manager.
• Engineering Lead — There is a single Engineering Lead per Squad who is accountable and responsible for all engineering delivery within the Squad. They think about technical strategy, solution and integration architecture, as well as the delivery pipeline and frequency of release. They can be, but are not always, the line manager for the other engineers within the Squad. They champion the engineering standard and best practices, guiding the overall quality and risk-based approach to software delivery. Engineering Leads are still software developers and on average are expected to spend ~50% of their time writing code.
• Product Designer — Product Designers develop the user experience to ensure that desired functionality is effective, intuitive, delightful, and above all meets user needs. They use research and data to understand product pain points and design effective improvements. This role can be split between a User Experience Designer and Digital Visual Designer, or combined into a single Product Designer role, but it’s expected that in time most designers will be T-shaped, with an appreciation for other aspects of their craft and the ability for at least a basic application of all parts of the design process. Where multiple designers are present in a Squad, one will ideally take on the ‘Lead’ mantle to enable effective decision making.
• Engineers — There will typically be between 3–6 software engineers within the Squad, often biassed towards a structure that enables pair programming (although the decision to make use of pairing sits within the Squad). To be successful, a team needs to be sufficiently resourced with engineers; a smaller number of engineers necessitates a strong underlying platform on which they can operate. Different capabilities and mindsets are anticipated and it is assumed that some form of a delegate architecture model is in place so decisions can be made within the team. In order to maintain agility and flexibility, there will also be a lean towards full-stack engineering capability where viable, however, engineering roles could broadly include: Front-end Engineer (Consumer facing), Back-end Engineer (Platform), DevOps (Reliability) and Test Engineer (Quality Assurance).
• Business domain specialist — There can be one, or on rare occasions, two business domain specialists within the Squad. This role varies in accordance with the requirement of each Squad’s particular mission. This will often take the form of a Marketing specialist, SEO specialist, Content Producer, Customer Services specialist or Commercial specialist to provide deep discipline knowledge that either directly contributes to the Squad’s mission, or enables it through a deeper appreciation and understanding of business needs. A key responsibility of the business domain specialist is to act as the representative as well as the comms coordinator with their departmental discipline/function. As noted above, the inclusion of a business domain specialist is not typical practice in Squad implementations that you will find in the majority of organisations where Squads are usually made up entirely of Product & Tech resources. This is one area where I think organisations can do better and I’m constantly looking to break new ground through greater collaboration and inclusivity.
• Data Analyst — Understanding the usage analytics data is the responsibility of everyone in the Squad. It’s critical, and quality becomes self fulfilling, if the product and engineering roles implement and analyse the results of data capture. This said, in my experience, this can be turbo-charged by including a Data Analyst role. Data Analysts perform the really detailed web analytics and customer behavioural analysis necessary to help the Squad make and evaluate their decisions. They understand how data relates to the tag management solution, and they are prepared to discuss and/or pair with engineers on defining complex analytical or tagging requirements. It should be noted that tagging and analytical requirements are an internal Squad responsibility, since it can notably affect development effort and time to delivery. Data Analysts will also often take up the role of supporting, analysing and making sense of A/B tests.

An example Squad with some supporting roles might look like this:

As you can see in the diagram above, there are some roles that will work very closely with or adjacent to a Squad, including but not limited to:

• Product Operations
• User Researcher
• Delivery Manager / Scrum Master
• Agile Coaching
• Optimisation Coaching
• Quality Coaching
• Copywriter
• Content specialist
• Market Researcher
• Legal & Compliance specialist
• Business Development
• Procurement
• Discipline/functional line management
• Leadership Team

There are some common roles that are not present in the Squad model and therefore notable by their absence:

• Project Managers
• Programme Managers
• Business Analysts
• Manual Testers

Let’s explore these in a little more detail too:

• Programme Managers — Squads are typically horizontal by nature, focusing on a desired business outcome that cuts across traditional products and services. The Squad model relies on long term commitment and ownership which seeks to minimise all dependencies external to the Squad itself. Implemented successfully, this model should remove the need for a Programme Manager to coordinate across teams/Squads or pull together larger pieces of work. This is not to say that there may not be a need for some programme management in and around other areas of the business that do not focus on Product/Service development.
• Project Managers — Squads are there at ideation & inception, living with a product or service through its life cycle to the point of decommission. There are no strictly finite projects within the Squad model, only continuous improvement through experimentation and iteration. Any planning or coordination is jointly owned internally by the Squad Leads. This is not to say that there won’t be a need for some Project Management in and around other areas of the business that do not focus on Product/Service development or large scale events that require a level of coordination across multiple Squads and teams. See my post on ‘Squads vs Projects’ for more information on this.
• Business Analysts — Product & feature definition is the responsibility of the whole Squad, although the Product Manager takes a particular lead in helping to coordinate this activity and ensure the Squad always has something ready to pick up. User stories, acceptance criteria and tasks should typically be written in three-amigo sessions (three-amigos = Product Manager, Engineering Lead, Product Designer — although this can now be expanded to four-amigos in order to include Business Domain Specialists). Product Managers should not subcontract their roles to Business Analysts! This is not to say business analysis skills are redundant, in practical terms it means ~70% of what a BA would have historically done should fall to the Product Manager, ~20% to the Product Designer and ~10% to the rest of the team. Business Analysts may still play a role in the delivery of some non-proprietary/bespoke business systems as a part of IT & Corporate Systems change projects. In the context of a Squad, however, the Product Manager needs to be intimately close to the user, data and detail in order to drive forward the desired outcome. You can read more on Product Managers versus Business Analysts in a great SVPG article here: https://svpg.com/product-manager-vs-business-analyst/ by Marty Cagan.
• Manual Testers — Exploratory manual testing is the responsibility of the whole Squad. The Squad should take ownership for the quality of what they produce through risk-based delivery. Dedicated manual testers are a thing of the past in most modern software delivery.

In summary
No two Squads will be exactly the same but they will mirror certain key roles. Strong Engineering and Product leadership are the things that will make the real difference. Ideally, keep squads small and focused, removing roles that duplicate responsibility and at all times seek to eliminate any external dependencies.

Please note: I do not receive commission or affiliate revenue of any kind from the above endorsements or links, which are provided only for the benefit of the reader. I do have professional relationships with some of the authors and one of SVPG’s partners is a Non-Executive Director for my current organisation, Which? Ltd. All the thoughts are my own.