1. [Writing](/writing) 2. / 3. Strategic Composition for Digital Teams: An Economic Approach 2023-11-08 · 16 min read # Strategic Composition for Digital Teams: An Economic Approach The Economics of Agile Team Structure Scroll to read Read with... Pick an agent - [ChatGPT](https://chatgpt.com/?q=Read%20this%20piece%3A%20Strategic%20Composition%20for%20Digital%20Teams%3A%20An%20Economic%20Approach%0AURL%3A%20https%3A%2F%2Fwww.assemblydigital.com%2Fwriting%2Fstrategic-digital-teams%0A%0APage%20context%3A%0ASummary%3A%20The%20Economics%20of%20Agile%20Team%20Structure%0A-%2016%20min%20read%0A%0AReturn%3A%0A1\)%20The%20core%20argument%20in%20one%20sentence.%0A2\)%20Three%20claims%20and%20where%20each%20could%20fail.%0A3\)%20The%20most%20useful%20takeaway%20for%20someone%20applying%20this.%0A4\)%20One%20practical%20next%20step%20to%20test%20this%20week.%0A%0AUse%20the%20page%20as%20the%20source%20of%20truth.%20Keep%20it%20concise%20and%20specific.) - [Claude](https://claude.ai/new?q=Read%20this%20piece%3A%20Strategic%20Composition%20for%20Digital%20Teams%3A%20An%20Economic%20Approach%0AURL%3A%20https%3A%2F%2Fwww.assemblydigital.com%2Fwriting%2Fstrategic-digital-teams%0A%0APage%20context%3A%0ASummary%3A%20The%20Economics%20of%20Agile%20Team%20Structure%0A-%2016%20min%20read%0A%0AReturn%3A%0A1\)%20The%20core%20argument%20in%20one%20sentence.%0A2\)%20Three%20claims%20and%20where%20each%20could%20fail.%0A3\)%20The%20most%20useful%20takeaway%20for%20someone%20applying%20this.%0A4\)%20One%20practical%20next%20step%20to%20test%20this%20week.%0A%0AUse%20the%20page%20as%20the%20source%20of%20truth.%20Keep%20it%20concise%20and%20specific.) - [Perplexity](https://www.perplexity.ai/search/new?q=Read%20this%20piece%3A%20Strategic%20Composition%20for%20Digital%20Teams%3A%20An%20Economic%20Approach%0AURL%3A%20https%3A%2F%2Fwww.assemblydigital.com%2Fwriting%2Fstrategic-digital-teams%0A%0APage%20context%3A%0ASummary%3A%20The%20Economics%20of%20Agile%20Team%20Structure%0A-%2016%20min%20read%0A%0AReturn%3A%0A1\)%20The%20core%20argument%20in%20one%20sentence.%0A2\)%20Three%20claims%20and%20where%20each%20could%20fail.%0A3\)%20The%20most%20useful%20takeaway%20for%20someone%20applying%20this.%0A4\)%20One%20practical%20next%20step%20to%20test%20this%20week.%0A%0AUse%20the%20page%20as%20the%20source%20of%20truth.%20Keep%20it%20concise%20and%20specific.) - [Your Claw](https://openclaw.ai) - [Gemini](https://gemini.google.com/app) Gemini and Your Claw use copy and paste. 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](#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](#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_ ![Flow of work from start to finish on a digital product team](/images/writing/strategic-digital-teams/figure-1-graphviz.svg) 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](#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](#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](#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)_ Frontend 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 Marginal Productivity Percentage Change Marginal Productivity Delta Average Marginal Cost Marginal Cost Percentage Change Marginal Cost Delta Return of Productivity 0 0 0 0 136,163 0 136,163 0 0 0 0 \- \- 0 \- \- \- 1 130 130 130 136,163 35,000 171,163 1,047.40 269.23 1,316.63 130 100% \- 269 100% \- 34970 2 249 127 122 136,163 70,000 206,163 546.21 280.80 827 119 91.76% 8.24% 293 108.98% 8.98% 34867 3 353 126 227 136,163 105,000 241,163 385.90 297.58 683.49 104 86.81% 4.95% 338 115.20% 6.22% 35152 4 429 124 305 136,163 140,000 276,163 317.38 326.32 643.70 76 73.57% 13.24% 459 135.92% 20.73% 34884 5 466 122 345 136,163 175,000 311,163 291.90 375.16 667.05 37 49.15% 24.42% 935 203.45% 67.53% 34595 6 455 119 336 136,163 210,000 346,163 299.42 461.79 761.22 \-12 \- \- \-2986 \- \- \- 7 389 115 274 136,163 245,000 381,163 349.85 629.49 979.34 \-66 \- \- \-534 \- \- \- 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](#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](#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)_ ![Original team composition plan](/images/writing/strategic-digital-teams/figure-5-original.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)_ ![Optimal team plan](/images/writing/strategic-digital-teams/figure-6-original.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](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/](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](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](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](https://en.wikipedia.org/wiki/Brooks%27s%5C_law) [ Previous post Stay Above the Curve ←](/writing/stay-above-the-curve)[ Next post Highways and Side Streets →](/writing/highways-and-side-streets-b2b-generative-ai) Read next [01Stay Above the Curve2023-03-30 · 7 min read→](/writing/stay-above-the-curve)[02Highways and Side Streets2024-05-24 · 4 min read→](/writing/highways-and-side-streets-b2b-generative-ai)[03AI Killed Servant Leadership2025-05-15 · 5 min read→](/writing/ai-killed-servant-leadership) Decision support ## Fast answers, zero fluff The core framing, audience fit, and time commitment in under a minute. 01What team size performs best in this model? In my experience, small teams with clear scope perform best because they preserve decision speed and reduce coordination drag. 02When does adding people make teams slower? I see teams slow down when dependency count rises faster than throughput and the organization starts paying a handoff tax. 03What should leaders do before hiring? Before I approve hiring, I reduce dependency chains, tighten ownership boundaries, and remove recurring coordination bottlenecks. 04How can we measure coordination cost? I measure coordination cost through decision latency, blocked-work ratio, handoffs per initiative, and rework rate. 05When does a larger team make sense? I scale team size only when work is modular, interfaces are stable, and leadership can absorb complexity without slowing execution.