Every manager eventually asks how to measure a team's productivity. The answers usually count individual activity: hours logged, tasks closed, utilisation. Most measure something real. Almost none measure work.
You cannot measure modern work by watching people work. You measure the system that work flows through: its speed, handovers, visibility, automation, knowledge, and ownership.
“How do I measure my team's productivity?” is the wrong first question
Hours in a tool measure presence. Tasks closed measure how finely someone splits their tasks. Utilisation measures how full a calendar looks. Each number can be accurate and still answer a question nobody asked.
Modern work crosses tools and teams. A request can touch a CRM, a project tracker, a design tool, and a support desk before anything ships. The crossings are where work slows down, yet individual metrics make them disappear.
Work rarely fails inside a team. It leaks between teams: into unowned queues, stalled handovers, and repeated explanations because the context lives in someone's inbox.
Measure the system, not the people
WorkOps treats measurement as a system problem. Fragmented tools, manual repetitive tasks, missing real-time visibility, and inefficient handovers are not people problems. They need system metrics.
The governing principle is Optimise Continuously: performance is measured constantly, and insights feed short review cycles and larger changes when a step change is needed. Measurement is not a quarterly ceremony. It runs while work runs.
The 6 WorkOps metrics you need to know
Each metric has a fixed definition, a practical way to compute it from the systems you already run, and a common way it can be gamed.
1. Cycle time
Track the timestamp from intake to the moment a result ships. Follow the distribution, not only an average. A team with a median of three days and a forty-day tail has a different problem from a steady ten-day team.
Cycle time catches what activity metrics miss: a team can be fully utilised while a customer's wait grows. Guard against gaming with a shared definition of start and delivered.
2. Cross-team efficiency
Measure the gap between one team marking work ready and the next team starting it. Most trackers expose this as time in status.
This makes the queue nobody owns visible. Do not solve it by accepting work instantly and letting it sit “in progress”.
3. Work visibility index
Sample delivered outcomes and trace each back. Count how many existed as tracked items before delivery.
If a third of work is invisible in inboxes, chat, or private spreadsheets, every other metric only describes the visible two thirds.
4. Automation rate
Pick your ten most frequent processes and score every step as manual or automated. Pair this with cycle time, because automation that matters shows up there.
5. Knowledge readiness
This assesses whether organisational knowledge is structured, current, and findable for people and AI. Count useful answers, not documents.
6. Ownership coverage
Count automations and agents with a named human owner and traceable record, then divide by the total.
Apart from knowledge readiness, the framework deliberately publishes no universal benchmarks. Look for direction: cycle times trending down, visibility and ownership trending up.
The precedent: DORA turned four numbers into a shared language
DORA, the DevOps Research and Assessment programme, gave engineering organisations a common way to describe how well software ships: deployment frequency, lead time for changes, change failure rate, and time to restore service.
Its lesson is simple. The four keys measure the delivery system, not individual developers. They are few, fixed, and published openly. The six WorkOps metrics apply the same move to structured work in general, where less of the work is instrumented and visibility becomes essential.
How to baseline in one quarter
You do not need six dashboards by Friday. Start with assessment, mapping workflows, tools, and inefficiencies before changing anything.
- Weeks 1–2: pick cycle time and cross-team efficiency.
- Weeks 3–6: agree definitions, identify handover states, and let data collect.
- Weeks 7–10: assess knowledge readiness and ownership coverage.
- Weeks 11–13: review the baseline and choose one intervention, not five.
If your first baseline shows disconnected systems and manual reporting, that is not a verdict. It is the starting point the maturity model expects.
Key takeaways
- Individual productivity metrics measure presence and busyness. The useful metrics are system metrics.
- The six WorkOps metrics are cycle time, cross-team efficiency, work visibility index, automation rate, knowledge readiness, and ownership coverage.
- Only knowledge readiness has a published target. Judge the rest by direction, not generic benchmarks.
- Start with two metrics and a one-quarter baseline, not six dashboards.
Measure the flow
The question answers itself once you stop aiming it at people. Measure how long work takes, where it waits, how much you can see, how much runs on its own, and whether knowledge and ownership can carry the load.
Explore the WorkOps framework for the model behind these metrics, or read From DevOps to WorkOps for the lineage.