8 Ways to Grow Solar Project Capacity Without Hiring

The hiring request often appears before the capacity diagnosis. A queue grows, customers ask for dates, several people stay late, and the obvious conclusion is that the company needs another person. Sometimes it does. Sometimes the proposed hire would inherit incomplete requests, reopen old decisions, search for current files, and wait on the same reviewer as everyone else.

To grow solar project capacity without hiring for every gain, treat headcount as one capacity lever rather than the default unit of growth. Define the work that should flow, prove the current constraint, protect the decisions that require competent authority, and test one change at a time. The aim is not maximum busyness. It is more completed, usable work without hidden recovery landing elsewhere.

That boundary matters. This article does not promise that a smaller team can absorb unlimited demand. Chronic overtime, skipped review, and quiet role expansion are not capacity strategies. A justified hire is a good outcome when the evidence shows sustained ready demand at a role-specific constraint. The work here is to make that decision with something better than a crowded calendar.

The solar operations bottleneck guide owns the diagnosis of the current constraint. The capacity-leverage checklist owns project-level review gates as a team grows. This page starts after that diagnosis and asks what to change: eight operating levers, the evidence each requires, and the point at which process repair should give way to software, flexible capacity, or permanent hiring.

What does solar project capacity actually mean?

Solar project capacity is the amount of ready, correctly scoped work a defined workflow can complete to its stated exit rule while preserving required quality, review, safety, and customer meaning. It is not employee utilization, pipeline size, raw backlog, or the number of tasks opened. Capacity belongs to a workflow and project class, not a headcount total.

That definition contains four controls. First, the work must be ready. A request missing site identity, customer scope, required evidence, or a decision owner is demand, but it is not yet executable demand for the next stage. Second, completion must have an exit rule. “Designer finished” is weaker than “the identified scenario, inputs, assumptions, review state, permitted use, and affected outputs are available to the receiving owner.”

Third, the workflow needs a boundary. Proposal capacity, permit-design capacity, installation capacity, and closeout capacity are different. One company can have available field labor while preliminary technical review constrains customer-facing work. Fourth, the work needs a class. A routine preliminary layout and a complex commercial revision should not be compared merely because both are called projects.

The U.S. Department of Energy’s solar soft-cost overview defines soft costs as non-hardware costs associated with going solar, names business and process categories, and says slow or inefficient processes contribute to them. DOE does not tell an individual company where capacity is lost or what an intervention will save. It does establish that workflow friction belongs in the cost conversation rather than being dismissed as ordinary office noise.

Keep these ideas separate:

A credible capacity statement therefore names the flow unit, project class, start and finish, readiness rule, observation period, source records, exclusions, review protections, and known gaps. “We can handle more projects” is not yet a capacity finding. “This workflow completed more work that met the same exit rule, with the same project class and review protections, during the bounded test” is closer, but any public numerical result still needs retained inputs and validated calculations.

Capacity also has a human limit. A workflow that produces more output by converting lunch, evenings, or constant interruption into unpaid buffer has not created durable operating capacity. It has shifted cost and risk onto people. Record workload signals, leave, training, supervision, and escalation health alongside the flow evidence. A result that cannot be repeated without exhaustion is an exception, not a new baseline.

Which constraint should a solar company fix first?

Fix the constraint supported by ready-work accumulation, downstream need, return patterns, and a reversible test, not the loudest complaint. Define one workflow and project class, audit its state records, separate blocked from ready work, and identify the decision or resource that limits usable completion. If evidence remains mixed, keep the diagnosis undecided.

Start by drawing the actual path, including information movement. A neat departmental sequence often hides the work: sales asks for missing data, design opens a partial model, review returns it, operations chases a customer choice, and someone updates a proposal that still points to the prior scenario. The queue sits in several tools and several heads.

The National Institute of Standards and Technology says value stream mapping visualizes manufacturing process and information flows. Its general sequence is to identify the value stream, map the current state, diagnose problems and define a future state, and implement improvements. NIST also emphasizes cross-functional participation. This is a manufacturing method, not a solar rule or result. The useful analogy is that a capacity map should include the people who supply and consume the output, not only the manager who owns the queue.

For a solar workflow, map these objects:

