Every engineering leader I know can recite the headline statistic about context switching: it takes something like twenty-three minutes to fully recover focus after an interruption. I have quoted that number myself in planning meetings. But the longer I have run engineering organizations in regulated fintech, the more I have come to believe that the twenty-three-minute figure dramatically understates the problem. The real cost is not the recovery time. It is the compounding tax that context switching levies on judgment, on code quality, and ultimately on the safety of the systems we ship.
In a payments business, a half-finished thought is not a benign inconvenience. It is a reconciliation routine someone forgot to finish, an idempotency key they meant to add, a ledger entry that almost balances. This post is my attempt to be specific about where that cost lands, why leaders underestimate it, and what I have done that genuinely helped.
What We Actually Mean by Context
When we talk about context in software, we are usually being lazy with the word. We treat it as if it means the file you have open or the ticket you are looking at. But the context an engineer holds while doing serious work is enormous and almost entirely invisible. It is the mental model of how a settlement batch flows from authorization to capture to payout, which edge cases have already been handled three functions up the stack, and the half-formed hypothesis about why a particular account is showing a one-cent discrepancy.
That working set lives in a part of memory that is fast but volatile. The moment attention moves, the cheap copy degrades, and reconstructing it is neither free nor perfectly reliable. The engineer who returns to the discrepancy investigation after a forty-minute incident call does not resume where they left off. They resume from a worse approximation, having silently dropped one of the three hypotheses they were juggling. The dropped one was, often enough, the correct one.
This is why I push back on the framing that context switching merely slows people down. Slowing down is recoverable. The corrosive part is that switching changes the quality of the work that eventually gets produced.
The Hidden Second-Order Costs
The first-order cost of an interruption is the lost time. The second-order costs are where the real damage accumulates, and they are the ones leaders systematically fail to measure because they do not show up on any dashboard we track.
Consider what happens when a senior engineer is pulled off a focused task four times in a single afternoon. Each return is a little degraded. By the fourth reload they are working from a thin reconstruction, and the natural response to that is to narrow scope defensively. They stop reasoning about the whole system and start reasoning about the immediate diff. In most software that is merely suboptimal. In payments infrastructure, narrowed scope is precisely how you ship a change that is locally correct and globally wrong.
The most expensive bugs I have shipped were not written by people who lacked skill. They were written by skilled people who were holding too many threads at once and quietly let go of the one that mattered.
There is a further cost that compounds over weeks rather than hours: the erosion of an engineer's willingness to take on deep work at all. If experience teaches them that any task requiring three uninterrupted hours will be shredded into twenty-minute fragments, they rationally stop attempting such tasks. The hard, architecture-shaping work simply does not get proposed, and leaders mistake the resulting busyness for productivity.
Why Fintech Amplifies the Tax
Not all software punishes context loss equally. A content site that renders a slightly stale cache will be fine. The systems my teams build move money, settle obligations, and produce records that auditors and regulators will examine years later. The blast radius of a half-loaded mental model is categorically different.
Financial systems are unforgiving in a specific way: they demand consistency invariants that must hold across every code path, not most of them. An engineer reasoning about a refund flow has to hold the happy path, the partial-failure path, the double-submission path, and the reconciliation implications of each, simultaneously. These interlock. The moment that model is paged out by an interruption, the probability that one of the harder paths gets dropped rises sharply, and the harder paths are exactly the ones that cause real-money incidents.
Regulation adds another layer. Much of what we build carries obligations around auditability, segregation of duties, and traceability that are not optional. A distracted engineer is far more likely to skip the unglamorous parts: the audit log entry, the comment explaining why a value is what it is, the test that exercises the boundary condition. Those omissions rarely fail in code review, because review itself is often done in fragmented attention. They fail months later, in production, in front of a customer or a regulator.
The Manager's Paradox
Here is the uncomfortable part, and I include myself in the indictment. The people responsible for protecting engineers from context switching are usually the people generating it. A manager's job is, in a real sense, a context-switching job. We move between hiring, incident response, roadmap negotiation, and one-on-ones within a single hour, and we get good at it. The danger is that we then assume our engineers can and should operate the same way.
They should not, and the asymmetry is the entire point. A manager who loses the thread of a hiring conversation can pick it back up tomorrow. An engineer who loses the thread of a concurrency bug investigation may ship the wrong fix today. My context is cheap to reconstruct because most of it is recorded somewhere or re-derivable from a calendar. An engineer's deep working set is not written down anywhere; it exists only in their head, and once it is gone it is genuinely gone.
I have learned to treat a request for an engineer's attention as a withdrawal from an account I cannot see the balance of. Before I interrupt, the honest question is not whether my question is important; almost everything feels important in the moment. It is whether it is more important than whatever they are holding in their head, and the truth is that I usually cannot know, so the default should be restraint.
Instrumenting the Invisible
If you cannot measure something, you will under-invest in fixing it, and context switching is notoriously hard to measure. We do not have a clean metric for it the way we have for latency or error rates. But over the years I have found a handful of proxies that, while imperfect, are far better than flying blind.
- The ratio of an engineer's calendar that is fragmented into sub-ninety-minute gaps between meetings. Anything below two hours is effectively unusable for the hardest work, and a calendar full of one-hour windows is a calendar that produces only shallow output.
- The volume and synchronicity of interruptions in team channels, especially direct mentions that carry an implicit expectation of an immediate reply.
- The lead time on tasks that are genuinely hard versus tasks that are merely tedious. When hard tasks balloon disproportionately, fragmentation is usually the cause rather than complexity.
- Where production incidents cluster. A surprising share trace back to changes made during weeks when the author's focus was visibly shredded.
None of these is a clean number you can defend in a board meeting. But used together, and discussed honestly with the team, they surface a pattern. The first time I overlaid our incident timeline against engineers' calendar fragmentation, the correlation was uncomfortable enough to change how I ran the organization. I do not present that as a controlled study; it is an observed pattern in one company. But it was strong enough to act on, and acting on it paid off.
Protecting Deep Work Without Going Dark
The naive solution is to declare heroic focus time and tell everyone to turn off notifications. This fails in an operational business, and it fails for a good reason. We run systems that move money in real time. Someone has to be reachable when a payment provider degrades or a settlement file does not arrive. You cannot simply make an engineering team unreachable and call it focus.
The approach that has worked for me is to separate the obligation to respond from the obligation to respond immediately, and to make that separation structural rather than a matter of willpower. We run a clear on-call rotation so that interrupt-driven work has a named owner at all times, which means everyone else is free to ignore the firehose. We default to asynchronous communication for anything that is not an active incident, and we are disciplined about what counts as one. A question that can wait four hours is not an incident, no matter how it feels to the asker.
Just as important, I have worked to make it culturally acceptable, even expected, to be unreachable for a block of hours. This only sticks when leaders model it. The first time engineers saw me decline a meeting because it collided with a maker's block I had committed to, it did more to legitimize the practice than any policy document could. Culture here is set by what leaders do under mild inconvenience, not by what they say in all-hands meetings.
The Economics of Interruption
I find it useful to put rough numbers on this, not because they are precise but because the exercise reframes the conversation for people who only respond to cost. Suppose a typical interruption destroys not the famous twenty-three minutes but, accounting for degraded re-entry and the occasional dropped thread, closer to forty-five minutes of effective capacity. Four such interruptions in a day consume three hours. Across a team of ten, across a quarter, the arithmetic becomes genuinely alarming.
But the direct labor cost is the smallest part of the equation. The larger cost is the option value of the deep work that never happens because the conditions for it never exist: the refactor that would have removed a class of bugs, the abstraction that would have let three features ship in days instead of weeks, the investigation that would have caught reconciliation drift before it became a customer-facing incident. These do not show up as costs because they are absences, and absences are invisible on every report we produce.
When I frame protected focus time to non-technical stakeholders, I do not argue that it makes engineers happier, though it does. I argue that fragmented attention is a direct driver of the operational risk they already care about. In a regulated business, that argument lands in a way that wellbeing language never quite does. Fewer dropped threads means fewer incidents, fewer audit findings, and fewer late nights reconstructing what went wrong.
What I Tell New Engineering Managers
When someone moves into their first management role on one of my teams, the conversation about context switching is one of the earliest I have with them, because the instinct to interrupt is strongest in new managers who feel they must constantly demonstrate engagement. The most useful reframe I can offer is that their job is not primarily to add information to the system. It is to protect the conditions under which their best people can do their best thinking.
I ask them to batch their questions rather than fire each one off the moment it occurs. I ask them to assume that any engineer who appears unresponsive is probably deep in something valuable, and to treat that as a success of the environment rather than a failure. And I ask them to be honest about the difference between something urgent for them and something genuinely urgent for the business, because conflating the two is the most common way managers destroy their teams' focus while believing they are being diligent.
The hardest lesson, and the one that takes longest to internalize, is that restraint feels like inaction. A manager protecting focus often looks, from the outside, like a manager doing nothing: no Slack message to point to, no meeting convened, no visible artifact of effort. But the absence of unnecessary interruption is real work, and it is frequently the most valuable work a manager does in a given week.
Conclusion
Context switching is not a productivity footnote to be solved with a focus app or a calendar trick. In the systems my teams build, it is a quiet contributor to operational risk, because a fragmented mind is more likely to drop exactly the thread that keeps money safe. The twenty-three-minute statistic was never the real story. The real story is the degraded judgment on re-entry, the deep work that never gets attempted, and the invariants that quietly stop holding when no one was able to keep the whole picture in their head. As leaders, our most underrated responsibility is to treat our engineers' attention as the scarce, fragile, high-value resource it actually is, and to defend it with the same seriousness we bring to defending the ledger itself.