If a manager does not trust his/her employee to deliver on a feature by a given deadline (even if that is 8am tomorrow morning) then he/she is to blame. The req

If a manager does not trust his/her employee to deliver on a feature by a given deadline (even if that is 8am tomorrow morning) then he/she is to blame. The request to the programmer should not even make it to them if you don't believe that they can deliver. At that point it's a management/political decision. If by the virtue of a political decision it makes it's way to the programmer's desk then the manager should ask if they think they can honestly meet the deadline and how they should interact to aid in this deadline. Secondly, if you don't understand at least the high level concepts involved in the technologies your employees are using then you are to blame. Asking an employee to stay late to fix a problem when you yourself have not stayed late previously to further understand the technologies at hand is hypocrisy. Whether or not you are aware of it, your development team is self organizing itself around perceived ability and trust within the department. You should make sure you are a part of the team and have some approximation of the ability to determine whether or not a problem could even feasibly be accomplished by a requested deadline. Otherwise management should be playing nothing more than the role of damage control if a requested bug fix, or feature won't be ready by the requested time line. Your developers will trust you more as a manager if they perceive that you are not regularly exposing them to the risks of over promised deadlines and unreasonable expectations. Clearly I speak to the ideal and I understand that sometimes shit hits the fan with an inherited team where trust has not yet been established. Damage control is the name of the game at that point. It may be tempting to expose your developers to the risk of not delivering. But, if that does occur and consequences arise because you over promised a deadline then resentment will take hold in your subordinates. In the long term, resentment and dissent are often more poisonous than making sure a (usually arbitrary) deadline is met. Building trust with your subordinates is what you should strive for. The decision as to whether or not you stay late should hinge on whether or not the trust you have as a supervisor will be compromised. The deadline may not be met this time around, but you sure as hell want to make sure that you are armed with your developer's best estimates as to how much time future development is going to require. Contempt and resentment will often undermine this process and ensure that situations like the one at hand will remain mostly cyclical.