Calm in the Chaos: Sabeesh on Crisis Leadership in Modern Tech

In conversation with Lieutenant Commander Sabeesh Harinarayanan (retd), Senior Technical Delivery Manager at the London Stock Exchange Group, on coordination, judgment, and decision-making under pressure.

When systems fail, customers see an outage. 
Executives see risk. 
Engineers see logs. 

What often goes unseen is the role that holds everything together when that moment arrives. 

Technical Delivery Managers are the firefighters of modern technology. They step in when releases stall, incidents escalate, and critical systems come under pressure. Working at the intersection of engineering, operations, compliance, and leadership, they coordinate responses, restore order, and make decisions that rarely make headlines but determine outcomes. 

In modern technology, this kind of work is increasingly recognised as crisis leadership, not just responding to incidents, but guiding teams through uncertainty with clarity and control.

In this interview, we speak with Lieutenant Commander Sabeesh Harinarayanan (retd), a Senior Technical Delivery Manager at the London Stock Exchange Group (LSEG) and former Site Reliability Engineer at JPMorgan Chase & Co.. A veteran with deep technical acumen, his experience across defence, banking, and financial markets infrastructure has shaped a calm, methodical approach to crisis leadership—where coordination, judgement, and trust matter as much as code. 

He offers a grounded view of what really happens when technology breaks—and what it takes to keep modern systems running when failure is not an option. 

When technology fails, or delivery starts slipping, where does the responsibility of a Senior Technical Delivery Manager really begin? 

Sabeesh: When something starts going wrong, the responsibility begins with making sure the team is working from the same “manual”. 

I often explain it using the example of building a Lego castle. If you don’t follow the instructions, you can still build something—but it won’t be what you intended. And you usually realise the problem much later, when fixing it becomes harder. 

A Technical Delivery Manager ensures instructions, alignment, and guardrails are in place early. If someone starts going off-track, it’s important to catch it quickly and correct course before it turns into a larger delivery issue. 

People often reduce the role to tracking progress. In reality, what are you accountable for when pressure is highest? 

Sabeesh: When things get busy, the focus shifts to keeping teams calm and centred on what matters most. Alignment on priorities becomes critical, along with ensuring governance and delivery rules are followed. Skipping these under pressure may feel faster in the moment, but it usually creates bigger problems later. 

A major part of the role is maintaining focus. When coordinating multiple teams across multiple projects, distractions and shifting priorities are constant. The responsibility lies in keeping everyone working toward the same outcome, even under pressure. 

In large, distributed teams, what does successful Agile delivery actually look like beyond ceremonies and sprint plans? 

Sabeesh: At scale, Agile needs structure. 

Teams rely on frameworks—such as SAFe and other Agile approaches—to break work into smaller, manageable sprints. Planning happens in fixed cycles, with a backlog of features carefully managed so teams don’t take on everything at once and overwhelm delivery. 

Successful Agile delivery is about planning and sequencing work systematically. It allows teams to deliver value iteratively, while maintaining control and avoiding chaos. 

How do you integrate Agile ceremonies into the delivery lifecycle so they drive outcomes rather than become routine meetings? 

Sabeesh: Ceremonies matter because they surface what blocks delivery. 

They help teams identify priorities, risks, and dependencies. A good ceremony is not just a status update. It’s a space where teams discuss issues, solve problems, plan next steps, and hold one another accountable. 

Retrospectives are especially important. After delivery, teams reflect on what worked, identify areas for improvement, and adjust how they operate. Ceremonies may evolve based on the team, but the core goal remains the same: delivering with clarity and control. 

Backlogs are rarely clean. How do you handle conflicting priorities when features, fixes, and urgent work all compete for attention? 

Sabeesh: Priorities are set based on business value, urgency, and risk. 

Close collaboration with the Product Owner and stakeholders helps align on what matters most at any given time. When urgent work emerges, reprioritisation happens transparently—reviewing what can move out rather than overloading the team. 

The focus is on making trade-offs clear and intentional, so delivery stays on track without compromising quality or trust.

When requirements change frequently, how do you still maintain predictable delivery? 

Sabeesh: Plans change all the time, and that’s normal. 

Predictability comes from quickly updating the plan and communicating those changes early, so all stakeholders understand what changed, why, and what the revised timeline looks like. 

A stable sprint scope also plays a key role. When too many tasks are added to a single sprint, predictability breaks down. Regular backlog refinement helps teams reassess priorities and understand what can realistically be delivered within the available capacity. 

RAID logs are often treated as documentation. How do you ensure they become real decision-making tools rather than passive trackers? 

Sabeesh: RAID is a practical delivery framework that helps teams proactively identify and manage anything that could affect successful delivery. It covers: 

• Risks: what might go wrong 

• Assumptions: what is believed to be true but not yet fully validated 

• Issues: What is happening right now 

• Dependencies: what relies on other teams, systems, or timelines 

Even when functionality has been tested in UAT, RAID focuses on everything beyond functional testing that can still impact delivery. UAT confirms that a product works from a business perspective, but factors such as change freezes, environment differences, production load, cross-team dependencies, access gaps, or unvalidated assumptions can still derail a release. 

By capturing risks, assumptions, issues, and dependencies early, RAID ensures these blockers are not discovered at the last minute, even when a feature has technically passed UAT. It gives teams the time and visibility needed to validate assumptions, align on dependencies, and plan for risks, resulting in smoother, more predictable delivery.

