profile

The Weekly Gist

Why Your Team Can't Focus


Helping you learn practical, straightforward methods to boost your soft skills and enhance your career as a software engineer.


Weekly Newsletter

November 3rd, 2026

Why Your Team Can't Focus

AI has made output cheap. An engineer can now take on work that used to belong to a designer, a DBA, a data analyst, or a security reviewer, and the tools make it feel reasonable to say yes to all of it.

Every one of those roles is another context to load into your head, and there's only so much room in there. That's why focus has become the scarcest thing on most engineering teams, and it runs out fastest when the person setting priorities keeps moving them.

Teams thrash when leaders change direction

In operating systems, thrashing happens when a machine spends more time swapping between tasks than doing any of them. The CPU is busy the whole time, and almost nothing gets finished.

Thrashing
A system is thrashing when the overhead of switching between work outweighs the work itself. It's a useful lens for teams, too. Read more about thrashing.

Teams thrash the same way. An engineer juggling five roles is already carrying a heavy switching cost. When their leader changes priorities every week, that cost multiplies. The work never gets enough uninterrupted attention to land, and the team can feel it. Organizational psychologist Sophie Leroy measured this effect in a 2009 study: when people switch away from a task before finishing it, part of their attention stays stuck on it, and their performance on the next task drops. She called it attention residue. More recent research on developers points the same way. A 2024 study of interruptions during software engineering work found that interruptions affected both developers' performance and their stress, and that the effect depended on how urgent the interruption was and who it came from. A priority change from your manager is about as urgent and high-pressure as interruptions get.

The effects show up quickly:

  • Engineers burn out from constant restarts, even when the total workload hasn't changed.
  • Trust erodes, because every pivot makes the next priority feel temporary.
  • Frustration builds when people can't explain why the thing they dropped last week mattered in the first place.

I learned this the hard way. When I first stepped into leadership, I managed three teams. One handled triage, working through incoming issues and a backlog of bugs. One was upgrading the framework under our server-side application. The third was building a new product inside our app. The work was connected, but each team had its own goal, and I let the priority swing between them. For a couple of weeks, bug fixes came first. Then the new feature's UI components became the most important thing. That went on for months. Everyone was working hard and almost nothing got done, and the teams felt it. They were thrashing, and I was the one causing it.

Where can AI save you time?

My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.

​

What leaders can do about it

Since I'd caused the thrashing, fixing it was on me. Three changes made the biggest difference, and all of them gave my teams something stable to point at.

Pick one priority, or you don't have one

If you have several priorities, you don't really have any. A real priority is a single thing every person on every team can connect their work to and state in their own words.

The test is simple. Ask a few people what the team's priority is. If you hear different answers, you don't have a priority yet, and people are filling the gap by guessing. This gap is common. When researchers surveyed nearly 8,000 managers across more than 250 companies, only 55% of middle managers could name even one of their company's top five priorities.

For my teams, that one thing should have been the server upgrade. Triage and the new product would still have moved, but everyone would have known which work came first when they collided, and they'd have pitched in to keep the upgrade moving. Choosing one thing means openly deprioritizing the others, which is where the second change came in.

Write the trade-off down

I started writing everything out: what each team was working on, what was competing for attention, and what we'd gain or lose with each option. Writing it down forced me to make an actual decision instead of hedging, and it gave me something concrete to share.

When I explained the trade-offs and why we chose a direction, people didn't always agree. They did understand it, and that was enough for everyone to swim in the same direction. A priority people understand holds up much better than one handed down without context. Explaining a decision only helps if it stays put long enough to matter, though, and that led to the third change.

Shrink the bet

The third change was making the focus smaller. If I tell a team our focus is rebuilding the UI in React, that's a huge chunk of work. If something goes sideways halfway through, changing course feels like whiplash, and all the half-finished work feels wasted.

Instead, I'd say something like: we're going to rebuild the whole UI eventually, and right now our focus is this one component. The long-term direction stays visible, and the team gets a target they can actually finish. When plans change, a small chunk means a small adjustment.

Two habits help it stick:

  • Absorb churn from above before it reaches the team. Not every shift in leadership's thinking needs to become a shift in the backlog.
  • When you do change direction, explain what changed and what the team should stop doing.

How to protect your focus when you're newer to the team

Leaders set the direction, but the thrashing lands on everyone, so you don't have to wait for your manager to fix it. If you're early in your career, you don't control the priorities, and pushing back on a leader can feel risky. You still have more influence than you think, and it starts with questions rather than objections.

You can run the same test a leader should. Ask a couple of teammates what the team's priority is right now. If you get different answers, the team doesn't have one yet, and that's worth raising with your manager.

When something new lands on your plate, one question does most of the work: what should I drop or pause to pick this up? It accepts the new work and puts the trade-off in front of your manager, which is often all a leader needs to notice they're scattering the team. I covered more ways to make that trade-off visible in How to Take Control of Your Workload.

It also helps to talk with your teammates. If you're all getting pulled in different directions, compare notes and raise it together. Coaching up is hard to do alone, and a shared observation lands better than an individual complaint.

Your focus becomes your team's focus

Whichever side of the priority list you're on, the pressure from the opening isn't going away. AI will keep making it easier to do more. That means the teams that win will be the ones that pick the right work and stick with it long enough to finish. That starts with the person setting the priorities. If you lead a team, whatever clarity they have starts with you.

Hit reply and tell me in one sentence: what's the last priority change that derailed your week? I read every reply.


David Ziemann

Founder of MoreThanCoders.com​
​
david@morethancoders.com​

​

Related Articles

5 Tips to Improve Your Communication

3 Easy Critical Thinking Exercises

​

Follow More Than Coders

Was this forwarded to you? Sign up here.


600 1st Ave, Ste 330 PMB 92768, Seattle, WA 98104-2246
​
You're receiving this email because you signed up for the MoreThanCoders Newsletter. If you prefer to not receive these messages anymore, feel free to unsubscribe or update your preferences.

The Weekly Gist

Learn practical, straightforward methods to boost your soft skills and enhance your career as a software engineer because you are so much more than a developer.

Share this page