This chart explains how we shape product development to work most effectively. In addition to individual BAU work (minor/low risk features, bug fixes etc), any sizable/high-risk initiative should be assigned to a multidisciplinary work ‘squad’. The nature of the squad depends on the context of the work. For example, high risk/cost projects may require a squad to be more exploratory or design focused, and collaborate with broader business units to validate a proof of concept potentially before any code is written.

As that project evolves, a squad may add developers as needed. In an ideal world, neither the head of product or CTO should be closely involved in day-to-day project-level work - they are there to oversee, govern, mentor, and set the overall roadmap and agenda, but each squad should be autonomous, accountable for the effective delivery of tasks within the team.

Note: We are not always in an ideal world, of course, i.e. we do not have the capacity to dedicate specific squads to work on a single project 100% of the time. However, individual team members should be able to task switch effectively and work across multiple squads at any one time (within reason).

Squads should follow the right processes depending on context. For example, at the beginning of a project, the squad, head of product and CTO should discuss and agree which projects require an upfront design process (prior to development) vs. an agile (ship and iterate) process. Squads should then be responsible for following this process, looping in key stakeholders at important stages of decision making, and conducting user testing sessions.

Squads should work to deadlines and utilisation targets. In a world with limited resources, we have to consciously plan %splits between BAU and strategic initiatives. As autonomous teams squads will be responsible for their own time management, between project deadlines and BAU work.