Writing Post-Mortems: Indian Engineers Guide

In the fast-paced world of Indian tech, where platforms like Swiggy and Paytm handle millions of transactions daily, an outage isn't just a bug—it's a headline. For engineers at TCS, Infosys, or a buzzing startup, the pressure to restore service is immense. But the real test begins after the site is back up: the systematic, blameless dissection of the incident known as a post-mortem. Far from being a punitive report, a well-crafted post-mortem is your team's most powerful tool for building resilient systems and accelerating your career.

Why Post-Mortems Are Non-Negotiable for Your Growth

In the Indian job market, where competition is fierce, demonstrating a methodical approach to problem-solving sets you apart. A post-mortem transforms a stressful incident into a documented case study of your technical and analytical skills. It shows prospective employers at companies like Flipkart or Zerodha that you prioritize system reliability and continuous learning. Beyond career growth, it’s a critical practice for reducing Mean Time To Recovery (MTTR) and preventing costly repeat incidents, directly impacting the business's bottom line and your team's sanity.

The Core Principles: Building a Blameless Culture

The single biggest hurdle in Indian engineering teams, often structured in strict hierarchies, is the fear of blame. A successful post-mortem must be blameless. The goal is to understand the sequence of events and the systemic conditions that allowed the error, not to find a scapegoat. This psychological safety encourages junior engineers to speak up and share crucial details without fear. Furthermore, the process must be action-oriented. A document that sits in a folder is useless; it must generate concrete action items that improve the system.

• Focus on Systems, Not People: Instead of "Rahul deployed faulty code," frame it as "The deployment pipeline lacked a mandatory integration test for this edge case."
• Encourage Full Participation: Ensure everyone from the DevOps engineer to the frontend developer feels their perspective is valued.
• Leadership Must Champion It: Tech leads and managers must actively participate and reinforce that the goal is learning, not punishment.

Step-by-Step: Writing Your First Post-Mortem

You've just navigated a major Sev-1 incident. The adrenaline is fading. Now, follow this structured approach to create a document that adds real value.

1. Immediate Response & Documentation: The moment the incident is declared, start a shared timeline. Use a simple doc or a dedicated tool. Every action, observation, and communication should be timestamped. This raw log is your primary source of truth.
2. Schedule the Meeting: Hold the post-mortem meeting within 48-72 hours of resolution. Memories are fresh, but emotions have cooled. Invite all key responders and stakeholders.
3. Build the Timeline Collaboratively: In the meeting, walk through the incident log together. Fill in gaps: "What were you seeing at this time?" "What was your hypothesis?" This collaborative reconstruction often reveals hidden triggers.
4. Identify Causes (Root & Contributing): Go beyond the obvious trigger. Use the "5 Whys" technique. Why did the database fail? The CPU spiked. Why? A query was unbounded. Why? A new feature missed performance testing. Why? The test suite doesn't simulate production load. You've now moved from symptom to systemic root cause.
5. Define Action Items & Owners: This is the most critical output. Each root or contributing cause must have a clear, actionable item assigned to an owner with a deadline.
   • Example: "Owner: Priya. Action: Enhance test suite to include performance regression tests for all new queries. Deadline: 2 sprints."
6. Write and Share the Document: Structure the final document clearly: Summary, Impact, Timeline, Root Cause Analysis, Action Items. Share it broadly within your organization to institutionalize the learning.

Key Sections of a Powerful Post-Mortem Document

Your document should tell a clear story to someone who wasn't there. Avoid jargon and be succinct.

• Executive Summary: A brief overview (3-5 lines) of what happened, when, the impact, and the primary cause. This is for leadership at companies like HCL or Accenture who need the high-level view.
• Impact Assessment: Quantify everything. "Service was degraded for 2 hours" is okay. "The payment API saw a 95% error rate, affecting ~50,000 transaction attempts worth an estimated ₹75 lakhs in lost GMV" is powerful. Include user impact, business metrics, and team toll.
• Detailed Timeline: A chronological list of events from the first trigger to full recovery. Use UTC or IST consistently. Include detection, escalation, diagnostic steps, and remediation attempts.
• Root Cause Analysis (RCA): The core analysis. Distinguish between the immediate trigger (e.g., a failed server) and the deeper root causes (e.g., lack of automated failover, insufficient monitoring alerts).
• Action Items: A table is ideal. Columns: Action Item Description, Type (Preventative, Detective, Corrective), Owner, Due Date, Status (Open/Closed).

Learning from the Best: Resources for Indian Engineers

You don't have to build this practice from scratch. The global and Indian tech community openly shares their post-mortems and methodologies.

• Study Public Post-Mortems: Companies like Google, Amazon AWS, and GitHub publish detailed incident reports. Analyze their structure, tone, and depth.
• Leverage Free Online Courses: Platforms like Coursera (using Financial Aid) and edX offer courses on Site Reliability Engineering (SRE) that cover post-mortems extensively. NPTEL also has courses on Software Engineering and Project Management.
• Follow Indian Tech Creators: YouTube channels like CodeWithHarry and Apna College often discuss real-world engineering practices. While not always SRE-specific, they provide context on the Indian tech ecosystem.
• Practice with Case Studies: Discuss hypothetical or past minor incidents with your peers. Walk through the 5 Whys and draft a mock action item list.

Common Pitfalls to Avoid

Even with the best intentions, teams fall into these traps. Be vigilant.

• Stopping at the Proximate Cause: Don't settle for "the server crashed." Dig into why the monitoring didn't alert you sooner, or why the auto-scaling didn't kick in.
• Vague Action Items: "Improve monitoring" is not an action item. "Add a Prometheus alert for database connection pool saturation at 80% within 2 weeks" is.
• Letting Actions Languish: The post-mortem process fails if action items are not tracked to completion. Use your project management tool (Jira, Asana) to track them like any other ticket.
• Making it a One-Person Job: The post-mortem author is a facilitator, not a sole investigator. The collective intelligence of the response team is irreplaceable.

Next Steps

Mastering the post-mortem is a career-long journey that signals maturity and operational excellence. To build the foundational technical skills that help you prevent incidents in the first place, start by exploring in-demand domains. Dive into our curated list of free Data Structures and Algorithms courses to write more efficient, less error-prone code. If you're interested in the SRE and DevOps mindset that makes post-mortems routine, browse our collection of free Cloud Computing and DevOps courses. For a broader perspective on building robust systems, check out our guides on free System Design resources to learn from the architecture of major Indian tech platforms.