On dealing with deadlines and estimates

Don't let your self be pushed. Don't let your superior (CEO, CTO or whatever) come and negotiate with you a deadline. Deadlines are just wrong to begin with, and negotiate one is a very bad idea, picture the following scenario:

• Hey when you think you will have X done?
• In 2 weeks.
• 2 weeks? No way... it needs to be done by next week.
• Well....

Bad, physics can't be violated. At the very moment you just consider yielding in a work/time negotiation you are screwed and you are not being professional. You know since a feature is being started in development that that you need testing for it, some minimum acceptance test, may be some degree of integration test, also there is infrastructure management deployment, check how it integrates with the rest of the components, check with the product owner if this is what they wanted and they put it in production and hope people use it. All that is like washing your hands when you are a doctor and you treat a patience.

You know you will need the time you said to go the whole round trip. So, why in this world are you considering to yield and make yours and your team life miserable? Not just in the short therm but also in the long one. You know well that when something is poorly designed or tested it will come for you later on. Because you will forget about this, but the code base doesn't forget.

Also that sets the ground for upper management to come again in a week and ask for another impossible. So, next time some one tells you to do something in half of the time, ask immediately for double of the money... that probably helps to stop them for asking for your free time :)

Any way, you may say: «But if there are no deadlines, what there is?» The answer is simple: «Goals», you decide what you want achieve and you just work towards that until you get there. That's it... «Ok, but what about time estimations? What management will do to plan stuff?», just don't do it... make up any crazy estimates, anyway estimates are lies we tell our self and then they get us into serious trouble. If you give a crazy time for completion and you are earlier no one will get mad at you. In the end this are estimates, but keep in mind that management love to take them as promises you made them and they will made you hold to them like if they were written on stone and not as an "estimate".

«Ok, I don't set deadlines and I give crazy estimation times, but how do I plan?» For planing and deciding what to do you need to work like a scheduler, yes, the ones that computers use, for sure you know some of them... I like to use something like a "Time Budgeting Scheduler", and it works like this:

Per each goal decide what's the maximum time it is worth to complete that goal for the business given it's value.

Examples:

Goal: We need our traffic lights not to have more than just one light on at the time.
Value: It will be confusing and cause accidents if this is not working properly.
Budget: All the time in the world, this is super important for the project to work.

Goal: There should be a way to go back to main screen after changing password.
Value: Users don't get lost after changing password
Budget: 1h, users could go back to main interface by clicking "home" in the navigation bar, if it takes more than 1h to add a "Back" button or something to go back is worthless to spend time on this.

Given that any estimates we do are usually too short for the real life execution:

If your raw estimate for any of this goals is more than the time budget on them, just don't work on them. Because is throwing resources away and wasting time and money.

If your estimates is bellow or equal to the budget you set, then it worth trying. If you deplete the time budget, re-evaluate if continuing or aborting the mission right there.

This will help you to decide if a task is feasible and you can use the time budget as the estimate you give to your boss.

Wrapping up

You are in control, don't let anyone put pressure on you, be professional. Tell me about your own experiences related to this and there will be more coming soon in how to deal with prioritization.