by Gary Worthington, More Than Monkeys

Steve Trapps made a useful point in his Scrum.org piece, The Financial Cost of Task Switching. He took something many of us already know, usually through bitter experience rather than formal education, and translated it into money. His argument was simple and effective: if you split a developer across multiple projects, you do not get neat slices of productive capacity, you get a switching penalty, and that penalty is expensive. Using Gerald Weinberg’s rule of thumb, he showed how a £600 day rate can quietly turn into a very visible annual loss.

That framing matters because once you put a pound sign next to a bad organisational habit, people suddenly become much more interested in whether it is still such a marvellous idea.

But I think the real cost is even higher than the spreadsheet suggests.

Task switching does not just waste time. It makes people slower, scrappier, more irritable, less proud of their work, and far less productive than they should be. It creates a very specific kind of frustration: the feeling of being flat out all day while somehow finishing very little. Most experienced developers know that feeling. It is rubbish, and yet plenty of organisations treat it as normal.

The lie we tell ourselves about busyness

Somewhere along the way, a lot of companies started confusing visible activity with useful output.

Someone is in meetings all day. They are replying instantly on Slack. They are helping two teams, reviewing pull requests, jumping on calls, unblocking other people, attending planning sessions, and dealing with the odd production wobble. On paper, they look fantastically engaged. A proper team player. A multi-talented delivery octopus.

In reality, they may be producing almost nothing of lasting value. That is the lie.

Busyness looks impressive because it is easy to observe. Productivity is harder. Productivity is about finishing meaningful work. It is about making progress. It is about learning, shipping, improving, and completing things that matter. A person can look extremely busy while contributing very little to any of those outcomes.

So let’s say it plainly (and I make no apoligies for my language).

Busy is bullshit

Busy is bullshit when it becomes a substitute for progress.

Nobody wins because a team looked swamped for six months. Nobody ships a good product because engineering looked exhausted on Zoom. Nobody improves quality because the calendar was wall-to-wall and everyone answered messages within thirty seconds like some grim customer service experiment.

Productivity is the aim.

Finishing meaningful work is the aim.

Learning quickly is the aim.

Delivering value is the aim.

The problem with task switching is that it inflates the appearance of activity while quietly destroying the conditions needed for actual delivery. That is why it is so poisonous. It does not usually fail loudly. It fails while looking industrious.

Why software work suffers so badly from it

Software development is high-context work.

That sounds a bit grand, but it is true. When an engineer is properly in the middle of something, they are carrying a live mental model of the system. Not just the code in front of them, but the assumptions around it. The edge cases, the naming decisions, the weird bit of behaviour in production that nobody fully trusts, the test intent, the architectural trade-offs, the likely blast radius if they change the wrong thing. That sneaking suspicion that a seemingly innocent line in one module is about to wake a demon three services away.

That context is fragile.

When you interrupt someone in the middle of that, they do not simply stop typing and later resume from exactly where they were. They lose mental state, they lose momentum and they lose the thread. When they come back, they have to reconstruct it, and reconstruction is expensive.

This is the bit leaders often underestimate. They think a switch costs a few minutes because the visible interruption only took a few minutes. But the real cost is not the message, meeting, or question itself. The real cost is the rebuild afterwards.

That is why task switching can make a full day vanish without much obvious to show for it. The time did not disappear. It was consumed in fragments, reloads, false starts, and mental re-entry.

The emotional cost is where it really starts to bite

This is the part I think many delivery leaders fail to understand.

Developers do not usually get unhappy because the work is hard. Good developers often like and thrive on hard work. They like solving knotty problems. They like understanding things properly. They like turning messy systems into cleaner ones. They live for the moment where a difficult bit of logic finally clicks and the whole thing settles into place. Its more enjoyable than a stoppage time winner in the Champions League Final (ok, maybe not, but you get the point).

What they do not like is spending every day in a state of broken concentration.

Task switching creates that state.

