Engineering teams don't spend all their time building product. Larridin Spark data shows operations and monitoring consuming a substantial share of engineering effort, while heavy AI users show nearly the same work mix as their organization overall.
The Short Answer
At one Larridin customer, deployments and ops accounted for 32.6% of captured engineering effort, compared with 26.3% for product development. Monitoring alone represented about 15.6% of total effort. In another Spark, heavy AI users showed nearly the same allocation as the organization overall. Measuring the work mix helps leaders see where engineering capacity is going before deciding what to change.
Key Wins
What’s a Spark Insight?
A Spark Insight is a data-backed finding Larridin surfaces automatically from how your teams actually use AI, flagging the patterns worth a leadership conversation.
Who This Matters To
CTO · VP Eng · Eng managers
| If you’re asking… | The answer | Go deeper |
|---|---|---|
| How much time do engineers spend on product development? | In one organization, product development accounted for 26.3% of captured engineering effort, versus 32.6% for deployments and ops. | The data |
| How much time do engineers spend on monitoring? | In one organization, monitoring accounted for 47.9% of deployments and ops work, or about 15.6% of all captured engineering effort. | The data |
| Does AI free engineers to build more product? | Not automatically. In one org, heavy AI users had almost the same mix of product and ops work as everyone else. | Why it happens |
| How much does engineering time allocation change week to week? | A lot. In one org, ops jumped from 35% to 56.4% of effort in a single week. | The data |
Roadmaps focus on planned product work. But engineering teams also spend time on deployments, monitoring, access management, and other operational tasks. WorkGraph makes those competing demands visible.
| What you’re struggling with | What you actually need | How Larridin helps | Proof from Spark data |
|---|---|---|---|
| “The roadmap keeps slipping, and I don’t know why.” | A view of where captured engineering effort goes | Breaks down engineering effort by work category | One org: ops 32.6% vs. product dev 26.3% |
| “We spend too much time watching systems.” | Visibility into monitoring effort | Breaks the ops bucket into its parts | One org: monitoring ~15.6% of all engineering effort |
| “Some weeks, ops takes over.” | Weekly trends, not quarterly averages | Tracks effort mix week by week | One org: ops jumped from 35% to 56.4% in one week |
| “AI was supposed to give us time back.” | A check on whether AI shifts the mix | Shows engineering effort by work category for comparison with AI usage data | Heavy AI users: 26.4% product, 32.6% ops; org-wide: 26.2% and 32.4% |
The question you’re asked: “Why aren’t we shipping more with the same team?”
What to do: Measure the product-versus-ops split before assuming more headcount will solve delivery delays.
For more on connecting engineering activity to outcomes, see AI Monitoring for Engineering Leaders.
The question you’re asked: “Where should we point AI next?”
What to do: Investigate monitoring, access management, and other recurring operational tasks for automation opportunities.
For more on identifying engineering bottlenecks, see WorkGraph's Effort Allocation view.
The question you’re asked: “Why was last sprint so slow?”
What to do: Check weekly ops share. A spike in operational effort may help explain why less planned product work got done.
For more on using weekly engineering data for planning, see Your Sprint Plan Is Built on Last Quarter's Average.
At one Larridin customer, more captured engineering effort went to deployments and operations than to product development.
Deployments, incident response, monitoring, and access requests are necessary, but they rarely show up on a roadmap. That makes them easy to underestimate. In one Larridin customer, deployments and ops took 32.6% of engineering effort, while product development took 26.3%.
Spark callout: Monitoring alone accounted for nearly half of that ops bucket, about 15.6% of all engineering effort.
Myth: Most engineering time goes to building product.
Reality: In one org, ops work took a bigger share of effort than product development.
Unplanned operational demands can quickly change how a team allocates its effort.
In one org, ops jumped from 35% to 56.4% of effort in a single week, and product development fell to 19.5%. Weekly views reveal changes in effort allocation that quarterly averages can hide.
Not necessarily. In one customer, heavy AI users had almost the same work mix as the organization overall.
Heavy AI users spent 26.4% of captured effort on product development and 32.6% on deployments and ops. Organization-wide, those shares were 26.2% and 32.4%. That comparison doesn't establish whether AI made the team faster, but it shows why high AI adoption alone isn't evidence that more effort is going toward product work.
There’s no universal benchmark. Track your team’s work mix over time and investigate whether operational demands are crowding out planned product development.
In one customer, monitoring accounted for 47.9% of deployments and ops work. Review alert volume, manual checks, and other monitoring tasks to understand what's driving the effort.
Possibly. In one customer, heavy AI users had nearly the same effort allocation as the organization overall. Measuring the trend over time is necessary to see whether that changes.
See your team’s product vs. ops mix week by week, and bring it to your next planning meeting.