From Firefighting to Flow: Lessons Learned from a Project in Crisis

Have you ever stepped into a QA or BA role midway through a project with heavy technical debt? It feels like opening a Pandora’s box: spaghetti code, brittle integrations, rework, developer burnout, and an endless blame game.

Startups often race to ship features first and deal with testing, documentation, and technical debt later — until turnover hits and the original developers are gone. Suddenly, bugs take longer to fix, releases slow down, and customer trust suffers. As someone transitioning from QA to BA, I found myself juggling defect triage, requirements, and stakeholder conversations — all while trying to make sense of a codebase I didn’t fully know.

The first challenge was simply figuring out what the system was supposed to do. With no documentation, every bug felt like an archaeological dig. Different developers had followed different coding practices, so even small fixes caused ripple effects in unrelated parts of the system. Knowledge drain made things worse: the original developers had moved on, and replacements from other projects needed time to understand the system. On top of that, I was constantly switching hats between QA and BA work in the same sprint — making it hard to focus. Stakeholders kept pressing to “ship faster,” and the new QA reminded us that they weren’t there from the start — meaning issues often landed back on me to explain, prioritize, and push through.

Finding Clarity and Momentum

We started by building a simple user flow chart that mapped every app, interface, and touchpoint. This single visual gave everyone a shared understanding before diving into code or databases. Next, each developer created a short wiki explaining logic, data flow, and edge cases for their area, then hosted walkthrough sessions. These not only sped up onboarding but also revealed hidden dependencies that needed more QA coverage.

With leadership’s support, we shifted to a phased approach: focus on the most business-critical apps first, break work into smaller deliverables, and meet weekly to stay aligned. I advocated for dedicated QA time in each sprint, ending the last-minute testing scramble. I also documented BA decisions in a shared space, reducing repeated questions, and mentored the new QA so they could take more ownership — freeing me up for bigger-picture BA work.

Lessons That Stuck

This approach changed the project completely. Instead of firefighting, we made steady progress on the right things first. Developers and QA gained confidence through walkthroughs, and weekly check-ins kept leadership aligned, avoiding last-minute escalations.
Here are the lessons I keep with me:

• Start with the big picture. A simple flowchart can save hours of confusion.
• Capture knowledge early. Document logic, data flows, and decisions before they disappear.
• Prioritize by business value. Not everything needs to be fixed at once.
• Mentor and empower others. Sharing ownership multiplies your impact.
• Make decisions visible. A single source of truth reduces noise and builds trust.

Your Turn

These lessons came from a tough but rewarding project. How have you handled stepping into a project midstream with significant technical debt? What strategies helped your team stay sane and still deliver?