Between AI rollout pressure, persistent cost scrutiny, and teams still operating at post-layoff headcounts, engineering leaders are caught in a familiar bind with a new twist. Engineers are expected to do more — and now, with AI tools at their disposal, the assumption is that "more" is finally within reach.
The data tells a different story. UC Berkeley researchers spent eight months inside a 200-person tech company tracking what happened when workers used AI. Nobody was pressured to hit new targets. People just started doing more because the tools made more feel doable. To-do lists expanded to fill every hour that AI freed up — and then kept going. The productivity surge gave way to workload creep, cognitive fatigue, burnout, and weakened decision-making.
This is the new version of a problem engineering leaders have always faced. The old version was: too many meetings, too many pings, too many competing priorities. The new version is all of that, plus an AI-powered misconception that your team can absorb unlimited work if given the right tools.
Both versions have the same fundamental solution: protect developer flow.
Preserving developer flow when it matters most
Mihaly Csikszentmihalyi defines flow as "the state in which people are so involved in an activity that nothing else seems to matter." For developers, that means sustained, uninterrupted time for the high-judgment work AI can't do — without Slack pings, redundant meetings, and context switches pulling them back to the surface.
Flow isn't a nice-to-have. It's a leading indicator of engineering effectiveness. Uplevel data shows that engineers at enterprise organizations spend more than half their day bouncing between meetings and short fragments of work. Workers using AI tools found that work began bleeding into lunch breaks and late evenings, with to-do lists expanding to fill every freed-up hour.
The irony is that AI, the tool meant to create more space for deep work, is eliminating the natural stopping points that used to regulate it.
As Siddhant Khare explains, "Before AI, there was a ceiling on how much you could produce in a day — set by typing speed, thinking speed, the time it takes to look things up. That ceiling was also a governor. AI removed the governor. Now the only limit is cognitive endurance, and most people don't know their limits until they've blown past them."
Your job as an engineering leader is to put a governor back in place — intentionally, structurally, at the system level.
Developer flow requires system-level thinking
The biggest obstacle to developer flow isn't individual willpower. Engineers don't lose flow state because they lack discipline. They lose it because the system around them isn't built to protect it.
Atlassian found developers were saving ten hours a week with AI tools, yet remained overworked due to "organizational inefficiencies." That gap — between what the tools make possible and what the organization actually delivers — is exactly where engineering leadership needs to intervene.
Protecting flow means getting ruthless about prioritization, like fewer, clearer missions and meeting structures that don't scatter attention across the day. Francisco Trindade, VP Engineering at Braze, talks about treating priorities as “options” for business stakeholders — a way of making trade-offs legible rather than leaving them implicit. That kind of structural clarity is what makes deep work possible at scale.
Flow state doesn't emerge naturally in modern work environments. It has to be engineered. That means making focus time the default, and treating distractions and interruptions as exceptions that require justification — not the other way around.
AI makes the clarity problem worse
There's a particular failure mode emerging right now: AI tools make it easier to start new work, which creates more WIP. More WIP means more context switching. More context switching degrades the focus that makes AI-assisted work actually good.
Part of what makes this hard to see is that the cognitive cost is hidden. AI removes low-cognitive-load work — the kind of low-stakes tasks that functioned as recovery time between periods of demanding focus.
When that recovery disappears, engineers feel it before the metrics show it.
That doesn't mean we should slow down AI adoption. Instead, measure what's happening to your team's focus time as adoption increases, and treat degraded deep work as the leading indicator it is — rather than waiting for burnout, quality problems, or attrition to tell you something already went wrong.
This is a harder conversation when the headline narrative is "AI equals productivity." But the leaders who close that gap — by showing what's happening at the system level, not just reporting adoption rates — are the ones who will build durable teams through this transition.
What Separates Great Engineering Teams from the Rest?
When we look at how high-performing engineering organizations operate, nothing is surprising. What separates them is the consistent execution of fundamentals most organizations know but don't protect.
High-performing teams prioritize ruthlessly. If a project isn't a genuine priority, it isn't assigned. Average teams have everything landing on the desk with equal urgency, which means nothing has real priority.
High-performing teams put deep work first. Leaders at these organizations have normalized a culture where engineers have protected time to write code. That protection shows up in calendar policies, meeting norms, and how managers run their own days.
High-performing teams have rules around tools. New tools — including AI tools — are adopted intentionally, with a clearly defined purpose. The question isn't just "does this help someone?" but "does this help the system?"
High-performing teams communicate clearly. Documentation is standard. Project scopes are defined. Engineers know which work is theirs and what it connects to. Ad hoc communication is the exception, not the infrastructure.
None of this requires cutting-edge management theory. It requires discipline and consistency — which is harder to maintain under AI-era pressure than it sounds.
The clarity engineers need right now
The vast majority of engineering organizations are actively using AI right now. Adoption isn't a question. The harder question is whether your organization is capturing those gains or funneling them into additional workload, expanded scope, and higher expectations.
Engineers are struggling despite AI because the clarity and structural protection that good flow requires hasn't kept pace with the demands being placed on them. As a leader, your job is to close that gap — to prioritize the work that matters, make trade-offs explicit, and defend the time your engineers need to actually do their best work.
Every company looks productive in a bull market. The ones that come out ahead during sustained pressure are the ones that protected the conditions for real productivity — not just the appearance of it.
Uplevel measures deep work as part of the WAVE framework — giving engineering leaders visibility into whether their teams have the focus time that predicts quality and velocity outcomes, before those outcomes degrade. See how it works.
