The Night the Dashboard Went Dark
Sep 19, 2025Authored By Anand Venkitaraman
It was 11:47 p.m. on a Thursday when my phone buzzed.
The message was blunt: “The release is dead. Nothing is working.”
This wasn’t just another sprint drop. This was the flagship data analytics platform that the client had promised their board. A single dashboard that would finally unify sales, finance, and operations data into one “source of truth.” For months, this project had been positioned as the silver bullet for decision-making. The CEO herself had been promised that by Friday morning, she could walk into her office, open her laptop, and see real-time insights for the very first time.
The stakes couldn’t have been higher. Six months of development, millions invested, and reputations on the line. And now, hours before launch, every dashboard tile was blank. Data pipelines had stalled. APIs were spitting cryptic error codes. The thing we had worked so hard to bring to life looked like an empty shell.
I opened the RAID log. Risks? Documented. Dependencies? Mapped. Mitigations? Assigned. None of it mattered. The project wasn’t “at risk.” It was flatlined.
Switching from Governance Mode to Crisis Node
In those moments, the project manager in me wanted to reach for process. But the delivery manager in me knew: process wouldn’t save us. Not tonight.
I pulled together the data engineers, ETL specialists, and visualization leads into an emergency war-room call. Everyone wanted to analyze root causes and assign blame. I shut that down immediately. “Forget why for now. What’s blocking us right this second?”
That became our mantra.
We created a rolling two-hour Kanban board, built only for survival:
- Critical Blocker: what’s completely down.
- In Progress: who’s fixing it right now.
- Fixed: what’s back up and running.
No retrospectives. No ceremonies. Just brutal focus.
The Fury Hits
Of course, while we were firefighting, the steering committee was lighting up my inbox. Hourly updates. Escalations. “When will this be fixed?” calls.
Then it escalated.
The client joined a late-night bridge call, furious. Voices rose, accusations flew, and the development team was being hammered for incompetence. I could see the morale drain in real-time — shoulders slumped, cameras switched off.
I knew I had to make a choice. I stepped in. I took the brunt of the criticism, absorbed the high-decibel frustration, and shielded the engineers from the worst of it. “Hold me accountable,” I told the client. “But let the team focus on fixing this.”
It wasn’t comfortable, but it bought us breathing space. Once the venting was done and the air cleared, the tone of the call softened. We got back to work.
Managing the Noise
I also knew a 20-slide deck of logs and fixes would only bury us deeper. So I redefined communication.
We set up a live RAG board visible to all stakeholders. One page, refreshed in real-time:
- Red: Current outages (pipelines, dashboards, API feeds).
- Amber: Risks likely in the next four hours (batch runs, latency spikes).
- Green: Stabilized components (data lake ingestion, authentication).
It was uncomfortable, but it worked. Stakeholders stopped chasing us for updates. They saw the same thing we did, at the same time.
Protecting the Team
The engineers wanted to brute-force through the night: all-nighters, adrenaline, caffeine. But I’ve seen that movie before — fatigue kills quality.
So I played air traffic controller. I staggered shifts, forced handoffs, and rotated responsibilities so nobody was making critical fixes with fried neurons. Delivery management isn’t just about timelines; sometimes it’s about protecting people from themselves.
5:30 a.m. – A Dashboard With a Pulse
By dawn, we had stabilized enough pipelines for the dashboards to light up. Not the full suite, not the polished product we’d envisioned. However, the core tiles —sales and finance —were alive. The CEO could open her laptop and see data moving, not blank screens.
We reframed the release plan into a phased rollout: core dashboards now, secondary ones within 48 hours, predictive models next week. The system was no longer a promise. It was real.
When the client’s leadership walked in that morning, they didn’t see a project on fire. They saw a team in control, a plan under execution, and credibility intact. We didn’t deliver perfection. We delivered resilience. And sometimes, that’s more valuable.
What I Learned That Night
That night taught me lessons no PMBOK guide or delivery framework ever could:
- The plan is not the project. Gantt charts, RAID logs, JIRA tickets — they’re all lenses, not the reality. When things break, you need adaptability, not adherence.
- Delivery management is about resilience under pressure. Anyone can run a project when things go smoothly. The real test is when pipelines fail at midnight, or when stakeholders expect miracles at sunrise.
- Radical transparency builds trust. Hiding delays behind polished dashboards only erodes credibility. Showing the mess, but showing it with clarity and structure, earns respect.
- Protect the team, or nothing gets delivered. Burnout is the silent killer of delivery. Keeping people sharp, even in crisis, is the only way to land the plane.
- Sometimes, you have to be the shield. Taking the heat isn’t fun. But absorbing client anger so the team can keep their heads clear is leadership in its rawest form.
Final Thought
We love to tell ourselves that projects succeed because of methodology, tools, or governance frameworks. The truth? Projects succeed because, when the dashboard goes dark, someone dares to step up, take the punches, strip away the noise, and lead.
That night, the data didn’t lie. The project plan didn’t save us. The team did.
And in the end, the delivery wasn’t perfect. But it was delivered.
Contributor Bio
Anand Venkitaraman is a delivery and program manager with nearly two decades in IT, known for steering complex projects through uncertainty with resilience and empathy. He believes delivery isn’t about perfect plans, but about protecting teams, building trust, and getting value across the finish line.
