Effectivity has a different meaning for a manager and for a developer. As a developer you know about the task how complex it is. In case of managers sometimes you are doing something using really all your power, you think you were really fast and the management is not satisfied with your, in other cases you do something easy and the management will be really satisfied. Crazy…

The point is that as a developer one of the most important soft skills is the knowledge, how to sell your work. How to negotiate with the other how complex is what you are doing. If you are negotiating well you can make the management more satisfied even if you keep do the same work as before. It can be also useful to know how negotiate your work if you are working directly with the customer or if you are discussing with other developers.

So the goal is to show someone else, who is most of the cases not so experienced with the topic, that your task is taking a bit longer. These people often things that “you just need to add one more button, it shouldn’t be complicated”. What it means in the reality? You need to setup the environment, understand the existing code, change the frontend, change the backend, setup the communication between the frontend and the backend, test your functionality and update the documentation. Furthermore you need to take part all the meetings related to the topic. And all of this takes time, pretty long time, even if the functionality itself is not complex.

Earlier I have written about how to do an estimation. Now the topic is how to let your manager/customer understand your estimation.

If you are simple replying that “Well, to add this button will take me three and half days”, then the answer will be simple “no way, it is too much”.

First rule: always ask some time to investigate the task. It makes the feeling that you are doing a really professional estimation instead of bullshitting and of course you can also consider all circumstance which can influence your estimation.

Next rule: split your task into several subtasks (more is always better). And make an estimation for each of the subtasks.

Like:

• Setup working environment (get source code, compile it, install dependencies): 4 hours
• Read all documentation and understand the current implementation of the button functionalities: 4 hours
• Plan how to add the new button with the expected functionality: 2 hours
• Add button to the frontend following the current design: 2 hours
• Implement related functionality to the backend:4 hours
• Implement unit tests for the new functionality: 2 hours
• Connect backend and frontend: 2 hours
• Do functional level testing on multiple operation systems and fix potential bugs: 4 hours
• Code review and integration with the current code base: 2 hours
• Attend related meetings (planning, demo, review etc.): 2 hours

SUMMARY: 28 Hours

So now you showed that is takes 28 hours, which is exactly three and half working day. Most likely some of the points are a bit overestimated, like most likely integration won’t take 2 hours, but nevermind, at each task there are some unpredictable issues which takes time (not working compilation, magic bug, huge git conflict etc.), you can use the overestimated time there. Now since you have a nice detailed list noone can really tell anything against your estimation.

You need to always see the following: for most of the subtasks are used either 2 or 4 hours as estimation. It is on purpose: 2 hours is small enough, so no one starts to negotiate that “Could it be done in 75 minutes?”. No, 2 hours is short enough to be acceptable for any task. 4 hour means that it is more complicated than the 2 hour-long subtasks. Against that it is also difficult to negotiate: if the other task takes 2 hours and this one is more complicated then let it take 4 hours, which is a bit more than 2, fine. If your estimation for a subtask would be more than 4 hours split rather the subtask in multiple one. Because if you are telling that “it takes 10 hours” then it is easy to tell that “It should fit into 8 hours”. But if it is splitted into 3 clear subtask no one will argue.

It is also important: find names for the subtasks which are easy to understand also for the one who are not technically deep in the topic. It makes the feeling for the manager/customer, that he totally understands what you are doing (even if it is not true) and it makes more trust.

When you are talking about your estimations user phrases like “based on the experience from previous tasks”, “it is similar to one of my previous tasks”, “last time unit testing took also so long” etc. It makes the feeling the you are really professional and you really do what you are doing.

If the customer/manager still thinks that it takes too long you can just tell, that “yes, I see, this is current estimation, we can make it faster but leaving xy sub functionality”. So always offer a limited functionality which takes pretty clear less time for your to be implemented, but never tell that you can do the same functionality in less time, because it makes your whole estimation meaningless.

These are all my tricks I used at negotiation, I hope they are helping also for you! If you have other good strategies feel free to share them!