You start on a problem. You begin to get somewhere. Somebody pings you about another issue. Then there is a meeting. Then a quick question. Then an incident. Then a review request. Then another call you “might be useful in”. Then back to the original work, except now you cannot quite remember why you ruled out the thing you ruled out earlier, and you burn twenty minutes rediscovering yesterday’s conclusion like a contestant in the world’s most irritating quiz show.

By the end of the day, you have been busy constantly and satisfied rarely.

That is an important distinction. People are happier when they can see progress. They are happier when effort turns into completion. They are happier when the work has shape, movement, and closure. Task switching steals that. It replaces momentum with fragmentation and satisfaction with residue.

And once that becomes normal, morale starts to sag.

Why context switching makes developers unhappy

It creates a particularly nasty psychological pattern.

The system is the problem, but the individual feels like the failure.

A developer who keeps getting dragged between unrelated tasks will often end the day feeling slow, scattered, and vaguely guilty. They know they worked hard, but they also know they did not finish the thing they meant to finish. Then it happens again the next day. And again the day after that.

Over time, people stop feeling effective.

That matters more than some leaders realise. A lot of professional satisfaction in software comes from a sense of competence. You take a problem, understand it, shape it, and solve it. You make something better than it was before. That feeling is not some fluffy perk. It is one of the key reasons good engineers stay engaged in the first place.

Context switching chips away at it.

Instead of mastery, you get interruption.

Instead of deep work, you get fractured thought.

Instead of clean progress, you get half-finished everything.

Instead of pride, you get the low-grade frustration of knowing you spent all day moving without really advancing.

That is not just annoying. It is demoralising. And when developers are demoralised, their productivity drops anyway. Not because they suddenly become lazy, but because constant fragmentation leaves them mentally tired, emotionally flat, and less willing to invest in depth. People stop leaning fully into problems when experience teaches them they probably will not be allowed to stay with them.

That is how a team becomes both unhappy and unproductive at the same time.

The team still looks busy, which is the trap

This is why the problem survives for so long in otherwise sensible organisations. Everyone appears to be working hard.

Messages are being answered. Meetings are being attended. Boards are being updated. Reviews are happening. Tickets are moving around. Stakeholders are getting responses. There is constant visible motion.

From the outside, it can look like a healthy, active, engaged delivery machine.

From the inside, it feels like trying to build a bridge while somebody keeps handing you unrelated planks and asking for status updates on the bridge you are no longer allowed to work on.

Throughput slows, but the busyness masks it.

Quality softens, but the noise hides it.

Cycle time stretches, but the diary is full, so nobody initially blames the operating model.

That is why this is such a pernicious problem. Teams can be deeply inefficient while looking highly utilised. In fact, high utilisation is often part of the problem. Once every minute is spoken for, nothing has enough room to finish properly.

Leaders usually create this by accident

Almost nobody sets out to build a fragmented team on purpose.

They do it one reasonable-sounding request at a time.

Can you just help another team for a few weeks?

Can you join this session because your input would be useful?

Can you support this incident while still keeping your current work moving?

Can you split your time between these two initiatives for now?

Can you stay close to that piece as well, just in case?

Every individual request sounds manageable. The damage comes from accumulation.

Because interruption is not additive. It compounds.

A single interruption might be recoverable. A day structured around constant interruption becomes something else. It destroys continuity and it destroys depth. It forces people into shallow work and permanent reload mode. Then the organisation wonders why delivery feels sticky despite everyone being visibly busy and apparently very committed.

This is the point where someone usually proposes more management and admin.

Which, of course, helps enormously if your core issue is that people have too much uninterrupted time to think.

What unproductive developers actually look like

It rarely shows up as obvious slacking.

It looks more like this.

People become snappier.

They lose patience more quickly.

They seem tired without being able to point to a single big event.

They start saying things like “I was rammed today” without being able to name much that actually got over the line.

They become hesitant about picking up deep work because they no longer trust they will be left alone long enough to do it properly.

They stop taking as much pride in the details.

They begin working around the system rather than within it.

That is not a motivation problem. It is an environment problem.

