What I ask before we add capacity

TL;DR: Before I add people, budget, or tools, I ask four questions in a set order. If the team can't answer them on paper, the fix is writing the missing record. Hiring comes after that, if at all.

• Where is the written set? Every decision needs a call, an owner, and a date, written down.
• Is the process vague? If nobody has defined what done looks like, more people just means a bigger vague process.
• What are we refusing to reopen? Settled decisions stay closed unless a new fact breaks the call, the owner, or the date.
• What, exactly, is the capacity for? The request needs its own call, owner, and review date.

The team that asks me for one more hire often doesn't need one. A lot of the time they need one page, and once it's written, the speed they wanted to buy shows up anyway.

The request usually lands when things are bad. Work's heavy, dates are slipping, people are tired. So someone asks for more people, more budget, a new tool, sometimes all three in one message. I pause before I say yes.

Instead of starting with the request, I start with four questions. If the answers are missing, adding capacity is the wrong next step, and I say so. Below are the questions in the order I ask them, plus why the order matters.

The short version: capacity multiplies whatever you already wrote down. A clear decision on paper turns into more useful work. Nothing on paper turns into more confusion, just faster and pricier.

Question 1: Where is the written set?

A decision is a record with three parts: the call, the owner, and the date. Some teams say action items, owners, and due dates. I don't care much what you call it, as long as it's written down.

Alignment is a feeling. The room nods, the meeting ends on a good note, and people walk out sure they agree. Three days later each person remembers something a little different. It's happened to me enough times that I stopped trusting the nod.

So when a team asks for capacity, I ask them to show me the written set. Call, owner, date, on a page somewhere.

If they can, we keep talking.

If they can't, the missing record is what's holding the work back, and an extra person won't fix that because there's nothing written for them to do. A new hire can't invent the call. They can't name the owner either, and no tool on earth sets the date for you.

No standard plus a new tool means the mess moves faster. No standard plus a new person means the same mess, at a higher cost.

Key point: If nobody can point to the call, the owner, and the date on paper, the team needs a record before it needs more hands.

Question 2: Is the process vague, or are you really short on people?

A vague process is where cost hides. You won't find it as a line item. It shows up as rework, delays, and the same question coming back every few weeks in a slightly different outfit.

Before I add capacity, I want to know which of these is slowing the work down:

• Too few people for a clearly defined task
• A process that never says what done looks like

From inside a tired team these look the same, because both give you late dates and packed calendars. The fixes are completely different, though.

Add people to a vague process and the new folks inherit the fuzziness. They do something reasonable, because they're reasonable people. Reasonable just means someone guessed well. So the handoff shows up missing the call, the owner, or the date, and checking it takes another meeting.

So you paid to get more meetings.

A vague process with more capacity is just a bigger vague process. It's expensive and easy to miss, because spending money feels like you're doing something about it.

So before the hire, I ask the team to write down what done means for the slow step. One page. Specific enough that a stranger could check the work against it. Often that page alone gets back the speed we thought we had to buy. I'm honestly not sure why it works as often as it does.

Key point: Figure out whether you're short on people or short on a definition of done, because a vague process soaks up new hires and spits out meetings.

Question 3: What are we refusing to reopen?

For me, quality comes down to which decisions stay settled.

That sounds harsh until you spend time with a team that doesn't work this way. Any uncomfortable moment puts the old call back on the table. New stakeholders get a fresh debate as a welcome gift. The same decision gets made four times, each version a bit different, and eventually somebody suggests hiring a person to sort out the versions.

More capacity won't settle a decision that keeps getting reopened. It pays for the reopening: more people in the room, more opinions on a call that was done, more hours rebuilding what was already said and agreed.

I hold one rule here:

Reopen a settled decision only when a new fact breaks the call, the owner, or the date. When that happens, write a new set before anyone leaves the room.

New facts deserve a hearing. Discomfort gets a conversation, and then the record stands. That's the difference between a team that builds on its decisions and a team that keeps recycling them.

Before any capacity talk, I want the team to name what stays closed. If nothing does, new people spend their first six months relitigating history. I'd rather they spent those six months on real work, and so would they.

Key point: If decisions keep getting reopened, extra capacity just pays for more debate. Decide what stays closed first.

Question 4: What, exactly, is the capacity for?

I name the owner and the date before anyone leaves the room. That goes for every decision I make, and the capacity decision doesn't get a pass.

The request itself has to become a record:

• The call is what the extra capacity will do, in one plain sentence.
• The owner is the single person accountable for using it.
• The date is when we will know whether it worked.