How do you forecast delivery risks early, before they turn into incidents or missed releases? 

Sabeesh: Early risk detection starts with listening closely to everyday signals. 

Daily stand-ups often surface the first indicators, unclear requirements, unresolved dependencies, or reliance on another team to deliver first. These may sound minor in isolation, but they often signal risks that can affect delivery if left unaddressed. 

Once these signals appear, the focus shifts to understanding impact. Risks are assessed against release timelines, dependencies are clarified, and conversations happen early across teams. Bringing the right people together at the right time prevents small issues from quietly growing into delivery failures. 

How do you drive accountability for risk mitigation across teams without creating fear or blame? 

Sabeesh: Accountability becomes easier when the plan is visible. 

Within RAID, risks are documented clearly, including the risk, when it was raised, who is involved, and the planned mitigation steps. While the Technical Delivery Manager remains accountable for ensuring risks are tracked and managed, delivery itself is always a shared responsibility. 

This is not a blame exercise; it’s about clarity. If a dependency is going to take months to resolve, the plan is adjusted, or alternatives are explored early. The goal is to make informed decisions early, rather than panic late. 

How do you link RAID management with release planning to protect timelines and outcomes? 

Sabeesh: RAID plays a central role in shaping release planning. 

When risks, issues, and dependencies are clearly understood, sprint scope and release timelines can be adjusted responsibly. This ensures planning reflects actual delivery conditions, rather than optimistic assumptions. Ignoring known risks and pushing ahead may appear to protect timelines in the short term, but it often leads to larger disruptions later. 

Reviewing RAID before every release brings realism into planning. It helps teams decide whether to proceed, adjust scope, or resequence work—protecting both delivery outcomes and stakeholder trust. 

Cross-team dependencies are a common failure point. How do you identify and manage them before they derail delivery? 

Sabeesh: Dependencies are best managed early, through RAID and sequencing. 

In most projects, multiple teams are involved, including authentication, database, backend, frontend, UI (user interface), API (application programming interface), and data teams. Many of these teams support multiple applications, so changes on their side can affect delivery timelines elsewhere. 

The key is to identify dependencies early, communicate clearly, and ensure they are either resolved in advance or planned around—before they turn into last-minute blockers. 

What signals tell you unresolved risks or RAID issues are about to impact a release, and how do you intervene in time? 

Sabeesh: A strong signal is consistent spillover. 

When a feature keeps slipping across sprints and releases, week after week, and new defects continue to surface, delivery confidence erodes. Teams become uncertain, timelines blur, and stress levels rise. That pattern usually indicates unresolved risks that are likely to impact the release. 

The intervention begins by restoring clarity to the system. The focus shifts to understanding what is blocking progress, reassessing scope, and realigning priorities. By surfacing the issue early and aligning teams on a clear plan, delivery can be stabilised before the risk turns into a missed release. 

During live incidents, how do you decide what must move fast, what must be escalated, and what must be paused? 

Sabeesh: Escalation is driven by impact and dependency. 

When dependent teams are unable to support delivery within the required timeline, the first step is to understand constraints. If progress still cannot be made, escalation happens with clarity—what the dependency is blocking, why it matters, and what outcome it enables. 

For larger incidents or outages, the response becomes more structured. Teams begin with an initial investigation, identify which support teams are needed, set up a technical review call, and coordinate the response. The Technical Delivery Manager’s role is to bring teams together, document each step, track progress, and ensure the right support is in place to resolve the incident effectively. 

How do you ensure retrospectives lead to genuine improvement rather than repeating the same lessons sprint after sprint? 

Sabeesh: After each sprint or release, gaps are identified and brought into retrospectives with a clear focus on improvement, not blame. 

The discussion centres on what didn’t work, why it didn’t work, and what needs to change going forward. Clear follow-up actions are defined for the next sprint, with ownership and expectations made explicit. 

When the same issues begin to repeat, it’s treated as a signal rather than a failure. Teams are reminded that this has occurred before, and execution is deliberately adjusted to prevent the same mistake from recurring. The goal is continuous improvement that translates into visible change, not just repeated discussion. 

For young engineers aspiring to delivery leadership or reliability roles, which certifications or core skills are truly worth investing in? 

Sabeesh: The starting point should be building a holistic understanding of how every team member contributes to delivery. That broader perspective helps engineers anticipate issues earlier and make better decisions as systems and teams scale. 

Certifications such as Scrum Master, PMP, CSPO, or SAFe can certainly be valuable. However, they have the greatest impact when they are connected to real delivery scenarios and applied in practice. Without that context, it’s easy to study for an exam, pass it, and gradually forget the concepts over time. 

If someone genuinely didn’t understand what a Technical Delivery Manager does, how would you explain the role in simple terms? And how do you explain it at home? 

Sabeesh: I usually describe the role as someone who keeps multiple groups grounded and guides them toward a shared goal. 

In my family, when I explain it to my eight-year-old daughter, Indira, I keep it simple. If she goes to Hamleys with a group of friends to buy one specific toy, the moment they walk in, everyone gets distracted and forgets what they came for. If she regroups them, reminds them of the target toy, and gets everyone back on track, the mission is successful. 

That’s essentially what a Technical Delivery Manager does—keeping teams focused on the objective so delivery doesn’t get lost in distractions.