Google runs one of the largest infrastructure operations on the planet, and it caps the amount of repetitive operational work any of its site reliability engineers can do at 50% of their time. Not because the work is beneath them. Because that work has a specific property: left alone, it grows until it fills every hour available, and then it starts eating the hours that were supposed to go to actual improvement. Google gave this category of work a name. They call it toil.
Most managers outside of engineering have never heard the term, which is a shame, because toil is probably the single largest hidden drain on your team’s capacity right now, and nobody on the team is tracking it.
What actually counts as toil
Toil is not just “work I don’t like.” Google’s definition is precise, and the precision is what makes it useful. In the Site Reliability Engineering book, toil is work that carries several of these traits at once:
- Manual. A person has to sit there and do it.
- Repetitive. You have done it before and you will do it again next week.
- Automatable. A machine, a script, or a template could do it about as well as a human.
- Tactical and reactive. It is interrupt-driven, not strategy-driven. Something pings and you respond.
- No enduring value. When you finish, the service is in the same state it was before. Nothing is permanently better.
- Scales linearly with the work. Twice the volume means twice the hours.
That last point is the one managers miss. Genuine engineering or genuine management work scales sub-linearly: you solve a problem once and it stays solved, so growth does not cost you proportionally more time. Toil scales one-to-one. If onboarding one new client requires four hours of someone manually copying data between two systems, onboarding ten clients requires forty hours. There is no leverage in it. You are just feeding the machine with human hours.
The reason Google draws the 50% line is blunt: toil expands if left unchecked and can quickly fill 100% of everyone’s time. Interestingly, their quarterly surveys show the average engineer actually spends about 33% of their time on it, well under the cap. Most teams I have worked with, if they measured honestly, would find the number closer to 60%.
The number is bigger than you think
The data on repetitive work outside of engineering is sobering. Asana’s Anatomy of Work Index, a survey of more than 10,000 knowledge workers, found people spend roughly 60% of their time on “work about work”: communicating about tasks, searching for information, switching between apps, chasing status. The same research pins the loss to duplicative work alone at 209 hours per person per year. That is more than five full working weeks, gone, per employee, to doing things twice.
A separate analysis found employees spend around 62% of the workday on mundane, recurring tasks. Research from APQC concluded that roughly a quarter of knowledge workers’ time is lost outright to productivity drains. And Microsoft’s 2025 Work Trend Index reported workers now face about 275 interruptions a day during core hours, one every two minutes, with focus efficiency at a three-year low.
Put those together and the picture is not “your team is lazy” or “your team is over capacity.” The picture is that a large slice of your team’s week is being consumed by work that produces nothing durable, and most of it is invisible because nobody has ever named it or counted it.
Why toil hides so well
In more than 20 years running IT operations, the pattern I saw over and over was this: toil never shows up as a project, so it never shows up in any plan. It lives in the gaps.
Nobody puts “manually reconcile the two spreadsheets every Monday” on a roadmap. Nobody staffs “re-run the report because the first version had last quarter’s filter.” Nobody budgets for “answer the same access-request email for the fortieth time this month.” These tasks slide into the cracks of the calendar, and because each one only takes fifteen or twenty minutes, they feel too small to fight. The cost is not any single instance. The cost is the aggregate, and the aggregate is enormous.
There is a second reason it hides. Toil often looks like helpfulness. The person who has quietly become the human API between two systems, copying and pasting figures every morning so the sales dashboard is right, is seen as reliable and dedicated. They are. They are also spending a third of their week on something a thirty-line script could do, and when they leave, the whole thing collapses. I wrote a while back about how a single undocumented dependency can put your team one resignation away from chaos; toil is very often where those single points of failure hide.
A practical way to find it
You cannot cut what you cannot see, so the first move is measurement, and it does not require a fancy tool. During a fractional COO engagement a couple of years ago, I ran a version of this exercise with an operations team of nine that was constantly behind and could not say why.
For two weeks, everyone kept a rough tally in a shared sheet. Three columns: what the task was, roughly how long it took, and one flag: “could a script, template, or rule do this instead of me?” No judgment, no precision to the minute. Just visibility.
The result was the same one I have seen every time I have run this. About 40% of the logged hours got the automatable flag. A chunk of it clustered around a handful of specific tasks: a manual month-end data pull, a recurring set of status updates that could have been a single dashboard, and an approval step that existed only because nobody had ever removed it. We had been treating a capacity problem as a headcount problem. It was a toil problem.
If you want to try it, three practical notes:
- Count the recurring first. Anything that happens weekly or daily is where the volume is. A painful task you do once a quarter is annoying, but it is not the drain.
- Log the interruptions, not just the scheduled work. The “quick question” that hits someone eleven times a day is toil with a friendly face.
- Look for the human-in-the-middle. Any task that is mostly moving information from one place to another, unchanged, is a red flag. That is a machine’s job.
What to do once you can see it
Not all toil is worth killing, and this is where managers overreach. The honest math is straightforward: the cost to automate or eliminate a task, divided by how often it recurs, tells you whether it is worth the effort. A daily two-hour task is worth a week of engineering to fix. A quarterly ten-minute task is not; automating it would cost more than it saves for years. Google’s own guidance is not “eliminate all toil.” It is to keep it under a threshold so it does not crowd out the work that compounds.
So triage in this order.
Eliminate before you automate. The best toil reduction is deleting the task entirely. That approval step we found existed because a manager three reorganizations ago wanted visibility into a process that no longer ran. Nobody needed it. We deleted it and reclaimed the hours for free. Before you build anything, ask whether the task needs to exist at all. This is the same discipline behind auditing what work your team should refuse to take on in the first place.
Then standardize. A lot of toil is toil because it is done ad hoc every time. A checklist, a template, or a saved query turns a twenty-minute judgment call into a two-minute rote step. This is unglamorous and it works. It also has a documentation benefit, which matters when you consider how much operational knowledge walks out the door undocumented.
Then automate. Once a task is standardized, it is a candidate for a script, a rule, an integration, or these days a well-scoped AI workflow. But automate the standardized version, not the messy one. Automating a broken process just gives you a broken process that runs faster.
The discipline that makes all of this stick is protecting the time to do it. This is the real reason Google’s 50% rule exists. If every hour is spoken for by the operational work itself, there is never any hour left to reduce it, and the team runs on a treadmill forever. You have to carve out capacity deliberately, the same way you would protect a team from being booked to 100% utilization, because the reduction work always loses to the urgent work unless you defend it on the calendar.
Why this is a management job, not a tooling job
It is tempting to hand this to whoever is most technical and call it done. Resist that. Toil reduction is a prioritization decision, and prioritization is your job.
Your team cannot unilaterally decide to stop doing the manual reconciliation, because they do not know whether someone downstream depends on it. They cannot judge whether the two weeks of automation work is worth pulling someone off a client deliverable. They cannot delete the pointless approval step, because it is not theirs to delete. Every one of those calls sits at your level. When you leave toil unmanaged, you are not staying out of the weeds; you are quietly deciding that your team should keep spending a third of its week on work that builds nothing, and you are deciding it by default rather than on purpose.
Name it. Measure it for two weeks. Triage it: delete, standardize, automate. Then protect the time to keep doing it. That is the whole practice, and on most teams it will give you back more capacity than any hiring requisition you are likely to get approved this year.