“We need more people” fails this test. So does “we need a tool.” Both are feelings written up like plans. The call is the waiting work, written clearly enough that a new person or system could start on day one without a week of archaeology.

If you can't write that sentence, you're not ready to add anything.

Three follow-up checks get the same treatment:

Check 1: Put the standard in before the tool

A standard is what a complete decision looks like: call, owner, date, written together. Put that in before the software and before the headcount, because tools speed up whatever standard you have, even if that standard is nothing.

Check 2: Put one name on the constraint

When nobody owns the bottleneck, adding capacity just spreads it around. So pick one name. A committee turns a clear owner into a shared one, and shared ownership is how the date quietly dies.

Check 3: Set the review date

A capacity add without a review date turns into a permanent exception, and permanent exceptions are where cost hides. The review date is when you look again and check whether the add did the job you wrote down. Skip it and you've raised the run rate and started hoping.

Key point: A capacity request is a decision too, so it needs a plain call, one owner, and a review date before anyone says yes.

Why does the order of the questions matter?

The order is on purpose.

Written set first, then process, then what stays closed, and only then the request for more. Each answer is what makes the next question answerable.

By the time someone asks for capacity, the first three should already be true. If they're missing, the honest answer is to write the missing record. No hire, no purchase, at least not yet.

I'm keeping this general on purpose, because I respect how hard that moment is. I don't have one team, budget, or tool in mind. Teams under deadline hit the same wall: the calendar's full, the work is late, and the proposal on the table is to add. The four questions are the useful pause.

A whole room can leave the capacity conversation aligned. That feeling is free and proves nothing. The record proves something: where the set is, whether the process is specific, what stays closed, and what the capacity is for, with an owner and a date attached.

When those four answers are on the page, add the capacity, with my full support. When they're missing, write them first, then decide.

Key point: Each question sets up the next one, so jumping straight to the capacity question skips the three answers it depends on.

What does waiting to hire actually cost?

I'd rather delay a hire than staff a question that's still open.

People push back on that, and I get why. When the team's drowning, waiting feels like neglect. But an open question stays open no matter how many people are holding it. It just gets louder. The owner's still missing, or the date is, or the call is still a warm feeling the room nodded at on the way out the door.

Staffing an open question turns a thinking problem into a payroll problem, and payroll comes back every month.

The whole test, shorter:

Capacity multiplies whatever you already wrote down.

Write down a clear set and a new person is producing in week one, because the call, the owner, and the date are already waiting for them. Write down nothing and the new person makes more versions of the confusion you already had. On salary.

So before adding anyone or anything to your team, ask the four questions. Where's the written set? Is the process vague? What are we refusing to reopen? What exactly is the capacity for, with one owner and one date?

Answer them on paper. Then either add with confidence, or save the money and write the record. Both ways, you end up with a decision you can point to.

Key point: Waiting has a cost, but staffing an open question costs more, and that cost shows up again every month on payroll.

FAQ

What is a “written set”?

It's the record of a decision: the call (what happens), the owner (who's on the hook), and the date (when it's due). Some teams call it action items, owners, and due dates. Either name works if it's on paper.

Why isn't alignment in a meeting enough?

Because alignment is a feeling. People leave sure they agree, and a few days later each one remembers something slightly different. A written record doesn't drift like that.

How do I tell a vague process from a real people shortage?

Write down what done means for the slow step, specific enough that a stranger could check the work against it. If that page brings the speed back, the process was the problem. If the work is clearly defined and still piling up, you might really be short on people.

When is it OK to reopen a settled decision?

Only when a new fact breaks the call, the owner, or the date. Discomfort on its own doesn't count. When you do reopen, write a new set before anyone leaves the room.

Why should a capacity request have a single owner?

When a committee owns it, nobody really owns it, and the date quietly dies. One name means one person is accountable for whether the new capacity gets used well.

Why does a capacity add need a review date?

Without one, the add becomes a permanent exception, and that's where cost hides. The review date is when you check whether it did the job you wrote down.

Isn't delaying a hire unfair to a team that's drowning?

It can feel that way. But an open question stays open no matter how many people hold it. Writing the missing record usually helps the team faster than a new hire who has nothing clear to work on.

Key Takeaways

• Capacity multiplies whatever you already wrote down, the good parts and the messy parts.
• Every decision, including a capacity request, needs a call, an owner, and a date on paper.
• Adding people to a vague process gets you a bigger vague process and more meetings.
• Reopen settled decisions only when a new fact breaks the call, the owner, or the date.
• Put the standard in before the tool, put one name on the constraint, and set a review date.
• Ask the four questions in order. If the answers are missing, write them before you hire or buy anything.