opinion

Dec 22, 20256 mins

As engineers and managers, we all have been interrupted by those unplanned, time-sensitive requests (or tasks) that arrive outside normal planning cadences. An “urgent” Slack, a last-minute requirement or an exec ask is enough to nuke your standard agile rituals. Apart from randomizing your sprint, it causes thrash for existing projects and leads to developer burnout. This is even more critical now in the AI-accelerated landscape, where overall volatility has increased with improved developer productivity. Randomizations are no longer edge cases; they are the norm.

Google’s DORA 2025 report found that “AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.” Teams that are not equipped to manage the increased volatility end up in chaos and their engineers pay the price. The fix isn’t heroics; rather, it is simple strategies that must be applied consistently and managed head-on.

Recognize the pitfalls and avoid them!

Existing team-level mechanisms like mid-sprint checkpoints provide teams the opportunity to “course correct”; however, many external randomizations arrive with an immediacy. This results in preempted work, fragmented attention and increases the delivery risk for teams. Let’s look at how some existing team practices fail:

• **We’ll cross that bridge when we get there. **I have often seen teams shoot themselves in the foot by planning to use 100% capacity in their regular planning cycles, only to scramble when they need some triage bandwidth. This leaves no runway for immediate triage when external randomizations land mid-cycle.
• **The squeaky wheel gets the grease. **Another common pitfall is that the loudest voice wins by default. Randomizations arrive through inconsistent channels like emails, chat pings, hallway conversations, etc. Sometimes I have seen that the loudest voice uses all available channels at the same time! Just because someone’s the loudest, does not mean their request is the top priority.
• **A self-fulfilling prophecy. **Treating everything as “urgent” or randomization also dilutes the concept. We must understand that backlog reshuffling (say, during team planning sessions), planned handoffs or context switches, etc., do not need teams to pivot abruptly and should not be considered as randomizations.

Here are a few ideas on how to avoid these pitfalls:

• Reserve dedicated triage bandwidth: Teams must be deliberate about randomizations. Teams should consider managing external randomizations as a swim lane with dedicated capacity. Teams that experience variable demand should reserve 5–10% of capacity as a buffer. These can be tuned monthly.
• Streamline Intake: Teams need not spend their time reconciling competing narratives across different channels; instead, they should create a single intake channel backed by a lightweight form (ex. Jira tickets). The form includes all information needed for triage, like change/feature needed, impact, affected customers and owner.
• **Determine priority: **There are several ways to determine the priority of tasks. For our team, the Eisenhower Matrix turned out to be the most effective at identifying priorities. It classifies work by urgency (time sensitivity) and importance (business/customer impact), making prioritization decisions straightforward. Items that are both urgent and important (“Do now”) are immediately scheduled, while everything else gets deferral treatment.

How can this be operationalized sustainably?

The above ideas form a baseline for how to process the randomizations as they come in. However, teams often fail to consistently follow these practices. Below ideas will help teams make this baseline repeatable and sustainable:

Make it intentional (cultural shift)

Let’s ensure we understand that randomizations are part of serving evolving business priorities; they are not noise. Teams benefit from a mindset shift where randomizations are not seen as a friction to eliminate but as signals to be handled with intent.

A few years back, our team’s monthly retrospectives found Job Satisfaction nosediving for a few months, until we identified its correlation to an increase in randomizations (and corresponding thrash). I invited an *Agile Coach *to discuss this issue, where we ultimately realized our cultural and mechanism gaps. With that mindset shift, the team was able to resolve the concerns by intentionally formalizing the randomization management flow: Intake → Triage → Prioritize → Execute (Rinse & Repeat). Where needed, promptly communicate to leadership about changes to existing commitments.

Be frugal with time (bounded execution)

Even well-triaged items can spiral into open-ended investigations and implementations that the team cannot afford. How do we manage that? Time-box it. Just a simple “we’ll execute for two days, then regroup” goes a long way in avoiding rabbit-holes.

The randomization is for the team to manage, not for an individual. Teams should plan for handoffs as a normal part of supporting randomizations. Handoffs prevent bottlenecks, reduce burnout and keep the rest of the team moving. Use of well-defined stopping points, assumptions log, reproduction steps and spike summaries are some ideas for teams to make hand-offs easier.

Escalate early

In cases where there are disagreements on priority, teams should not delay asking for leadership help. For instance, Stakeholder B came up with a higher priority ask, but Stakeholder A is not aligned with their existing task to be deprioritized. This does not mean the team needs to complete both. I have seen such delays lead to quiet stretching, slipped dates and avoidable burnout. The goal is not to push problems upward, but to enable timely decisions, so that the team works on business priorities. A formal escalation mechanism on our team reduced the % unplanned work per sprint by around 40% when we implemented it.

Instrument, review and improve

Without making it a heavy lift, teams should capture and periodically review health metrics. For our team, % unplanned work, interrupts per sprint, mean time to triage and periodic sentiment survey helped a lot. Teams should review these within their existing mechanisms (ex., sprint retrospectives) for trend analysis and adjustments.

Thankfully, a good part of this measurement and tracking can now be automated with AI agents. Teams can use a “sprint companion” that can help classify intake, compute metrics, summarize retrospectives and prompt follow-ups to keep consistent discipline.

Final thoughts

When teams treat randomizations as a managed class of work, interrupts can be handled in hours, avoiding multi-day churn! It helps transform chaos into clarity, protects delivery, reduces burnout and builds trust with stakeholders. I have seen this firsthand in our teams, and I encourage you to make it part of your playbook.

**This article is published as part of the Foundry Expert Contributor Network. **Want to join?

Contributor

Priyank Desai is a senior engineering leader, with 13-plus years of experience building and leading mission-critical applications. He currently leads the global payments processing organization at Amazon, managing teams and systems responsible for processing billions of payment transactions. His interest areas include highly scalable and secure cloud architectures, applied AI/ML and technical leadership excellence. He is passionate about supporting and growing leaders and is actively involved in coaching and mentoring. He contributes externally through participation in various conferences and committees in different roles.

The views expressed in this article are the author’s own and do not represent those of Amazon.

Contributor

Shubham S. Amilkanthwar is a staff data engineer at Crusoe, where he leads the data team and architects real-time analytics that track customer behavior and feature adoption. Previously, he drove BI strategy at Sprout and built AI-assisted revenue pipelines at Asana.

An active IEEE member, Shubham has presented on scalable streaming security log analytics at IEEE forums such as CARS, shared infrastructure as code security best practices in Cyber Defense magazine, and showcased his enterprise multi-agent platform research at CNRIA. His interests span large-scale data engineering, cloud analytics, observability pipelines and applied AI for software quality. Shubham holds an MS in computer science from the University of North Carolina at Charlotte and a BE from the University of Pune.