TLDR: Quarterly planning doesn’t solve backlogs; it shows the demand-capacity gap. By distinguishing Core work from Clear and Scale work, leaders can add external capacity effectively, leading to faster delivery and reduced backlogs.
The Cargo Cult of Quarterly Planning
Your last planning meeting took eight hours. Forty-seven initiatives went into the prioritization matrix. Everyone agreed the CFO’s cost optimization was critical. Security’s compliance work couldn’t wait. Product’s three features would change everything.
You walked out with a ranked backlog. The top 12 priorities would take 18 months with your current team.
The meeting changed nothing except now you have documentation proving you can’t deliver what the business needs.
Prioritization frameworks give you the appearance of control while your backlog grows faster than you can ship. A healthcare CIO described it perfectly: demand comes in like a massive funnel from everywhere in the organization, and the universal answer is more process to manage that funnel.
The process prevents total chaos. It stops whoever screams loudest from getting resources. But you still have 23 months of critical work and 12 months of calendar time. Ranking changes nothing about that math.
Every hour spent in prioritization meetings is an hour you could have spent shipping something.
Why Engineering Capacity Gets Treated Like Office Space
Organizations treat engineering capacity like physical real estate. You have 40 desks, so you have 40 engineers. When demand exceeds 40 people worth of work, leadership says prioritize better or hire more.
Traditional hiring takes four months to fill a role plus three months before that person ships production code. Seven months total. In growth companies, new demand arriving in those seven months exceeds the capacity you just added.
The real problem is treating all engineering work as if it requires the same type of capacity. Your team’s deep knowledge of your legacy systems isn’t the same as capacity needed to build a greenfield API with clear requirements.
The Core-Clear-Scale Model for Managing Engineering Capacity
Core work requires institutional knowledge only your team has. Platform architecture, data model, technical debt, system dependencies. External help can’t ramp fast enough. This stays internal.
Clear-spec work has defined requirements without dependencies on legacy systems. New feature with an API spec. Greenfield mobile app. Dashboard pulling from your data warehouse. External capacity moves fast here because onboarding takes days, not months.
Scale work involves documented systems with established patterns. Extending existing features, maintaining codebases with good documentation, building variants of things you’ve built before. This scales with external teams without pulling core engineers off platform problems.
Most CTOs force their internal team to handle all three. When a critical project needs acceleration, you pull people from Scale work to help with Core work. Scale work becomes technical debt. Next quarter that debt becomes an emergency pulling people off the next critical project.
The loop never ends because you’re treating fixed internal capacity as the answer to variable demand.
How One CTO Cleared 15 Months of Backlog in Six Months
A hospital system ran a 40 person technology team against a 23 month backlog. The CFO sent passive-aggressive messages about IT velocity every Monday.
The CTO stopped trying to rank an unrankable backlog. Instead, he asked which initiatives required deep institutional knowledge versus which just needed solid engineering execution.
Twelve projects had clear requirements and minimal dependencies on legacy systems. External engineering capacity took those projects. The internal team focused exclusively on Core work only they could do.
Six months later, the backlog dropped to eight months. Completion rate exceeded incoming demand for the first time in 18 months. The CFO’s Monday messages stopped.
Stop Prioritizing and Start Asking the Right Question
Your next quarterly planning session is six weeks away. You’ll spend another eight hours with the prioritization matrix. The CFO will ask why technology can’t move faster. You’ll explain resource constraints and show the ranked backlog. Leadership will nod and nothing will change.
Or you could ask a different question before that meeting. Which of your 47 critical initiatives actually require your team’s institutional knowledge? Which ones are stuck in your backlog because you’re treating all engineering work as if it needs the same fixed internal capacity?
One question is prioritization theater that makes you feel productive while the backlog grows. The other question changes the math on what you can actually deliver.
The backlog isn’t a planning problem. It’s a capacity problem disguised as a planning problem. Companies that figure this out stop drowning. Companies that don’t keep ranking deck chairs while the ship sinks.
