Utilization Rate in Software Houses: How to Measure Capacity, Idleness, and Margin
Utilization is the most sensitive economic indicator of a technology services company: err on the low side and the margin disappears, err on the high side and quality drops along with people. This guide shows how to separate billable hours from internal investment, calculate capacity and idleness, define goals by role, and build a weekly allocation dashboard.
In a software house, inventory is invisible. It doesn't sit on a shelf: it passes by. Every hour of a person that is not sold, is not invested in something that generates future revenue, and is not used to improve the operation simply evaporates at the end of the day. That is why the utilization rate is the most sensitive economic indicator for this type of business.
At the same time, it is the easiest indicator to misuse. Companies that turn utilization into an individual goal end up with creative time tracking, rushed code review, zero investment in learning, and an exhausted team that delivers more hours and less software. The correct ambition is not to maximize utilization: it is to find the range in which it sustains margin without corroding quality and future capacity.
In this guide, we use the same logic we apply in Shinier's operation and in the software houses we follow: first we define the indicator, then we separate the hour categories, calculate real capacity and idleness, define goals by role, link utilization to margin per project, and close with a weekly capacity and allocation dashboard model that fits into a thirty-minute meeting.
💡 The biggest management mistake: treating utilization as an individual performance grade. Utilization is the responsibility of those who sell, prioritize, and allocate — not of those who execute. When it becomes a personal demand, the indicator stops describing reality and starts describing people's fears.
What is the utilization rate in software houses and consultancies?
Utilization rate is the ratio between the hours effectively applied in work that generates revenue and the available capacity of a person, team, or company in a period. The base formula is simple: utilization = billable hours ÷ available capacity × 100. The difficulty is never in the math: it is in defining honestly what goes into the numerator and what goes into the denominator — and keeping that definition stable over the quarters.
Billable Utilization
Hours linked directly to active contracts (fixed scope, squads, or monthly support). Real measure of cash conversion.
Productive Utilization
Sums billable hours with projects of internal economic value: own products, automations, and technical pre-sales.
Capacity Utilization
Compares planned allocation with total theoretical capacity (including vacations and holidays) to anticipate bottlenecks.
Why three readings and not one
Service companies arrive at very different numbers starting from the same time entries, depending on which variation they use — this is the central point of the benchmark materials from Productive and BigTime. If the board looks at billable utilization, the technical leadership looks at productive utilization, and finance looks at capacity, the discussion turns into a spreadsheet fight. Choose an official definition for a goal, publish the other two as support, and document the rule on a single page.
Does your software house know the real margin of each project?
In the Shinier Accelerator, software houses structure capacity, pricing, and allocation with integrated pricing, cash flow, and roadmap tools — with guidance from those who have already operated this model for years.
Talk about my software houseHow to separate billable, non-billable, and internal investment hours?
Without a time taxonomy, utilization is fiction. The practical recommendation is to work with four buckets — and only four, because taxonomies with fifteen categories make people choose the first option on the list instead of the correct one.
1. Billable hours
Work linked to an active contract: development, analysis, testing, deployment, client meeting, correction within contracted warranty. Golden rule: if there is a contract that supports that hour, it is billable even if the commercial model is fixed scope and not sold hour.
In fixed-scope contracts, track the actual hour even when it exceeds the budgeted one. It is this difference that reveals projects that silently consume margins.
2. Internal investment
Non-billable hours with expected return: own product, internal library, deployment automation, formal training, mentoring of junior people, pre-sales, and commercial proof of concept.
This bucket needs to have an owner, a ceiling, and a quarterly review. Investment without a ceiling becomes an excuse; investment without an owner becomes an expensive hobby.
3. Operational overhead
Internal management meetings, company rituals, administrative, recruitment, onboarding. It is a legitimate cost, but it grows quietly. When overhead exceeds 15% of total capacity, there is almost always an excess of recurring meetings that no one had the courage to cancel.
4. Rework and waste
Correction outside of warranty, regression bug, rework due to poorly gathered requirements, waiting for client dependency. Separating this bucket is painful and transformative: it shows that part of what seemed like healthy utilization is, in fact, the cost of poor quality being paid twice.
🎯 Time tracking rule: daily launch, in blocks of thirty minutes at most, with the mandatory project and optional free comment. Weekly tracking done on Friday is memory, not data — and memory always rounds in favor of the person filling it out.
What utilization rate is healthy for each role?
A single goal for the entire company is the most common and most expensive shortcut. Each function has a different work composition, and a person who reviews, unblocks, and teaches generates value precisely in the hours that do not appear as billable. The ranges below are consistent starting points with agency and consultancy benchmarks — and should be calibrated with your operation's history.
| Role | Healthy range | Why |
|---|---|---|
| Allocated mid-level/senior dev | 70% to 80% | Needs slack for code review, peer support, and incidents. |
| Junior dev | 55% to 70% | A relevant part of the time is supervised learning — and that is an investment, not a loss. |
| Tech lead / architect | 50% to 65% | Value lies in technical decisions, reviews, and unblocking multiple fronts. |
| Designer / UX | 65% to 75% | Research and design systems consume unsold time with a direct return on delivery. |
| Project management | 40% to 60% | Coordination, risk, and relationship are not always billable, but they secure margin. |
| Sales and leadership | up to 30% | Occupying these people in delivery is the fastest way to dry up the next quarter's funnel. |
In the company's weighted average, a healthy services operation usually falls between 65% and 75% billable utilization. Sustained below 60%, the problem is commercial or allocation. Above 85%, the problem is imminent: lack of slack to absorb variation, and the bill arrives in the form of delays, bugs, and resignation requests.
How to calculate capacity, idleness, and margin per project?
Theoretical capacity is easy and deceiving. Real capacity is what is left after discounting everything that is already committed before any project exists.
Real capacity
Start from the working hours of the month (something between 168 and 176 in most months), subtract proportional vacations, holidays, leaves, and the fixed overhead of rituals. In a typical operation, 176 hours become about 140 hours of real capacity per person.
Planning sales on top of 176 hours is the origin error that generates an oversold team and an impossible schedule right at the contract signing.
Idleness
Idleness is real capacity minus billable hours and planned internal investment. It has a direct cost: multiply the idle hours by the fully loaded hourly cost (salary, charges, benefits, tools, and structure allocation) and you have, in reais, the size of the hole for the month.
Separate planned idleness (purposeful slack between projects) from involuntary idleness (lack of sales or waiting for client). Only the second is a problem.
Gross margin per project, step by step
- Recognized revenue in the period — what was actually delivered and can be billed, not the total contract value.
- Direct cost — tracked hours in the project multiplied by the loaded hourly cost of each person, plus dedicated licenses and infrastructure.
- Gross margin = (revenue − direct cost) ÷ revenue × 100. In technology services, healthy projects usually stay above 45% to 50% gross margin, before commercial and administrative expenses.
- Effective hourly rate — recognized revenue divided by the hours actually spent. This number, compared to the contracted rate, reveals in seconds how much invisible discount the project is giving.
High utilization with low margin
It is the most dangerous and most frequent scenario: the team is 90% occupied and the company does not generate cash. The cause is almost always one of these three — price below actual cost, open scope without an addendum, or rework consuming hours that have already been sold once. None of them are solved by asking people for more hours; all are solved in contract, prioritization, and quality.
Why does 100% utilization reduce quality and innovation?
The answer lies in queuing theory, and Goldratt had already written it in The Goal: in a system with variation, the queue grows non-linearly as utilization approaches 100%. A 70% occupied resource absorbs an unforeseen event without delaying anything; the same resource 95% occupied turns any unforeseen event into a chain delay — and software is, by definition, a job with high variation.
In practice, slack is what pays for a careful code review, refactoring before technical debt becomes an incident, documentation that avoids dependency on a single person, and a quick response when production goes down. All these activities appear as "non-billable hours" in the spreadsheet and as lower lead time and fewer failures in the delivery metrics tracked by DORA.
There is also the human effect. Utilization near the ceiling for consecutive quarters is the direct path to exhaustion, quality drops, and the departure of the most experienced people — the very ones who sustained the productivity the goal was trying to protect. Rehiring and training costs much more than the 20% slack that would have prevented the departure.
That is why the correct goal is a range, not a ceiling: between 70% and 80% for those who deliver, with a quarterly review. Below that, it's a conversation with sales; above that for more than a month, it's a decision to hire, raise prices, or refuse a project.
How to combine utilization rate, lead time, and gross margin?
An indicator alone becomes a perverse goal. The logic of the Balanced Scorecard, by Kaplan and Norton, solves this with counterweights: each financial metric is read alongside a process metric and a learning one. In a software house, the minimum trio is utilization, lead time, and gross margin.
Utilization
Answers if the capacity is being used. Alone, it encourages occupying people in anything that can be charged.
Lead time and failures
Answers if work is flowing with quality. It comes from the four DORA metrics and is the brake that prevents high occupation from hiding stalled delivery.
Gross margin
Answers if occupation turned into money. It is the final judge: utilization that does not improve margin is movement, not result.
Allocation discipline comes from FinOps
The FinOps Framework organizes cloud cost management into three phases — inform, optimize, and operate — and the same sequence works for hours. Inform is giving visibility of utilization and cost per project to decision-makers, every week. Optimize is rebalancing allocation, renegotiating scope, and adjusting price based on that data. Operate is turning this into a permanent ritual, with a defined owner and cadence. Without the third phase, the dashboard becomes a decoration in two months.
Weekly dashboard model for capacity and allocation
The panel below is what we recommend for a thirty-minute weekly meeting with technical, commercial, and financial leadership. Five blocks, one decision per block.
1. Weekly utilization by team
Billable percentage by team and by person, with the target range drawn on the chart. The decision for the block is simple: who is out of the range up or down and what changes in next week's allocation.
2. Committed capacity in the next 6 weeks
Hours already allocated versus real capacity per week. This is the block that anticipates revenue gaps and overselling with enough time to act — sell, reallocate, or hire.
3. Margin and effective rate per project
Accumulated gross margin and effective hourly rate versus contracted rate. Any project below the defined floor goes into scope review, addendum, or recovery plan in the same meeting.
4. Rework and hours over budget
Hours classified as rework and projects that exceeded the hour budget. It is the early warning of margin erosion, almost always visible weeks before it appears in the result.
5. Delivery and quality
Average lead time and change failure rate, in the DORA model. It serves as a counterweight: if utilization increased and quality dropped, the operation did not become more efficient — just tighter.
6. Internal investment used
How much of the investment hour ceiling was consumed and on what. It ensures that the planned slack is going to product, automation, and training, and not evaporating in unrecorded meetings.
Do not manage capacity looking in the rearview mirror
A dashboard that only shows the past is a blame generation tool. A dashboard that shows the next six weeks of committed capacity is a decision-making tool. Switch the focus from "why did we miss the goal last month" to "what needs to happen next week for the margin to close."
Referências
- GOLDRATT, Eliyahu M. The Goal. It is a reference because it formalizes the Theory of Constraints and demonstrates that optimizing the occupation of each resource in isolation increases inventory and delay instead of result — exactly the mistake of those who pursue 100% utilization in technology teams. View on Amazon
- KAPLAN, Robert S.; NORTON, David P. Balanced Scorecard. It is a reference because it structures performance reading in connected perspectives (financial, customer, internal processes, and learning), preventing utilization from becoming an isolated goal without a counterweight of quality, delivery, and people development. View on Amazon
- DORA. Accelerate State of DevOps Report. It is a reference because it measures, based on thousands of responses per year, the four software delivery metrics (lead time, deployment frequency, change failure rate, and time to restore service) — the quality counterweight that prevents high utilization from hiding delivery degradation. Access DORA
- FINOPS FOUNDATION. FinOps Framework. It is a reference because it defines the vocabulary of allocation, visibility, and cost optimization in technology (inform, optimize, operate) — the same discipline we apply to team hours, not just to the cloud bill. Access the framework
- PRODUCTIVE. Agency Utilization Benchmarks. It is a reference because it publishes aggregate data from agencies and consultancies on billable utilization, average hourly rate, and margin per project, allowing you to compare your operation with a market base instead of with internal intuition. View benchmarks
- BIGTIME. What Is a Good Employee Utilization Rate. It is a reference because it details the calculation variations (billable, productive, and capacity utilization) and shows why service companies arrive at different numbers starting from the same time entries. Read the article