Six Weeks?!

Six weeks was the runway we had to rebuild a product that had taken ten years to develop, feature by feature, config by config. The custom hardware it ran on had reached end of life, and the business needed it running on Android hardware before the old platform went dark. There was no negotiating the deadline. There was only the work.

I tried to get ahead of it. I pushed to split the architecture handoff into two pieces: the networking library that everything else depended on first, and the UI and business logic second. That way part of the team could start two weeks early on the prerequisites while we waited for the rest of the spec. It was the right call, and it bought us some time.

Then the second dump arrived. Fifty pages of detailed technical specifications, with a refinement session scheduled for the following day. Not nearly enough time for anyone to build a mental model of what they were reading, let alone turn it into a coherent set of stories. We sat in front of a whiteboard with handfuls of sticky notes, trying to figure out what our story layout should even look like. We did our best. Maybe half the work got refined. With five weeks left and pressure mounting, we had to start building somewhere — refined or not. The team lead tried to finish refinement solo while the rest of the developers started chewing through the stories that were ready.

Go! Go! Go!


When the safety net got pulled

Before the first architecture dump even landed, a decision came down from above: cancel all unnecessary meetings. Concentrate. No distractions. That included 1-on-1s.

That was the decision that hurt us the most. My 1-on-1s aren’t status meetings. They’re the primary channel through which my team members tell me what they’re struggling with, where we can set goals and work toward them, and where we can pull things back before they become a crisis. Cancelling them at the very start of the most stressful project of the year didn’t help the team concentrate. It left them without a reliable way to escalate, and left me without the insight I needed to help.

All I had was the morning scrum. And by the time something surfaced there, the runway to fix it was already short.

So when problems started happening (and the incomplete refinement made sure they did) there was very little I could do about them in time. No working agreement meant no plan for pulling things back on track. Scope doubled. Last minute requirements jumped the line. Must-fix bugs as far as the eye could see.

I stayed online with the team through weekends to keep them unblocked. I was up until 2am helping debug where I could. I negotiated with product to cut even one requirement so the rest could ship on time. We were working hard instead of working smart, and we all knew it.

The team made the deadline. Ninety-five percent complete, against all odds. They went straight into bug-fixing mode the following week, chasing must-fixes and as many nice-to-haves as they could reach. And my job became documenting everything that had gone wrong, so that it would never happen again.


What I wish we’d protected

The lesson wasn’t about balancing deadlines or managing technical complexity. It was simpler than that.

When a crisis hits, the instinct is to throw out everything that feels like overhead and just run. Cancel the meetings. Skip the process. Heads down, ship it. But the things that feel like overhead in a crisis are usually the things that were keeping the team functional. The 1-on-1s. The refinement sessions. The working agreements. The feedback loops. Strip those out and you don’t get a leaner, faster team. You get a team running in the dark, working harder instead of smarter, with no early warning system and no way to course-correct.

Honestly, I wish I’d pushed back harder on the 1-on-1 decision. I understood the pressure, and I tried to work within the constraints I was given. But those conversations were load-bearing, and losing them cost us more than the time they would have taken.

Protect your Process.