• the request and the customer or project identity it belongs to;
• the required evidence and the state of each item;
• the scenario, design, document, or decision that moves;
• active, review, blocked, returned, released, and superseded states;
• the role authorized to change each state;
• the next consumer and its acceptance rule;
• external waits that no internal staffing change can remove;
• rework caused by a legitimate project change versus preventable recovery.

Do not assign every delay to the person nearest the queue. A design team can appear slow because intake releases incomplete requests. A reviewer can appear slow because every item arrives as an exception. A project coordinator can appear overloaded because current status exists only after reconstructing email, chat, and document versions. A field team can appear underused because projects called “scheduled” lack a released design, material decision, access condition, or approval.

NASA’s technical-planning guidance applies to NASA systems work, not solar businesses. It describes defining technical effort against objectives and cost, schedule, and risk constraints, planning workflows and resource requirements, assigning roles and interfaces, and reassessing plans when resources or constraints change. The analogy prevents one common mistake: adding a resource before reconciling what work the objective actually requires and which interface constrains it.

Copy-ready solar capacity experiment record

Use this operating record for one proposed change. Leave unknown fields unknown. Do not fill a blank with an optimistic estimate just to make the experiment look complete.

The record is deliberately stricter than “try the tool” or “give the team a push.” It makes the mechanism falsifiable. If an intake change reduces blocked starts but the reviewer queue remains unchanged, the team learned something. If an automation moves work forward but returns rise because input states were ambiguous, the intervention did not create usable capacity.

NASA’s technical-assessment guidance describes monitoring progress through reviews and defined indicators that support technical and management decisions. That guidance is not a solar benchmark. Its useful lesson is to connect a measure to a decision. A dashboard full of timestamps has little value when nobody can say which capacity choice a signal should support.

How do eight capacity levers work?

The eight capacity levers improve different mechanisms: readiness, focus, repeated decision work, revision recovery, review allocation, skill concentration, information transfer, and variable demand. Apply a lever only where evidence supports its mechanism. Protect competent authority and downstream acceptance throughout the test, and stop when apparent speed comes from hidden work or weaker review.

Use this table as a routing view, not a scorecard:

1. Improve intake readiness before accelerating starts

An intake rule increases usable capacity when the constrained stage receives work it can actually complete. Define the minimum identity, scope, evidence, customer decision, output requested, owner, and missing-information treatment for that project class. A request that fails the rule stays visible, but it does not quietly enter active work.

This is not an excuse to reject every imperfect project. Early solar work often includes uncertainty. The rule should distinguish an accepted assumption from missing evidence and a missing decision from a known exception. The next person needs to know what is provisional, who owns verification, which output may be produced, and what release remains blocked.

Create a separate exception lane for urgent or unusual work. An override should record the reason, authorizing person, work displaced, missing information, review restriction, and next checkpoint. Without that record, “urgent” becomes a second intake system and any WIP limit becomes fiction.

Watch for gaming. A team under pressure may mark a request ready because the status is required, attach an old bill because a file is required, or copy a default assumption because a value is required. Readiness is a factual condition, not a green icon. Audit a sample against the source evidence and downstream acceptance rather than trusting field completion alone.

The site-visit reduction guide goes deeper on evidence completeness and the boundary between remote work and site verification. Reducing repeat collection can create capacity, but only when the retained evidence supports the stated use. A missing roof, access, structural, electrical, safety, customer, or jurisdictional fact does not become harmless because a workflow moved faster.

2. Limit simultaneous active work and protect focus

A large active queue can consume capacity without completing more. Each reopened item requires someone to find the current request, recover prior reasoning, check whether inputs changed, and decide what still applies. Limit the number of items genuinely active at the constrained stage, while leaving queued and blocked demand visible.

The boundary should be local and adjustable. There is no universal number of active solar projects per designer, reviewer, coordinator, or crew. Project mix, skill, evidence quality, review depth, tooling, market rules, and customer variation make a borrowed ratio unreliable. Begin with observed work, identify the point where starts displace finishes, and retain the evidence behind any policy.

Define what “active” means. If nobody is working an item and no immediate decision is pending, it may belong in ready, review, or blocked. A status called “in progress” that covers all four conditions prevents useful measurement. Give blocked work a reason and owner so it does not disappear when the active lane is tightened.

