It is Thursday evening. The feature is due on Friday. The team stays online until 11 PM, fueled by caffeine and adrenaline, hammering out code to cross the finish line. You merge the final PR, drop a celebratory GIF in Slack, and log off feeling like champions. Then Monday morning arrives. The CI pipeline is broken. Customer Support is logging bizarre edge-case bugs. The database is throwing deadlock errors. You spend the next two weeks cleaning up the mess you made on Thursday night. You didn’t actually move faster. You just borrowed velocity from the future at an exorbitant interest rate. If you are reading this, you already know chronic “crunch time” is bad. You know burnout is real. But understanding that the system is broken does not magically give you the power to fix it. The Traffic Jam Paradox Crunch does not happen because engineers type too slowly. It happens because of a failure in organizational negotiation. To negotiate effectively, you only need one concept from queuing theory: Utilization vs. Throughput. Utilization vs. Throughput Think of a highway. At 50% capacity, cars move at the speed limit. At 100% capacity, it becomes a parking lot. Engineering teams work the exact same way. If management demands 100% utilization, collaboration dies. Your finished PR sits idle for three days because your reviewer is fully booked. A team running at 100% utilization is not an engine. It is a traffic jam. The Reality of Pushing Back This is the part where most advice columns tell you to “just decline meetings” or “say no to your boss.” That is dangerous advice. If you work at an agency, a startup under massive investor pressure, or a company with a founder who rules by decree, showing up with a spreadsheet that implies the business made a bad decision is a career risk. If your environment is truly toxic, yes, you should update your resume. But what do you do for the six months it takes to find a new job? You practice Defensive Documentation. You work your 40 hours, you clearly document what features will drop, and you let the bad deadline fail. You act as a heat shield for your junior developers, telling them to log off at 5 PM. Defensive Documentation Let’s be brutally honest: this is a calculated risk. Letting a deadline fail in a toxic culture can absolutely get you performance-managed or fired, regardless of how clean your paper trail is. But burning yourself out for a system that will gladly replace you tomorrow is also a risk. You have to choose which risk you are willing to take. However, if you have a baseline level of psychological safety, a Senior Engineer has a responsibility to push back. You just have to do it correctly. Arguing with the Right Metrics Telling your manager “the team is burning out” is an emotional argument. Emotional arguments rarely win against delivery dates. But you also cannot use bad data. Trying to correlate “story points delivered” with “bugs created six months later” is statistically noisy. A smart VP or Finance partner will tear that argument apart. Instead, argue using metrics that are impossible to dismiss: Cycle Time and PR Review Lag. Cycle Time PR Review Lag When utilization hits 100%, code review is the first thing to die. Bring this specific metric to your leadership. Say: “During our last crunch push, our PR review lag went from 4 hours to 3 days. We aren’t actually shipping faster. We are just piling up undeployed inventory and increasing merge conflicts.” “During our last crunch push, our PR review lag went from 4 hours to 3 days. We aren’t actually shipping faster. We are just piling up undeployed inventory and increasing merge conflicts.” You cannot argue with a PR sitting untouched for 72 hours. It perfectly illustrates the traffic jam. When the Manager Already Said “Yes” The most common failure mode is not a villainous CEO. It is a well-meaning Engineering Manager who agreed to a bad deadline in a leadership meeting without consulting the team. Now the date is promised, and the crunch is mandated. What do you do? You cannot throw your manager under the bus in front of Product, but you can force reality into the room. You do this by negotiating scope, not time. First, you need context. Do not guess what is important. Spend 15 minutes with your Product Manager and ask one question: “If we can only ship one feature on Friday to keep the contract alive, which one is it?” “If we can only ship one feature on Friday to keep the contract alive, which one is it?” Once you know what is actually load-bearing, you approach your manager with a concrete compromise. “I know we committed to Friday. Based on the current blockages, we will miss that date unless we cut something. We can hit Friday if we drop the reporting dashboard and ship just the core pipeline. How do you want to communicate this to Product?” “I know we committed to Friday. Based on the current blockages, we will miss that date unless we cut something. We can hit Friday if we drop the reporting dashboard and ship just the core pipeline. How do you want to communicate this to Product?” You are not whining. You are giving your manager a lifeline to go back to stakeholders with a professional compromise. Your Homework This week, you are going to diagnose your team’s traffic jam. Open your team’s sprint board right now. Count the total number of tickets currently marked as “In Progress” or “In Review.” Divide that number by the number of engineers on your team. Is that number greater than 1.5? While Kanban experts will rightly tell you that WIP limits should be calibrated specifically per team, 1.5 is a solid baseline heuristic. It accounts for one active ticket per person, plus a small buffer for tickets currently blocked in review or QA. Anything higher strongly predicts context-switching and review bottlenecks. If your number is higher than 1.5, your highway is jammed. Bring this specific metric to your next 1:1. Say: “Our WIP-per-engineer is currently 2.4. We are starting a lot of things but finishing them slowly. I recommend we implement a strict WIP limit next sprint so we can clear the review backlog and actually get code merged.” “Our WIP-per-engineer is currently 2.4. We are starting a lot of things but finishing them slowly. I recommend we implement a strict WIP limit next sprint so we can clear the review backlog and actually get code merged.” Every time you bleed to save a bad deadline, you are not being a hero. You are training your organization that the deadline was reasonable. You are proving that their broken estimation process actually works. Stop masking organizational failures with your weekends. If the system is worth fixing, let the bad deadline fail, point to the traffic jam, and force the system to change.

Crunch Time Is Just Debt in Disguise

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How To Explain Code to People Who Control the Budget

10 Common Product Management Mistakes that Could be Slowing Your Progress

The Noonification: How to Dockerize And Deploy Django Applications (10/14/2023)

1:1 with Alex Roetter: Leading Engineering at Twitter

121 Stories To Learn About Management And Leadership

3 Book Recommendations For Tech Leads (And Those Aspiring To Be)

How To Explain Code to People Who Control the Budget

10 Common Product Management Mistakes that Could be Slowing Your Progress

The Noonification: How to Dockerize And Deploy Django Applications (10/14/2023)

1:1 with Alex Roetter: Leading Engineering at Twitter

121 Stories To Learn About Management And Leadership

3 Book Recommendations For Tech Leads (And Those Aspiring To Be)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps