A CTO utilisation dashboard answers three questions: are we using capacity well, where is time going, and do we need more people? Track five metrics — billable utilisation rate, billable ratio, project allocation, sprint velocity vs capacity, and meeting-to-coding ratio — at the team level, not the individual level.
The board wants to know why you need two more engineers when your current team’s utilisation is sitting at 68 per cent. Your gut says the team is at capacity. You know there is invisible overhead — code reviews, meetings, on-call, internal tooling — but you do not have the data to prove it. Without a structured CTO utilisation dashboard, you are walking into a headcount conversation armed with anecdotes instead of evidence. That is a losing position.
A well-designed CTO-level utilisation dashboard translates raw time data into the metrics that drive hiring, capacity planning, client profitability, and resource allocation decisions. It is not a surveillance tool. It is a strategic planning instrument that tells the story of where engineering capacity goes.
Key Metrics for a CTO Utilisation Dashboard
The most effective CTO utilisation dashboards track five numbers. Each one answers a distinct question. Start here before adding anything else.
Billable Utilisation Rate
This is the core metric: (billable hours / available hours) × 100. Available hours means total working hours minus PTO, company holidays, and sick leave — not theoretical capacity. Target 70–80 per cent for most engineering organisations. Below 60 per cent suggests overcapacity or poor project allocation. Above 85 per cent is unsustainable and leads to burnout.
The key word is “billable.” This metric requires that you define billable work consistently across the team. Code, code review, architecture, and client-facing meetings are typically billable. Hiring, internal tooling, and company all-hands typically are not. Document the definition and apply it uniformly.
Billable Ratio
Where billable utilisation rate measures hours against capacity, billable ratio measures what percentage of all tracked time was billable. A team billing at 70 per cent utilisation but logging 90 per cent of their time as billable is close to the target. A team at 70 per cent utilisation but only logging 60 per cent as billable has a categorisation problem — either their non-billable work is underreported or their definition of billable is too broad.
Healthy range: 65–75 per cent billable at the team level. This leaves room for learning, internal work, and the unplanned effort that does not fit neatly into any project.
Project Allocation
A breakdown of how engineering hours are distributed across clients, products, or initiatives. Visualise this as a stacked bar chart or treemap, updated weekly. The key insight project allocation provides is concentration risk: if a single client consumes more than 50 per cent of engineering capacity, you are exposed. A lost contract, a delayed project, or a client scaling back creates an immediate capacity problem with no buffer.
Project allocation also reveals over-assignment: when one team is at 90 per cent while another runs at 55 per cent, rebalance before the first team burns out. The data makes that conversation objective rather than political.
Sprint Velocity vs Capacity
The gap between planned story points or hours and actual delivery, compared against available capacity. This metric answers the estimation problem: teams consistently underestimate sprint work by 1.3–1.5x, but without data, you cannot prove it or fix it. Track estimated vs actual across 6–8 sprints and the pattern becomes undeniable.
This metric is also the clearest indicator of invisible work. If the team delivers 80 per cent of planned story points but reports 95 per cent capacity utilisation, the missing 15 per cent is going somewhere — unplanned incidents, code review, context-switching. That is valuable information for capacity planning.
Meeting-to-Coding Ratio
What percentage of engineering time is spent in meetings versus hands-on development? Alert threshold: if meetings exceed 30 per cent of team time, investigate. An engineering team where a third of capacity is consumed by meetings has a structural problem that no amount of headcount will fix.
This metric becomes especially useful when triangulated with the others. A team reporting low utilisation alongside a high meeting ratio has a different problem from a team reporting low utilisation with a high coding ratio. The root cause — and therefore the solution — is different.
Where Dashboard Data Comes From
A CTO utilisation dashboard is only as reliable as its data sources. Stitching together five or six feeds manually is not sustainable. The goal is a data pipeline that automates collection, normalises the format, and updates the dashboard without manual intervention.
Git activity provides the most accurate coding time available. Commit timestamps, pull request activity, and branch data give you coding time per developer, project, and repository — without requiring anyone to log anything manually. This is the most under-used data source in engineering organisations. Teams that track time from git commits have significantly better data quality than teams relying on manual timesheets.
Calendar integration captures meeting time from Google Calendar or Outlook. Combined with git data, you can calculate the meeting-to-coding ratio automatically. No developer needs to record that they were in a meeting — the calendar knows.
Project management tools (Jira, Linear, and similar) provide issue-level and sprint-level context. This is where estimated vs actual comparisons live, and where task categories — billable, non-billable, internal — are typically tagged.
Time tracking tools aggregate git, calendar, and manual entries into a unified dataset. A tool designed for engineering teams will normalise these sources into a consistent time-entry format that can feed a dashboard. Look for tools that pull directly from git and calendar so that manual logging is the exception, not the rule.
HR and PTO systems are required for available hours calculation. Without leave data, your utilisation rate is calculated against the wrong denominator.
The standard architecture is extract-transform-load: pull from each source, transform into standardised time entries with consistent billable/non-billable classification, and load into a dashboard tool. If you are building this yourself, a weekly batch pipeline is sufficient for strategic planning purposes.
Dashboard Design for Executive Consumption
The most common failure mode for CTO dashboards is not bad data — it is bad design. An executive dashboard that requires twenty minutes to interpret will not be used. Design principles matter as much as the metrics themselves.
Top-line numbers first. Show billable utilisation rate, billable ratio, and headcount on the first screen. If a board member or CEO needs to see the state of engineering capacity in thirty seconds, these three numbers should be visible without scrolling or clicking.
Drill-down, not detail-up. Design the default view at the firm or team level. Allow drill-down to project and individual team level, but never make individual developer metrics the default view. The engineering manager’s perspective on non-surveillance tracking applies here too — when individuals know their data is on the executive dashboard, behaviour changes in ways that distort the metrics.
Trends over snapshots. Show 4–12 week trends rather than just this week’s numbers. A utilisation rate of 74 per cent is meaningless without context. A utilisation rate trending from 68 per cent to 78 per cent over eight weeks tells a story. Trends reveal whether capacity is improving or declining and help you catch problems before they become crises.
Alerts and anomalies. Highlight metrics outside healthy ranges automatically. Utilisation below 60 per cent or above 85 per cent should be flagged in red. A meeting-to-coding ratio above 30 per cent should trigger a note. The executive should not have to know the thresholds — the dashboard should surface the exceptions.
Comparison context. Show current vs target, current vs previous quarter, and team vs team where relevant. Raw numbers without benchmarks require the reader to do mental arithmetic. That friction reduces how often the dashboard gets consulted.
Refresh cadence. Weekly for operational decisions such as sprint planning and resource allocation. Monthly for strategic planning. Quarterly for board reporting. A dashboard that updates only monthly is a historical report, not a planning tool.
Using Dashboard Data for Strategic Decisions
The purpose of a CTO utilisation dashboard is not reporting — it is decision-making. Each metric should connect directly to an action.
Headcount decisions. If billable utilisation consistently exceeds 80 per cent across the team for eight or more weeks, you have a data-backed case for hiring. “The data shows we have been above threshold for two months and the trend is upward” is a different conversation from “I think we are stretched thin.” The dashboard gives you the evidence; you still need to make the argument.
Client profitability. Combine utilisation data with revenue per client to identify which engagements are profitable and which are not. A client consuming 30 per cent of engineering capacity but generating 15 per cent of revenue is a margin problem. This analysis is most useful at renewal or scope negotiation time.
Resource rebalancing. When one team runs consistently above 85 per cent while another runs below 65 per cent, rebalancing is a planning decision, not a people management conversation. The data makes it structural.
Meeting overhead reduction. If the meeting-to-coding ratio trends upward across multiple teams, an async communication policy or a meeting audit is warranted. Reducing meeting load by 10 per cent frees approximately four hours per developer per week — that is the equivalent of adding half an FTE to a ten-person team.
SOW negotiation. Project-level utilisation data informs pricing and scope for new and renewed engagements. If you know a project type consistently runs 10 per cent over estimate, you can price it accordingly. If a particular client generates a disproportionate amount of non-billable overhead, that context belongs in the renewal conversation.
Teams at consultancies and software agencies find that time tracking software designed for client-facing work integrates this data more cleanly than generic project management tools, because it is built around the billable/non-billable distinction from the ground up.
Common Pitfalls in CTO Utilisation Dashboards
Measuring individuals, not teams. Individual utilisation rates create perverse incentives and damage trust. Developers who feel monitored individually log hours defensively, pad complex tasks, and rush through straightforward ones. The data becomes unreliable precisely because of the measurement. Track at the team level. If you need individual data for a specific operational reason, keep it out of the executive dashboard.
Targeting 100 per cent utilisation. Maximum utilisation is not optimal utilisation. Engineering teams need slack time for learning, innovation, incident response, and unplanned work. A team at 100 per cent capacity cannot absorb a production incident without something else slipping. Target 70–80 per cent and treat the remaining capacity as a buffer, not a problem to fix.
Ignoring non-billable categories. Not all non-billable time is waste. Internal tooling, technical training, and hiring are investments. A useful utilisation dashboard distinguishes between strategic non-billable work (tooling, learning, hiring) and administrative overhead (unnecessary meetings, context-switching). Aggregating everything as “non-billable” hides this distinction.
Using stale data. A dashboard that updates monthly is a historical report. By the time you see that utilisation was high in February, the team has already been stressed for six weeks. For operational decisions, weekly data is the minimum. For sprint-level visibility, daily is better.
Over-engineering the dashboard. Start with five key metrics. Resist the temptation to add charts for every data source you have wired up. Complexity reduces adoption. A clean, minimal dashboard consulted every week delivers more value than a comprehensive one that requires a training session to interpret.
Not sharing with the team. Utilisation data hoarded by leadership creates suspicion. When developers know that a dashboard exists and that leadership is making decisions from it, but they cannot see it themselves, they assume the worst. Share team-level dashboards openly. Let engineers see the same capacity data you see. Transparency turns the dashboard from a management tool into a shared planning resource — and typically improves data quality as a side effect.
Key Takeaways
- A CTO utilisation dashboard should answer: are we using capacity well, where is time going, and do we need more people?
- Five key metrics: billable utilisation rate (target 70–80%), billable ratio, project allocation, sprint velocity vs capacity, and meeting-to-coding ratio
- Pull data from git, calendars, project management tools, and HR systems — not manual timesheets
- Design for executive consumption: top-line numbers first, trends over snapshots, drill-down not detail-up
- Above 85% utilisation is unsustainable; below 60% needs investigation
- Share the dashboard with your team — transparency builds trust and improves data quality
Ready to Build Your CTO Utilisation Dashboard?
Keito builds your engineering utilisation dashboard automatically from git, calendar, and project management data. Executive metrics without manual timesheets — billable utilisation rate, project allocation, and sprint capacity calculated in real time.
Frequently Asked Questions
What should a CTO look for in a team utilisation dashboard?
Five key metrics: billable utilisation rate (target 70–80%), billable ratio, project allocation, sprint velocity versus capacity, and meeting-to-coding ratio. Design the dashboard around trends over time, not just current snapshots, and ensure top-line numbers are visible without drilling down.
How do you calculate engineering team utilisation?
Billable utilisation rate = (billable hours / available hours) × 100. Available hours equals total working hours minus PTO, public holidays, and sick leave — not a fixed number like 40 hours per week. Track at the team level, not the individual level, to get reliable and actionable data.
What is a healthy utilisation rate for engineering teams?
70–80% billable utilisation is healthy for most engineering teams in agencies and consultancies. Below 60% suggests overcapacity or poor project allocation. Above 85% is unsustainable — teams operating above this threshold consistently report burnout and reduced quality within 8–12 weeks.
Should I share utilisation dashboards with my engineering team?
Yes. Sharing team-level dashboards openly builds trust and typically improves data quality. When developers see the same capacity metrics that leadership sees, they engage with the data as a planning tool rather than viewing it with suspicion. Never share individual-level utilisation data in a team context.
How often should a CTO utilisation dashboard update?
Weekly for operational decisions such as sprint planning and resource rebalancing. Monthly for strategic planning and capacity forecasting. Quarterly for board and executive reporting. A dashboard that updates only monthly is a historical report — insufficient for the weekly decisions most CTOs need to make.