top of page

Balanced Teams & Roles

The Problem

​

How to minimize handoffs of work, eliminate waste, expedite communication, and decision making?  

The Solution

The answer is to internalize external dependencies by creating a full-stack architecture and skillsets inside a small co-located product team, hopefully using pairing in an innovation lab.  It is realistic in H3 and H2, but harder in H1, especially in a legacy enterprise.   


Such a "balanced" team consists of one product manager, one product designer, and two or three pairs of software engineers.  So a typical total team size is 6 or 8 people.  

 

Three roles 

  • Product manager (PM).  A PM is the "CEO of the product."   A product manager focuses on solving the customer problem, measuring success, understanding the industry and the market, communication of outcomes, team promotion, and leadership.  "The honest truth is that the product manager needs to be among the strongest talent in the company," Marty Cagan (1).

 

  • Product Designer (PD).  PD consists of multiple skillsets, such as front end design, usability, user interviewing, marketing, and research.  Designers who possess all of these skills are called "unicorns" for their ubiquity.  Designers may rotate in and out of the team,  depending on the product needs and the sPDLC phase.  At times, a team may need a pair of designers.

​

  • Software Engineer (SE).  SEs learn full-stack skills, practice TDD and scenario testing, deploy to production frequently, follow 12+ factor principles and practices (2), remove tech debt continuously, pair and rotate pairs with teammates daily.

balanced_teams.jpg

Variations and examples

 

  • PM: During a handoff from H2 to H1, a PM from an H1 team pairs with the H2 PM.  In larger teams, a technical PM may pair with a "business" PM, but I would not recommend it long-term.  

 

  • PD: Some API teams do away with product designers.  Are such teams truly full-stack?  

 

  • SE: Some teams may add a specialist, like a data scientist.  However, the goal should be to upskill full-stack developers using pairing with a specialist so that with time the team could incorporate the new skillset into the full stack capability.

 

Declining roles

 

  • Testers.  Test automation/manual/integration. The days of software testing as a separate function are mostly over.  Manual testing has minimal use; product designers may perform this role.  Test automation is part of software engineering.  The last bastion of testing is the automation of integration testing on large programs in H1, mostly in large mature enterprises with legacy architecture.

​

  • Architects.  The role of architecture is diminishing.  A dev team should perform application architecture.  Solution architecture at the product portfolio level is useful in larger organizations (see enablement).  However, enterprise architecture should remain for the overall software strategy led by a CTO.   

 

  • Project managers (PMO).  They are not needed for product discovery and will likely interfere with product discovery.  Project and program managers may belong to H1, mostly in mature enterprises.  They focus on "feature factories" tasked with efficiency, cost reduction, and an increase in the profitability of matured commoditized products.  

​

  • Scrum masters.  A product manager performs a dual role of a product owner and a scrum master in a product team.  I don't think that scrum is the best agile/lean methodology for product discovery.  Scrum (and SAFe) may belong to H1, especially in larger enterprises undergoing a gradual lean transformation.  I will provide more details separately.

​

If these prescriptions appear too radical for you, I defer to Kent Beck (3) and Marty Cagan (1). 

Takeaway

"Balanced" full-stack pairing teams co-located in a corporate innovation lab provide the human capital for dynamic resource allocation in horizons 3 and 2 of a sustainable product portfolio. 

References

  1. "Inspired" by Marty Cagan

  2. "Beyond the Twelve-Factor App" by Kevin Hoffman

  3. "Extreme Programming Explained" by Kent Beck

ref
bottom of page