Shape teams to win
Products range in complexity, and the nature of the team highly depends on the product type. Experiment to find the perfect blend of roles. For example, a microservices implementation may not require front-end developers yet will require additional testing engineers to implement high unit test coverage across the product. On the other hand, a mobile banking app will need multiple product designers because the research, testing, and design workloads are much higher.
Let’s briefly cover organizational structure because it helps in the understanding of both how we serve our clients and how we enable our team members to develop their careers. Each client has a single managing director as a primary point of contact for the relationship (although there are some exceptions, such as when a single organization works with multiple offices). A managing director (MD) is located in one of our client-facing offices.
Each MD leads a team of product and design professionals. Historically, we have found these roles to be more successful when in close contact with the client. Each MD is assisted by a product design manager and group product manager. The individuals are responsible for the direct management of team members and the advancement of their respective disciplines.
We call the MD counterpart on the engineering side of the organization a squad lead (SL). Squad leads manage team leads (TL) and the team leads oversee front-end engineers, software engineers, DevOps, and testing engineers.
Once an engagement starts, we form working product teams consisting of PMs, designers, and engineers. Each member of the team has a local manager for delivery oversight and a disciplined lead responsible for career development, coaching, and evolution of their respective disciplines.
Team structure
Below is an illustration of the organizational structure and team structure:
We structure these independent working teams for the following reasons:
- The more self-managing we are, the flatter the organization is. The team has ownership over the engagement and is an independent, self-managing unit.
- The structure is laterally scalable—the more clients we serve, the more of these mini-Devbridge organizations we can establish without unnecessary hierarchies. The more we grow, the more opportunities open up in the company for people to take on more responsibility. Win-win!
- The structure enables us to establish client-serving offices across multiple geographies. Each new office is established by an MD with clear outcomes, team structure, and a process to follow. We have branched out into Chicago, Toronto, and London.
Our cross-functional product teams are self-governing entities where each individual contributes and takes ownership of the product’s success. Members of the team are partners in the venture and tackle their individual workloads. Members seek out how they can maximize their impact on the product and lift the team to the next level of productivity. Team members who lack competence or fail to adopt these values are detected by the team instead of by a detached manager.
At times, the team will take advantage of the expertise from support roles. For example, DevOps is typically a support role because there simply isn’t enough work for a DevOps engineer to be dedicated to a single team throughout the whole project (although there are exceptions). Directors of disciplines such as product design, product management, testing, and engineering are also pulled in for ad hoc, highly complex challenges.
The total product team size varies from six to twelve—more than that and effectiveness and communication quality start to deteriorate. If the team becomes too large, they ideally split into two, retaining the domain knowledge while expanding the small teams with new members.
The member count from each practice group varies based on the team and its responsibility within the overall product roadmap. Ideally, there will be some overlap and shared understanding—a designer with the knowledge of a front-end skillset, an engineer who is fluent with front-end and server-side technologies. Finally, all team members are 100 percent allocated to a single product.
Every SOW should reflect permanent, 100 percent allocated FTEs.
This section outlines the typical roles in a Devbridge’s cross-functional team. Of course, not every team needs every role. For example, a testing engineer may not be needed on a proof of concept initiative. The intent is to provide clarity when it comes to who does what.
Team roles
Product Manager
At Devbridge, a product manager (PM) advocates for the success of the customer while balancing spend, schedule, and product scope. A PM seeks to maximize the business outcomes while operating within a set of constraints:
- The product must ship on time and on budget.
- The clients must have buy-in and be aligned with the goals.
- The product backlog must be dev-ready to avoid idle time.
The product manager’s primary responsibility is to break down the customer’s needs and product requirements into easily digestible user stories for the team. The PM is readily available to address any questions or concerns the team may have as it works its way through these stories. The PM also collaborates with designers and engineers on requirements gathering, backlog refinement, orchestrating sprint rituals, and facilitating retrospectives.
Business Analyst
Business analysts help break down complexity on products with deep domain complexity or large product builds where a Product manager may need to coordinate the wider program while individual teams focus on feature work. In practical terms, this translates into the BA owning backlog refinement.
Software Architect
A software architect is a senior engineer in an advisory role who helps the team navigate complex architectural decisions, determine best application of a technical capability, and introduce emerging technology capabilities (e.g., artificial intelligence and machine learning). Architects rotate through teams, staying long enough to guarantee solid delivery.
Engineering Team Lead
A senior software engineering team lead (ETL) is responsible for making architectural decisions and for leading the development effort within the cross-functional team. This person works together with the product manager to delegate individual user stories, making sure that team members are enabled to complete the work they pick up (e.g., routing complex stories to more senior members of the team, coaching, problem solving, and performing technical spikes). The responsibilities vary based on team maturity and selected rituals.
Product Design Manager
A product design manager (PDM) is a senior practitioner of the craft who owns a portfolio of products that are currently worked on by the team. Each design manager supports a group of product designers, leads design thinking on client engagements, participates in hiring of new designers into the team, and provides mentorship and coaching to the cross-functional team. PDMs have a deep understanding of the product design practice that includes research, interface design, interaction design, and so on.
Group Product Manager
A group product manager (GPM) leads a group of product managers and is the point of escalation for all delivery-related issues. As seasoned and experienced product managers, the GPMs help the team scale obstacles, hire new PMs to the team, and coach members to be successful in the long term.
Product Designer
Product designers (PD) help the team build the right things by answering a range of questions: How will the product be used by the customer? Why does the customer behave a certain way? How should the product be designed to maximize effectiveness? Designers work to capture user personae, understand their motivations and desires, and design workflows and experiences that make using the product simple, desirable, and valuable. There are different types of designers—some focus more heavily on usability, while others focus more on visual design and research. Regardless of their particular areas of expertise, all team members are familiar with various subdisciplines of design.
Front-End Engineer
Thanks to the evolution of front-end technologies (e.g., HTML5, CSS3, and JavaScript), a separate role has emerged to translate the designs produced by the design team into functioning interfaces. Front-end engineers (FEEs) may work purely on the UI of the application (including transitions, animations, responsive frameworks) or they may perform some lightweight integration to hook the interfaces up to the application code that drives the UI. An understanding of design is necessary because FEEs often have to extend design patterns from a single template mock-up across several interfaces or workflows. Performance optimization is another important area of responsibility for a FEE—making sure our products on mobile devices and desktops adhere to best practices established by Google’s RAIL (response, animation, idle, and load) model.
Software Engineer
Software engineering is the backbone of every product we build and is the role filled by the highest number of employees in the company. Software engineers (SE) are responsible for successful, scalable, and maintainable implementation of the product. Their expertise ranges from native mobile development, web application development, and cross-platform engineering to data architecture and performance optimization.
Testing Engineer
A testing engineer (TE) works closely with the PM during backlog definition to capture and agree upon the acceptance criteria for each user story. We have found that TEs who integrate tightly with business SMEs and start by defining the right way for the product to work are much more successful than testers who simply pound on the application until it breaks. Testing engineers also manage test plans and test cases, capture defects, recommend product improvements, and more.
Test automation engineers write unit tests and other automation scripts that help the product team simplify quality assurance as the product grows in complexity and size.
DevOps Engineer
The DevOps engineer (DOE) enables continuous delivery for the team through the configuration of environments, processes, and tools. This role is typically employed at the beginning of the project as the infrastructure and deployment needs are being configured. The primary responsibility of the DOE is to equip the team with tools and processes that support continuous delivery—or at the minimum, continuous integration.
Client roles
Client stakeholders and sponsors may be directors, C-level executives, or middle management, but when it comes to shipping products to market, they are solely responsible for supporting the delivery team. The involvement of client roles varies depending on how tightly they’re coupled with the Devbridge team. In most scenarios, the client is heavily involved in planning. Once the Devbridge product team starts working on the software, the client participates in backlog refinement and demo sessions to ensure acceptance of the product.
Sponsor
Typical sponsors are the CIO, the VP of products, or the SVP of sales. Key characteristics are having control over the funding procurement for the initiative and having ultimate ownership of the product’s success (or failure). Often, the sponsor may be a leader within the client’s technology organization who is investing in a product requested by one of the product lines (business) in the company. The success of delivery falls on the sponsor’s shoulders, while the viability and ROI of the product may belong to the stakeholders within the business line.
The involvement of the sponsor in the product delivery is minimal. They are interested in understanding the strategy and the prototype and potentially participating in some demonstration sessions along with delivery. If they lack the domain expertise to guide or support the team, they may take an overseer role versus that of an involved mentor. During times of escalation and conflict, however, the ultimate decision devolves to the individual who signs the checks.
Stakeholder
The stakeholders are those individuals who have influence on ROI or are affected by the release of the product (efficiency, change management, etc.). They are often directors or vice presidents within a specific business line inside the client’s enterprise—VP of sales, VP of product, or director of customer experience. The stakeholders have a good understanding of customer needs, although their role may lend itself to some bias. Stakeholders are actively involved in Lean Requirements, prototyping activities, and sprint demos. Their roles extend beyond a single product, and they may disengage as soon as the product releases.
Subject Matter Expert
A subject matter expert (SME) is called in when requirements need to be defined for a specific part of the product. For example, we had one client invite its distributors to an anonymous user-testing session that validated (or invalidated) assumptions made by the product team for a new e-commerce model. The session exposed the SMEs to multiple online experiences spanning the client’s preexisting website, competitor services, and the new prototype. SMEs, when interviewed and properly engaged, help the product team make better, less biased decisions about product design and functional acceptance criteria. SMEs may be involved in requirements and user-testing sessions. Because assembling a group of SMEs may be challenging and costly, their involvement is limited to the validation of critical decisions and clarification of vague requirements.
Product Manager
Similar to Devbridge’s product managers, the client PMs are responsible for amplifying the voice of the customer and for aggregating decisions on the client side. Their responsibility is to perform market research and customer interviews, recommend product positioning, and ultimately guarantee success of the software product in the market. The client’s PM may be tasked with creating a series of minimum viable products (MVPs) and finally a minimum marketable product (MMP). For example, a product manager who is aligned to mobile commercial banking products may be responsible for all digital products that serve the commercial banking customers.
Our objective is to pair our PM with the client’s PM and make that person the single link through which most decisions are made.
