# TBM 334: The Capacity Allocation Illusion ! [ rw-book-cover] (https://readwise-assets.s3.amazonaws.com/media/uploaded_book_covers/profile_126891/https3A2F2Fsubstack-post-media.s3.amazonaws.com2Fpublic2Fimages2Ff4bf8fc8-1935-47c1-bc46-bfdc95a0cadc_1200x960.png) URL: https://cutlefish.substack.com/p/tbm-334-the-capacity-allocation-illusion?utm_source=post-email-title&publication_id=24711&post_id=155147232&utm_campaign=email-post-title&isFreemail=true&r=3mtnp9&triedRedirect=true&utm_medium=email Author: John Cutler  ## AI-Generated Summary The article discusses the complexities of measuring team capacity in software development and warns against oversimplifying it to just time tracking. It emphasizes that capacity involves many factors, including past investments and the ability to adapt, rather than just the number of hours worked. Ultimately, true capacity reflects a team's long-term strategic capabilities, not just their immediate outputs. ## Highlights > People with more background in manufacturing will offer ideas like: > > *You have to consider factors like supply chain reliability, the quality of raw materials, equipment maintenance schedules, seasonal demand, and energy costs. And it 100% depends on the current bottleneck. One thing can limit the output of the whole line, no matter how well everything else is running. Also, capacity isn't just about how much you can produce but how consistently you can hit that number under real-world conditions. There are many ways to theoretically boost production in the near-term that are unsustainable long-term in the real world.* ([View Highlight](https://read.readwise.io/read/01jjam71xtmf3dkjwqdqmps3tk)) > Shifting to the software product development world, let's brainstorm the investments that constitute our "current capacity." Today's capacity is a function of investments in: > 1. Hiring, onboarding, training, developing, and retaining employees > 2. Developing high-performing teams with trust and psychological safety > 3. The current organizational structure, reporting lines, etc. > 4. Insights about the market, customers, partners, competitors, the codebase > 5. Building "the product" and everything learned while building the product > 6. Working (or not working) down technical debt > 7. Tools, systems, and infrastructure to enable teams > 8. Partnerships, brand equity, and customer relationships/goodwill > 9. Taming bureaucracy, waste, friction, perverse incentives, etc. > 10. Efforts to strengthen and preserve the unique culture ([View Highlight](https://read.readwise.io/read/01jjam8aee5qdec0mpysj8z0qt)) > I once worked at a company that encouraged a lot of mobility between teams. Despite it likely being less efficient in the short term, it had the benefit of giving people broad exposure to the codebase, different customer personas, and different teammates and team environments. When conditions changed, the company was able to adapt without too much disruption. Meanwhile, I've worked at other companies where deprioritizing a particular product area meant almost certain layoffs due to more rigid reporting lines and budgeting. Decisions in both companies impacted the nature of their capacity. ([View Highlight](https://read.readwise.io/read/01jjamjph2mc2kr7ee6j3k988x)) > Picture a team experiencing debt-induced friction and high context-switching costs caused by juggling too many efforts simultaneously ("I'm sorry, they are all high priority"). The team's **capacity** to deliver impactful changes is low, not because they lack hours, but because the system is overwhelmed and the code is hard to work with. ([View Highlight](https://read.readwise.io/read/01jjamk9s5cd36svddpr64fg06)) > • Teams frequently tackle new, novel problems. > • Adding more people to a software team doesn't linearly increase capacity (though I have seen large groups self-organize into smaller, loosely coupled groups to get something big done). > • Teams build and maintain the factory while operating it > • They maintain and upgrade what they "ship" for long periods of time. > • Teams must monitor and respond to feedback in tighter loops. > • The tool and technology landscape changes rapidly > • Capacity in software relies heavily on intangible assets like shared context. ([View Highlight](https://read.readwise.io/read/01jjamrhkn9qbv0zrhvx1fky39)) ![[Capacity Allocation Illusion - John Cutler.png]]