A fragmented environment trains developers to think in fragments. It nudges them towards reactive behaviour, shallow problem solving, and defensive work patterns. It teaches them that responsiveness matters more than completion and presence matters more than progress.

That is backwards.

Good engineering needs room to think.

The financial cost is only the entry fee

Steve was right to make the economic case. That is useful, because senior leaders often need a hard commercial framing before they pay attention.

But the real bill includes more than salary waste.

It includes slower delivery of valuable work.

It includes delayed learning because features reach users later.

It includes more defects because concentration is broken more often.

It includes more rework because people lose the thread and make weaker decisions.

It includes lower morale because progress feels constantly interrupted.

It includes disengagement from capable developers who are tired of being treated like a shared utility rather than thoughtful professionals.

Eventually it includes attrition, because some of your best engineers decide that spending their lives as highly-paid context-swapping machines is not actually the dream.

That is not developers being melodramatic. It is a rational response to a badly designed system.

What to do instead

The answer is not to pretend interruptions will vanish. Software teams live in the real world. Production issues happen. Collaboration matters. Reviews matter. Decisions need input. Some switching is unavoidable.

But a lot of it is completely self-inflicted.

If you want happier, more productive developers, you need to reduce fragmentation on purpose.

Cut work in progress harder than feels comfortable.

Make ALL workstreams visible — no more “Dave is just working on side project x for Brian”.

Stop spreading people across too many streams of work.

Protect real blocks of uninterrupted time rather than merely talking about focus as if it were a nice personality trait.

Treat interruptions as expensive, because they are.

Reward completion, not just responsiveness.

And pay attention when the team starts sounding mentally threadbare, because that is often an early sign that the operating model is grinding them down.

None of this is especially revolutionary. It is just inconvenient, because it forces leadership to stop pretending that keeping everyone busy is the same as getting good outcomes.

It is not.

Busy is bullshit.

A final word on Steve Trapps

It is also worth saying that Steve is not writing about this stuff from the cheap seats. He is a veteran of the software industry who started out as a software developer, later moved into Agile and Scrum practice after years of delivering complex products, and now works as a Scrum Master, Professional Scrum Trainer, coach, and consultant. Scrum.org describes him as having more than twenty years of experience across a range of sectors, and notes that he began his career in software development before moving into the world of Scrum and product delivery improvement.

That matters, because his argument about task switching lands precisely because it is practical. It does not read like theory written at a safe distance from the work. It reads like the view of someone who has seen software delivery from both sides: first as a developer trying to build things in the mess, and later as someone helping teams work in a saner, more effective way. Scrum.org links Steve directly to Scrum Facilitators, whose site describes the company as a Scrum.org partner focused on professional Scrum training, consultancy, and helping teams navigate complexity, and you can also find Steve on LinkedIn.

That is probably why his original piece lands so well. It is grounded. It is useful. And it comes from somebody who clearly understands that the cost of fragmented work is not just theoretical inefficiency, but something teams feel every day in the quality of their output, the predictability of their delivery, and frankly their general level of sanity by Thursday afternoon.

The bigger point

The deeper issue here is not simply that task switching wastes effort, though it absolutely does.

It is that it creates the illusion of progress while steadily undermining the conditions required for real progress to happen.

It leaves smart people feeling ineffective.

It makes good developers unhappy, not because they dislike hard work, but because they are denied the chance to do it properly.

It encourages motion over momentum, noise over flow, and frantic responsiveness over meaningful completion.

Then everyone acts surprised when output is poor and morale is worse.

So yes, talk about the money. Use the numbers. Use the commercial argument. Steve Trapps was right to do that.

But do not stop there. The true cost of task switching is not just the wasted salary.

It is the wasted focus, wasted satisfaction, wasted potential, and wasted capability of people who could do excellent work if we would stop chopping their days into tiny useless pieces.

And once you see that clearly, the conclusion is hard to avoid.

The goal was never to keep people busy.

The goal was always to help them be productive.

Gary Worthington is a software engineer, delivery consultant, and fractional CTO who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance