Marcus Adeyemi manages an eight-person data engineering team at a logistics company. In April his director walked over with what she called "a quick question": could Marcus's team take on a new real-time tracking pipeline this quarter, on top of everything already in flight? Marcus said what he always said, "Let me check and get back to you." Then he stared at his roster for an hour, half-remembering who was on leave in May, mentally juggling allocations, and finally answered with a shrug disguised as confidence: "Probably, if things go well." Two months later things did not go well. The pipeline shipped late, two of his engineers were quietly burned out, and his answer had cost him credibility. This lesson is about never having to give that answer again.

What This Lesson Covers

Resource and capacity planning is the work of matching what your team can realistically do against what is being asked of them, then making honest decisions when those two numbers do not match. Capacity is your supply. Workload is the demand. The gap between them is where burnout, missed deadlines, and wasted salary all live.

AI does not make the decision for you. It does the arithmetic, models the scenarios, and drafts the analysis so you can spend your time on the part only you can do: knowing whether the numbers reflect reality. In this lesson you will learn to model team capacity, account for allocations and leave, run a feasibility check on new work, reason about what would have to shift, judge the quality of your inputs, spot over-allocation before it becomes attrition, and communicate capacity to the people asking you to do more.

Capacity planning is the part most managers do in their heads. That is exactly why it breaks down the moment things get complicated.

Modeling Team Capacity

Start with a simple truth: a person on your team does not give you 40 productive hours a week on assigned project work. Meetings, email, planning, code review, interruptions, and the general overhead of working in an organization all take their cut. The fraction of someone's time that actually goes to assigned work is their utilization rate, and for most knowledge teams it lands somewhere between 60 and 75 percent once you are honest about it.

The core capacity formula is plain: available capacity equals headcount times hours per person times utilization rate. If you have five engineers, each available 160 hours a month, at 70 percent realistic utilization, you have 5 times 160 times 0.70, which is 560 hours of real project capacity per month. Not 800. The 240-hour difference is the overhead that is invisible until you forget to subtract it.

You can express the same idea in FTE, or full-time equivalents, where one FTE is one person working full time. Five engineers at 70 percent utilization give you 3.5 FTE of usable capacity, even though your headcount says five. Managers who plan against headcount instead of effective FTE consistently overcommit, because they are budgeting hours their team was never going to have.

A useful AI prompt to set your baseline:

Here is my team: 5 engineers, each available roughly 160 hours per month. Based on our calendar, meetings and admin eat about 25 percent of the week and on-call support eats another 10 percent. Calculate our effective monthly project capacity in both hours and FTE, and show your working so I can sanity-check the assumptions.

What Actually Goes Into a Capacity Model

Before Marcus could answer his director, he had to know what a complete picture even looked like. Seven inputs make up a capacity model, and a plan that is missing any of them will be confidently wrong in a predictable way.

• Team size and roles. How many people, and in what roles. Six engineers and two analysts is a different capacity than eight engineers, because the work is not interchangeable.
• Utilization rate. The share of each person's time that goes to assigned project work, usually somewhere between 60 and 80 percent once overhead, meetings, and admin are subtracted.
• Current workload. Everything already planned for the coming quarter, in hours or FTE.
• Forecast workload. What is expected to arrive but is not yet committed. This is the input managers most often leave out, and it is why capacity plans that looked fine in January fall apart in March.
• Velocity, or actual productivity. How much work your team genuinely completes per sprint or per month, measured rather than assumed. Velocity is the reality check on every other number in the model.
• Skill requirements. Which roles and skills each piece of work actually needs. Hours are only fungible between people who can do the same work.
• Growth projections. Whether the workload is expected to grow, by how much, and when. A team that is comfortable today and facing a 40 percent increase next quarter has a hiring problem now, not later.

Available capacity is the total hours your team could put on assigned projects, which is headcount times hours times utilization. Workload is the total hours of work needed, whatever your backlog or burndown says. The capacity gap is the difference between the two, and its sign tells you which problem you have: a positive gap means overload, a negative one means underutilization, and both are worth managing.

Where the Rest of the Time Goes

It helps to see the overhead itemized rather than lumped into a single percentage, because that is how you defend the number when someone asks why your team is not planned at 100 percent. Meetings, planning, and admin typically take 15 to 25 percent of the week. Support, bug work, and interruptions take another 10 to 20 percent. Training and professional development take 5 to 10 percent. What survives, the time genuinely available for new project work, is usually somewhere between 50 and 70 percent.

The AI can do this arithmetic in seconds, but only you know your team's actual pattern. If your engineers are on a rotating support duty that eats a full day a week, that is not a rounding error, it is a fifth of their capacity, and it belongs in the model explicitly.

Accounting for Allocations and Leave

Raw capacity is only half the picture. The other half is where that capacity is already committed. An allocation is a claim on someone's time: Priya is 50 percent on the billing migration, 20 percent on production support, and so on. Sum the allocations and you see how much capacity is already spoken for and how much is genuinely free.

This is where mental math fails fastest. When three people are each 20 percent allocated to a legacy contract, and two of them are on vacation the same week in May, and a new project just kicked off, the question "how much can we actually take on?" stops being answerable in your head. Leave is not a footnote here. A single engineer out for two weeks in a quarter is roughly an 8 percent reduction in that person's quarterly capacity, and if they were your only specialist on a critical system, the practical impact is larger than the percentage suggests.

Feed the AI the full allocation picture and let it keep the books:

Build an allocation table for my team this quarter. Priya: 50% billing migration, 20% prod support. Sam: 80% tracking pipeline, on leave 2 weeks in May. Lin: 100% billing migration. Dev: 30% prod support, 40% tech debt. For each person show total allocated percentage, flag anyone over 85% or under 50%, and adjust Sam's effective quarterly capacity for the leave. Show remaining free capacity in FTE.

What comes back is a structured ledger you can correct, not a number you have to defend from memory. If Sam's leave actually falls during the tracking pipeline's critical week, you know that now, in a table, rather than in a postmortem.

Feasibility: Can We Take This On This Quarter?

This is the question Marcus fumbled in April, and it has a real answer. Feasibility analysis compares the demand of the new work against your free capacity after existing allocations and leave. The structure is always the same: how much does the new work need, how much do we have left, and what is the gap.

Let us work a full example with real numbers. Marcus's team is eight people: six engineers and two analysts. Each is available 160 hours a month, and across a three-month quarter that is 480 hours per person. Marcus, being honest about meetings and support, models effective utilization at 70 percent. So per person he has 480 times 0.70, which is 336 effective hours per quarter. Across eight people that is 2,688 effective hours, or 16.8 FTE-months of usable capacity for the quarter.

Now subtract what is already committed. Existing projects (the billing migration, ongoing production support, and tech debt) consume 2,100 hours. Two engineers have a combined three weeks of planned leave, which at roughly 84 effective hours per lost week removes about 252 hours. So committed plus leave is 2,352 hours, leaving 2,688 minus 2,352, which is 336 free effective hours for the quarter.

The new tracking pipeline, scoped honestly, needs 520 hours of engineering work this quarter. Free capacity is 336 hours. The gap is 184 hours, a shortfall of roughly 0.4 FTE for the quarter. The honest answer to "can we take this on this quarter?" is: not as scoped, not without something changing. That is a far better answer than "probably, if things go well," and Marcus now has the arithmetic to back it.

The prompt that produces this in two minutes:

Run a feasibility check. Capacity: 8 people, 480 hours each this quarter, 70% effective utilization. Already committed: 2,100 hours to existing projects. Planned leave: 3 person-weeks, roughly 84 effective hours each. New request: tracking pipeline needs 520 engineering hours this quarter. Calculate free capacity and the gap, and state plainly whether the new work fits as scoped.

What Would Have To Shift

A shortfall is not a no. It is the start of a tradeoff conversation, and this is where you earn your title. Once the AI has shown the 184-hour gap, ask it to lay out the levers rather than pick one for you:

We have a 184-hour shortfall on the tracking pipeline this quarter. Lay out the options to close it: (1) what could we defer or descope from existing work to free 184 hours, (2) what would the pipeline look like if we cut it to fit available capacity, (3) what contractor or partial-hire would cover the gap and roughly how many hours. For each option, note the main risk.

Marcus's options came back as three honest paths. He could defer the tech debt work, freeing the hours but accepting that the codebase stays fragile another quarter. He could ship a reduced pipeline, real-time for the top three customers only, deferring the rest. Or he could bring in a contractor for roughly six weeks, accepting onboarding cost and the fact that a contractor ramps slowly on an unfamiliar system. Marcus chose the descoped pipeline plus a small tech debt deferral, and crucially, he brought all three options to his director rather than a single take-it-or-leave-it answer. The decision became shared, and so did the accountability for it.

One discipline makes these conversations land: never present a single number as if it were certain. Model three versions. An optimistic case assumes everything ships on schedule with no surprises. A realistic case bakes in normal delays and the overhead you know is coming. A pessimistic case asks what happens if a key person leaves or a major blocker lands mid-quarter. When Marcus showed his director that the pipeline fit comfortably in the optimistic case, was tight in the realistic case, and broke entirely in the pessimistic case, the conversation stopped being about whether his estimate was right and became about how much risk the business wanted to carry. That is the conversation a manager should be having.

Garbage In, Garbage Out

Every model in this lesson is only as good as the numbers you feed it. The AI will compute confidently on bad inputs and hand you a precise, professional, completely wrong answer. The failure is almost never the arithmetic. It is the assumptions.

Three inputs go wrong most often. The first is utilization: you assume 75 percent because it sounds right, when your team's calendars say meetings and interruptions leave them closer to 55 percent. Plan against 75 and you are quietly overcommitted before the quarter starts. The second is hidden allocations: someone is "50 percent available" on paper while actually covering for a departing colleague, mentoring a new hire, or carrying an on-call rotation nobody logged. The third is ramp-up: a new hire is not 1.0 FTE on day one. Realistically they are near zero in week one and only approaching full contribution after a month or more, and during that ramp they consume your senior people's time, so capacity dips before it rises.

The discipline is simple: before you trust any capacity output, check whether the inputs match how work actually happens on your team. The AI cannot know that Sam is secretly the only person who understands the billing system. You can, and you have to tell it.

Skills and Buffers: The Limits of Hour Arithmetic

Two more assumptions break capacity plans, and neither is visible in the arithmetic. The first is treating people as interchangeable units. It is tempting to look at the model, see that one engineer sits at 55 percent, and move work to them. But a skill-based constraint means some work can only be done by people with specific skills, and it limits how freely you can reallocate. If the free engineer works on back-end systems and the waiting work is front-end, the capacity is real and unusable at the same time. Model capacity by skill and specialization, not only by headcount, and say so in the prompt when you ask the AI to rebalance.

The second is planning to 100 percent of capacity. It feels efficient and it is fragile: one urgent bug or one person off sick and the whole plan breaks, because there was never any slack to absorb it. Planning to 70 to 75 percent of capacity leaves 25 to 30 percent for the unknowns, the learning, and the growth that always arrive. That headroom is not waste. It is the difference between a plan that bends and a plan that snaps.

Over-Allocation Warning Signs

Sustained high utilization is not a badge of efficiency. It is a leading indicator of attrition. When you model your team and see individuals parked above 85 percent quarter after quarter, treat it as a warning light, not a target you have successfully hit.

The signals show up in the model before they show up in an exit interview. Watch for anyone over 85 percent for more than a sprint or two, for a plan that only works if nobody gets sick and no urgent bug appears, and for the same one or two names absorbing every overflow because they are reliable. Watch, too, for the inverse: someone sitting under 50 percent, which is its own problem of wasted cost and, often, disengagement. A healthy plan targets most people around 70 to 75 percent, leaving real headroom for the unexpected work that always arrives.

Ask the AI to police this for you:

Scan this allocation table and flag every person over 85% or under 50%. For anyone over 85%, note whether their load is sustainable for a full quarter or only with zero disruptions. Identify whether the same individuals are repeatedly absorbing overflow.

When Marcus ran this, the model surfaced something he had felt but never named: two engineers had quietly carried every rush job for three quarters running. They were the ones near burnout in his April story. Seeing it in a table is what finally let him fix it.

A Worked Example: Rebalancing the Load

Spotting an imbalance is the easy half. Fixing it is where capacity planning turns into management. By the following quarter Marcus's allocation table had drifted into a familiar shape: Priya at 90 percent, Sam at 60, Lin at 75, and Dev at 85. Priya was overloaded and at real burnout risk, Sam was underused, Lin was healthy, and Dev was slightly over. The work in front of them was the tracking pipeline needing about 90 engineer-hours, the billing migration needing 70, production support at 30, and tech debt at 20. Marcus wanted everyone near 70 to 75 percent, the band that leaves room to breathe and to learn.

Analyze utilization by person and suggest a rebalancing that gets everyone to 70 to 75 percent. Current: Priya 90%, Sam 60%, Lin 75%, Dev 85%. Work to cover: tracking pipeline 90 engineer-hours, billing migration 70, production support 30, tech debt 20. Tell me who should do what, the target utilization per person, and the risks in your proposal.

What came back was a concrete redistribution. Priya drops to about 75 percent by handing off her production support work and splitting the pipeline: 40 percent as primary engineer, which is roughly 64 hours, plus 10 percent, about 16 hours, mentoring Sam, with the remaining quarter of her time going to overhead. Sam rises to about 72 percent by taking 40 percent of the pipeline work with Priya's mentoring, keeping 12 percent for learning and the rest for overhead, an increase of a dozen points that grows his responsibility rather than simply filling his calendar. Lin holds steady near 72 percent but shifts focus, taking 40 percent on tech debt and refactoring with 20 percent on production support. Dev settles at about 73 percent as the primary on the billing migration at 50 percent, roughly 80 hours, with a reduced 10 percent of support.

The model also spelled out what the change buys and what it costs. The pipeline gains a second person while reducing any individual's load, the billing migration gets a focused owner, support is distributed across Lin and Dev instead of quietly living on Priya, tech debt finally gets dedicated time, and Sam develops expertise while Priya develops as a mentor. Against that, three risks: Sam needs real mentoring rather than nominal mentoring, so block two hours a week for it; Lin's tech debt work may feel invisible and undervalued, so its importance has to be said out loud; and the pipeline may run slightly slower while Sam ramps, so plan a 10 percent buffer.

Marcus read it and pushed back on one point, which is exactly the right instinct. Was it realistic for Sam to take on pipeline work given how complex that system had become? He decided it was, but only with the mentoring time protected. Then he did the part no model can do, which was to have three conversations. He told Priya he wanted to reduce her load because 90 percent was not sustainable, that some of her pipeline work would move to Sam, and that he wanted her to mentor him, then asked whether that would be motivating for her. He offered Sam the pipeline work as a growth opportunity with Priya's support. And he told Lin plainly that he wanted to invest in tech debt, that Lin would own it, and that while it was not glamorous it was what would let the team move quickly again. All three said yes, and the plan went in for the next sprint with a check-in after one sprint to adjust.

The lesson is the division of labour. The AI produced a defensible redistribution in seconds. Marcus supplied the relationships, the growth opportunities, and the honest doubt about whether Sam could ramp on that particular system. The result improved utilization, removed an overload, and developed two people, which is more than a spreadsheet can claim.

Communicating Capacity to Stakeholders

A capacity analysis that lives in your notes changes nothing. Its value is realized the moment you use it to have a clearer conversation with the people asking for your team's time. The shift is from "we're really swamped right now" to "we have 336 free hours this quarter, the request needs 520, here are three ways to close the gap." The first is a complaint. The second is a partnership.

Use the AI to turn your model into a one-page summary aimed at whoever is asking, whether that is your director requesting new work or a peer team negotiating a shared deadline. Lead with the gap, show the options, and make a recommendation. The goal is not to say no. The goal is to make the cost of yes visible, so the decision gets made with eyes open and by the right people.

There is also a staffing case to make here. When the gap is structural rather than one-off, your capacity model becomes the evidence for a headcount request. Instead of arguing "we feel stretched," you can show your director that the team runs at 110 percent of effective capacity this quarter, that the forecast workload grows another 40 percent next quarter, and that the gap widens to nearly a full FTE without a hire. AI is good at drafting that one-page business case from your numbers. You then add what it cannot know: the salary and onboarding cost, the replacement cost of losing one of your overloaded engineers to burnout, and the realistic timeline, since a hire approved today does not become productive until after their ramp-up. The argument that wins is the one that pairs the AI's arithmetic with your business context.

Two cautions on the human side. Be transparent about your real utilization rather than inflating it to look productive, because inflated numbers are how you get handed work you cannot deliver. And never use an AI-generated plan as cover to push people past sustainable limits. The model can justify 90 percent allocation across the board. Your job is to know that it should not.

