Strategic Composition for Digital Teams: An Economic Approach

Building digital products that people love is hard. Humans are emotional and irrational, which makes us hard to design for.

Equally challenging is composing the team that ships the product. Past a certain point, adding people increases coordination cost faster than it increases delivery.

This essay shows how smaller agile sprint teams can outperform larger teams when you model marginal productivity and marginal cost. The analysis focuses exclusively on agile teams.

Context: agile teams and role ratios

Key factors of agile product teams and waterfall development teams are:

1. Agile processes emphasize the importance of effective informal communication among developers, and of iterative improvement of implementations driven by use-case scenarios, and they champion small cohesive development teams over large structured units. (Estler et al., 2013)

2. Waterfall methodology, also known as the linear sequential lifecycle model, is defined by its linear, structured approach to project management. It is made up of a series of steps that are completed in sequential order within the software development life cycle. (Kavlakoglu, 2020)

A digital product team includes roles such as a Product Manager, Product Designers, Software Engineers, and an Engineering Manager, with possible support from Data Analysts or UX Researchers. A Product Manager is explicitly responsible for ensuring value and viability, the Product Designer is responsible for ensuring usability, and the Engineering Manager is responsible for ensuring feasibility. (Cagan, 2019) My experience suggests that using Frontend Engineers as a benchmark for team composition ratios yields high quality, efficiency, and speed of delivery.

The "Typical Work Multiplier," presented in Table 1, represents the standard workload for each discipline to achieve success. When scaled against the Frontend Engineer's multiplier, it helps determine optimal team ratios. Table 1 also lists example annual salaries (in USD, representative, not actual) for each role, constituting the fixed costs in this analysis.

Table 1

Digital Product Team Composition (transcribed from original figure)

Role	Avg Salary	Typical Work Multiplier	Work Ratio
Frontend Engineer	140,000	2.5	1
Fullstack Engineer	150,000	1	0.40
Manager, Engineering	170,000	0.5	0.20
Product Designer	130,000	1	0.40
Data Analyst	120,000	0.5	0.20
UX Researcher	105,000	0.33	0.13
Product Manager	170,000	0.5	0.20

Workflow: how work moves

The workflow through the digital product team, as outlined above, is depicted in Figure 1.

Figure 1

Flow of work from start to finish on a digital product team

Roles that enhance the efficiency of subsequent positions act as force multipliers. Product Managers boost team effectiveness by defining business goals and metrics. UX Researchers and Data Analysts provide data for decision-making to Product Designers and Management. Product Designers convert these insights into prototypes and final designs. In the transition from prototype to finished product, the Engineering team works in tandem with Product Designers to develop the work into a complete digital product, with Engineering Managers ensuring process quality and efficiency.

Calibration: sprint points and delivery rate

Utilizing two years of data from GitLab’s Digital Experience team, which has a biweekly sprint delivery rate of 20 points per sprint (1pt = 0.5 day) (Preuss, 2020), this analysis identifies an ideal digital product team composition.

Table 2

Sprint points per person over time

Metric	Value
Sprint Points Per Person Per Sprint	20
Sprint Points Per Person Per Year	520
Sprint Points Per Person Per Quarter	130

Diminishing returns: Brooks’ Law

This analysis models the diminishing returns associated with increased team size using the rates in Table 3. This concept has also been referred to as Brooks’ Law:

• Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them.

• Communication overhead increases as the number of people increases. (Wikipedia, 2022)

Table 3

Rate of diminishing return

Number	Diminishing Rate
0	0%
1	0%
2	2.08%
3	3.28%
4	4.69%
5	6.42%
6	8.60%
7	11.43%
8	15.17%
9	20.23%
10	27.18%

Economics model: marginal cost vs productivity

Beginning with Frontend Engineers as the "work ratio" basis from Table 1, Table 4 shows that expanding the team from five to six Frontend Engineers leads to decreased marginal productivity. In essence, the addition of the sixth Frontend Engineer reduces, rather than increases, sprint point output.

This is mirrored in the cost analysis, where average total and fixed costs rise when transitioning from five to six Frontend Engineers. The interaction between marginal productivity and marginal cost suggests that the team's efficiency improves when increasing from two to three Frontend Engineers, but decreases when adding a fourth. Multiplying average marginal productivity by average marginal cost indicates the highest return on productivity occurs with three Frontend Engineers.

Table 4

Frontend Engineers (full economics table transcribed from original figure)

In Figure 2, isolating economic indicators like sprint points, average fixed costs, average variable costs, average total costs, and marginal cost highlights inefficiencies as team size increases. This view makes it clear where additional headcount produces lower cost efficiency per delivered sprint point.

Figure 2

Frontend Engineers with Average Total Cost

Note: Average Marginal Cost is shown only where marginal productivity is positive (through FE 5). FE 6 and FE 7 are N/A.