Priority overrides need consequences. When a leader inserts an urgent item, the record should identify which work pauses, which customer or internal commitment changes, and who communicates the effect. Otherwise the active boundary exists only for routine work while interruption continues unchanged.

The solar design queue metrics guide owns detailed queue-age, work-in-progress, blocked-task, review-delay, and revision signals. Use those measures descriptively before turning them into targets. If people protect a number by hiding work in another state, the metric has stopped representing capacity.

3. Standardize recurring decisions, not every project outcome

Repeated interpretation consumes scarce attention. If qualified people answer the same naming, evidence-state, scenario, output, review-response, or handoff question differently, define the decision boundary once. A useful standard states applicability, required inputs, default method, output meaning, prohibited shortcuts, exception evidence, accepting authority, and change owner.

Standardization does not mean identical designs. Solar projects differ in geometry, site evidence, equipment, customer objectives, local requirements, and professional decisions. The standard should make those differences visible. It should not force a difficult project into the shape of an ordinary one so a dashboard stays green.

Begin with high-frequency, low-ambiguity decisions that create downstream reconciliation when inconsistent. Project identity, scenario naming, evidence states, current-versus-superseded outputs, and review-response states are usually safer starting points than a technical conclusion that depends on local facts. Test ordinary, incomplete, conflicting, and exception cases before publishing the rule.

The standardize solar design guide provides a rule card, standards register, exception model, and rollout process. Keep standards and QA separate. A standard defines the expected method or state. QA tests a project against the applicable rule and records the response. Combining them makes it difficult to tell whether a project failed or the standard was wrong.

Retire old copies. A new rule does not create capacity if a proposal template, spreadsheet, onboarding page, equipment library, and personal checklist retain different meanings. Name each consumer, update it, and record what superseded the prior version. The work of maintaining the standard is part of the capacity calculation, even when it is not visible on a project board.

4. Control revisions and remove duplicate reconstruction

Revision work is not inherently waste. Customer choices, site findings, equipment availability, permitting feedback, utility decisions, engineering review, and scope changes can legitimately reopen a project. Capacity disappears when the team cannot identify the active scenario, determine what changed, or find which outputs and people consume that change.

NASA’s configuration-management guidance applies to NASA work, not solar companies. It describes making product state known, distinguishing versions, controlling baseline changes, tracking changes, and keeping products consistent with information about them. The process analogy is direct: a revision should carry identity, source, decision, affected objects, review, release, and supersession.

Use one change record for the connected project objects. State the prior value or decision, new value or requested change, source, date, reason, owner, technical or commercial review required, outputs affected, customer communication effect, and status of the old version. A chat message can alert people, but it should not be the only durable record of a material change.

Then remove duplicate reconstruction. If a coordinator must read several threads to produce a status, a designer must retype a module choice into separate tools, or a proposal owner must compare PDFs to discover the current system size, the company is spending scarce attention on transfer. Fix the field authority and change path before automating the copying.

NASA’s technical-data-management guidance covers data identification and control, retrieval metadata, point-of-use access, reusable formats, origin and change responsibilities, storage, procedures, tools, and training. It is another analogy, not a solar requirement. It helps expose why “all the data exists somewhere” is not the same as usable project information.

5. Move checks upstream while preserving final authority

Late review is expensive in attention because several outputs may already rely on the same bad input or inconsistent scenario. Move checks upstream when an earlier role or automated control can verify an objective condition: required fields, project identity, source date, equipment mapping, scenario agreement, missing evidence, revision status, or output-to-input consistency.

Do not move approval merely because you moved a check. A salesperson can confirm that a consumption document is attached and associated with the correct customer. That does not authorize a financial interpretation. A coordinator can confirm that a design version is identified. That does not approve electrical, structural, safety, production, or code conclusions. An automated check can compare values and still be unable to decide which value is valid.

Use risk-tiered review only when the tiers have explicit criteria, authority, and exception handling. Routine work may follow a standard route. A project with conflicting evidence, unusual geometry, a new equipment combination, a local requirement, a material customer change, or a professional judgment may need a different reviewer. The result should be “route changed,” not “capacity target missed.”

Record return reasons at the decision boundary. “Design error” is too broad. Name whether the return involved missing input, wrong source, stale scenario, misunderstood request, rule ambiguity, legitimate change, reviewer disagreement, or an external response. That distinction tells the team whether to improve intake, training, standards, tools, review criteria, or customer communication.

Upstream checks create usable capacity only if they reduce preventable recovery without suppressing legitimate review. Observe downstream acceptance, later corrections, workload, and unreported work. A shorter review queue can be a false success when people stop logging the questions they still resolve privately.

6. Cross-train bounded work and preserve escalation

Cross-training helps when one person’s time is consumed by routine work that can be described, practiced, observed, and reviewed. Choose a bounded task, not an entire professional identity. Define the required inputs, allowed actions, output, prohibited decisions, examples, competency evidence, supervision, escalation route, and conditions that return the task to the specialist.

Good candidates are repeatable and inspectable. They may include intake completeness checks, project identity control, source-file organization, scenario-status updates, routine output preparation, or a clearly governed first-pass consistency check. Whether any task is suitable depends on the company’s people, agreements, jurisdiction, risk, and required qualifications.

Do not turn familiarity into authority. Someone who can prepare a record may not approve its technical meaning. Someone who can operate a model may not accept its assumptions. Someone who can identify a common issue may not decide the engineering, safety, contractual, financial, permitting, utility, or customer consequence. Put the escalation boundary on the task card and in the workflow.

Cross-training also needs coverage logic. If everyone learns a little but nobody owns final decisions, the team creates a wider uncertainty network. Name the primary owner, backup, reviewer, and unavailable-state response. Training time and supervision consume capacity before the new coverage can support it, so include them in the experiment rather than treating learning as free.

Use actual cases. Have the learner process an ordinary case, an incomplete case, a conflict, and an exception. Ask them to explain what evidence supports the action and where authority stops. A clean demonstration alone shows memory. An exception shows whether the person can protect the boundary when the workflow becomes inconvenient.

7. Use software at a verified transfer point

Software is a capacity lever when it removes a demonstrated transfer problem while preserving the project’s meaning. Good targets include duplicate entry, version searches, repeated output assembly, disconnected scenario updates, or review records that are difficult to retrieve. “We need automation” is too broad to test.

Define the input contract first. Which fields are authoritative? Which may be estimated? Which require a source and date? Which project object owns a value? What happens when two sources conflict? Which output can be generated before review, and which release remains restricted? Automation makes an answer repeatable. It does not make the answer valid.

The Department of Energy’s PV system design overview describes connected choices involving modules, mounting, orientation, inverters, storage, and other system elements. DOE does not prescribe a company workflow. The connection matters because a changed design input can affect layout, energy analysis, electrical work, materials, financial scenarios, and proposal language. Tooling should expose that dependency rather than produce several polished but inconsistent outputs.

Test software on changed and incomplete work, not only a clean new project. Can the team identify the current scenario? Does a changed equipment choice reach every affected output? Can a reviewer find the source and assumption? Does the system preserve a superseded state? Can the workflow stop an output from being treated as approved? Can the team recover or export the needed record if the process changes?

Measure the transfer, not the sales demonstration. Observe data reconstruction, review effort, correction reasons, downstream acceptance, exception handling, training load, and workload at the suspected constraint. Do not publish a time or labor result unless the comparison uses defined work, retained inputs, a validated calculation, and an honest account of setup and review.

8. Add flexible capacity before making a permanent change

Temporary internal coverage, a specialist service, or an external production partner can test whether added capacity at the suspected constraint changes whole-workflow completion. This can suit a variable peak, a bounded work package, a capability needed intermittently, or a reversible step before permanent hiring. It is not automatically cheaper or safer.

Package the work. Define project identity, required inputs, evidence states, output format, company standard, allowed assumptions, prohibited decisions, review criteria, revision handling, acceptance state, communication path, confidentiality, security, ownership, retention, and exit. If the package requires constant explanation, the company may have exposed an undefined process rather than a labor shortage.

Keep the accepting authority inside the correct boundary. An external provider can prepare work within scope. The company still needs a person able to review the output, resolve exceptions, connect it to customer and project commitments, and route decisions reserved for qualified or external authorities. Outsourcing a bottleneck without preserving acceptance capacity can create a larger review queue.

Observe coordination and correction. A provider’s delivered count is not the same as usable completion. Track whether the receiving owner can accept the work, whether returns concern preventable misunderstandings or legitimate changes, whether project meaning survives, and whether the arrangement protects customer, security, technical, and contractual obligations.

