“Can you deliver on date X, please?”
Manager: “We need [insert any software product] to be delivered on date X. Can you do it?”
The person who actually does the job: “Well…”
This is such a simple and typical conversation in today’s companies that we overlook the complexities at play here.
First, the manager is in the power position – s/he is implicitly in the position to ‘give the work’ to the employee. It means that for the employee to say “No!” becomes very difficult as it carries a lot of risks (loss of trust from the manager, fewer points in the performance review, negative feedback, being fired, etc.). Therefore, the usual strategy of an employee is to avoid answering anything that the manager would take as a decline even when it should have been a clear “No!”.
Second, from the manager’s perspective, s/he has hired a competent employee who should not only be honest about his/her response but also has a sound judgment if the particular piece of work actually can be delivered by date X. As explained in my recent post – due to the “planning fallacy”, the employee does not have an accurate way of determining if the particular piece of software development can actually be completed by date X. Well, the manager is bluntly ignoring the “planning fallacy”, – that puts the employee in a fairly uncomfortable hot seat where s/he has to promise to do something without being 100% certain s/he can do it.
Third, we can predict one thing for sure – the outcome of this situation will be unpleasant. The employee will promise to do his/her best to deliver the promised software on date X and the manager will take his/her word for that. Close to date X, the employee will admit that the software cannot be delivered in the promised shape or form and there will be some deficiencies or it will be delivered later. From the employee’s perspective – s/he did his/her best to deliver on time but it feels bad to go back and admit the failure; from the manager’s perspective – the promise has been broken. Resentment, loss of trust, and ruined reputation – are the usual outcomes.
What would an Agile solution for this look like? Check this post for the answer!
