Measuring developer time spent on platform tasks
by Simon Campion
Reducing developer time spent on platform tasks is one of the core missions of a platform team. Developer time is expensive and should be spent on product work.
This post is about how to measure developer time spent on platform tasks. Without measurement, it is hard to know whether a platform investment actually reduced the work developers had to do.
What counts as a platform task?
A platform task is any work related to the systems that build, test, deploy, and monitor code.
Examples:
- Writing a GitHub Actions workflow to run the test suite on every PR.
- Debugging a failed pipeline that turns out to have been caused by platform-wide test runner instability.
- Writing Kubernetes manifests.
Ways of measuring
There are different ways to measure time spent on platform tasks.
Surveys. Send a short survey to a random subset of developers (say, 10%) each day asking how much time they spent on platform tasks that day. Ideally, you send an automated direct message with buttons for the possible answers so the developer only has to make one click. While developers may not reliably estimate time spent over the past quarter, they can usually estimate the past day reasonably well. Aggregating responses over a month gives an estimate of average time per developer per day.
A common but weaker variant is sending a quarterly questionnaire to all developers. Estimates of time spent over the previous quarter are often skewed. For instance, by whatever happened in the final weeks (“recency bias”).1 If you use surveys, the daily approach is more reliable.
Ticket tracking. Ask developers to tag platform tasks in their issue tracking system. If they also track time spent on each ticket, this can give you concrete data over time.
Shadowing. Sit with a developer and watch how they bring a new service into production, without helping them. This gives also gives you qualitative signal about where they slow down or get stuck.
Automatically analyzing developer-platform interactions. If developer-to-platform interactions flow through a shared layer, you can observe automatically where developers lose time and get hard data on which problems recur most. This is the approach Heplon takes: the platform team gets continuous observability into developer friction.
I’m already tracking X, why should I measure time spent on platform tasks, too?
You might already collect metrics such as change lead time. Why start tracking time spent on platform tasks, too?
We suspect that many metrics you might be tracking are not strongly correlated with time spent on platform tasks. So, measuring that time gives you new information about how well your platform works for your business. Below are some example metrics and why we think they usually do not correlate strongly with time spent on platform tasks.
Change lead time. Many code changes do not require platform tasks to be done. CI and deployment config were set up once, and shipping a new feature does not require setting them up again. Changes in lead time are often due to changes in manual testing, code review, or approval chains. These are distinct from platform tasks.
Time to first change. How long does it take a new developer to get a trivial change into production? In our own experience, access provisioning, local setup, and other tasks account for the majority of the time to first change. These are one-off tasks that increase and decrease independently of time spent on platform tasks.
Caveat: This skepticism about the correlation between time spent on platform tasks and the metrics above is based on our own anecdotal experience. If you have ever measured multiple of these metrics, we’d be keen to hear what correlation coefficients you saw.
What to do with this
Platform teams can have a large business impact by reducing the time developers spent on platform tasks. This is difficult to do without a way to measure that time.
To recognize trends, you don’t need a perfect measure, as long as your measure is strongly correlated with the actual time spent. Approaches that produce data from observed behavior, rather than self-reported estimates, can give you more reliable signal over time.
If you want to see where your developers are actually losing time, book a demo to see how Heplon in action.