Figure 3

Frontend Engineers without Average Total Cost (line graph)

Note: Average Marginal Cost is shown only where marginal productivity is positive (through FE 5). FE 6 and FE 7 are N/A.

Figure 3 provides an alternative view, showing that with three Frontend Engineers, average marginal costs are lower than the sprint points delivered. Figure 4 further illustrates that return on productivity peaks with three Frontend Engineers.

Figure 4

Frontend Engineers Return on Productivity (line graph)

Brooks’ Law is evidenced by the cost savings when scaling from one to two Frontend Engineers. As shown in Figure 3, the average marginal cost is lower than the sprint points delivered. Figure 4 shows that productivity return is maximized at three Frontend Engineers, indicating the optimal team number.

Sizing subsequent roles

Using the optimal ratio of three Frontend Engineers, it is possible to calculate the sprint points needed for maximum efficiency, as seen in Table 5. For instance, if Frontend Engineers require 80% of a Fullstack Engineer's output, which translates to 140 sprint points per quarter, Table 6 aligns the number of Fullstack Engineers needed. These calculations take into account the efficiency of subsequent roles.

Table 5

Frontend Engineer Sprint Points Needed From Fullstack Engineer

Frontend Engineer	Sprint Points	Individual Productivity	Group Productivity	Sprint Points Needed from Fullstack Engineer
0	0	0	0	0
1	130	130	130	42
2	260	130	130	83
3	390	130	260	140
4	520	130	390	166
5	650	130	520	208
6	780	130	650	250
7	910	130	780	291

Table 6

Fullstack Engineer

Fullstack Engineer	Sprint Points	Individual Productivity	Group Productivity	Fixed Costs	Variable Costs	Total Costs	Average Fixed Costs	Average Variable Costs	Average Total Cost	Average Marginal Productivity	Average Marginal Cost
0	0	0	0	186,163	0	186,163	0	0	0	0	0
1	130	130	130	186,163	37,500	223,663	1,432.02	288.46	1,720.48	130	288
2	249	127	122	186,163	75,000	261,163	746.78	300.86	1,047.63	119	314
3	353	126	227	186,163	112,500	298,663	527.61	318.84	846.45	104	362
4	429	124	305	186,163	150,000	336,163	433.92	349.63	783.55	76	492

Implications: team composition and resourcing

As mentioned earlier, constructing high-performing digital product teams is often counterintuitive. This economic analysis of average marginal productivity and cost has revealed inefficiencies in my initial approach to team organization. Previously, I matched the number of Engineering Managers to engineering teams needed, as Figure 5 shows.

Figure 5

Original Team Composition Plan (source SVG)

However, recognizing that three Frontend Engineers per digital product team is optimal, I've revised the team composition into four smaller, more efficient teams, detailed in Table 7 and depicted in Figure 6. This reorganization improves efficiency and allows for more accurate prediction of quarterly sprint point delivery.

Table 7

Optimal Team Composition (maximum efficiency table from original figure)

Maximum Efficiency	Count	Expected Sprint Points Per Quarter
Teams	4	-
Frontend Engineers	10	1176
Fullstack Engineers	4	520
Engineering Manager	2	65
Product Designers	4	520
Data Analysts	2	260
UX Researchers	1	130
Product Managers	2	65
Total Team Size	25	-
Sprint Points Per Quarter	2736	-

Figure 6

Optimal Team Plan (source SVG)

Understanding the principles of marginal cost, average costs, marginal revenue, marginal output, fixed costs, and variable costs has shifted my approach to team composition and resource allocation.

The practical takeaway is that team size should be treated as an economic decision. Past the point where marginal productivity declines, scaling output by adding teams can be more effective than adding more people to the same team.

References

References

1. Estler, H.-C., Nordio, M., Furia, C. A., Meyer, B., & Schneider, J. (2013). Agile vs. Structured Distributed Software Development: A case study. Empirical Software Engineering, 19(5), 1197-1224.

2. Kavlakoglu, E. (2020, November 4). Agile vs. Waterfall. IBM. Retrieved March 23, 2022, from https://www.ibm.com/cloud/blog/agile-vs-waterfall

3. Cagan, M. (2019, September 18). Product vs. Feature Teams. Silicon Valley Product Group. Retrieved March 23, 2022, from https://svpg.com/product-vs-feature-teams/

4. Preuss, M. (2020). Digital Experience Handbook. GitLab. Retrieved March 23, 2022, from https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/#sprint-planning

5. Pierreten. (2020, June 20). How do you create a formula that has diminishing returns? Stack Overflow. Retrieved March 23, 2022, from https://stackoverflow.com/a/2813655

6. Wikimedia Foundation. (2022, March 21). Brooks's Law. Wikipedia. Retrieved March 23, 2022, from https://en.wikipedia.org/wiki/Brooks%27s\_law