A psychologist named Mihaly Csikszentmihalyi spent decades studying the state where people are so absorbed in a task that they lose track of time. He called it flow. Rock climbers have it. Surgeons have it. Chess players have it.
DevOps engineers have it for about forty minutes a quarter, usually right before the pager goes off.
This is not a productivity post. I am not going to tell you to wake up at 5 a.m. or buy a standing desk. I am going to argue something narrower and, I think, more useful: most of the tooling we build is accidentally engineered to keep us out of flow, and you can see exactly where, if you know what flow is made of.
The two failure states
Csikszentmihalyi’s whole model fits on one axis. Plot challenge against skill. When the challenge badly outstrips your skill, you get anxiety. When your skill badly outstrips the challenge, you get boredom. Flow lives in the thin diagonal channel between them, where the two roughly match.
DevOps is unusual because it manufactures both failure states on the same team, on the same day.
The boredom is toil. Manually SSHing into a box to bump a package. Copy-pasting the same config across six environments. Watching a deploy bar crawl for thirty minutes because someone decided the build should reinstall the world every time. This is skill wildly exceeding challenge. You are a trained engineer playing tic-tac-toe against a wall.
The anxiety is the 5 p.m. Friday deploy with no rollback. The Kubernetes cluster you inherited with no documentation and no training. The pager firing at 2 a.m. for a service you have never read the code of. This is challenge wildly exceeding skill. You are playing chess against a grandmaster who is also on fire.
The interesting part is that these are not opposites you balance by averaging. A day that is 90% boredom and 10% terror does not net out to a calm, engaged afternoon. It nets out to an engineer who is numb and then briefly, vividly awake, and then numb again. Both states burn people out. Boredom does it slowly.
What flow is actually made of
Csikszentmihalyi broke the experience into components, and the genuinely useful move is to read them not as a vibe but as a checklist for your pipeline. Three of them map onto things you already control.
Clear goals. Flow needs an unambiguous target. “Make it better” is not a goal; it is a meeting. “Cut p99 latency from 400ms to 250ms” is a goal. Notice that incident response, for all its terror, gets this one right by accident: “restore service” is the clearest goal anyone on the team will have all month. The clarity is half of why a good incident can feel weirdly good afterward, which is a fact most engineers are embarrassed to admit.
Immediate feedback. This is the one we break most often, and it is the most fixable. Flow requires that the system tell you, right now, whether the last thing you did worked. A test suite that takes twenty minutes does not give feedback; it gives you time to open another tab, lose the thread, and come back a stranger to your own change. The number that matters here is not “is the build green,” it is “how long between my action and my knowing.” Under five minutes, you stay in the loop. Over fifteen, you have left the building.
Sense of control. You cannot relax into a task you are afraid of permanently breaking. This is the whole psychological argument for the boring infrastructure practices — version-controlled config, the ability to revert in one command, environments you can throw away and rebuild. They are not just operationally safer. They lower the felt stakes of any single action, which is the only thing that lets you stop white-knuckling the keyboard long enough to think.
There are more components — the merging of action and awareness, the loss of self-consciousness, the way time bends. But those tend to emerge when the first three are in place. You do not engineer “time passing like minutes.” You engineer clear goals, fast feedback, and a working undo, and the rest shows up on its own.
The part nobody automates
Here is the load-bearing claim, and it is uncomfortable.
The cure for the boredom side — automating toil — is real and well understood. Google’s SRE book has the line everyone quotes: cap toil at 50% so engineers spend the other half on actual engineering. Fine. Automate the package bumps. Templatize the configs. Make the deploy a button.
But automating toil only moves you off the boredom floor. It does not, by itself, put you in flow. It just clears the room. And the thing teams consistently under-invest in is the anxiety side, because that work is invisible. Nobody gets a promotion for the canary deploy that prevented an outage that therefore never happened. Nobody demos the rollback that never had to fire. The guardrails that raise your sense of control — the staged rollouts, the feature flags, the practiced incident drills — are precisely the work that produces no artifact when it succeeds.
So the boredom gets fixed because the fix is visible, and the anxiety persists because the fix is not. And you end up with a team that has automated all its tic-tac-toe and is now exclusively playing the grandmaster who is on fire, full time, and calling that “high velocity.”
The honest caveat
I want to be careful here, because flow is the kind of concept that gets stripped for parts by the optimization industry, and I do not want to be that.
Flow is not the goal of your job. Shipping working software that people can rely on is the goal. Flow is a pleasant and productive byproduct that shows up more often when the work is well-designed. If you find yourself optimizing your pipeline in order to feel flow, you have quietly swapped the end for the means, and you will end up gold-plating your CI config while the actual product rots. The autotelic engineer — the one who automates a thing because the automation is elegant, not because it needed doing — is one bad week away from a Rube Goldberg deploy pipeline that only they understand.
And some toil is just toil. Not every boring task is a flow violation worth a sprint to eliminate. Sometimes you SSH into the box, bump the package, and move on, because building the automation would cost more than the boredom ever will. Knowing which is which is the actual skill, and there is, annoyingly, no framework for it.
So: read the nine components if you like. But the whole essay collapses into one practical question you can ask in any retro. For the work we did this cycle — was the challenge roughly matched to our skill, or were we mostly bored and occasionally terrified? If it is the second one, you do not have a motivation problem or a hustle problem. You have a pipeline tuned to produce the two states flow lives between, and never the channel itself.
That is an engineering problem. Which is the good news, because engineering problems are the ones we are allowed to fix.
The source material, if you want the real thing instead of my gloss: Flow: The Psychology of Optimal Experience (Csikszentmihalyi), and the toil chapter of Google’s Site Reliability Engineering, which is free to read online and worth it.