There are actually a couple of questions here.
The first is "Who do I empathise with?" And honestly the answer is almost always the employee. It doesn't matter how many mistakes they've made, and I'm sure they've made some, it's management's job to spot them early and fix them -- even if "fix" means telling his managers that they have to rescope or move the deadline.
The one exception to this is if an employee has outright lied and covered up his failure. But even then your question has all the classic hallmarks of a company with a blame culture, which only encourages people to hide the truth in the hope that they can fix problems before anyone notices. I still blame the management and culture to some extent.
Another major cultural red-flag in your question is the repeated use of delay not being an option. Delay is always AN option. Just saying that it isn't doesn't fix the problem. There may be better options, such as rescoping or a certain amount of overtime (hiring into a project running late is rarely a good idea), but we cannot ignore that delay is an option.
When you tell us that the developer set his own deadlines, is that really true, or was it a passive-aggressive "we need to release by this date, if you can't do it then we might as well fire you all now cause the project is useless to us"? (I have seen both extremes and a lot in-between, all described as developers setting their own deadlines. Usually, it's the companies that force the estimates they want that say "delay is not an option," when you fail to hit them.)
Even if he did set his own deadlines, did management understand that developers are inherently optimistic and put processes in place to identify any slippage early? Did they put processes in place to make sure that dependencies were prioritised appropriately? Did they prioritise by behaviour/functionality, so that you couldn't run into the situation where less-important functionality was complete but key functionality wasn't?
If not, these are all management failings.
All that said, the real question you're asking is "Who do I point the finger at in my one-on-one interview with upper-management?" And, unless you're very brave, you can't storm in and scream "it's all your fault, you idiots!"
If I was in your position, I would blame the team, as a unit, including the manager, his managers, the employee and yourself. Say that there is clearly something wrong with the way you're working, if one individual is running late and others aren't. You should be working as a unit to deliver a single product; what you are clearly doing is working as a group of individuals, delivering your own modules and hoping it all fits together later.
I might even talk to a few more people who clearly aren't to blame and see if we can all agree a common message that spreads blame around, rather than focussing it.
Suggest that if you were working more as a unit then, if there ARE individuals who slow down the team, that would become apparent to all very early and then upper management may have someone to fire when -- or, better, before -- things go wrong.
But (and this is the most important thing) also suggest that pointing fingers, behind-closed-doors and after-the-fact, like this is counter-productive. You all have a job to do, getting this product out of the door. Losing people, even bad managers, at this point, would only make matters worse. And wasting an hour each (more for the senior managers involved), destroying whatever cohesion the team currently has, is a crazy idea right now.
So the team should have a different meeting now, about damage limitation for this deadline (and yes, that means sacrifice and compromise from everyone), then have another meeting after the deadline about how you don't get into this mess again.