A Worked Example: Building the Headcount Case

The most consequential thing a capacity model produces is a staffing request that survives contact with leadership. The method is the same at any team size, so take a smaller shape than Marcus's for clarity: four engineers and one designer, with a manager who wants to hire one more engineer and a leadership team that wants to know why.

You give the AI the raw picture, which takes ten minutes to assemble: current team size, the workload planned for the next two quarters, current capacity, and the forecast growth. Ask it to calculate the current utilization rate, the coming quarter's capacity gap, and the point at which a hire would be needed to support growth, then to draft a one-page summary supporting a headcount request. What used to be two hours of analysis becomes about thirty minutes, most of which is your review.

The analysis that comes back is unsentimental. Four engineers at roughly 75 percent available capacity give 3 FTE of usable engineering. The committed workload is 3.3 FTE, which puts the team at 110 percent utilization, overloaded by 0.3 FTE, while the single designer runs at 95 percent. Next quarter the planned workload rises to 3.8 FTE against the same 3 FTE of capacity, a shortfall of 0.8 FTE with no relief in the current trajectory. The quarter after that, with 40 percent workload growth, demand reaches 5.3 FTE against 3 FTE available, a gap of 2.3 FTE. Stated that way, the trend does the arguing for you.

The draft recommendation follows from the numbers: hire one engineer immediately, which covers the near-term gap and about 30 percent of the following quarter's growth; plan a second engineer for the quarter after; and add a contractor or half a designer's worth of support, since design is already at capacity. It also offers an alternative, hiring two engineers now to bring the team to six, which handles the growth and absorbs any attrition at higher cost, and then makes a clear call: hire one now to address the immediate overload and reassess next quarter against actual demand.

Now the manager's review, which is where the draft becomes usable. The arithmetic is correct, the overload is clearly stated, two scenarios are offered rather than a single demand, and the recommendation is unambiguous. Two things are wrong with it. The phrase "immediate crisis" is stronger than the situation warrants and will cost credibility with a director who knows the team is delivering; "unsustainable load" is accurate and harder to dismiss. And the draft is missing the two facts leadership will ask about first: what it costs, and how long hiring takes.

So you add them. On timing: if the hire is approved now, the engineer onboards in about two months and is productive by the start of the busy quarter, whereas waiting means the team is already overloaded and the new person does not catch up until the quarter after that. On cost: salary plus onboarding, set against the replacement cost of losing one of the currently overloaded engineers, which is the comparison that makes a hire look conservative rather than expensive.

The final request that goes upward is short. It states the current situation in numbers: the team is 10 percent overloaded, next quarter shows a 0.8 FTE gap, and the growth forecast implies a 2.3 FTE gap after that. It asks for one engineer with a target start date. It justifies the ask on four grounds: preventing the quality degradation that comes when overloaded teams cut corners, reducing attrition risk since overload is the primary driver of burnout, enabling on-time delivery of already committed work, and providing a buffer for growth. It lays out the cost against the replacement cost of attrition, and it sets out the timeline, including what happens if the decision is delayed: missed deadlines, damaged morale, and potential departures. Then it recommends approval and asks to start recruiting.

The AI calculated the capacity and the gaps. The manager supplied the business context, the cost framing, the timing, and the language. That combination is what turns a complaint into a compelling, data-backed request, and it is the same combination Marcus used to renegotiate his tracking pipeline.

Checkpoints Before You Commit to a Plan

Before you finalize any capacity plan, walk five checkpoints. They take a few minutes and they catch the errors that cost quarters.

• Reality check. Does this match your team's actual pace? Are the meeting and admin hours honest, and do the utilization numbers feel like the team you actually manage?
• Skill check. Is the work genuinely allocatable as modelled? Can this specific person do this specific work, and does the team hold all the skills the plan assumes?
• Growth check. Are you planning for people to learn and grow, or only maximizing short-term utilization? A plan with no development time in it is a plan that trades next year for this quarter.
• Sustainability check. Can the team carry this load over time? Sustained utilization above 85 percent leads to burnout, and anyone sitting at 50 percent or below is a waste of budget and usually a morale problem too.
• Contingency check. Where is the buffer for the unknown? Unexpected bugs, sick leave and holidays, and urgent requests are not surprises, they are certainties without dates attached.

Alongside those, hold to three commitments about how you use the analysis. Do not let an AI-generated plan become the justification for pushing people past sustainable limits, because sustained utilization above 80 percent leads to burnout and attrition no matter how neat the table looks. Be honest about your utilization rate rather than inflating it to appear productive. And share your capacity constraints openly with both your team and your stakeholders; if you are overloaded, say so plainly rather than hiding behind the analysis.

Practice

Four exercises will turn this from a method you have read about into one you have used.

Start with a current capacity analysis. List every person on your team, their projects, and their estimated hours per week. Calculate each person's utilization percentage, identify who is over and who is under, and then ask yourself the only question that matters: is this sustainable, and where are the imbalances?

Then try a rebalancing. Pick one person who is overloaded and one who has room. What work could actually move between them? What skills does that work require? How would you structure the handover, and what would the impact be on both people and on the delivery date?

Next, run a what-if scenario. Assume your workload grows 30 percent. What is the capacity gap, when would you need to hire to stay ahead of it, and how would you staff to handle the growth rather than absorb it through overtime?

Finally, build a hiring case. Put your current capacity against your workload, state the forecast gap, work through the cost and benefit including the replacement cost of attrition, and set out the timing and recruitment plan. Even if you never submit it, having it written is what lets you answer in one meeting rather than one quarter.

Then take two minutes for a reflection. Think about your past week and find one decision, one commitment, or one conversation where a capacity model would have changed your answer. What would you have done differently, and what would the outcome have been? Write it down. That connection between the method and your own week is where it starts to stick.

Related Lessons

Creating Project Plans With AI depends on the numbers you build here. A project plan is only as credible as the capacity assumptions underneath it, and a plan drawn against headcount rather than effective capacity will slip for reasons that have nothing to do with the work.

Prioritization Frameworks With AI is the other side of the same equation. Capacity tells you how much you can do; prioritization decides what fills it. When the feasibility check says the new work does not fit, prioritization is the discipline that decides what gets deferred.

Risk Identification and Mitigation picks up where the pessimistic scenario leaves off. Capacity risk, a key person leaving, a single specialist holding a critical system, an unplanned absence in the wrong week, is one of the most common risk categories, and the register is where those move from worry to plan.

Verification Workflows is how you keep the model honest over time, by tracking actual delivery against what you planned. Without that loop your utilization assumptions never improve, and the next quarter's model repeats this quarter's errors.

Key Takeaways

• Plan against effective capacity, not headcount. A person is not 40 productive hours a week. Apply a realistic utilization rate, usually 60 to 75 percent, and budget in FTE so you stop committing hours your team never had.
• Let AI keep the allocation ledger. Allocations plus leave are where mental math fails fastest. Give the AI the full picture and let it track who is committed where, so free capacity is a table you can correct rather than a guess you have to defend.
• Answer feasibility with arithmetic, not optimism. "Can we take this on?" has a real answer: free capacity minus the new work's demand. "Probably, if things go well" is the answer that costs you credibility two months later.
• A shortfall is a tradeoff conversation, not a no. Ask the AI to lay out the levers, defer, descope, or add a contractor, then bring options to the stakeholder so the decision and its accountability are shared.
• Your inputs decide your accuracy. The AI computes confidently on bad numbers. Wrong utilization, hidden allocations, and ignored ramp-up time are the usual culprits. Check that the inputs match how work really happens before you trust the output.
• Sustained high utilization is an attrition warning, not a win. Anyone parked above 85 percent quarter after quarter is a risk. Watch for the same names absorbing every overflow, and target most people near 70 to 75 percent to leave real headroom.
• Skill matters as much as headcount. Hours are only movable between people who can do the work. Model capacity by skill and specialization, or you will "discover" free capacity that cannot touch the task in front of you.
• Plan the ramp-up for new hires. Nobody is a full contributor in week one, and while they learn they consume your senior people's time, so capacity dips before it rises. Budget for that or your hire arrives as a short-term loss.
• Use AI for the analysis, not the decision. The arithmetic and the drafting are genuinely fast; the judgment about your team's dynamics, growth, and sustainability is the part that has to stay yours.
• Turn the model into a conversation. Capacity analysis is worthless in your notes and powerful in a stakeholder meeting. Lead with the gap, show the options, make the cost of yes visible, and keep your utilization numbers honest.