We Will Get You Through It!
There is a comedy sketch from Bob & Tom that starts with a hilariously impossible promise: overnight delivery by train, from New York to Los Angeles.
At one point, someone asks if they can really get a 2,000-pound package across the country overnight by rail. The answer is delivered with absolute confidence: “Norfolk and Waypal, overnight. Absolutely. Positively.”
The name is doing some careful work. It lets you hear the phrase that nobody has actually said out loud.
No way, pal.
When I end up leading a project with six weeks left and something that feels like four months of work to do, I start the internal kickoff by telling the team to go watch that sketch. No other explanation. Just go watch it, then come back.
Then I tell them: “Absolutely, positively, we will get you through it. There's Norfolk and Waypal, we are gonna to do it.”
That does not mean we are going to do the thing exactly as it was originally promised. It means we are going to get through it. Absolutely. Positively.
There is a difference.
Laugh at the impossible first
I think newer developers especially need permission to laugh at impossible requirements.
An 800-pound gorilla from New York to Los Angeles overnight by train is impossible in a way that is easy to laugh at. A project that needs a full cloud environment, API work, a mobile application in the app stores, production deployment, security approvals, and a dozen other things in six weeks? That can feel less funny when it is sitting in your sprint board.
But it may be just as impossible if we take the requirements literally.
The first danger on a crunch project is shame. A junior developer can look at an impossible deadline and wonder if they are missing something. Maybe everyone else understands how this gets done. Maybe it is a talent problem. Maybe if they just worked harder, they could turn six weeks into twelve.
Nope.
Sometimes the work is just Norfolk and Waypal.
Humor does not solve the problem. It lowers the temperature enough that the real conversation can happen. Saying “this cannot be done as stated” is not always safe or easy, particularly when you are speaking within a real power imbalance. The joke gives the team shared language for reality without asking the least-powerful person in the room to be the first one to say the quiet part out loud.
Set limits before the project sets them for you
One of the projects I remember most clearly was a virtual medical-care application that had to launch during the Q4 healthcare open-enrollment season. I was not part of the original strategy and scoping work. My job was to lead delivery.
We had six weeks. We needed development, QA, and production environments. We needed API endpoints. We needed a mobile application published. We needed to get through internal security reviews. We needed a real production launch.
The deadline was real. It was not simply somebody failing to plan. The client had a seasonal business opportunity, and if the launch did not happen, the work would stop. That was actually a useful guard against throwing good money after bad.
It was still Norfolk and Waypal.
The first boundary I set was around hours. I believe the cap was 50 hours a week. It applied to everyone, including me. The cap held, although that does not mean the pressure went away. Testing support and bug triage still come back to developers. Things still break. Decisions still have to be made quickly.
But more hours were not going to turn six weeks into twelve. They were going to make us tired, make us less effective, and effectively pay everyone less for their time.
This is the part where I want to be careful with junior developers. “Set a boundary” can sound wonderfully simple when you have enough authority to set one. In the United States, at-will employment makes this extraordinarily gray. You may not be able to demand overtime pay. You may not be able to refuse extra hours without risking your job.
Still, be very concerned whenever you are asked to “sacrifice” for a project. That word tends to mean someone wants your time, your energy, or your health without compensating you appropriately for it. Cash is the most obvious cost. Extra vacation time can be another. The point is not that compensation buys the right to burn people out. It does not. The point is that putting a real cost on an exception exposes the tradeoff before unpaid overtime turns into an expectation.
And if an employer pushes back on a junior developer who is honestly trying to surface those tradeoffs, that is useful information. It is worth asking whether that is an environment where you can stay and build a successful career.
Find the Norfolk features
After we watched the sketch, I asked the team to find the Norfolk features.
A Norfolk feature is a feature users would not miss unless they explicitly knew it was supposed to be there.
That is not a claim that the feature is bad. It may be perfectly reasonable in the longer-term product. It is a claim about the deadline. If we spend time on it now, what work are we not doing instead?
I pushed hard for a prioritized client feature list. I did not always have a perfect cutoff where I could say, “Everything below this line is out.” But I did know what the client believed mattered most. That made it possible to show honest progress against their actual priorities at every stage.
On this project, patient billing integration was the poster child. A partner could handle the EHR side, but direct patient billing was not ready at launch. It mattered, but because claims still had to go through the usual submission and adjudication delays, it was not truly required on day one. The client wanted patient billing within 30 days. Nothing in the contract said it had to be 30 days instead of 90.
That is the kind of tradeoff I mean. Not “we will skip whatever is inconvenient.” We did not treat privacy, security, compliance, or regulatory obligations as Norfolk features. In a medical application, skipping those requirements carries legal and financial risks that are much worse than a missed feature. If we had failed the needed regulatory hurdles, we would not have launched.
The work is not about pretending every decision has a clean answer. It depends. It always depends. The work is about keeping the decision in front of everyone: is this issue truly blocking the smallest safe thing that needs to exist on day one, or is it pulling effort away from that thing?
Be ready to get through it, not just to win it
The client deserves most of credit for that successful launch. Their leadership understood the tradeoffs, prepared their stakeholders, and was willing to launch a truly narrow MVP. One of their leaders said something I still fondly remember: “If you actually like your MVP, you waited too long.”
That client partnership was honestly more important than anything I did. I also could not assume I would get this level of participation at the start. If the client had refused to narrow the scope, I was prepared for the project to fail. I communicated that to my internal leadership and to the team.
That is not a heroic story. It is the opposite of “success at all costs.” Sometimes the responsible thing is to make the risk visible instead of quietly transferring all of its cost to the people doing the work.
For me, the outcome signal is not only whether a project goes live. It is whether I want to talk to the team afterward. It is whether they want to work together again. A year later, if somebody on a completely ordinary project can joke about a Norfolk feature, I take that as a much better sign than a green status report from launch week.
Crunch is going to happen. We should try to avoid it (duh!). We should not normalize it. But when it arrives, do not immediately assume that an impossible assignment is a test of your talent or your willingness to care.
Look at the requirements. Find the thing nobody would miss. Protect your limits where you can. Ask what is being traded away. And if the project really is asking for the gorilla by rail overnight?
Absolutely. Positivly.
We are going to get through it.
There’s Norfolk and Waypal.
We are gonna do it.