Flexible capacity should have a stop rule. End, revise, or narrow the test when input quality prevents useful work, review demand exceeds the relief, security or authority boundaries are unclear, later corrections rise, or the original constraint does not move. Continue only because evidence supports the mechanism, not because setup effort makes the team reluctant to stop.

Illustrative workflow: a review constraint after intake repair

This illustrative workflow is not a customer case and includes no claimed result. A solar company sees many preliminary-design requests waiting. Its first hypothesis is insufficient design capacity. The intake audit shows that several requests are blocked by missing scope or site evidence, while a smaller ready group repeatedly waits for one technical review decision.

The company separates blocked from ready requests and assigns missing-evidence owners. It then protects a review block for the ready project class, standardizes the review packet, and routes exceptions separately. The experiment record preserves prior state, reviewer authority, work mix, return reasons, downstream acceptance, workload observations, and a stop condition.

If usable completion changes while review quality and downstream acceptance remain intact, the review point was likely part of the constraint. If work merely accumulates at proposal reconciliation, the team has exposed the next limit. If no whole-flow response appears, it rejects or revises the hypothesis. Only after this test does it compare cross-training, flexible review support, tooling, and a permanent hire.

A bounded process for running a capacity experiment

Use the following sequence for one workflow and one project class. Do not combine several levers in the first test, because the team will not know which mechanism changed the result.

1. Name the decision. State whether the evidence will inform intake, sequencing, standards, cross-training, software, outsourcing, hiring, or another capacity choice.
2. Define the flow. Record the unit, project class, start, finish, exit rule, ready rule, blocked states, and excluded work.
3. Audit the record. Check identity, sources, dates, state history, return reasons, side channels, duplicates, missing data, and changed definitions.
4. Write the constraint hypothesis. Name the current limiting decision or resource, mechanism, evidence period, and alternative explanations.
5. Choose one lever. Explain how the lever should change the constraint and why a smaller or more reversible test is not sufficient.
6. Protect authority. Retain technical, safety, structural, electrical, financial, contractual, permitting, utility, lender, insurer, customer, and professional review where applicable.
7. Define stop and rollback conditions. Include quality, workload, customer, security, downstream, authority, and data-integrity failures.
8. Record the starting state. Preserve the actual work mix, ready and blocked items, open returns, staffing conditions, unusual events, and known data gaps.
9. Run the bounded change. Keep the entry, exit, and observation definitions stable unless a defect in the definition itself requires the test to stop.
10. Inspect the whole workflow. Look at usable completions, downstream acceptance, returns, blocked work, workload, and where work accumulates next.
11. Classify the result. Mark the hypothesis supported, rejected, mixed, or undecided. Do not turn incomplete evidence into a win.
12. Make and record the decision. Adopt, revise, reverse, escalate, outsource, hire, or run a different test, with a named owner and review trigger.

Run the process with the people who supply, perform, review, and consume the work. A capacity change that helps one team but creates reconciliation for another is a local optimization. Make the downstream owner part of acceptance.

How do you choose process, software, outsourcing, or hiring?

Choose the intervention that matches the proven mechanism and required authority. Repair process when readiness or rules fail, use software when verified information transfer consumes capacity, outsource bounded variable work with clear acceptance, cross-train specifiable tasks with supervision, and hire when sustained ready demand remains at a strategically important competent role after safer tests.

The decision is not a maturity ladder where hiring comes last and software wins. Each route solves a different problem. A company with sustained demand for a qualified decision cannot template its way out of the need. A company with broken intake should not hire someone to curate preventable ambiguity. A company with seasonal overflow may not need a permanent role. A company whose central capability depends on outside availability may decide internal ownership is worth the fixed commitment.

Use a decision record like this:

Hiring evidence should be role-specific. Preserve the ready demand, project mix, work content, current coverage, supervision, review authority, training requirement, forecast assumptions, workload condition, alternatives tested, risks, economics, and decision owner. Do not use a generic projects-per-person ratio from another business as the controlling fact.

A new hire also creates work before adding reliable capacity. Recruiting, selection, onboarding, access, equipment, training, supervision, quality review, and team integration belong in the plan. This does not argue against hiring. It prevents the company from promising immediate relief while the constrained specialist must train the new person.

There are clear reasons to stop searching for a no-hire answer. Stop when workload is unsafe or unsustainable, competent authority is unavailable, a core capability needs durable ownership, external support cannot meet acceptance or security needs, the tested process already works, or ready demand remains above the protected capacity the business is willing to provide. The goal is not fewer employees. It is an operating system whose staffing choices are explainable.

Capacity decision failure modes

The most honest result can be “undecided.” If the observation period did not include the relevant project class, data is incomplete, work definitions changed, or several interventions ran together, do not manufacture confidence. Preserve the gap and choose a smaller next test.

How should SurgePV support capacity growth?

SurgePV can support capacity work by keeping roof models, layouts, shading, energy, financial scenarios, electrical workflow information, bills of materials, and proposals connected to project inputs and review. It cannot validate missing evidence, authorize staffing, accept project risk, or replace responsible technical, financial, customer, permitting, utility, lender, insurer, and professional decisions.

Start with the transfer point identified by the experiment. If designers rebuild project context because source evidence and assumptions are scattered, test whether a connected project record makes the current scenario and inputs easier to inspect. If proposals drift from the design after a revision, use the verified solar proposal workflow as one transfer test. If the constraint is field labor, authority response, or missing customer access, design-and-proposal software may not address it.

SurgePV’s repository source of truth lists 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation within published product scope. This is first-party evidence about the product, not an objective productivity result.

The same source states that results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility. Confirm current access, implementation scope, pricing, and contract terms in a written quote.

Use a difficult test project. Include a changed input, an unresolved evidence item, more than one scenario, and an output that needs review. Ask each receiving role to identify what is current, what is assumed, what changed, who can accept it, and which release remains blocked. A clean demonstration can show features. A changed project shows whether the workflow protects meaning.

The scalable solar design workflow guide owns the broader operating architecture. This article’s narrower test is capacity: does the verified transfer problem at the current constraint improve without weakening acceptance, authority, or workload? Keep the answer local until the company has retained evidence across the work it actually performs.

Frequently Asked Questions

Can a solar company grow project capacity without hiring?

Sometimes. A team can recover usable capacity when incomplete intake, excess parallel work, repeated decisions, avoidable revisions, unfocused review, skill concentration, or disconnected tools consume the current staff. That is not a promise that hiring is unnecessary. Sustained ready demand at a competent, protected constraint may justify another person after the company tests safer alternatives.

What is the first capacity lever a solar business should use?

There is no universal first lever. Define one project class and workflow boundary, separate ready from blocked work, identify where usable work accumulates, and test the smallest reversible change that addresses that mechanism. Fixing intake will not solve scarce electrical review, while adding review capacity will not repair projects released without required evidence.

Does limiting work in progress reduce customer service?

A sensible work-in-progress boundary can improve customer clarity because fewer projects sit ambiguously active. The team still records every request, but it starts only work that meets an entry rule and can receive focused attention. Exceptions need a named authority and displacement record. The appropriate boundary must come from local evidence, not a universal ratio.

When should a solar company outsource instead of hire?

Outsourcing can suit bounded, specifiable work, temporary peaks, a capability the company does not need continuously, or a reversible test of the suspected constraint. Keep input, output, review, confidentiality, security, revision, ownership, and escalation terms explicit. Hire when the need is sustained, strategically central, economically supported, and best controlled inside the team.

Can solar software replace operations or design employees?

Software can reduce duplicate entry, connect versions, preserve assumptions, generate supported outputs, and make reviews easier to inspect. It cannot make missing evidence true, accept technical or commercial risk, perform field work, or replace competent engineering, safety, permitting, utility, lender, insurer, contractual, and customer authority. Evaluate it against a defined workflow problem.

Capacity is a property of a system, but people live inside that system. A useful intervention removes avoidable reconstruction, unclear decisions, or badly released work. A harmful intervention asks the same people to absorb more ambiguity and calls the strain efficiency.

Use the eight levers to learn before committing. Improve readiness, focus active work, standardize recurring decisions, control revisions, move objective checks upstream, cross-train bounded work, use software at a verified transfer point, and test flexible capacity. Then hire when the evidence supports hiring. That is not a failure of process. It is what a good process decision looks like.