The other day I was reading this Gergely tweet and I realized how true it is.

At my team at Wallbox, we follow a Scrum-inspired way of organizing our work. We plan two-week sprints, keeping our quarterly goals as primary milestones to accomplish.

Every now and then, somebody from another team or management comes with an urgent task we need to do ASAP. Most of the time, our Engineering Manager (EM) shields the team from the pressure of context-switching and debating priority. The funny thing is that most of the times an urgent request does reach the team, it could have been completely avoided with proper advance planning, as it rarely turned out to be genuinely new.

So let’s review key pillars to evaluate whether changing team focus is actually worthwhile.

Business Impact

This is key: if a request has low business impact, there is no reason to derail focus from our OKRs. But if it has high impact, it’s a different story.

For example, if a country changes a regulation that could block selling chargers there, or users cannot charge their EV due to a critical bug, these situations are genuine triggers to drop what we are doing and pivot.

Clear Requirements

We need clear, unambiguous requirements; otherwise, we’ll likely end up redoing the work before even releasing it. Without them, we shouldn’t change our focus. Gathering those requirements may require synchronizing with other teams and aligning with product stakeholders first.

Work Estimation

Even when impact and requirements are clear, the team must estimate the effort. This estimation cannot come from outside the team, since only the team itself knows the codebase and what the work entails.

Cost

Once everything is clear, leadership needs to acknowledge the opportunity cost of shifting focus. When new tasks are added, existing commitments get delayed, so stakeholders must understand the trade-offs on the team’s planned delivery.